1634047 - Context menu highlight is delayed (with non-compositing window manager)

Status: RESOLVED FIXED

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

Description

[Darkspirit]

Attachment: 2020-04-29_16-04-51.mp4

KDE (with disabled compositor), X11, Debian Testing
Screencast: mozregression --launch 2020-04-28 --pref gfx.webrender.all:true

mozregression --good 2020-04-15 --bad 2020-04-28 --pref gfx.webrender.all:true

5:25.37 INFO: Last good revision: 6cb8c11ef22f099c038051cda297a40308729954
5:25.37 INFO: First bad revision: 2c0b3fa9021bb11f3caa225b9f1cdaebc6024a32
5:25.37 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6cb8c11ef22f099c038051cda297a40308729954&tochange=2c0b3fa9021bb11f3caa225b9f1cdaebc6024a32

2c0b3fa9021bb11f3caa225b9f1cdaebc6024a32 Tim Nguyen — Bug 1625720 - Scope popup.css to menupopup and panel custom elements. r=dao

This regression introduced the behavior of bug 1567791 for the context menu. Tooltips do not have this problem.
The underlying cause is using Basic in GPU process.
bug 1574746 will upgrade autoscroll icon, identity panel, page actions menu and main menu from Basic to WebRender,
but the context menu is still restricted to Basic:

(Sotaro Ikeda [:sotaro] from bug 1574746 comment 18)

With gfx.webrender.debug.primitives I noticed that Basic is still used for the context menu.

The patch does not expected to use WebRender for all windows(widgets). When ComputeShouldAccelerate()/WidgetTypeSupportsAcceleration() return false, widget does not use WebRender.

Could this restriction already be removed [for the context menu] on GTK? (or in general: bug 1622633)

Comment 2

[Darkspirit]

Panels of the menu bar (press Alt key) are affected as well.

Comment 3

[Mathew Hodson]

Was this fixed by the backout in bug 1634865?

Comment 4

[Darkspirit]

Yes