924198 - [Australis] [Mac] Background tab separators and tab hover graphics are briefly shown at the same time when moving the mouse over a tab

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[u484349]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131003040204

Steps to reproduce:

Having multiple tabs opened and moving the mouse over an inactive tab.


Actual results:

The hover graphic of the tab shows as expected, but the inactive tab separators also remain visible for ~100ms (sometimes up to 1s when CPU load is high). Easiest to see if you swiftly move the mouse over the tab and out again.


Expected results:

The tab separators should disappear at the same instant as the hover graphic is shown.

Comment 1

[:Gijs (he/him)]

(In reply to philippsackl from comment #1)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:27.0)
> Gecko/20100101 Firefox/27.0 (Beta/Release)
> Build ID: 20131003040204
> 
> Steps to reproduce:
> 
> Having multiple tabs opened and moving the mouse over an inactive tab.
> 
> 
> Actual results:
> 
> The hover graphic of the tab shows as expected, but the inactive tab
> separators also remain visible for ~100ms (sometimes up to 1s when CPU load
> is high). Easiest to see if you swiftly move the mouse over the tab and out
> again.

I've been trying to record this because I felt the same, but I think it's in my mind. There's not a single frame in my screencast that actually has them overlayed. The 1s stuff sounds like you *can* reproduce this, so could you create a screencast of this? Cheers!

Comment 2

[u484349]

(In reply to :Gijs Kruitbosch from comment #1)
> I've been trying to record this because I felt the same, but I think it's in
> my mind. There's not a single frame in my screencast that actually has them
> overlayed. The 1s stuff sounds like you *can* reproduce this, so could you
> create a screencast of this? Cheers!

I tried to do this, but – just as you did – couldn't capture it using a screen recording. I then tried to capture it by just filming the screen with a camera: https://vimeo.com/76986659
You can see the effect, but it is unclear whether it is because of compression/capture performance or FF itself.

Perhaps it really is an optical effect. The only solution I can think of from the top of my head would be to animate the transition, but that comes with its own set of issues in UX, performance, etc.

Comment 3

[:Gijs (he/him)]

So, the only thing I can think of is that we update the style of the hovered tab using :hover, IIRC, and we decide whether we show the separator before the next tab using the [beforehovered] attribute, which we set based on mousemove handlers.

Because we're happily inserting these before the tab rather than after the tab, we can abuse the CSS sibling selector - kind of, because it might not be (because of tab groups and hidden tabs and... ugh.

We could also use an attribute for the hovered tab, which would ensure it's sync'd with the before/after hovered states. However, trying that, I don't really see a difference between the current state and the one with an attribute. I'll add a PoC patch for this in a second.

Comment 4

[:Gijs (he/him)]

Attachment: make Australis use hovered tab attribute to show hovered tab

Comment 5

[:Gijs (he/him)]

Comment on attachment 8343694 [details] [diff] [review]
make Australis use hovered tab attribute to show hovered tab

Mike, can you do me a favour and try this, and see if you think it helps or doesn't seem to make a difference? It doesn't seem to, as far as I can tell, but maybe that's just me... if not, I think we should WONTFIX/WFM this bug, or at least make it lower prio.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8343694 [details] [diff] [review]
make Australis use hovered tab attribute to show hovered tab

I'm having a pretty hard time detecting any kind of change with this patch. TBH, I think it adds more complexity than anything else.

I'm inclined to P- this bug, considering how hard-to-detect it is.

Comment 7

[:Gijs (he/him)]

(In reply to Mike Conley (:mconley) from comment #6)
> Comment on attachment 8343694 [details] [diff] [review]
> make Australis use hovered tab attribute to show hovered tab
> 
> I'm having a pretty hard time detecting any kind of change with this patch.
> TBH, I think it adds more complexity than anything else.
> 
> I'm inclined to P- this bug, considering how hard-to-detect it is.

Concur. Philipp, if you disagree and/or have ideas on how we can make this less noticeable (even if it's really an optical illusion), please let us know, but otherwise, I think we should focus on other bugs...

Comment 8

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

> Concur. Philipp, if you disagree and/or have ideas on how we can make this
> less noticeable (even if it's really an optical illusion), please let us
> know, but otherwise, I think we should focus on other bugs...

I absolutely agree. Should a suitable solution cross my mind at some point in the future, you'll hear from me again :)

Comment 9

[Paul Silaghi, QA [:pauly]]

(In reply to philippsackl from comment #2)
> Perhaps it really is an optical effect.
Tend to believe this, couldn't see anything concrete on Mac OS X, Win 7 even with busy CPU

(In reply to Philipp Sackl [:phlsa] from comment #8)
> I absolutely agree. Should a suitable solution cross my mind at some point
> in the future, you'll hear from me again :)
Closing meantime