Closed Bug 1004167 Opened 6 years ago Closed Last year

loss of subpixel antialiasing of address bar text

Categories

(Firefox :: Theme, defect)

29 Branch
x86
Linux
defect
Not set

Tracking

()

RESOLVED WORKSFORME
Firefox 41

People

(Reporter: cranberrydoughan, Assigned: karlt)

References

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428194004

Steps to reproduce:

Look at the text in the address bar of Firefox 29 (Linux).


Actual results:

Notice that the font is not rendered correctly in the address bar. Specifically, the hinting is off and FF29 seems to be purely grayscale (or, in the case of colored text, a varient of that same color).


Expected results:

The text in the URL bar should look the same as it did in previous versions (FF28 and before) and the same as text in other parts of Firefox (like the search bar). The font hinting should be more complex and use colors to look good on screen.

In FF29, putting the same text in the address and search bars will allow for easy comparison and show how the URL bar's font hinting is off.

Note that this, as far as I can tell, only affets the address bar. Text in other places (search bar, etc.) is fine as well.
I expect we broke this by giving it opacity or something. :-\
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: firefox-backlog?
This should the same as bug 828073. Going back to an SVG mask instead of the clip-path would supposedly fix this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 828073
Flags: firefox-backlog? → firefox-backlog-
Yes, a regression from https://hg.mozilla.org/mozilla-central/rev/7baa06f4b49c

I'll leave bug 828073 for fixing the clip-path implementation, but
non pixel-aligned clips are not going to be efficient even if the subpixel-aa issue is resolved.  Here I'll avoid the complex clip.
Status: RESOLVED → REOPENED
Component: Untriaged → Theme
Resolution: DUPLICATE → ---
Summary: Font hinting regression (address bar) → loss of subpixel antialiasing of address bar text
Make back-button background match the color of its ancestor toolbar, where
possible, so that overdrawing the start of the url bar makes aligning the clip
with the arc of the back button border unnecessary.

This enables subpixel antialiasing and more efficient drawing in the url bar.

back-button border outside is aligned with the visible toolbarbutton-icon to
avoid any awkward lines should the color of the toolbar be modified in any
way.

A good deal of what was lost in tresize is recovered:

TResize (tresize)
Ubuntu 32 (details)	20.13	±0.44	19.2	±0.18	-0.93	-4.62%
Ubuntu 64 (details)	18.4	±0.48	17.41	±0.64	-0.99	-5.38%

http://perf.snarkfest.net/compare-talos/index.html?oldRevs=86fcb301c3fd&newRev=502b812487e3&submit=true
(The patch there was a prototype, but should behave similarly without lwtheme.)

A simplified svgPath is used for clip-path because basic shapes are waiting
on bug 1075457.

I did originally try overflow-x: -moz-hidden-unscrollable instead of the
clip-path but that gave a regression in cart:

Customization Animation Tests (cart)
Ubuntu 32 (details)	56.48	±1.6	59.15	±1.7	2.67	4.73%
Ubuntu 64 (details)	56.29	±1.74	57.85	±1.64	1.56	2.77%

http://perf.snarkfest.net/compare-talos/index.html?oldRevs=86fcb301c3fd&newRev=dd18d119f66f&submit=true

Comparison of overflow-x vs rectangular clip-path:

Customization Animation Tests (cart)
Ubuntu 32 (details)	59.15	±1.7	56.89	±1.94	-2.26	-3.82%
Ubuntu 64 (details)	57.85	±1.64	55.25	±0.74	-2.6	-4.49%

http://perf.snarkfest.net/compare-talos/index.html?oldRevs=dd18d119f66f&newRev=502b812487e3&submit=true

We should be able to use the same approach on NT too.
Attachment #8615717 - Flags: review?(mdeboer)
Assignee: nobody → karlt
Status: REOPENED → ASSIGNED
Comment on attachment 8615717 [details] [diff] [review]
opaque back-button when not -moz-lwtheme to pixel-align clip

Review of attachment 8615717 [details] [diff] [review]:
-----------------------------------------------------------------

My apologies for not getting to this earlier! It somehow got lost in my queue :/ (Too focused on Hello work, I guess...)

This looks good, thanks for fixing this!

::: browser/themes/linux/browser.css
@@ +903,5 @@
>  }
>  
>  @conditionalForwardWithUrlbar@:-moz-locale-dir(rtl),
>  @conditionalForwardWithUrlbar@ > #urlbar:-moz-locale-dir(rtl) {
> +  /* let clip-path clip the urlbar-wrapper's right side for RTL */

Comment nit: please start with a capital L and end with a dot (.).
Attachment #8615717 - Flags: review?(mdeboer) → review+
https://hg.mozilla.org/mozilla-central/rev/f0889dbf9694
Status: ASSIGNED → RESOLVED
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
Comment on attachment 8615717 [details] [diff] [review]
opaque back-button when not -moz-lwtheme to pixel-align clip

This regresses bug 571454. Too bad browser_backButtonFitts.js hasn't been enabled on Linux...
Attachment #8615717 - Flags: review-
Status: RESOLVED → REOPENED
Keywords: leave-open
Resolution: FIXED → ---
Keywords: leave-open
Ah, I wondered why it was designed so that missing the UI to the left of the back button would trigger going back a page.
I currently experience this issue with FF48b9 on Linux
Per Comment 11 closing this one.

@ Karl Tomlinson (:karlt) - Do you agree with this?



(In reply to Clemens Eisserer from comment #13)
> I currently experience this issue with FF48b9 on Linux

Report the bug about it, as this one was fixed.
Status: REOPENED → RESOLVED
Closed: 5 years ago3 years ago
Flags: needinfo?(karlt)
Resolution: --- → FIXED
Please stop resolving bugs where no proper fix landed. The commit in comment 11 was not supposed to and did not fix this bug.
Status: RESOLVED → REOPENED
Flags: needinfo?(karlt)
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 3 years agoLast year
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.