"ListPicker._handleMouseUp" run "forever" in Performance tab
Reported by
w.wierch...@gmail.com,
Apr 26 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Open page that contain <select /> element 2. Start record performance 3. Click/change select element 4. Stop record after some time 5. Watch never ending ListPicker._handleMouseUp execution on timeline What is the expected behavior? ListPicker._handleMouseUp should be "marked" as executed. What went wrong? Probably Performance tab bug or ListPicker._handleMouseUp hangs somehow (this is worst scenario). Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: 10.0 Flash Version:
,
May 9 2018
w.wierchola@ -- Thanks for reporting this issue. Could you please share the sample URL through which the issue can be reproduced. Also, please verify by updating your Chrome to latest #66.0.3359.139. And let us know your observations. Thanks in advance!
,
May 9 2018
Sample URL: https://media.cyclosport.pl/f/9a098ece548403d3693a63858c94a43e/test.html Updated to: 66.0.3359.139 (64-bit). Sample recorded on: Debian/Linux as guest.
,
May 9 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 11 2018
Able to reproduce the issue on chrome reported version 65.0.3325.181 and on latest stable# 66.0.3359.170 and latest chrome# 68.0.3426.0. As this issue is seen from introduction of "Function Call" in Devtools > performance tab from M-65 milestone, hence considering this issue as Non-Regression and marking it as untriaged. Note: Issue is not applicable to Mac. Thanks!
,
May 12 2018
,
Dec 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/825499a5b8e52b1de8b276ebaa8fc263d004a6ef commit 825499a5b8e52b1de8b276ebaa8fc263d004a6ef Author: Alexei Filippov <alph@chromium.org> Date: Mon Dec 17 20:27:05 2018 DevTools: Make sure FunctionCall trace event is closed. It turned out we cannot use probe mechanism to emit FunctionCall trace event, as the function call itself can cause LocalFrame to be detached and correspoding probe sink and InspectorTraceEvents agent gone. That led to the END part of trace event is not generated. BUG= 837244 Change-Id: Iabc031d385f27972cf010a938e1a9d4ddeeeebc0 Reviewed-on: https://chromium-review.googlesource.com/c/1374452 Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#617209} [modify] https://crrev.com/825499a5b8e52b1de8b276ebaa8fc263d004a6ef/third_party/blink/renderer/bindings/core/v8/v8_script_runner.cc [modify] https://crrev.com/825499a5b8e52b1de8b276ebaa8fc263d004a6ef/third_party/blink/renderer/core/inspector/inspector_trace_events.cc
,
Dec 17
,
Dec 18
Able to reproduce the issue on chrome reported version# 65.0.3325.181 and tried verifying the fix on chrome version# 73.0.3644.0 using Windows-10 and observations are as follows: 1) Launched chrome version# 73.0.3644.0 and navigated to URL: https://media.cyclosport.pl/f/9a098ece548403d3693a63858c94a43e/test.html 2) Opened Devtools>Performance tab, clicked on record button, clicked on drop-down and selected the values and clicked on stop 3) Clicked on 'Function Call' observed "ListPicker._handleWindowMouseMove @ (unknown)" in summary tab Note: Observed same behavior on Ubuntu 17.10 @Alexei Filippov: Please find above mentioned information and attached screencast for your reference and help in verifying the fix. Thanks!
,
Dec 18
Viswa, thank you for verifying the fix. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by krajshree@chromium.org
, Apr 27 2018