Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2143353003:
FileReader shouldn't mark itself as inactive before firing events (Closed)
|
Created:
4 years, 5 months ago by jochen (gone - plz use gerrit) Modified:
4 years, 5 months ago Reviewers:
haraken CC:
chromium-reviews, blink-reviews, kinuko+fileapi, nhiroki, tzik Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionFileReader shouldn't mark itself as inactive before firing events
BUG=626736
R=haraken@chromium.org
Committed: https://crrev.com/b4fd7ed776b57dd923cdb8bd43e0c43edc11d3f9
Cr-Commit-Position: refs/heads/master@{#405118}
Patch Set 1 #
Total comments: 1
Patch Set 2 : comment #
Messages
Total messages: 19 (5 generated)
Hmm. As you mentioned in the bug, this will keep FileReader alive but won't keep the event listener alive, no?
On 2016/07/13 07:57:40, haraken wrote: > Hmm. As you mentioned in the bug, this will keep FileReader alive but won't keep > the event listener alive, no? Ah, found your comment in the bug.
On 2016/07/13 at 07:57:40, haraken wrote: > Hmm. As you mentioned in the bug, this will keep FileReader alive but won't keep the event listener alive, no? Send you a separate CL for this. in blob-workshop, we use reader.onloadend = function() ... in that case, the reader itself has a JS reference to the listener, so the issue that makes blob-workshop fail is that reader dies too early.
LGTM Do you think this issue is limited to FileReader? Or is it a more general issue for other DOM objects that dispatch events? https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/fileapi/FileReader.cpp (right): https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/fileapi/FileReader.cpp:436: TemporaryChange<bool> firingEvents(m_stillFiringEvents, true); Can we move these TemporalChange<>s into fireEvent()?
On 2016/07/13 at 08:04:33, haraken wrote: > LGTM > > Do you think this issue is limited to FileReader? Or is it a more general issue for other DOM objects that dispatch events? I'd bet that 50% or more of our active dom objects don't get their lifetime right. > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > File third_party/WebKit/Source/core/fileapi/FileReader.cpp (right): > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/fileapi/FileReader.cpp:436: TemporaryChange<bool> firingEvents(m_stillFiringEvents, true); > > Can we move these TemporalChange<>s into fireEvent()? that's more brittle, however, as there might be other JS execution between changing m_state and firing event listeners
On 2016/07/13 08:33:23, jochen wrote: > On 2016/07/13 at 08:04:33, haraken wrote: > > LGTM > > > > Do you think this issue is limited to FileReader? Or is it a more general > issue for other DOM objects that dispatch events? > > I'd bet that 50% or more of our active dom objects don't get their lifetime > right. > > > > > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > > File third_party/WebKit/Source/core/fileapi/FileReader.cpp (right): > > > > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > > third_party/WebKit/Source/core/fileapi/FileReader.cpp:436: > TemporaryChange<bool> firingEvents(m_stillFiringEvents, true); > > > > Can we move these TemporalChange<>s into fireEvent()? > > that's more brittle, however, as there might be other JS execution between > changing m_state and firing event listeners Yeah, let's add a TODO at the moment. I think we need a more generic fix to this problem (e.g., keep alive wrappers of on-stack DOM objects; although I don't think that's a nice fix).
On 2016/07/13 at 08:40:19, haraken wrote: > On 2016/07/13 08:33:23, jochen wrote: > > On 2016/07/13 at 08:04:33, haraken wrote: > > > LGTM > > > > > > Do you think this issue is limited to FileReader? Or is it a more general > > issue for other DOM objects that dispatch events? > > > > I'd bet that 50% or more of our active dom objects don't get their lifetime > > right. > > > > > > > > > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > > > File third_party/WebKit/Source/core/fileapi/FileReader.cpp (right): > > > > > > > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > > > third_party/WebKit/Source/core/fileapi/FileReader.cpp:436: > > TemporaryChange<bool> firingEvents(m_stillFiringEvents, true); > > > > > > Can we move these TemporalChange<>s into fireEvent()? > > > > that's more brittle, however, as there might be other JS execution between > > changing m_state and firing event listeners > > Yeah, let's add a TODO at the moment. I think we need a more generic fix to this problem (e.g., keep alive wrappers of on-stack DOM objects; although I don't think that's a nice fix). where should we add the TODO?
On 2016/07/13 09:10:37, jochen wrote: > On 2016/07/13 at 08:40:19, haraken wrote: > > On 2016/07/13 08:33:23, jochen wrote: > > > On 2016/07/13 at 08:04:33, haraken wrote: > > > > LGTM > > > > > > > > Do you think this issue is limited to FileReader? Or is it a more general > > > issue for other DOM objects that dispatch events? > > > > > > I'd bet that 50% or more of our active dom objects don't get their lifetime > > > right. > > > > > > > > > > > > > > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > > > > File third_party/WebKit/Source/core/fileapi/FileReader.cpp (right): > > > > > > > > > > > > https://codereview.chromium.org/2143353003/diff/1/third_party/WebKit/Source/c... > > > > third_party/WebKit/Source/core/fileapi/FileReader.cpp:436: > > > TemporaryChange<bool> firingEvents(m_stillFiringEvents, true); > > > > > > > > Can we move these TemporalChange<>s into fireEvent()? > > > > > > that's more brittle, however, as there might be other JS execution between > > > changing m_state and firing event listeners > > > > Yeah, let's add a TODO at the moment. I think we need a more generic fix to > this problem (e.g., keep alive wrappers of on-stack DOM objects; although I > don't think that's a nice fix). > > where should we add the TODO? Around the TemporalChange so that we should consider a way to remove the hack? It'd be anyway a good thing to explain why we need the TemporalChange.
The CQ bit was checked by jochen@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org Link to the patchset: https://codereview.chromium.org/2143353003/#ps20001 (title: "comment")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
The CQ bit was checked by jochen@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Description was changed from ========== FileReader shouldn't mark itself as inactive before firing events BUG=626736 R=haraken@chromium.org ========== to ========== FileReader shouldn't mark itself as inactive before firing events BUG=626736 R=haraken@chromium.org Committed: https://crrev.com/b4fd7ed776b57dd923cdb8bd43e0c43edc11d3f9 Cr-Commit-Position: refs/heads/master@{#405118} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/b4fd7ed776b57dd923cdb8bd43e0c43edc11d3f9 Cr-Commit-Position: refs/heads/master@{#405118} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
