986942 - Top five pixel-rows of inactive tabs are not registering mousehover and clicks

Status: RESOLVED DUPLICATE of bug 1249818

(Firefox :: Theme, defect)

Description

[Elbart]

Attachment: australis_tabs_drag_200percent.png

Considering Firefox is exposing the toggle to enable the titlebar in "Customization" in Australis, turning inactive tabs into magical buttons which don't register the mousehover in the top five pixel-rows is counter-intuitive.

It's made even worse by 

a.) pre-Australis-tabs registering mousehover over their whole area,
b.) enabling the mousehover when the titlebar is enabled or when the window is maximized, thus changing behavior, and
c.) the open-new-tab-button still having the old behavior of registering the mousehover over its whole vertical size, although it's being displayed like an inactive tab.

The additional click-and-drag-area is just five pixels high, which adds up to only 21 pixel-rows for click-and-dragging the window.

On the other hand, enabling the titlebar to accomplish the same adds 32 pixel rows. This should be the prefered way of enlarging the click-and-drag-area, and not turning some tabs into magical buttons.

Comment 2

[:Gijs (he/him)]

(In reply to Elbart from comment #0)
> Created attachment 8395415 [details]
> australis_tabs_drag_200percent.png
> 
> Considering Firefox is exposing the toggle to enable the titlebar in
> "Customization" in Australis, turning inactive tabs into magical buttons
> which don't register the mousehover in the top five pixel-rows is
> counter-intuitive.

We didn't just enable the titlebar toggle for the click and drag target, but also for showing the title of the page you're currently at, and because some people felt that certain themes (e.g. custom windows themes) don't work well with tabsintitlebar. So, there were several reasons. That doesn't mean we don't want to fix some of the problems with not showing the titlebar (like the click and drag target) even for tabsintitlebar mode.

> It's made even worse by 
> 
> a.) pre-Australis-tabs registering mousehover over their whole area,

These weren't tabsintitlebar except in maximized mode on Windows, where dragging the window is less of a common operation. So I don't see how this is in any way relevant.

> b.) enabling the mousehover when the titlebar is enabled or when the window
> is maximized, thus changing behavior, and

Because it wouldn't make any sense to have this behaviour in maximized mode or when the titlebar is enabled. I don't see how this is in any way a problem.

> c.) the open-new-tab-button still having the old behavior of registering the
> mousehover over its whole vertical size, although it's being displayed like
> an inactive tab.

Maybe we should make the new tab button consistent, then, but that's orthogonal to the change as a whole making sense or not.

> The additional click-and-drag-area is just five pixels high, which adds up
> to only 21 pixel-rows for click-and-dragging the window.
> On the other hand, enabling the titlebar to accomplish the same adds 32
> pixel rows.

Maybe this is what it is for you on your particular OS. The difference is much smaller on OS X, for example, and will be different on different versions of Windows, also.

You're essentially asking for bug 887397 to be reverted. I don't think we should do that, so I'm going to mark this bug as wontfix.

Comment 3

[Elbart]

(In reply to :Gijs Kruitbosch from comment #2)
> > It's made even worse by 
> > 
> > a.) pre-Australis-tabs registering mousehover over their whole area,
> 
> These weren't tabsintitlebar except in maximized mode on Windows, where
> dragging the window is less of a common operation. So I don't see how this
> is in any way relevant.

Consistency.
Pre-Australis: Whole area of an inactive tab is a mouse-target, regardless of the state of the window.
Australis: Only the bottom 2/3rds of the inactive tab is a mouse-target, and only when not maximized or when there's no titelbar.

Having different mousetargets depending on the state of being maximized or not is confusing. That "OMG CHANGE!"-stuff.

> Maybe this is what it is for you on your particular OS. The difference is
> much smaller on OS X, for example,

So what's prohibiting making this change OSX-only, as
> and will be different on different
> versions of Windows, also.
is not true?

Seeing a screenshot like this
> http://img.applesfera.com/2013/11/firefoxaustralis.jpg
, the change makes sense for OSX.
But there's plenty of space to drag in Windows.
And if I'm following the conversation in bug 887397 and its deps and blocks (australis-tabs-*osx*!) correctly, the commenters there are mostly, if not all, OSX-users.

No point in projecting the shortcomings of one OS onto all the others.

Comment 7

[Elbart]

Now that the new Developer-theme got the original state of registering hover across its whole area, can Australis please get this change reverted too?

Comment 9

[Dão Gottwald [:dao]]

This has now been fixed in bug 1249818 since the original implementation of bug 887397 didn't work anymore.