Chrome locks up whole GUI when debugging a <select> change event handler
Reported by
kirke...@gmail.com,
Jan 16
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Open any page with a <select> tag that has a change event handler 2. In the developer console, set a breakpoint on the event handler 3. Use your mouse to open the <select> and choose an option What is the expected behavior? The <select> will close (showing only the selected option) and JavaScript execution will be paused in the change event handler. What went wrong? The <select> stays open. This is apparently modal, so nothing else in the GUI can respond to clicks, not even the developer tools window. The whole desktop is locked up. I have to hit <Ctrl-Alt-F1> to switch to a Linux console screen and run "killall chrome" to make my desktop work again. Did this work before? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: OpenSUSE LEAP 42.2 Flash Version: My desktop is XFCE4.
,
Jan 18
(5 days ago)
Thanks for the report. I'm unable to repro on Linux, perhaps this is specific to the OS/windowing system. Repro attempt: http://jsfiddle.net/nbecgmd0/
,
Jan 18
(4 days ago)
Thanks for the quick action. Using your unmodified jsfiddle, I was able to immediately recreate the issue. I just right-clicked on the <select> element, then clicked "Inspect", and in the Developer window I clicked "Event Listeners", "change", the "(index):33" link, and the "33" line number to set a breakpoint. Nothing unusual. Then, back in the jsfiddle sample frame I clicked on the <select> element to change "Opt 1" to "Opt 2" and everything locked up. Perhaps XFCE4 implements modal operations in an incompatible way. Its hard to say who's at fault here. For now, I'll just use Firefox for debugging <select> change handlers. |
||
►
Sign in to add a comment |
||
Comment 1 by viswa.karala@chromium.org
, Jan 16