Removing element with PointerLock crashes tab
Reported by
johan.is...@gmail.com,
Mar 30 2017
|
|||||||||
Issue description
Chrome Version : 59.0.3056.0
OS Version: OS X 10.12.4
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 10.1: FAIL
Firefox 52.0.2: OK
IE 7/8/9:
What steps will reproduce the problem?
1. requestPointerLock on element
2. remove element on mouse up
document.addEventListener('mousedown', function() {
document.getElementById('lockTo').requestPointerLock();
document.addEventListener('mouseup', function() {
document.getElementById('lockTo').remove();
console.log('Runs this then crashes');
});
});
What is the expected result?
Element removed without crash
What happens instead of that?
Tab crashes
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3056.0 Safari/537.36
,
Mar 31 2017
,
Mar 31 2017
Tested this issue on MacBook Air 10.12.4 with chrome #59.0.3056.0 Pasted the code (provided in comment #0) in the console and didn't observe any crash. Attaching the screen-shot for reference. johan.isaksson@ could you please look into it and let us know your observations. If possible please provide us sample html test case for further triage. Thank You...
,
Mar 31 2017
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 3 2017
Able to reproduce the issue on Windows-7,Mac-10.12.3 and Linux Ubuntu-14.04 using Chrome stable version 57.0.2987.133 and canary 59.0.3060.0 with the testpage provided in comment#4. This is regression issue,broken in M49. Narrow Bisect:: =============== Good::49.0.2616.0- -- (build revision 368227) Bad ::49.0.2617.0 --- (build revision 368501) After executing the per-revision bisect script , got the following CL's between good and bad build versions =============================================== https://chromium.googlesource.com/chromium/src/+log/341d2448bc927a649aedf791e64018e701386343..98e3b7bc81f60f737b02a38776fb36ec0b4b16b4 Unable to find the suspect from above CL,hence marking this as Untriaged to get more inputs from dev team. Thanks,
,
Apr 5 2017
,
Apr 11 2017
Able to reproduce this issue on Windows 10 with chrome #59.0.3068.1 chongz@ could you please look into it and update latest info. Thank You...
,
Apr 18 2017
Friendly ping to get an update on this issue. Thank you!
,
May 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/92650052047f581f5c7a400e379b24d0f2f15495 commit 92650052047f581f5c7a400e379b24d0f2f15495 Author: chongz <chongz@chromium.org> Date: Thu May 04 23:18:04 2017 [PointerLock] Add null check before dispatching click event BUG= 706802 Review-Url: https://codereview.chromium.org/2846993002 Cr-Commit-Position: refs/heads/master@{#469510} [add] https://crrev.com/92650052047f581f5c7a400e379b24d0f2f15495/third_party/WebKit/LayoutTests/external/wpt/pointerlock/pointerlock_remove_target_on_mouseup-manual.html [add] https://crrev.com/92650052047f581f5c7a400e379b24d0f2f15495/third_party/WebKit/LayoutTests/external/wpt_automation/pointerlock/pointerlock_common_input.js [add] https://crrev.com/92650052047f581f5c7a400e379b24d0f2f15495/third_party/WebKit/LayoutTests/external/wpt_automation/pointerlock/pointerlock_remove_target_on_mouseup-manual-automation.js [modify] https://crrev.com/92650052047f581f5c7a400e379b24d0f2f15495/third_party/WebKit/LayoutTests/resources/testharnessreport.js [modify] https://crrev.com/92650052047f581f5c7a400e379b24d0f2f15495/third_party/WebKit/Source/core/page/PointerLockController.cpp
,
May 4 2017
,
May 5 2017
Deprecate IO>PointerLock
,
May 11 2017
Tested this issue on Windows 7, mac 10.12.4 & Ubuntu 14.04 using chrome Dev#60.0.3095.5 as per html provided in comment#4. No crash observed when user moves down the element and element got removed as per the expected behavior.Hence adding TE Verified labels. Please find the attached screen cast for reference. Thanks..!! |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by lgrey@google.com
, Mar 30 2017