Closed Bug 1433787 Opened 3 years ago Closed 3 years ago

hit-test: short hang when (un)focusing Nightly


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




Tracking Status
firefox-esr52 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 --- disabled


(Reporter: jan, Assigned: kats)


(Blocks 1 open bug, )


(Keywords: hang, nightly-community)


(1 file)

Attached video 2018-01-28_18-39-11.mp4
Nightly 60 x64 20180128100650 de_DE @ Debian Testing (KDE, Radeon RX480)
fresh profile: gfx.webrender.all, gfx.webrender.hit-test

1. open the testcase:
2. (you may zoom to 300%)
3. repeatedly click (or hold your mouse down) on Nightly, then beside it, then on Nightly again etc.
Linux only?
Assignee: nobody → bugmail
Priority: -- → P1
Flags: needinfo?(jan)
I can repro on OS X
Flags: needinfo?(jan)
Has STR: --- → yes
OS: Linux → All
Based on a profile [1] it looks like the compositor thread is stuck in FlushRendering() at [2]. This in turn because the Renderer thread in WR is busy doing lots of composites, each of which gets stuck in SwapBuffers for a vsync. The composites it's doing are presumably from a bunch of hit-tests. It's not really clear to me why we end up doing a lot of hit-tests when focusing/unfocusing the browser, and why each of those hit-tests triggers a render (it implies we're getting display list updates in between the hit-tests). But the fix I'm doing for the debug assertion failure in bug 1421380 fixes this by ensuring the Renderer thread doesn't try to composite these frames after rendering them.

Nightly 60 x64 20180130223236 de_DE @ Debian Testing (KDE, Radeon RX480).
It seems to be fixed. Thank you!
Your try build from bug 1421380 comment 16 was already good.
Thanks for verifying!
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.