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

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

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.

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

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

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.

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