624225 - Non-clickable areas on both top corners of each tab and "New Tab" button

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Sid]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre

There is a non-clickable area on the top left corner of each tab, when tabs are drawn in titlebar.

Reproducible: Always

Steps to Reproduce:
1. Ensure you have browser.tabs.drawInTitlebar option set to true, tabs on top, and your browser window is maximized.
2. Open some tabs.
3. Keep your mouse pointer at the very top edge of screen and move it along tab bar.
4. Notice how inactive tabs are highlightened under mouse pointer, indicating that they are ckickable.
5. But when you move pointer to the left side of each tab (approx. 7-8px from the left border) the tab is no more highlighted and is non-clickable.
Actual Results:  
Unable to click and activate tab on the top left corner of the tab.

Expected Results:  
Should be able to click anywhere along tab bar.

Comment 1

[Sid]

Attachment: That tiny red area is non-clickable

Comment 2

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

Confirming.

Doesn't affect buttons placed on the tabs toolbar, just the tabs themselves, including app tabs.

Comment 3

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

Unclickable area is actually a window drag surface for Aero Snap in Win7, apparently.

Comment 4

[Mathieu Johnson]

Just adding that the New Tab button also suffers from the same problem.

It makes it very hard to hit that button while touching the edge of the screen at the same time considering the non-clickable area (or window drag surface as per comment#3) is about 30% of total surface (on edge).

Comment 5

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

Checking with Windows' "Mouse Keys" feature (to use the keyboard for pixel-by-pixel control of the mouse cursor) in non-maximized mode, the tabs have the same dead areas. 

I put the cursor in the titlebar over a tab, then used keyboard buttons to move the cursor down pixel-by-pixel until the tab showed the hover effect, then I used the keyboard to move the cursor to the left one pixel at a time until it hit the dead area and lost the hover effect.

Looking at Bug 572160's patch, I didn't see anything that would have caused this. So maybe it's always been like this, just no one's ever worried about the top most row of pixels in the tabs being clickable, since it was much harder to land on that row prior to tabs being on top?

Comment 6

[Sid]

(In reply to comment #5)
> So maybe it's always been like this, just no one's ever worried about the
> top most row of pixels in the tabs being clickable, since it was much harder to
> land on that row prior to tabs being on top?

You're probably right. It appears I'm able to reproduce this even with tabs on bottom. The same few pixels on top left corner of each tab are dead.

Comment 7

[Sid]

Playing with tabs a little bit, I surprisingly found the same amount of dead pixels on top _right_ corner of each tab. Anybody get this too?

Comment 8

[bgzllbs]

Yeah, there are dead pixels on the top right tab corner, but not as many as on the top left.

Comment 9

[Sid]

(In reply to comment #8)
Thanks for confirmation. I changed bug title accordingly.

Comment 10

[Florian J. [:FeuerFliege]]

Attachment: non-clickable gap

I marked the not clickable gap in this picture. There are 7px from the left edge, 8px from the left, plus 1px between the tabs.

Comment 11

[pumay]

On Windows XP, 1-2 pixels on top Tabs non-clickable. What do it?

Comment 12

[pino_sb]

I suppose this to be caused by the rather large border radii that have been defined here: http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#1557 ?? I don't know why these are larger than the actual radius of the tabs, but reducing them may fix this bug?

Comment 13

[Eamon Nerbonne]

I found this same bug and posted it as bug 638746 - that should probably be closed then.  

It's worth noting however that this bug is a fairly significant usability bug when closing tabs with the middle mouse button.  Try it - when you do occasionally the entire window "disappears", which is caused by accidentally clicking on these few pixels, which windows 7 interprets as "send to back".

Comment 15

[Sid]

Attachment: Removing border-radius from tabs

As suggested in comment #12, a possible solution is to completely remove top border radii from tabs (reducing it is not enough to fix the bug). Visible tab radius is almost unaffected by this (may be just a fraction of pixel).

Comment 16

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/dd2361d3b3f5

Comment 17

[Eamon Nerbonne]

Should this be in the nightly 2011-06-26?  I'm still seeing non-clickable areas.

Comment 18

[Sid]

(In reply to comment #17)
> I'm still seeing non-clickable areas.

My fault, didn't tested it enough. It seems to be working only if border-radius is specifically set to 0.

Comment 19

[Sid]

Attachment: Removing border-radius from tabs v2

Corrected version of patch.

Comment 20

[Dão Gottwald [:dao]]

Comment on attachment 542489 [details] [diff] [review]
Removing border-radius from tabs v2

The 2px radius might actually be a better trade-off, but we can try this as well.

Comment 21

[Sid]

(In reply to comment #20)
> The 2px radius might actually be a better trade-off, but we can try this as well.

Using 0px we can also roughly fix bug 649441, sacrificing a tiny bit of design for an improved usability.

Can we get it to Aurora builds? The possible impact may be some custom theme breaking, though I doubt it.

Comment 22

[Dão Gottwald [:dao]]

Third-party themes replace this file, so they're entirely unaffected.

Comment 23

[Dão Gottwald [:dao]]

Comment on attachment 542489 [details] [diff] [review]
Removing border-radius from tabs v2

1. I don't think this should land on mozilla-aurora
2. This patch won't apply cleanly on mozilla-aurora
3. It needs to land on mozilla-central first anyway

Comment 24

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/460c4b89c468

Comment 25

[AndreiD[QA]]

Verified fixed on the latest Nightly, on central
 Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110630 Firefox/7.0a1

Comment 26

[Eamon Nerbonne]

I've no idea about the implementation, but it sounds like this doesn't need to affect the design at all; if necessary, couldn't the click-able region be distinct from the visual region (e.g. which might be the clickable region's child and have things like border radius just for looks)?