1692519 - Library menu is glitchy when opening or closing submenus

Status: RESOLVED DUPLICATE of bug 1706039

(Core :: Graphics, defect, P3)

Description

[Florencia Di Ciocco, NI to vbalducci]

Attachment: glitches from bookmark menu.webm

[Affected platforms:]
Windows 10
Ubuntu 20

[Affected versions:]
Nightly 87.0a1

[Description:]
when I browse through the library menu (in the toolbar), the menu is glitchy.

[Steps:]

1. Open Firefox with a new profile.
2. Have the library menu on the toolbar.
3. Open one of the subfolders.
4. Go back to the main menu.

[Actual result:]
The menu is glitchy when changing the box's size.

[Expected result:]
The menu shouldn't be glitchy.

Comment 1

[Mark Banner (:standard8)]

Moving across to menus, since it seems this was affected by the recent proton work. Clearing severity so that it can get triaged.

Comment 2

[Marco Bonardo [:mak]]

Why is this marked as confidential? I don't see any personal data here

Comment 3

[Rares Doghi, Desktop QA]

Hi Marco sorry for the confusion, I marked it as such because of the Screen Recording. It slightly showed some new design for the Library Menu.

Comment 4

[:Gijs (he/him)]

We don't need to mark bugs as confidential.

Can you clarify if this is happening without setting any proton preferences?

Comment 5

[:Gijs (he/him)]

(Also, if not impacted by proton preferences, please can you find a regression window? Thank you.)

Comment 6

[Florencia Di Ciocco, NI to vbalducci]

(In reply to :Gijs (he/him) from comment #4)

We don't need to mark bugs as confidential.

Can you clarify if this is happening without setting any proton preferences?

This happens both with and without preferences.

(In reply to :Gijs (he/him) from comment #5)

(Also, if not impacted by proton preferences, please can you find a regression window? Thank you.)

I tried but for some weird reason, on the mozregression I couldn't replicate this bug.

Comment 7

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
If this is happening even without proton we need to get to the bottom of what broke and how?

This sounds like it's related to some kind of graphics setting. Can you reproduce in a completely clean profile during the first run? Or perhaps only the second run? We'll need to nail down what is triggering this in order to figure out how this is happening.

:dholbert, I don't suppose you have ideas about what is going on here based on the video / not being able to reproduce on mozregression?

Comment 8

[Rares Doghi, Desktop QA]

I also tried to reproduce this issue again, In our latest builds as well as the older builds including the one where this issue was logged from but I couldn't reproduce it anymore, It used to happen with some fresh profiles but not every time, I'm not exactly sure what is causing it but I will keep trying some of the older builds.

Unfortunately the Mozregression tool is blocked by our AV plus with the older mozregression tool build i.e version 4.0.5 that does work the Nightly builds from 2021 do not open because of the Troubleshoot Compatibility issue, so we have to manually download and test each version.

Comment 9

[tgn-ff]

I ran mozregression and ended up to a WebRender patch (Bug 1574746) as the culprit. Disabling WR does indeed prevent this issue.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=74d50028caec9d5856a173c98a6172700f1ccc29&tochange=6a43f985307516ec1ae2d413a39cd6d813560b8b

Comment 10

[:Gijs (he/him)]

(In reply to tgn-ff from comment #9)

I ran mozregression and ended up to a WebRender patch (Bug 1574746) as the culprit. Disabling WR does indeed prevent this issue.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=74d50028caec9d5856a173c98a6172700f1ccc29&tochange=6a43f985307516ec1ae2d413a39cd6d813560b8b

I'm a little confused because QA reported this as a new bug in 87, and that patch landed in 78. I cannot reproduce the issue shown in the video at all myself.

Is it perhaps the case that webrender is default-on in nightly but not release builds (where the set of people for which it's turned on is smaller, but not empty), and this issue only happens with webrender on?

I also wonder if this is related to bug 1687828 (which I think was really a dupe of bug 940733 which we should probably close) - but that'd mean 86 is affected, too.

Mike, do you have ideas on what's going on here?

Comment 11

[tgn-ff]

I can reproduce the issue on ESR v78.7.1 when I enable WR. It's difficult to detect in a clean profile, though. If you added a few, say 50, bookmarks, then it'd be easier to detect it when you open the Bookmarks submenu. Something has changed recently to make it more pronounced even in empty profiles. I can't find said recent change, however. It's possible that is more than one and every time makes it slightly worse. Btw, I can only reproduce it on Linux.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

I don't know what's happening here, no - looking frame by frame, it looks like the subview sliding in is temporarily overtaking the outer bounds for the arrow panel and causing some brief repositioning before it settles back down and resolves...

The fact that this is only reproducible with WebRender though compels me to put this in Core :: Graphics : WebRender for now.

Comment 13

[Florencia Di Ciocco, NI to vbalducci]

I'm clearing my needinfo since the mozregression was already given. Thanks.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Comment 15

[Jim Blandy :jimb]

Needinfo'ing Sotaro as owner of bug 1574746.

Comment 16

[Julien Cristau [:jcristau]]

From later comments it sounds like this is not actually new in 87, and seems hard to reproduce.

Comment 17

[Rares Doghi, Desktop QA]

Hi, regarding this issue, that library animation acts a bit different on other systems, its not as glitchy but it definitely slower, specially when a lot of Bookmarks are involved, I will leave a screen recording of what we see on Windows 7, 10 and Mac 11, but please note that this issue also occurs with Webrender disabled, and it also happens in Beta and Release.

Please let us know if we should log a separate issue or if its the same thing.

Comment 18

[Rares Doghi, Desktop QA]

Attachment: LibraryAnime.mp4

Comment 19

[tgn-ff]

It seems this is an issue with OpenGL layers too. It was first introduced on 2017-07-12 (I can't get a more precise result because of missing intermediate builds), and it affected WR too. Later, the issue was fixed only on WR on 2018-01-15 (missing builds). The most recent re-intoduction of this bug in WR was in the mozregression result of comment 9.

The Basic and software WR compositors aren't affected, at least not in the current build (20210311093001).

Comment 20

[Alin Ilea, Desktop Test Engineering]

Attachment: 2021-03-11_15h27_21.mp4

Also the history -> recently closed tabs/windows submenus from the toolbar library are affected, they are not opening and closing smooth. The same submenus but from the hamburger menu are not affected. Tested with latest Nightly 88.0a1, new profile, without webrender enabled. Cannot reproduce it in Beta 87 or Release 86.

Comment 21

[Romain Testard [:RT]]

Marking as P2. Per experience review we agreed to mark as P1 bugs only bugs that will block MR1.

Comment 22

[Florencia Di Ciocco, NI to vbalducci]

Hi,
This is still present on today's nightly. A friendly note, this is easier to reproduce with a lot of bookmarks.

Comment 23

[tgn-ff]

The drop-down menus of the site information, the protections and the extensions in the overflow menu are also affected.

Comment 24

[Jim Mathies [:jimm]]

We've lived with this for a while. Maybe Sotaro can find something when he has a chance. Not a blocker as far as the graphics team is concerned.

Comment 25

[Jim Mathies [:jimm]]

Note we don't want to confuse this with the Swiggle popup painting issues we currently have on Nightly. If you're testing something here please be sure and detail the release and platform.

Bug 1705415 - [meta] Software WebRender popups