Current Nightly, Windows 10 (latest updates)

Description: NVIDIA GeForce GTX 1070
Vendor ID: 0x10de
Device ID: 0x1b81
Driver Version: 27.21.14.6192
Driver Date: 3-10-2021

Going to Menu->Library->History

Opening the menu either

1. Hangs the entire browser UI. Nothing is clickable any more, requires killing via task manager.
2. Causes extreme flicker.

Movie attached.

This is a movie of the "hang".

I can reproduce this with "synced tabs" too so it's specific to how those kind of menus get drawn. Not sure whether to move under gfx or win32 widget.

I can reproduce this with software WebRender, though in that case tab titles remain clickable when it "hangs".

It does NOT reproduce without WebRender using classic Direct3D11 compositing.

It looks like the hangs eventually recover after a long wait, and I managed to profile one: https://share.firefox.dev/3ddFd7T

Can you get a regression window?

Possibly relevant: there are flickering issues that appear when the native compositor is not in use, see Lee's comment https://bugzilla.mozilla.org/show_bug.cgi?id=1680128#c17.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a0f0682883e1db93f88a6ed4b87ee79bf2d22d31&tochange=3165f2868244961dff5db5903d24b1d53733a602

I start crashing on startup at this range, but it seems pretty obvious that the breakage is due to bug 1697040.

This is basically a dupe of bug 1700101 but with the entire browser locking up as additional fallout.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #9)

This is basically a dupe of bug 1700101 but with the entire browser locking up as additional fallout.

Can you confirm by flipping 'gfx.webrender.software.unaccelerated-widget.allow'?

Yes, tried that, and I didn't manage to produce any failures.

Hey Gcp, about how many entries do you have in your history drop down?

Hey Gcp, about how many entries do you have in your history drop down?

About 34, see video.

I can easily reproduce this on my Windows 10 desktop (NVIDIA Geforce 1080 Ti, 144Hz monitor) by clicking either history or bookmarks panel arrow from the library drop-down menu. This issue is very likely the root cause of bug 1705085.

Hang seemed to happen by flood of nsWindow::OnPaint(). And WM_PAINT message seemed to be triggered by nsWindow::Invalidate().

nsWindow::Invalidate() was called from nsWindow::Resize().

Call stack was like the following.

nsWindow::Resize()
nsBaseWidget::ResizeClient()
nsView::DoResetWidgetBounds()
nsView::ResetWidgetBounds()
nsViewManager::ProcessPendingUpdatesForView()
nsViewManager::ProcessPendingUpdates()
nsViewManager::WillPaintWindow()
nsView::WillPaintWindow()
nsWindow::OnPaint()
nsWindow::ProcessMessage()
nsWindow::WindowProcInternal()
CallWindowProcCrashProtected()
nsWindow::WindowProc()

When the hang happened, widget->ResizeClient() was always called in nsView::DoResetWidgetBounds(), since nsWindow::Resize() did not update widget size.

argument of nsWindow::Resize() was (447.0, -912.0), but it was adjusted to (447, 12) by ConstrainSize(&width, &height). And window size was not updated as expected.

Created Bug 1709864 for comment 20.

I looked into more. nsWindow::Resize() was not root cause of the hang(nsWindow::OnPaint() flood).nsWindow::Resize() caused the problem because, argument aHeight became negative value. It happened by size mismatch between GetClientBounds() and mBounds in nsBaseWidget::ResizeClient().

The size mismatch was caused by UpdateLayeredWindow() call in PresentableSharedImage::PresentToWindow(). When window size was changed, old window size could be applied via size of mSharedImage. The old size was applied as window size.

:gcp, is the problem addressed on latest nightly?

I don't see this any more, but Proton completely changed the layout of the History menu, including reducing the amount of entries, so it's actually pretty hard to verify.

Thank you for the confirmation.