Visual corruption in the list of the bookmarks menu when scrolling
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
People
(Reporter: itiel_yn8, Assigned: Gijs)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(4 files, 2 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
(deleted),
image/png
|
Details |
STR:
- Latest Nightly, Windows 10
- Customize > Put the "Show your bookmarks" icon on the toolbar
- Add many bookmarks so that the bookmarks menu would be scrollable
- Open the bookmarks menu, hover one of the bookmarks and don't move your mouse
- 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?
Comment 5•6 years ago
|
||
??
Updated•6 years ago
|
Comment 6•6 years ago
|
||
Regressed by:
66ef885f0b66 Markus Stange — Bug 1400259 - Add will-change:transform to the panel in order to work around a compositor bug. r=mconley
Assignee | ||
Comment 7•6 years ago
|
||
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.)
Updated•6 years ago
|
Comment 8•6 years ago
|
||
I'm going to fix bug 1414033, so I think you could back out the will-change additions (bug 1400259) to fix this.
Assignee | ||
Comment 9•6 years ago
|
||
(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...
Assignee | ||
Comment 10•5 years ago
|
||
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 | ||
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
Sounds like this belongs in Web Painting. Moving there and setting as P3 for now.
Assignee | ||
Comment 13•5 years ago
|
||
:Virtual and Itiel, could you test that this fix works (ie fixes this issue and doesn't regress bug 1400259) by checking this build off try ( https://treeherder.mozilla.org/#/jobs?repo=try&revision=d2ced925a638ebf3b512be0147dc5892f299ec30&selectedJob=249440066 ), please:
64-bit: https://queue.taskcluster.net/v1/task/HdphrU0aQVOPSrmc5GIYPQ/runs/0/artifacts/public/build/target.zip
32-bit: https://queue.taskcluster.net/v1/task/J-0kKZXaT-awWS4oVdgZgw/runs/0/artifacts/public/build/target.zip
Thank you!
Reporter | ||
Comment 14•5 years ago
|
||
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.
Comment 15•5 years ago
|
||
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.
Comment 16•5 years ago
|
||
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)
Comment 17•5 years ago
|
||
@ 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.
Comment 18•5 years ago
|
||
(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.
Assignee | ||
Comment 19•5 years ago
|
||
(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?
Reporter | ||
Comment 20•5 years ago
|
||
(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?
Comment 21•5 years ago
|
||
Comment 22•5 years ago
|
||
bugherder |
Reporter | ||
Comment 23•5 years ago
|
||
I can confirm that now, on latest Nightly:
- This bug is fixed
- I can't reproduce bug 1400259
- I can't see the issue mentioned in comment 14
Assignee | ||
Comment 24•5 years ago
|
||
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
Assignee | ||
Comment 25•5 years ago
|
||
(Thanks, Itiel!)
Comment 26•5 years ago
|
||
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.
Comment 27•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Updated•5 years ago
|
Updated•3 years ago
|
Description
•