FullscreenControlHost: Browser Crash
Reported by
craig.fr...@gmail.com,
Jun 26 2018
|
||||||||||||||||||||||
Issue description
Chrome Version : 68.0.3440.33 (Official Build) beta (64-bit), MacOS 10.13.5
URLs (if applicable) : N/A
Other browsers tested: N/A
What steps will reproduce the problem?
(1) Open a HTTPS website, and in the console run:
navigator.keyboard.lock();
document.documentElement.webkitRequestFullscreen();
(2) Press the [esc] key multiple times, with occasional holding down for 1 second, then for the required 2 seconds.
What is the expected result?
Should exit from full screen.
What happens instead?
Browser crashed.
Please provide any additional information below. Attach a screenshot if
possible...
See attached "crash-report.txt"
,
Jun 26 2018
I was unable to repro with Canary M69.0.3473.0 Following steps above, with additional step: (1.5) Click somewhere on website to switch focus away from devtools Does this repro consistently for you? If so, can you try it with Canary to see if you have the same problem? Thanks!
,
Jun 27 2018
As per comment #2, adding label Needs-Feedback. Thanks...!!
,
Jun 27 2018
I've just done some testing on Canary 69.0.3474.0, MacOS 10.13.5. It's not repeatable every time, but out of the last 10 restarts of the browser, it crashed 6 times (3 MacOS crash reports from these have been attached). I say restarts of the browser, because it seems that if it works once, then it continues to work (as in, if it does not crash, I can keep going into and out of full screen mode as often as I like, and it's fine). In addition to these tests, if I just use `webkitRequestFullscreen` by itself, I have no issues... but as soon as I introduce the `navigator.keyboard.lock()` it starts having issues again. The point at which it does crash, the window is animating down from full screen... where it's smaller than the original window size, and semi-transparent. I've taken a before/after screenshot, to show the original window size as I've opened the browser, and the point at which it crashed. When it does not crash, the window scales down from full size, to the dimensions of the original window size, with no transparency... so it animates differently.
,
Jun 27 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
,
Jul 9
As per comment #4 forwarding this issue to Inhouse for further triaging it and adding TE-NeedsTriageFromHYD lable to it. Thanks..!
,
Jul 9
My guess from reading this is that it is related to the FullscreenControllHost UX on MacOS (which is different than the other platforms). I will see if I can repro on the Mac.
,
Jul 10
I've tried repro'ing (using the restart Chrome method) but no luck on M68/69 Mac. My assumption is that this is a timing issue as we lazily load the FullscreenControlHost instance on MacOS and perhaps that is delayed longer on Craig's machine than mine (which leads to the crash). When you experience the crash, do you see the grey circle / exit UI displayed? Or does the window exit fullscreen w/o any visual indicators?
,
Jul 10
I've attached a video, so you can compare. One thing I did notice though... I'm doing this on a laptop (MacBook Pro, 15-inch, 2016) with external displays. When I first tried to do the video, I started by disconnecting those external displays, because I thought having a smaller screen (with the dock shown) would help, but I was unable to get it to crash. I connected 1 monitor (which runs at 144dpi, the same as the built in monitor), and it started experiencing problems... which is what I used in the video. I've tried changing the arrangement (e.g. external monitor to the left or right), changing to the 2nd external monitor (which runs at 72dpi), opening Chrome on the laptops monitor (so having the external monitor attached, just not used)... and in all cases it causes it to crash most of the time. Or in other words, a second monitor needs to be attached in some way.
,
Jul 11
There is only one that had been uploaded: Uploaded Crash Report ID 2ca4e73124a6c82a (Local Crash ID: d8e734be-3c08-4209-970a-8ff4db0e2166) Crash report captured on Tuesday, 10 July 2018 at 21:04:20, uploaded on Tuesday, 10 July 2018 at 21:04:29 Where I've requested the others to be uploaded... Local Crash ID ed3479b5-1a38-40f6-97bf-6b45475d8525 Crash report captured on Tuesday, 10 July 2018 at 21:21:18 (upload requested by user, not yet uploaded) Local Crash ID 68150477-2909-4130-86e0-699935f584c0 Crash report captured on Tuesday, 10 July 2018 at 21:20:27 (upload requested by user, not yet uploaded) Local Crash ID 35c42c44-5ef8-4b22-b4f7-e2740854553a Crash report captured on Tuesday, 10 July 2018 at 21:18:17 (upload requested by user, not yet uploaded) Local Crash ID 0d520ab6-7005-4789-8a0d-fd1748a16202 Crash report captured on Tuesday, 10 July 2018 at 21:15:22 (upload requested by user, not yet uploaded) Local Crash ID b8e14c08-f950-4cc2-8101-f3b093338809 Crash report captured on Tuesday, 10 July 2018 at 21:13:48 (upload requested by user, not yet uploaded) Local Crash ID c3a40a30-d031-4d34-ae33-03b8d5f25dbc Crash report captured on Tuesday, 10 July 2018 at 21:07:00 (upload requested by user, not yet uploaded) Local Crash ID b4cd9e54-1fb4-4c4f-8b64-95f4ae9573ed Crash report captured on Tuesday, 10 July 2018 at 21:05:43 (upload requested by user, not yet uploaded)
,
Jul 11
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
,
Jul 11
Those last set have just been uploaded: - 5ff27ed9c1e605c2 - 2d6bd5d8f5901998 - b50046cc55e3c01e - 1470c18047a1af30 - 7c617de14735537d - 8f54eb35262f67ff - f92df041be42a15a
,
Jul 17
Unable to reproduce this issue on reported version 68.0.3440.33 and latest canary 69.0.3493.0 using MacBook Pro 10.13 , 15 inch with below steps. Attaching screencast for reference. 1. Navigated to https://bugs.chromium.org/p/chromium/issues/detail?id=856639 and opened dev console. 2. Typed navigator.keyboard.lock(); and document.documentElement.webkitRequestFullscreen(); in console. 3. Clicked outside devtools and pressed esc -- Observed page comes out of fullscreen and didnt see any crash. @Reporter: Please check the screencast and let us know if we miss anything. Also please check the issue on fresh profile which do not have any apps/extensions added. This would help in better triaging of the issue. Stack trace of 2ca4e73124a6c82a ================================= Thread 0 (id: 0x8df711) CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x00000000 ] MAGIC SIGNATURE THREAD Stack Quality84%Show frame trust levels 0x0000000115ffeeab (Google Chrome Framework -widget.cc:1025 ) views::Widget::CanActivate() const 0x0000000115ffe4a0 (Google Chrome Framework -widget.cc:630 ) views::Widget::Show() 0x0000000116fd38f0 (Google Chrome Framework -fullscreen_control_host.cc:233 ) FullscreenControlHost::ShowForInputEntryMethod(FullscreenControlHost::InputEntryMethod) 0x0000000114759e36 (Google Chrome Framework -callback.h:129 ) base::Timer::RunScheduledTask() 0x00000001146d2b81 (Google Chrome Framework -callback.h:99 ) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) 0x00000001146f1f93 (Google Chrome Framework -message_loop.cc:357 ) base::MessageLoop::RunTask(base::PendingTask*) 0x00000001146f270d (Google Chrome Framework -message_loop.cc:367 ) base::MessageLoop::DoDelayedWork(base::TimeTicks*) 0x00000001146f4842 (Google Chrome Framework -message_pump_mac.mm:459 ) base::MessagePumpCFRunLoopBase::RunWork() 0x00000001146e4cb9 (Google Chrome Framework + 0x022eacb9 ) base::mac::CallWithEHFrame(void () block_pointer) 0x00000001146f414e (Google Chrome Framework -message_pump_mac.mm:431 ) base::MessagePumpCFRunLoopBase::RunWorkSource(void*) 0x00007fff3808ea60 (CoreFoundation + 0x000a3a60 ) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 0x00007fff3814847b (CoreFoundation + 0x0015d47b ) __CFRunLoopDoSource0 0x00007fff380714bf (CoreFoundation + 0x000864bf ) __CFRunLoopDoSources0 0x00007fff3807093c (CoreFoundation + 0x0008593c ) __CFRunLoopRun 0x00007fff380701a2 (CoreFoundation + 0x000851a2 ) CFRunLoopRunSpecific 0x00007fff37356d95 (HIToolbox + 0x0002fd95 ) RunCurrentEventLoopInMode 0x00007fff37356a0e (HIToolbox + 0x0002fa0e ) ReceiveNextEventCommon 0x00007fff37356883 (HIToolbox + 0x0002f883 ) _BlockUntilNextEventMatchingListInModeWithFilter 0x00007fff35608a72 (AppKit + 0x00041a72 ) _DPSNextEvent 0x00007fff35d9ee33 (AppKit + 0x007d7e33 ) -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 0x000000011431883f (Google Chrome Framework -chrome_browser_application_mac.mm:233 ) __71-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke 0x00000001146e4cb9 (Google Chrome Framework + 0x022eacb9 ) base::mac::CallWithEHFrame(void () block_pointer) 0x0000000114318773 (Google Chrome Framework -chrome_browser_application_mac.mm:232 ) -[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 0x00007fff355fd884 (AppKit + 0x00036884 ) -[NSApplication run] 0x00000001146f50eb (Google Chrome Framework -message_pump_mac.mm:808 ) base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) 0x00000001146f3c6d (Google Chrome Framework -message_pump_mac.mm:184 ) base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) 0x0000000114716674 (Google Chrome Framework -run_loop.cc:102 ) <name omitted> 0x000000011431f2ca (Google Chrome Framework -chrome_browser_main.cc:2063 ) ChromeBrowserMainParts::MainMessageLoopRun(int*) 0x0000000112f24763 (Google Chrome Framework -browser_main_loop.cc:1015 ) content::BrowserMainLoop::RunMainMessageLoopParts() 0x0000000112f26d41 (Google Chrome Framework -browser_main_runner_impl.cc:169 ) content::BrowserMainRunnerImpl::Run() 0x0000000112f2121a (Google Chrome Framework -browser_main.cc:51 ) content::BrowserMain(content::MainFunctionParams const&, std::__1::unique_ptr<content::BrowserProcessSubThread, std::__1::default_delete<content::BrowserProcessSubThread> >) 0x00000001142d3455 (Google Chrome Framework -content_main_runner_impl.cc:600 ) content::ContentMainRunnerImpl::Run() 0x0000000115beedb6 (Google Chrome Framework -main.cc:459 ) service_manager::Main(service_manager::MainParams const&) 0x00000001142d2563 (Google Chrome Framework -content_main.cc:19 ) content::ContentMain(content::ContentMainParams const&) 0x00000001123fe0f2 (Google Chrome Framework -chrome_main.cc:101 ) ChromeMain 0x000000010cf2edd0 (Google Chrome Canary + 0x00000dd0 ) 0x00007fff5fe7e014 (libdyld.dylib + 0x00001014 ) start From above stack trace this issue looks similar to issue 650882 . Hence cc'ing lgrey@ from that bug. @lgrey@: Please help in triaging of this issue. Thanks!
,
Jul 17
Did you have a second monitor connected? That seems to be a significant factor, as I don't have any crashes when I was only using the laptop's monitor; as soon as a second or third monitor is attached, the crashing problem retuned. In testing again, with Chrome 69.0.3493.0, I had another crash report (4e1cff766f171675) - this happened with a clean profile, with the default apps/extensions (Google Docs Offline, and Chrome Apps Docs/Sheets/Slides)... disabling those didn't change anything (4375c9196bbf1ea2).
,
Jul 17
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
,
Aug 2
Removing Blink>Inpu as the trace in #14 shows this is in browser UI land rather than Blink.
,
Aug 7
Note: ----- 1. As per provided crash id 5ff27ed9c1e605c2, in M69 this crash is seen on only Mac 2. List of builds 69.0.3493.0 1.14% 2 69.0.3487.0 4.55% 8 69.0.3474.0 0.57% 1 68.0.3440.33 0.57% 1 64.0.3282.186 6.82% 12 64.0.3282.167 9.66% 17 64.0.3282.140 3.41% 6 64.0.3282.119 2.84% 5 63.0.3239.132 9.66% 17 3. There are no crashes observed for this magic signature since : 69.0.3493.0 craig.francis@ Could you please upgrade chrome to the latest canary and let us know if you are able to reproduce the issue
,
Aug 7
Yep, still happening on Chrome Canary 70.0.3515.0. Crash ID: fc569cd81ec0e126 Just as a reminder, it only happens when I have external monitors connected.
,
Aug 7
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
,
Aug 7
,
Aug 15
I've tried repro'ing with two monitors on my Mac but no luck so far. We should still be able to fix it w/o a repro given the stack info, we'll probably just have a lower confidence of the fix. In that case we may need the bug reporter to try the next Canary build once we have something checked in. Also of note is that I see similar crashes on other platforms. I scanned our crash reports and I see a couple on M68 for Windows (no M69/70). An example report ID is 4faf37edcd99fd33. I'm also updating the title as the issue is in the FullscreenControlHost which is used by KeyboardLock but is not required (it is used on non-MacOS platforms to exit fullscreen).
,
Aug 15
Stack from an example Windows crash (M68):
0:000> kb
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr Args to Child
00 0024edb8 6424bff6 0ba73e50 0024edf0 63fb3f74 chrome!views::Widget::CanActivate+0x3 [C:\b\c\b\win_clang\src\ui\views\widget\widget.cc @ 1019]
01 0024edc4 63fb3f74 0024edd0 00000000 00000000 chrome!FullscreenControlPopup::Show+0x52 [C:\b\c\b\win_clang\src\chrome\browser\ui\views\fullscreen_control\fullscreen_control_popup.cc @ 72]
02 0024edf0 63fb40ca 00000002 00610072 00000000 chrome!FullscreenControlHost::ShowForInputEntryMethod+0x4c [C:\b\c\b\win_clang\src\chrome\browser\ui\views\fullscreen_control\fullscreen_control_host.cc @ 241]
03 0024ee20 624b3685 0024f0c0 0024f0c0 0024ee48 chrome!FullscreenControlHost::OnMouseEvent+0x13e [C:\b\c\b\win_clang\src\chrome\browser\ui\views\fullscreen_control\fullscreen_control_host.cc @ 168]
04 0024ee30 624b35fe 0024f0c0 0024eea0 0024f0c0 chrome!ui::EventHandler::OnEvent+0x3f [C:\b\c\b\win_clang\src\ui\events\event_handler.cc @ 27]
05 0024ee48 624b354c 0ba73e50 0024f0c0 0024eea0 chrome!ui::EventDispatcher::DispatchEvent+0x2c [C:\b\c\b\win_clang\src\ui\events\event_dispatcher.cc @ 192]
06 0024ee6c 624b3382 0024eeac 0024f0c0 0024eeac chrome!ui::EventDispatcher::DispatchEventToEventHandlers+0x6c [C:\b\c\b\win_clang\src\ui\events\event_dispatcher.cc @ 170]
07 0024ee8c 624b32c0 06149b90 0024f0c0 00000000 chrome!ui::EventDispatcher::ProcessEvent+0x56 [C:\b\c\b\win_clang\src\ui\events\event_dispatcher.cc @ 128]
08 0024eec8 624b274e 0024eee2 06149b90 0024f0c0 chrome!ui::EventDispatcherDelegate::DispatchEventToTarget+0x46 [C:\b\c\b\win_clang\src\ui\events\event_dispatcher.cc @ 87]
09 0024eef4 624b16be 0024ef1c 06149b90 0024f0c0 chrome!ui::EventDispatcherDelegate::DispatchEvent+0xbe [C:\b\c\b\win_clang\src\ui\events\event_dispatcher.cc @ 58]
0a 0024ef38 633ca0e6 0024ef5e 0024f0c0 098633e4 chrome!ui::EventProcessor::OnEventFromSource+0x11a [C:\b\c\b\win_clang\src\ui\events\event_processor.cc @ 21]
0b 0024ef74 624b1590 0024ef9c 0024f0c0 00000000 chrome!ui::EventSource::SendEventToSinkFromRewriter+0x17c [C:\b\c\b\win_clang\src\ui\events\event_source.cc @ 86]
0c 0024ef8c 63773e25 0024ef9c 0024f0c0 92d5375e chrome!ui::EventSource::SendEventToSink+0x12 [C:\b\c\b\win_clang\src\ui\events\event_source.cc @ 44]
0d 0024efac 624b0e5a 0024f0c0 00000000 099f99c8 chrome!views::DesktopWindowTreeHostWin::HandleMouseEvent+0x25 [C:\b\c\b\win_clang\src\ui\views\widget\desktop_aura\desktop_window_tree_host_win.cc @ 877]
0e 0024f1b0 624b0b1f 00000200 00000000 00000555 chrome!views::HWNDMessageHandler::HandleMouseEventInternal+0x2f4 [C:\b\c\b\win_clang\src\ui\views\win\hwnd_message_handler.cc @ 2823]
0f 0024f1e0 624b0a8d 00000200 00000000 00000555 chrome!views::HWNDMessageHandler::HandleMouseMessage+0x39 [C:\b\c\b\win_clang\src\ui\views\win\hwnd_message_handler.cc @ 1000]
10 0024f218 6244b4e5 00000200 00000000 00000555 chrome!content::LegacyRenderWidgetHostHWND::OnMouseRange+0xe7 [C:\b\c\b\win_clang\src\content\browser\renderer_host\legacy_render_widget_host_win.cc @ 319]
11 0024f29c 6244b393 0005028a 00000200 00000000 chrome!content::LegacyRenderWidgetHostHWND::_ProcessWindowMessage+0x149 [C:\b\c\b\win_clang\src\content\browser\renderer_host\legacy_render_widget_host_win.h @ 84]
12 0024f2c4 6244b2b0 0005028a 00000200 00000000 chrome!content::LegacyRenderWidgetHostHWND::ProcessWindowMessage+0x21 [C:\b\c\b\win_clang\src\content\browser\renderer_host\legacy_render_widget_host_win.h @ 78]
0:000> dv
this = 0x00000000
0:000> .frame 1
01 0024edc4 63fb3f74 chrome!FullscreenControlPopup::Show+0x52 [C:\b\c\b\win_clang\src\chrome\browser\ui\views\fullscreen_control\fullscreen_control_popup.cc @ 72]
0:000> dv
this = 0x0ec3ec80
parent_bounds_in_screen = 0x0024edd0 (0, 0) x (1366, 768)
0:000> .frame 2
02 0024edf0 63fb40ca chrome!FullscreenControlHost::ShowForInputEntryMethod+0x4c [C:\b\c\b\win_clang\src\chrome\browser\ui\views\fullscreen_control\fullscreen_control_host.cc @ 241]
0:000> dv
this = 0x0ec3ec80
input_entry_method = MOUSE (0n2)
bubble = <value unavailable>
,
Aug 16
I'm reassigning this over to Yuwei to take a look since he worked on this component and the crash is not specific to KeyboardLock.
,
Nov 22
***Mass UI Triage*** Hi, Just to update: We were unable to reproduce this bug on Mac(10.13.1, 10.13.4, 10.14.2) and Windows(7,8,8.1,10) OS using Latest canary #72.0.3617.0 Hence, marking it as WontFix. If this bug still reproduces for you, please reopen or file a new issue. Thank you. |
||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||
Comment 1 by viswa.karala@chromium.org
, Jun 26 2018