996568 - Right tabbar-arrow is blurry and too large

Status: NEW

(Firefox :: Theme, defect)

Description

[Elbart]

Attachment: tabarrow_400%zoom.png

See attachment for a size comparison

Affected:
Versions all the way down to 29.0b7

Regression-range:

m-c
Last good revision: 6c924a018540 (2014-04-04)
First bad revision: 5fa70bd90a8b (2014-04-05)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6c924a018540&tochange=5fa70bd90a8b

m-i
Last good revision: c4d1adee6057
First bad revision: 95dac7341bc0
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c4d1adee6057&tochange=95dac7341bc0

Narrowed down to
c4dbb3c39b33	Matthew Noorenberghe — Bug 990387 - Toolbar buttons on the TabsToolbar appear below the nav-bar border with a theme. r=dao
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4dbb3c39b33

by a user on Mozillazine:
http://forums.mozillazine.org/viewtopic.php?p=13470425#p13470425

Comment 1

[:Gijs (he/him)]

Interestingly, I can see the size discrepancy on Windows 8, but DOMI insists both images and buttons are the same size. On top of that, it's actually *the same image* - just transform: scaleX(-1)'d. So it being any more or less blurry and the 1px apparent size difference is technically a graphics bug. That said, we could probably workaround by just shipping a properly flipped image... Dão, thoughts?

Comment 2

[Dão Gottwald [:dao]]

Yes, this is an old graphics or more likely layout bug. We've seen it before and it should already be filed somewhere. Not sure whether we've worked around it in the past.

Comment 3

[:Gijs (he/him)]

image-rendering: -moz-crisp-edges seems to fix this. I'm checking if adding this in other places where we use scaleX(-1) helps (particularly the URL bar in RTL mode).

Comment 4

[:Gijs (he/him)]

Err, actually, now that I try it on Nightly instead of beta, I'm seeing artifacts. Sigh.

Comment 5

[Elbart]

scaleX(-1) was used before the blocked bug landed too, and the image wasn't blurry.
Why's that?

I think the bug referred to in comment 2 is bug 683707.

Won't the arrow look bad when a higher dpi is being used? AFAIK -moz-crisp-edges isn't doing any antialiasing.

Comment 6

[:Gijs (he/him)]

(In reply to Elbart from comment #5)
> scaleX(-1) was used before the blocked bug landed too, and the image wasn't
> blurry.
> Why's that?

Different positioning after that bug landed (perhaps now fractional ones instead of integer ones, see some of the comments in bug 683707).

> I think the bug referred to in comment 2 is bug 683707.

Thanks!

> Won't the arrow look bad when a higher dpi is being used? AFAIK
> -moz-crisp-edges isn't doing any antialiasing.

It doesn't really matter because on Nightly it just messes it up completely for me. Not sure why, but it seems like we should just push for bug 683707 to be fixed.

Comment 7

[Elbart]

Attachment: tabarrow_newtabbutton_400%.png

OK, understood, thanks.

One thing I noticed just now: The "plus" of the newtab-button is also one pixel higher than before. Is that change intentional?
The "list all tabs"-button has the same position, though.

Comment 8

[Elbart]

I played a bit with DOM Inspector and discovered this:

1.) Changing margin-bottom for the "scrollbutton-down"-toolbarbutton to any even number fixes the blurriness. Every uneven number shows the blurriness.

2.) Changing margin-bottom for "scrollbutton-up" to uneven or even numbers does not show the different behavior, and as far as I can see, there is also no visible difference regarding the position between 0px and 1px.

Comment 9

[Elbart]

I'd like to post more info regarding the bug and the "life and death" of the blurriness of the tab-overflow-button. Maybe it will help getting to the root of this problem:

1.)
scaleX was added to reuse images, introducing the blurriness of the overflow-button (barely noticeable though, only when zooming in):
Last good revision: 6b58d2615145 (2010-07-19)
First bad revision: c71dba463f85 (2010-07-20)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6b58d2615145&tochange=c71dba463f85
Bug 579920 - Consolidate tab bar scroll button styling.
http://hg.mozilla.org/mozilla-central/rev/90b4a68fae07

2.)
Blurriness fixed(?) for tabbar-overflow-buttons
Last good revision: 413eb50d4b81 (2011-01-16)
First bad revision: 66addc5c30ca (2011-01-17)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=413eb50d4b81&tochange=66addc5c30ca

3.)
The bug was reintroduced in
Last good revision: fd0817e454fe (2011-02-09)
First bad revision: 199cb6282554 (2011-02-10)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fd0817e454fe&tochange=199cb6282554

4.)
And fixed(?) again in
Last good revision: 919f15d71153 (2011-03-02)
First bad revision: e79b2b60d394 (2011-03-03)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=919f15d71153&tochange=e79b2b60d394

5.)
Since range 4, applying "margin: 0 0 1px" to the scrollbuttons causes the blurriness for .scrollbutton-up, which was now also triggered by default with bug 990387.

Tested with this userChrome.css in the profile\chrome-folder:

.tabbrowser-arrowscrollbox > .scrollbutton-up,
.tabbrowser-arrowscrollbox > .scrollbutton-down {
   margin: 0 0 1px !important;
}

Comment 10

[Elbart]

Attachment: 996568_newtab_button_200%.png

(In reply to Elbart from comment #7)

> One thing I noticed just now: The "plus" of the newtab-button is also one
> pixel higher than before. Is that change intentional?

It's only higher when the scrollbuttons are visible too.
I doubt it's an intentional change, as going from tab-overflow to no overflow produces a visible jump of the plus.