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.
Confirming. Doesn't affect buttons placed on the tabs toolbar, just the tabs themselves, including app tabs.
Unclickable area is actually a window drag surface for Aero Snap in Win7, apparently.
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?
(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.
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?
Yeah, there are dead pixels on the top right tab corner, but not as many as on the top left.
(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.
On Windows XP, 1-2 pixels on top Tabs non-clickable. What do it?
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?
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".
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).
Should this be in the nightly 2011-06-26? I'm still seeing non-clickable areas.
(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.
Created attachment 542489 [details] [diff] [review] Removing border-radius from tabs v2 Corrected version of patch.
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.
(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.
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
Verified fixed on the latest Nightly, on central Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110630 Firefox/7.0a1
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)?