Closed Bug 1701451 Opened 6 months ago Closed 4 months ago

Extreme flicker / hanging when opening history menu

Categories

(Core :: Graphics: WebRender, defect, P2)

x86_64
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox88 --- disabled
firefox89 --- wontfix

People

(Reporter: gcp, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [proton-hamburger-menu] [priority:2b])

Attachments

(3 files)

Attached video 2021-03-27_22-29-39.mkv

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.

Attached file aboutsupport.txt
Attached video 2021-03-29 12-31-24.mkv

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.

Component: Bookmarks & History → Graphics: WebRender
Product: Firefox → Core

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?

Flags: needinfo?(gpascutto)
Blocks: gfx-triage
QA Whiteboard: [qa-regression-triage]
Severity: -- → S3
Priority: -- → P3

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.

Flags: needinfo?(gpascutto)
Regressed by: 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.

Depends on: 1700101

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

Flags: needinfo?(gpascutto)

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

About 34, see video.

Flags: needinfo?(gpascutto)
Duplicate of this bug: 1697751
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1697751
Duplicate of this bug: 1701773
No longer blocks: gfx-triage

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.

Blocks: 1705085
Status: RESOLVED → REOPENED
No longer depends on: 1700101
Priority: P3 → P2
Resolution: DUPLICATE → ---
See Also: → 1616245
Duplicate of this bug: 1708029
Whiteboard: [proton-hamburger-menu]

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.

Depends on: 1709864

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.

Depends on: 1709998
Depends on: 1710335
No longer blocks: gfx-triage

:gcp, is the problem addressed on latest nightly?

Flags: needinfo?(gpascutto)
Whiteboard: [proton-hamburger-menu] → [proton-hamburger-menu] [priority:2b]

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.

Flags: needinfo?(gpascutto)

Thank you for the confirmation.

Status: REOPENED → RESOLVED
Closed: 5 months ago4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.