Closed Bug 1701451 Opened 3 years ago Closed 3 years 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
Has Regression Range: --- → yes

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)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
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
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: 3 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: