Closed Bug 1543508 Opened 6 years ago Closed 5 years ago

Visual corruption in the list of the bookmarks menu when scrolling

Categories

(Core :: Web Painting, defect, P3)

All
Windows 10
defect

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox-esr60 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed
firefox69 --- verified

People

(Reporter: itiel_yn8, Assigned: Gijs)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(4 files, 2 obsolete files)

STR:

  1. Latest Nightly, Windows 10
  2. Customize > Put the "Show your bookmarks" icon on the toolbar
  3. Add many bookmarks so that the bookmarks menu would be scrollable
  4. Open the bookmarks menu, hover one of the bookmarks and don't move your mouse
  5. Scroll to the bottom, slowly

AR:
Right before getting to the bottom "Show All Bookmarks" item, you'll see a glitch in the list, and the right side (for both RTL and LTR locales) of the list will extend be a few pixels

ER:
No glitch.

See attached.

This is a regression. Can't pinpoint to the exact regressing bug (Mozregression doesn't bisect further than mozilla-central builds for some reason), but for me the regression window is 2017-11-02 to 2017-11-03.
Alice, maybe you'll have better luck than me here?

Attached image Good (the right side of the list is web content) (obsolete) (deleted) —
Attached image Bad (obsolete) (deleted) —
Attached image Good (deleted) —
Attachment #9057361 - Attachment is obsolete: true
Attached image Bad (deleted) —
Attachment #9057362 - Attachment is obsolete: true
Flags: needinfo?(alice0775)

??

Flags: needinfo?(alice0775)

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a4fb78381ea0fe9fddd36a8ea7b74a63062a1bf3&tochange=66ef885f0b66cb680a3f0734bfbfd8fd385fa104

Regressed by:
66ef885f0b66 Markus Stange — Bug 1400259 - Add will-change:transform to the panel in order to work around a compositor bug. r=mconley

Component: Bookmarks & History → Toolbars and Customization
Regressed by: 1400259

Markus, this looks like a layout/painting issue (unsure which). Can you (or someone else who knows this code) take a look?

(Not super high priority given we don't show the bookmarks menu button by default and there's no lasting damage, just a small visual artifact.)

Component: Toolbars and Customization → Layout
Flags: needinfo?(mstange)
Product: Firefox → Core
Flags: needinfo?(mstange) → needinfo?(matt.woodrow)

I'm going to fix bug 1414033, so I think you could back out the will-change additions (bug 1400259) to fix this.

Flags: needinfo?(matt.woodrow)

(In reply to Matt Woodrow (:mattwoodrow) from comment #8)

I'm going to fix bug 1414033, so I think you could back out the will-change additions (bug 1400259) to fix this.

Ni me to look at this next week...

Flags: needinfo?(gijskruitbosch+bugs)
Blocks: 1551697

The problem is I can't reproduce this issue. I'll attach a patch to revert the will-change stuff given both this and bug 1551697 cover this, but someone who can actually reproduce this will need to test that it actually fixes things and doesn't regress bug 1400259 (which it doesn't for me, but...).

Assignee: nobody → gijskruitbosch+bugs
Flags: needinfo?(gijskruitbosch+bugs)

Sounds like this belongs in Web Painting. Moving there and setting as P3 for now.

Component: Layout → Web Painting
Priority: -- → P3
Flags: needinfo?(itiel_yn8)
Flags: needinfo?(Virtual)

This build fixes the issue, and I can't reproduce bug 1400259. I'd prefer that :Virtual will verify that as well.

A regression I can see with this build is that the Bookmarks Toolbar does not appear after a restart, no matter how many times you'll toggle it on (after every restart). Happens on this build with a fresh profile as well. Nothing that seems to relate to that appears in the Browser Toolbox.
Changing other settings such as enabling the Title bar does work.
On the latest Nightly I don't see this issue.

Flags: needinfo?(itiel_yn8) → needinfo?(gijskruitbosch+bugs)

Also green light from me. :)
I'm no able to reproduce issue from bug #1400259 with Mozilla Firefox Nightly 69.0a1 (2019-05-31) (64-bit) [Built from https://hg.mozilla.org/try/rev/d2ced925a638ebf3b512be0147dc5892f299ec30] from comment #13.

Flags: needinfo?(Virtual)
Attached image image.png (deleted) —

I can still reproduce the issue on Nightly69.0a1 Windows10.

Build ID 20190602094449
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101
Compositing Direct3D 11 (Advanced Layers)

@ Alice0775 White - What about build from Comment #13?
As for me this bug wasn't reproducible and I can't reproduce bug #1400259 with that build,
but I'm on Windows 7, not Windows 10, which this bug is probably only reproducible.

Flags: needinfo?(alice0775)
OS: Unspecified → Windows 10
Hardware: Unspecified → All

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #17)

@ Alice0775 White - What about build from Comment #13?
As for me this bug wasn't reproducible and I can't reproduce bug #1400259
with that build,
but I'm on Windows 7, not Windows 10, which this bug is probably only
reproducible.

I cannot reproduce the issue on the try build of comment#13.

Flags: needinfo?(alice0775)

(In reply to Itiel from comment #14)

This build fixes the issue, and I can't reproduce bug 1400259. I'd prefer that :Virtual will verify that as well.

OK great, between you, Virtual and Alice that's a high amount of confidence the fixes so far are good. Thanks to all of you for checking.

A regression I can see with this build is that the Bookmarks Toolbar does not appear after a restart, no matter how many times you'll toggle it on (after every restart). Happens on this build with a fresh profile as well. Nothing that seems to relate to that appears in the Browser Toolbox.
Changing other settings such as enabling the Title bar does work.
On the latest Nightly I don't see this issue.

I suspect this is an issue with xulstore or the browser.xul -> .xhtml rename. I don't think anything in this patch itself could possibly trigger this issue... Can you reproduce on a clean profile? What about now-current nightly? Are you reusing a profile between "regular" nightly and the custom build otherwise, and could that be the cause of the issue?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(itiel_yn8)

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

I suspect this is an issue with xulstore or the browser.xul -> .xhtml rename. I don't think anything in this patch itself could possibly trigger this issue... Can you reproduce on a clean profile? What about now-current nightly? Are you reusing a profile between "regular" nightly and the custom build otherwise, and could that be the cause of the issue?

When I last tested (and commented in comment 14), I overwrited the C:\Program Files\Firefox Nightly contents with the files in the zip file from comment 13, created a clean profile and there I saw this issue.
Now, I just ran the firefox.exe along with the other extracted files with a clean profile, and I can't reproduce it now.
So.. false alarm, I guess?

Flags: needinfo?(itiel_yn8)
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/2d70e6f3a03a revert will-change additions now that layers no longer cause compositor bugs, r=mconley
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

I can confirm that now, on latest Nightly:

  1. This bug is fixed
  2. I can't reproduce bug 1400259
  3. I can't see the issue mentioned in comment 14
Status: RESOLVED → VERIFIED

Comment on attachment 9068724 [details]
Bug 1543508 - revert will-change additions now that layers no longer cause compositor bugs, r?mstange

Beta/Release Uplift Approval Request

  • User impact if declined: Ugly/broken visual artifacts in the UI
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: n/a
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): CSS-only revert of a workaround that used to be necessary but isn't anymore.
  • String changes made/needed: None
Attachment #9068724 - Flags: approval-mozilla-beta?

(Thanks, Itiel!)

Comment on attachment 9068724 [details]
Bug 1543508 - revert will-change additions now that layers no longer cause compositor bugs, r?mstange

approved for 68.0b8, thanks.

Attachment #9068724 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: