1004167 - loss of subpixel antialiasing of address bar text

Status: RESOLVED WORKSFORME

(Firefox :: Theme, defect)

Description

[Jackson Sul]

Attachment: FF font hinitng 28 vs 29.png

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.

Comment 1

[:Gijs (he/him)]

I expect we broke this by giving it opacity or something. :-\

Comment 2

[Dão Gottwald [:dao]]

This should the same as bug 828073. Going back to an SVG mask instead of the clip-path would supposedly fix this.

Comment 3

[Karl Tomlinson (:karlt)]

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.

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: opaque back-button when not -moz-lwtheme to pixel-align clip

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.

Comment 5

[Mike de Boer [:mikedeboer]]

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 (.).

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f0889dbf9694

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f0889dbf9694

Comment 8

[Dão Gottwald [:dao]]

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...

Comment 9

[Dão Gottwald [:dao]]

backed out: https://hg.mozilla.org/integration/fx-team/rev/82cab91c01cd

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/87c9b69a0ec0

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/87c9b69a0ec0

Comment 12

[Karl Tomlinson (:karlt)]

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.

Comment 13

[Clemens Eisserer]

I currently experience this issue with FF48b9 on Linux

Comment 14

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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.

Comment 15

[Dão Gottwald [:dao]]

Please stop resolving bugs where no proper fix landed. The commit in comment 11 was not supposed to and did not fix this bug.