Click event isn't dispatched if an element is removed from the document tree and added back before mouseup (e.g. appendChild(lastChild))
Reported by
aakru...@vt.edu,
Apr 29 2017
|
|||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. On a graphical topology in our application that employs the d3.js and sevenbridges.js libraries, when a node is clicked a slider-view panel is expected to open up (as seen in the attached video) 2. After the update to the latest version of chrome, on the click event of the node, a mouse move (drag) event is triggered and the slider-view panel does not open up. What is the expected behavior? Expected Behavior: On click of each node, a click event is triggered to open up a slider view (as seen in the video) What went wrong? The Application has a few pages where we can view/edit/click and drag nodes on a graphical topology. On click on each node, a drag event is triggered instead of a click event and hence nothing opens up (as shown in the video). This problem happens on Chrome on windows as well as the mac. Doesn't seem to be related to the windows or mac OS versions as it seems to be happening on windows 10/7 and OS X >= 10.10. Problem does not happen on IE or Firefox. Problem is not there in Chrome version 57. Did this work before? N/A Chrome version: 58.0.3029.81 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 25.0 r0 Issue is of high priority. Cisco Systems Data Center Application (DCNM) is suffering an outage as crucial pages on the tool aren't working. Cisco DCNM is used by thousands of customers in the field and all existing versions will face this problem due to the Chrome update.
,
Apr 29 2017
Broken after the latest update (58.0.3029.81). Please fix ASAP.
,
Apr 29 2017
cc'ing few people to get attention on the bug.
,
Apr 29 2017
Adding OS=Windows as this issue is also observed on Windows per bug description.
,
Apr 29 2017
Unable to roll out due to this. Need to be fixed asap!
,
Apr 29 2017
What we’re observing in our code is that the “click” event is not firing after "mousedown/mouseup" events are fired.
This behavior started taking place after Chrome was updated to version 58. Similar behavior was observed when Safari was upgraded to 10.1.
We are using D3 version 3.4.11; and "drag" (mentioned previously) is a synthetic event that starts on "mousedown" and stops on "mouseup". There is logic in D3 to check if the coordinates have shifted thus indicating a drag (via mousemove event).
We have verified that click event listener was not removed from the node. Here is the event trace we see in Chrome 58 when we click a node:
d3.v3.min.js:1115 EVENT name=mouseover
d3.v3.min.js:1115 EVENT name=mouseenter
d3.v3.min.js:1115 EVENT name=mouseout
d3.v3.min.js:1115 EVENT name=mouseover
d3.v3.min.js:1115 EVENT name=mousedown
seven-bridges.js:153 Dragging START | _onNodeDragStart() [Array(1)]
d3.v3.min.js:1115 EVENT name=mousedown
d3.v3.min.js:1115 EVENT name=mouseup
d3.v3.min.js:1117 this <g data-sb-node-id="152080" class="n9k sb-node healthscore60" transform="translate(600,750)">…</g>
d3.v3.min.js:1115 EVENT name=mouseup []
d3.v3.min.js:1117 this Window {stop: function, open: function, alert: function, confirm: function, prompt: function…}
seven-bridges.js:153 Dragging STOP | _onNodeDragEnd() <g data-sb-node-id="152080" class="n9k sb-node healthscore60" transform="translate(600,750)">…</g>
d3.v3.min.js:1115 EVENT name=transitionend
d3.v3.min.js:1115 EVENT name=mouseout
d3.v3.min.js:1115 EVENT name=mouseleave
Chrome 57:
d3.v3.min.js:1115 EVENT name=mouseenter
d3.v3.min.js:1115 EVENT name=mouseout
d3.v3.min.js:1115 EVENT name=mouseover
d3.v3.min.js:1115 EVENT name=mousedown
seven-bridges.js:153 Dragging START | _onNodeDragStart() [Array(1)]
d3.v3.min.js:1115 EVENT name=mousedown
d3.v3.min.js:1115 EVENT name=mouseup
d3.v3.min.js:1117 this <g data-sb-node-id="152080" class="n9k sb-node healthscore60" transform="translate(600,750)">…</g>
d3.v3.min.js:1115 EVENT name=mouseup []
d3.v3.min.js:1117 this Window {stop: function, open: function, alert: function, confirm: function, prompt: function…}
seven-bridges.js:153 Dragging STOP | _onNodeDragEnd() <g data-sb-node-id="152080" class="n9k sb-node healthscore60" transform="translate(600,750)">…</g>
d3.v3.min.js:1115 EVENT name=click <------ CLICK triggered
d3.v3.min.js:1115 EVENT name=transitionend
d3.v3.min.js:1115 EVENT name=mouseout
d3.v3.min.js:1115 EVENT name=mouseleave
FireFox 52:
EVENT name=mouseover d3.v3.min.js:1115:7
EVENT name=mouseenter d3.v3.min.js:1115:7
EVENT name=mouseout d3.v3.min.js:1115:7
EVENT name=mouseover d3.v3.min.js:1115:7
EVENT name=mousedown d3.v3.min.js:1115:7
Dragging START | _onNodeDragStart() Array [ Array[1] ] seven-bridges.js:153:39
EVENT name=mousedown d3.v3.min.js:1115:7
EVENT name=mouseover d3.v3.min.js:1115:7
EVENT name=mouseenter d3.v3.min.js:1115:7
EVENT name=mouseup d3.v3.min.js:1115:7
this <g data-sb-node-id="144060" class="n9k sb-node healthscore70 sb-event-drag-active" transform="translate(600,500)"> d3.v3.min.js:1117:9
EVENT name=mouseup Array [ ] d3.v3.min.js:1115:7
this Window → https://172.23.244.148/ d3.v3.min.js:1117:9
Dragging STOP | _onNodeDragEnd() <g data-sb-node-id="144060" class="n9k sb-node healthscore70 sb-event-drag-active" transform="translate(600,500)"> seven-bridges.js:153:39
EVENT name=click d3.v3.min.js:1115:7 <---- CLICK triggered
EVENT name=transitionend d3.v3.min.js:1115:7
EVENT name=mouseout d3.v3.min.js:1115:7
EVENT name=mouseover d3.v3.min.js:1115:7
EVENT name=mouseout d3.v3.min.js:1115:7
EVENT name=mouseleave
"click" is never triggered in Chrome 58.
We also observe that in Chrome 57 or below, an node element needs to be clicked twice. Once to gain focus on the element and then second to trigger the "click" event. Our default implementation requires a double-click anyways but in Chrome, it seems a single click is first needed to gain focus. This behavior is only observed in Chrome.
,
May 1 2017
Looks similar to issue : https://bugs.chromium.org/p/chromium/issues/detail?id=701965. Lopping to lfg@ for confirming.
,
May 1 2017
,
May 1 2017
Does anyone have a public reproduction URI? If we have a reproduction URI we can do a bisect and identify the change. Has anyone escalated this via Cisco's support? They may be able to give us a more detailed report.
,
May 1 2017
There are quite a few number of people seeing this issue in their app. Can anyone even outside of Cisco give us any example? I just wrote a very simple example and it just works. https://output.jsbin.com/sivubu Is everyone using the same js libraries?
,
May 1 2017
Re #21: Unrelated, this does not involve the mouse wheel or pointer lock.
,
May 1 2017
This is presumed to also happen on Chrome OS if it is happening on Windows and Mac, once we have a repro case we can verify.
,
May 1 2017
d3 examples all work fine in M58 for me... http://bl.ocks.org/couchand/6420534 https://bl.ocks.org/mbostock/ec10387f24c1fad2acac3bc11eb218a5
,
May 1 2017
We are planning a stable RC today, since we don't have a solid reproducible testcase, not blocking the release. Leaving as RBS for tracking purpose.
,
May 1 2017
,
May 1 2017
I can provide access to the DCNM setup, if someone can ping me directly? My email is kiran_nn@yahoo.com. Please can someone contact us ASAP?
,
May 1 2017
Sorry for the regression here everyone! Note that "please fix" comments are harmful to getting this fixed. If you just want to register your interest / support, simply click the star. If the bug becomes overwhelmed with "me too" comments we'll disable comments for non-chromium-contributors. What we need to make any progress on this are reproduction steps - ideally ones that can be made public for our community of developers/testers to easily use. shyamkapadia@ - in absense of a public repro, private access may be enough, thank you - somebody will reach out to you. But if anyone else can provide a link / steps to reproduce this issue please add it here! We can't investigate what we can't reproduce! Unfortunately this issue was filed too late to stop the M58 roll-out. In general we hope that some users of critical applications are using Chrome beta/dev so we can be alerted to critical issues like this before it's too late to prevent them from causing harm. At this late stage the best we're likely to be able to do is get a fix into Chrome 59 ASAP, and impacted users can switch to using dev/beta channel to pick up that fix.
,
May 1 2017
Possibly related to issue 708394 ? That was confirmed as fixed in 58.0.3029.81, but perhaps a similar underlying cause? /cc hayato@
,
May 1 2017
Per update #33, we are not blocking M58 Desktop Stable refresh release schedule for this week due to this bug.
,
May 2 2017
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.3 using chrome version 58.0.3029.81 and canary 60.0.3087.0 with the test steps provided by Shyam over email. Note::Observed the pop-up with switch details is coming with 2 clicks(double click) on node.Considered this as good behaviour. This is regression issue broken in M58. Please find the per revision bisect information as below Narrow Bisect:: ================== Good ::58.0.3006.0 -- (build revision 448862) Bad:: 58.0.3007.0 -- (build revision 449173) Change Log:: ============== https://chromium.googlesource.com/chromium/src/+log/a79a95466df9d013721167cf2f0c8ba849214207..1c12127b721f833f37b81553e19b8eb0392da651 Possible suspect:: https://codereview.chromium.org/2496133002 tkent@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Note::This issue also reproducible on today's stable build 58.0.3029.96 Thanks,
,
May 2 2017
Navid I think you need to drive the fix for this. tkent@ is OOO due to national holidays in Japan. I believe with tkent's change NodeWillBeRemoved is now called and it clears the click node... https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/MouseEventManager.cpp?l=391 We need to evaluate what other vendors do to see what happens when you insert and re-add the same node in the DOM. ie; The difference clicking "bar" in this example here is key: http://jsbin.com/gaqina/edit?html,js,console,output (FF generates a click)
,
May 2 2017
I tested with both Safari and Edge. They don't fire click event either. As per spec it seems that when the node is removed from the DOM after mousedown no further events including mouseup and click should be sent to that element. https://w3c.github.io/uievents/#example-60eb6b28 But it is not very clear what should happen if the node gets added back.
,
May 2 2017
I filed a spec issue regarding this behavior and we will follow with other browser vendors on this issue so we achieve compatibility and interoperability. https://github.com/w3c/uievents/issues/141 Note that this may take a while until we get more information from other vendors and come to a consensus. However, in the meantime I believe your code is relying on a behavior that is not interoperable across browsers and not well documented in the spec either. The code for the website was obfuscated and made it hard for me to track down where you remove and add back the node. But I was wondering if you can look into your code and see whether you can avoid removing and adding back the element.
,
May 2 2017
Unable to use certain features of my application when opened with latest Chrome update. This is totally a downer for me. I love Chrome, but am moving away from it unless this issue is resolve quickly (in the next update). As of now, my next options are IE and Mozilla are working well on their latest updates. Hope i don't get too use to those. Thank you for your time and consideration.
,
May 2 2017
I believe the cause is a repeated appendChild... http://jsbin.com/gaqina/edit?html,js,console,output
,
May 2 2017
Targeting for M59, M58 is rolled out to stable today.
,
May 3 2017
One interesting thing about the JS Bin code snippet is that if you call getEventListeners(bar), you can see the event listener listed but it is never called. I know the kinks still have to be ironed out but wanted to point this out for reference.
,
May 9 2017
tkent@ do you have any insight on the solution to this? You may want to add your opinion to this github issue as well: https://github.com/w3c/uievents/issues/141
,
May 11 2017
We shouldn't change the behavior back to the previous one because the current behavior is interoperable with Safari and Edge, and it doesn't violate the standard. We need to wait until the resolution of https://github.com/w3c/uievents/issues/141 .
,
May 11 2017
,
May 11 2017
,
May 19 2017
I'm going to add some metrics and also change in the behavior behind the flag to measure the impact.
,
May 24 2017
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/facebe17862d084a9100cebc46d126b4d1d6773b commit facebe17862d084a9100cebc46d126b4d1d6773b Author: nzolghadr <nzolghadr@chromium.org> Date: Thu May 25 23:28:08 2017 Gather UMA for click retarget due to DOM changes If the mouse down element is removed from DOM and gets added back we do not send a click event. This change adds the UMA metric to see how often this happens. Also enables sending that click event behind flag to see the effect in the wild. BUG=716694 Review-Url: https://codereview.chromium.org/2894963002 Cr-Commit-Position: refs/heads/master@{#474841} [modify] https://crrev.com/facebe17862d084a9100cebc46d126b4d1d6773b/third_party/WebKit/LayoutTests/fast/events/remove-target-in-mouseup-insertback.html [modify] https://crrev.com/facebe17862d084a9100cebc46d126b4d1d6773b/third_party/WebKit/Source/core/input/MouseEventManager.cpp [modify] https://crrev.com/facebe17862d084a9100cebc46d126b4d1d6773b/third_party/WebKit/Source/core/input/MouseEventManager.h [modify] https://crrev.com/facebe17862d084a9100cebc46d126b4d1d6773b/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5 [modify] https://crrev.com/facebe17862d084a9100cebc46d126b4d1d6773b/tools/metrics/histograms/histograms.xml
,
Aug 17 2017
Issue 755559 has been merged into this issue.
,
Oct 6 2017
Issue 772399 has been merged into this issue.
,
Dec 14 2017
,
Jan 7
Still an issue but I'm working on some related clean ups for firing click events in general.
,
Jan 7
Issue 716145 has been merged into this issue. |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by shyamkap...@gmail.com
, Apr 29 2017