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

VERIFIED FIXED in Firefox 7

Status

()

Firefox
Theme
VERIFIED FIXED
7 years ago
4 years ago

People

(Reporter: Sid, Assigned: Sid)

Tracking

unspecified
Firefox 7
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
Created attachment 502320 [details]
That tiny red area is non-clickable
(Assignee)

Updated

7 years ago
Blocks: 572160
Confirming.

Doesn't affect buttons placed on the tabs toolbar, just the tabs themselves, including app tabs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Unclickable area is actually a window drag surface for Aero Snap in Win7, apparently.

Comment 4

7 years ago
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).
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?
(Assignee)

Comment 6

7 years ago
(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.
(Assignee)

Comment 7

7 years ago
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

7 years ago
Yeah, there are dead pixels on the top right tab corner, but not as many as on the top left.
(Assignee)

Updated

7 years ago
Summary: There is a non-clickable area on the top left corner of each tab, when tabs are drawn in titlebar → Non-clickable areas on both top corners of each tab and "New Tab" button
(Assignee)

Comment 9

7 years ago
(In reply to comment #8)
Thanks for confirmation. I changed bug title accordingly.
Created attachment 502341 [details]
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

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

Comment 12

6 years ago
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

6 years ago
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".

Updated

6 years ago
Duplicate of this bug: 638746
(Assignee)

Comment 15

6 years ago
Created attachment 541858 [details] [diff] [review]
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).
Attachment #541858 - Flags: review?

Updated

6 years ago
Attachment #541858 - Flags: review? → review+

Updated

6 years ago
Assignee: nobody → pawsome
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/dd2361d3b3f5
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7

Comment 17

6 years ago
Should this be in the nightly 2011-06-26?  I'm still seeing non-clickable areas.
(Assignee)

Comment 18

6 years ago
(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.
(Assignee)

Updated

6 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

6 years ago
Attachment #541858 - Attachment is obsolete: true
(Assignee)

Comment 19

6 years ago
Created attachment 542489 [details] [diff] [review]
Removing border-radius from tabs v2

Corrected version of patch.
Attachment #542489 - Flags: review?
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.
Attachment #542489 - Flags: review? → review+

Updated

6 years ago
Keywords: checkin-needed
(Assignee)

Comment 21

6 years ago
(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.
Third-party themes replace this file, so they're entirely unaffected.
(Assignee)

Updated

6 years ago
Attachment #542489 - Flags: approval-mozilla-aurora?
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
Attachment #542489 - Flags: approval-mozilla-aurora?
http://hg.mozilla.org/mozilla-central/rev/460c4b89c468
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED

Comment 25

6 years ago
Verified fixed on the latest Nightly, on central
 Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110630 Firefox/7.0a1
Status: RESOLVED → VERIFIED

Comment 26

6 years ago
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)?

Updated

5 years ago
Duplicate of this bug: 218701
You need to log in before you can comment on or make changes to this bug.