[Note]: - This issue is visible only on the beta and release builds [Affected versions]: - 62.0b5 build1 (20180702164905) - 61.0 build3 (20180621125625) [Affected platforms]: - Ubuntu 16.04 x64/x86 [Steps to reproduce]: 1. Launch Firefox using a clean profile 2. Inspect the Firefox firstrun page [Expected result]: - The firstun page is properly displayed - No visual glitches are triggered [Actual result]: - The "Get your bookmarks, history, passwords and other settings on all your devices." text has glitchy shadow - In order to make this visible after a refresh, switch between the firstrun page and another tab, then come back to it [Regression range]: - This is not a recent regression, as it's reproducible all the way back to the first beta 57 build (57.0b3 20170925150345), when the new type of firstrun page was implemented - The issue is easily visible starting with the first 62 beta build (62.0b3 20180625141512) though; before it, the firstrun page had this type of URL https://www.mozilla.org/en-US/firefox/61.0/firstrun/ and also, the glitch was only visible for a couple of seconds [Additional notes]: - The issue is still visible after refresh/restart, after switching between the firstrun page and another tab, then coming back to it
Summary: Glitchy text shadow in the beta and release Firefox firstrun page → [Ubuntu] Glitchy text shadow in the beta and release Firefox firstrun page
Forgot to add a screenshot of the mentioned issue. Here it is.
Feels more likely a graphics issue...
Component: Layout: Text → Graphics: Text
I was able to reproduce this in mozregression on Ubuntu 18.04. So it also happens on nightly. https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cb4152d2175e9ada6736224067b322a785e106c8&tochange=79ab9d3259944b808a88f0c6783504e269bcff2c Added the about:welcome page as we see it today. I think bug 1448918 actually did the implementation, but bug 1462427 completed the merge into the mozilla-central repo so that about:welcome loads as it does today. The distortion actually appears briefly and disappears when it was first introduced, while it remains displayed on today's builds. The computed font for me is Ubuntu, which is on the font-family list. If I uncheck the font-family, it switches to DejaVu Serif, and still shows the distortion. If I uncheck the background SVG "../data/content/assets/sync-devices.svg" from ".firstrun-content", both the background image and the text distortion disappear. Lee, any obvious interactions between a background SVG and the text distortion that jump out at you?
The bug here is that PaintThebes can get called recursively with the same gfxContext, but with a different layer for each invocation of PaintThebes. So the inner calls to PaintThebes can thus nuke the PermitSubpixelAA state that is set up right before jumping into the callback. The simple fix here is just to save and restore this state around the callback. There is only one place where this recursive behavior occurs, and only then in basics layers. All other users of SetAntialiasingFlags just borrow a completely fresh scratch DrawTarget and return it after they're done, thus not reusing any passed in DrawTarget, and so are immune to this problem. This explains why we only see this problem on Linux currently, since it requires basic layers to trigger.
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #8991407 - Flags: review?(mstange)
Attachment #8991407 - Flags: review?(mstange) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/e6698ef51a7e save and restore PermitSubpixelAA state for basic layer paint callback. r=mstange
Happy to take this on beta as well if you want to request uplift.
Comment on attachment 8991407 [details] [diff] [review] save and restore PermitSubpixelAA state for basic layer paint callback Approval Request Comment [Feature/Bug causing the regression]: All current branches. [User impact if declined]: Bad rendering of antialiased text on some websites. [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: no [List of other uplifts needed for the feature/fix]: [Is the change risky?]: no [Why is the change risky/not risky?]: Just a simple fix to properly save and restore text rendering state when recursing into painting routines. [String changes made/needed]: none
Attachment #8991407 - Flags: approval-mozilla-beta?
Comment on attachment 8991407 [details] [diff] [review] save and restore PermitSubpixelAA state for basic layer paint callback Fix for an issue with display of Linux text in some situations. Let's uplift for beta 9.
Attachment #8991407 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Iulia, would you mind verifying this fix since you found the issue originally? Note, Lee, usually we don't call issues verified unless someone checks it who isn't the developer fixing the issue.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12) > Iulia, would you mind verifying this fix since you found the issue > originally? I can confirm that 63.0a1 (2018-07-17) and 62.0b9 build1 (20180713213322) are verified fixed an Ubuntu 16.04 x86.
11 months ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.