Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2245723002:
Support "once" event listener option (Closed)
|
Created:
4 years, 4 months ago by Anton Obzhirov Modified:
4 years, 3 months ago CC:
blink-reviews, blink-reviews-w3ctests_chromium.org, chromium-reviews, tfarina Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionSupport "once" event listener option
Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3
submitted by cdumez@apple.com.
BUG=615384
Committed: https://crrev.com/16d55b8e978e4ad50c858bc89f231dc568718da8
Cr-Commit-Position: refs/heads/master@{#415446}
Patch Set 1 #
Total comments: 10
Patch Set 2 : Updated after review #
Total comments: 2
Patch Set 3 : Added comment about the iterator. #
Total comments: 1
Patch Set 4 : Added forcing 'once' to be always defined." #
Messages
Total messages: 40 (13 generated)
Description was changed from ========== Support "once" event listener option Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3 submitted by cdumez@apple.com. BUG=615384 ========== to ========== Support "once" event listener option Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3 submitted by cdumez@apple.com. BUG=615384 ==========
a.obzhirov@samsung.com changed reviewers: + dtapuska@chromium.org, quanxunzhen@gmail.com, tkent@chromium.org
On 2016/08/12 17:18:42, Anton Obzhirov wrote: > mailto:a.obzhirov@samsung.com changed reviewers: > + mailto:dtapuska@chromium.org, mailto:quanxunzhen@gmail.com, mailto:tkent@chromium.org I noticed there was a new layout test added recently to blink tests written by Xidorn Quan so I've invited him as well.
On 2016/08/12 17:20:39, Anton Obzhirov wrote: > On 2016/08/12 17:18:42, Anton Obzhirov wrote: > > mailto:a.obzhirov@samsung.com changed reviewers: > > + mailto:dtapuska@chromium.org, mailto:quanxunzhen@gmail.com, > mailto:tkent@chromium.org > > I noticed there was a new layout test added recently to blink tests written by > Xidorn Quan so I've invited him as well. The test written by Xidorn Quan is third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once.html. I've written in parallel third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html since I didn't know there was a test already testing 'once' option.
https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... File third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:3: <title>EventListenerOptions.once</title> You shouldn't add a test to the imported directory but reimport the current web platform tests. See https://www.chromium.org/blink/importing-the-w3c-tests https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h:31: bool m_onceBeingRemoved; This variable is private and nobody uses it. A clear opportunity that it isn't needed. https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/events/EventTarget.cpp (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/events/EventTarget.cpp:618: if (registeredListener.onceBeingRemoved()) Is it possible to change the RegisteredListener not to be a reference but a copy on the stack in this method and call removeEventListener before you dispatch the event to the listener. That should prevent the re-entrancy problem the onceBeingRemoved is trying to fix. I just wonder if it is over complicated and could be fixed in an alternate fashion.
Most of the new tests look fine, but some of them overlaps the existing test. I guess those could be removed from this file? https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... File third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:70: }, "Event handler shouldn't be called second time if the event is dispatched from the handler if the 'once' option is true"); It seems the existing test for once already tests this. Why do we need to test it again here? https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:101: }, "'once' behavior of one listener should be unaffected by the presence of other listeners"); This test looks like something the existing test also covers.
Hi guys, thanks for review. I will remove my test since it is not supposed to be added like this anyway. May be I can extract the test case to trigger event listener while it is being removed and put it in layout tests. https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... File third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:3: <title>EventListenerOptions.once</title> On 2016/08/12 18:44:02, dtapuska wrote: > You shouldn't add a test to the imported directory but reimport the current web > platform tests. See https://www.chromium.org/blink/importing-the-w3c-tests OK, didn't know, thanks for pointing out. I guess AddEventListenerOptions-once.html was imported already so I can reuse it in this case. https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:70: }, "Event handler shouldn't be called second time if the event is dispatched from the handler if the 'once' option is true"); On 2016/08/13 03:20:41, Xidorn Quan wrote: > It seems the existing test for once already tests this. Why do we need to test > it again here? Yes, this one checks the same logic, I guess the whole test can be removed since it is not supposed to be added like this. https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:101: }, "'once' behavior of one listener should be unaffected by the presence of other listeners"); On 2016/08/13 03:20:41, Xidorn Quan wrote: > This test looks like something the existing test also covers. https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h:31: bool m_onceBeingRemoved; On 2016/08/12 18:44:02, dtapuska wrote: > This variable is private and nobody uses it. A clear opportunity that it isn't > needed. Yes, seems to be leftover. https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/events/EventTarget.cpp (right): https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/events/EventTarget.cpp:618: if (registeredListener.onceBeingRemoved()) On 2016/08/12 18:44:02, dtapuska wrote: > Is it possible to change the RegisteredListener not to be a reference but a copy > on the stack in this method and call removeEventListener before you dispatch the > event to the listener. That should prevent the re-entrancy problem the > onceBeingRemoved is trying to fix. I just wonder if it is over complicated and > could be fixed in an alternate fashion. > Hm, I will need to add new method to EventListenerVector to swap content of the RegisteredEventListener instance in the vector with the new instance on stack and then remove empty registered listener from EventListenerVector. Should be possible to do, let me try.
On 2016/08/15 22:18:01, Anton Obzhirov wrote: > Hi guys, thanks for review. I will remove my test since it is not supposed to be > added like this anyway. May be I can extract the test case to trigger event > listener while it is being removed and put it in layout tests. > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > File > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html > (right): > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:3: > <title>EventListenerOptions.once</title> > On 2016/08/12 18:44:02, dtapuska wrote: > > You shouldn't add a test to the imported directory but reimport the current > web > > platform tests. See https://www.chromium.org/blink/importing-the-w3c-tests > OK, didn't know, thanks for pointing out. I guess > AddEventListenerOptions-once.html was imported already so I can reuse it in this > case. > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:70: > }, "Event handler shouldn't be called second time if the event is dispatched > from the handler if the 'once' option is true"); > On 2016/08/13 03:20:41, Xidorn Quan wrote: > > It seems the existing test for once already tests this. Why do we need to test > > it again here? > Yes, this one checks the same logic, I guess the whole test can be removed since > it is not supposed to be added like this. > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:101: > }, "'once' behavior of one listener should be unaffected by the presence of > other listeners"); > On 2016/08/13 03:20:41, Xidorn Quan wrote: > > This test looks like something the existing test also covers. > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > File third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h > (right): > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h:31: bool > m_onceBeingRemoved; > On 2016/08/12 18:44:02, dtapuska wrote: > > This variable is private and nobody uses it. A clear opportunity that it isn't > > needed. > Yes, seems to be leftover. > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > File third_party/WebKit/Source/core/events/EventTarget.cpp (right): > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/events/EventTarget.cpp:618: if > (registeredListener.onceBeingRemoved()) > On 2016/08/12 18:44:02, dtapuska wrote: > > Is it possible to change the RegisteredListener not to be a reference but a > copy > > on the stack in this method and call removeEventListener before you dispatch > the > > event to the listener. That should prevent the re-entrancy problem the > > onceBeingRemoved is trying to fix. I just wonder if it is over complicated and > > could be fixed in an alternate fashion. > > > Hm, I will need to add new method to EventListenerVector to swap content of the > RegisteredEventListener instance in the vector with the new instance on stack > and then remove empty registered listener from EventListenerVector. Should be > possible to do, let me try. Updated the patch, plz have a look.
On 2016/08/18 14:59:50, Anton Obzhirov wrote: > On 2016/08/15 22:18:01, Anton Obzhirov wrote: > > Hi guys, thanks for review. I will remove my test since it is not supposed to > be > > added like this anyway. May be I can extract the test case to trigger event > > listener while it is being removed and put it in layout tests. > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > > File > > > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html > > (right): > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > > > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:3: > > <title>EventListenerOptions.once</title> > > On 2016/08/12 18:44:02, dtapuska wrote: > > > You shouldn't add a test to the imported directory but reimport the current > > web > > > platform tests. See https://www.chromium.org/blink/importing-the-w3c-tests > > OK, didn't know, thanks for pointing out. I guess > > AddEventListenerOptions-once.html was imported already so I can reuse it in > this > > case. > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > > > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:70: > > }, "Event handler shouldn't be called second time if the event is dispatched > > from the handler if the 'once' option is true"); > > On 2016/08/13 03:20:41, Xidorn Quan wrote: > > > It seems the existing test for once already tests this. Why do we need to > test > > > it again here? > > Yes, this one checks the same logic, I guess the whole test can be removed > since > > it is not supposed to be added like this. > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/LayoutTe... > > > third_party/WebKit/LayoutTests/imported/wpt/dom/events/AddEventListenerOptions-once2.html:101: > > }, "'once' behavior of one listener should be unaffected by the presence of > > other listeners"); > > On 2016/08/13 03:20:41, Xidorn Quan wrote: > > > This test looks like something the existing test also covers. > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > > File third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h > > (right): > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > > third_party/WebKit/Source/core/events/AddEventListenerOptionsResolved.h:31: > bool > > m_onceBeingRemoved; > > On 2016/08/12 18:44:02, dtapuska wrote: > > > This variable is private and nobody uses it. A clear opportunity that it > isn't > > > needed. > > Yes, seems to be leftover. > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > > File third_party/WebKit/Source/core/events/EventTarget.cpp (right): > > > > > https://codereview.chromium.org/2245723002/diff/1/third_party/WebKit/Source/c... > > third_party/WebKit/Source/core/events/EventTarget.cpp:618: if > > (registeredListener.onceBeingRemoved()) > > On 2016/08/12 18:44:02, dtapuska wrote: > > > Is it possible to change the RegisteredListener not to be a reference but a > > copy > > > on the stack in this method and call removeEventListener before you dispatch > > the > > > event to the listener. That should prevent the re-entrancy problem the > > > onceBeingRemoved is trying to fix. I just wonder if it is over complicated > and > > > could be fixed in an alternate fashion. > > > > > Hm, I will need to add new method to EventListenerVector to swap content of > the > > RegisteredEventListener instance in the vector with the new instance on stack > > and then remove empty registered listener from EventListenerVector. Should be > > possible to do, let me try. > > Updated the patch, plz have a look. lgtm; tkent@ please take a look.
Did you sent intent-to-ship to blink-dev? https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/events/EventTarget.cpp (right): https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/events/EventTarget.cpp:627: removeEventListener(event->type(), listener, registeredListener.capture()); Is it safe to remove a listener while iterating over |entry|?
I sent the intent to implement. Will also update the patch. https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/events/EventTarget.cpp (right): https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/events/EventTarget.cpp:627: removeEventListener(event->type(), listener, registeredListener.capture()); On 2016/08/19 02:21:15, tkent wrote: > Is it safe to remove a listener while iterating over |entry|? No, it is not, thanks for pointing out. I need to update as minimum i and size. Basically I need to do similar to what removeEventListenerInternal does with the firing iterators.
On 2016/08/19 10:41:39, Anton Obzhirov wrote: > I sent the intent to implement. Will also update the patch. > > https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/events/EventTarget.cpp (right): > > https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/events/EventTarget.cpp:627: > removeEventListener(event->type(), listener, registeredListener.capture()); > On 2016/08/19 02:21:15, tkent wrote: > > Is it safe to remove a listener while iterating over |entry|? > No, it is not, thanks for pointing out. I need to update as minimum > i and size. Basically I need to do similar to what removeEventListenerInternal > does with the firing iterators. Hi, after double check I realized that the index and size are updated when removeEventListener is called in EventTarget::removeEventListenerInternal since they are passed to the last firing event iterator. So there is no need to update them again and it should be safe.
On 2016/08/22 at 15:49:50, a.obzhirov wrote: > On 2016/08/19 10:41:39, Anton Obzhirov wrote: > > I sent the intent to implement. Will also update the patch. > > > > https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/core/events/EventTarget.cpp (right): > > > > https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... > > third_party/WebKit/Source/core/events/EventTarget.cpp:627: > > removeEventListener(event->type(), listener, registeredListener.capture()); > > On 2016/08/19 02:21:15, tkent wrote: > > > Is it safe to remove a listener while iterating over |entry|? > > No, it is not, thanks for pointing out. I need to update as minimum > > i and size. Basically I need to do similar to what removeEventListenerInternal > > does with the firing iterators. > > Hi, after double check I realized that the index and size are updated when removeEventListener is called > in EventTarget::removeEventListenerInternal > since they are passed to the last firing event iterator. > So there is no need to update them again and it should be safe. I had expected this to be safe; because the code deals with re-entry into the structure if the event listener ends up calling removeListener DOM API. So I was surprised when you initially said that you required a subsequent change. So thanks for double checking.
The intent-to-ship was approved. LGTM.
On 2016/08/22 15:56:57, dtapuska wrote: > On 2016/08/22 at 15:49:50, a.obzhirov wrote: > > On 2016/08/19 10:41:39, Anton Obzhirov wrote: > > > I sent the intent to implement. Will also update the patch. > > > > > > > https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... > > > File third_party/WebKit/Source/core/events/EventTarget.cpp (right): > > > > > > > https://codereview.chromium.org/2245723002/diff/20001/third_party/WebKit/Sour... > > > third_party/WebKit/Source/core/events/EventTarget.cpp:627: > > > removeEventListener(event->type(), listener, registeredListener.capture()); > > > On 2016/08/19 02:21:15, tkent wrote: > > > > Is it safe to remove a listener while iterating over |entry|? > > > No, it is not, thanks for pointing out. I need to update as minimum > > > i and size. Basically I need to do similar to what > removeEventListenerInternal > > > does with the firing iterators. > > > > Hi, after double check I realized that the index and size are updated when > removeEventListener is called > > in EventTarget::removeEventListenerInternal > > since they are passed to the last firing event iterator. > > So there is no need to update them again and it should be safe. > > I had expected this to be safe; because the code deals with re-entry into the > structure if the event listener ends up calling removeListener DOM API. So I was > surprised when you initially said that you required a subsequent change. So > thanks for double checking. sorry for extra noise.
The CQ bit was checked by a.obzhirov@samsung.com
The patchset sent to the CQ was uploaded after l-g-t-m from dtapuska@chromium.org Link to the patchset: https://codereview.chromium.org/2245723002/#ps40001 (title: "Added comment about the iterator.")
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: linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
On 2016/08/23 09:31:03, commit-bot: I haz the power wrote: > Try jobs failed on following builders: > linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux > (JOB_FAILED, > http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) I'll check the failures, may be because of the change timing changed or something else.
https://codereview.chromium.org/2245723002/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/events/AddEventListenerOptions.idl (right): https://codereview.chromium.org/2245723002/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/events/AddEventListenerOptions.idl:9: boolean once; This should likely be: boolean once = false; I wonder if that is causing you the issues because once is undefined sometimes.
On 2016/08/24 17:24:57, dtapuska wrote: > https://codereview.chromium.org/2245723002/diff/40001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/events/AddEventListenerOptions.idl (right): > > https://codereview.chromium.org/2245723002/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/events/AddEventListenerOptions.idl:9: boolean > once; > This should likely be: boolean once = false; > > I wonder if that is causing you the issues because once is undefined sometimes. Thanks for the tip, it seems to be the case. Tried few failing tests here and it fixed the crash. Will try the bot now.
The CQ bit was checked by a.obzhirov@samsung.com
The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org, dtapuska@chromium.org Link to the patchset: https://codereview.chromium.org/2245723002/#ps60001 (title: "Added forcing 'once' to be always defined."")
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_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
On 2016/08/25 16:29:53, commit-bot: I haz the power wrote: > Try jobs failed on following builders: > win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED, > http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...) Just checked failing tests, they pass on Linux and shouldn't be affected by the change in any case.
The CQ bit was checked by dtapuska@chromium.org
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_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
On 2016/08/26 17:47:40, commit-bot: I haz the power wrote: > Try jobs failed on following builders: > win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED, > http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...) It seems like every time it was failing differently. I can try to get build on Windows to reproduce, looks quite random.
The CQ bit was checked by dtapuska@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.
Description was changed from ========== Support "once" event listener option Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3 submitted by cdumez@apple.com. BUG=615384 ========== to ========== Support "once" event listener option Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3 submitted by cdumez@apple.com. BUG=615384 ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001)
Message was sent while issue was closed.
Description was changed from ========== Support "once" event listener option Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3 submitted by cdumez@apple.com. BUG=615384 ========== to ========== Support "once" event listener option Based partially on WebKit patch 18bb5a9195ffb934a2678a8b8805411443b552a3 submitted by cdumez@apple.com. BUG=615384 Committed: https://crrev.com/16d55b8e978e4ad50c858bc89f231dc568718da8 Cr-Commit-Position: refs/heads/master@{#415446} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/16d55b8e978e4ad50c858bc89f231dc568718da8 Cr-Commit-Position: refs/heads/master@{#415446} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
