Closed Bug 358632 Opened 13 years ago Closed 12 years ago

XUL tab rendering on Windows


(Core :: Widget: Win32, defect)

Not set





(Reporter: beerfan, Unassigned)




(8 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Ever since Qute was made the default theme, the tab styles in global/tabbox.css have made all tabs other than the browser tabs (e.g. those in the preferences and page info windows) render with incorrect padding causing them to bounce around when selected (on all platforms and window manager themes). I will attach screenshots which demonstrate this.

Reproducible: Always

Steps to Reproduce:
1. Right-click a webpage and select "View Page Info"
2. Note the positioning of the tabs at the top of the window
3. Click the "Forms" tab and witness all tabs to the right of it shift 2 pixels to the right

Expected Results:  
Native tab widgets do not cause other tabs to move around when they are clicked. They shift the tab text up 1 pixel and the tabs absorb any changes in size in order to defeat any shifting.
Updating version. The patch was made against the Firefox 2.0 release classic theme because I couldn't immediately find out where it exists in cvs now.
Version: unspecified → 2.0 Branch
Blocks: 122248
Component: General → Widget: Win32
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → win32
Summary: [winstripe] Global tabs (not browsertabs) are styled incorrectly → XUL tab rendering on Windows
Version: 2.0 Branch → Trunk
Duplicate of this bug: 254760
Duplicate of this bug: 271146
This patch has been written while fixing bug 265698 on linux since it wasn't costly to do adapt the gnomestripe CSS to winstripe. It may be helpfull to solve the bug here (perhaps it is even sufficient, it depends on the native rendering part that I cannot test, not having Windows)
Attached image Current rendering
Attached image Rendering with patch
I don't make builds myself.  So instead I edited tabbox.css myself making the changes from the patch.
Note: Those screenshots were with Windows set to Extra Large Fonts.  
So this is not completely enough, but it's a good start. Brian: how does this compares with tabs in other apps ?
Attached image native tabs
The main problem I see is the focus ring.  It should not overlap the orange at the top.
The overlap with the orange does not happen with normal font size.  But the missing border pixel is still there.  Maybe that's a pixel rounding problem. ??
First thing to notice is that the first tab isn't aligned with the tabpanel border when it is unselected. I don't know how it looks like when selected.
By the way, could someone with a Classic theme (does it exist at all in Windows Vista ?) test with this patch, since we are aiming at pixel perfection with classic when native rendering is disabled ? (compare with native tabs, with first tab selected, then with second or third)

The second thing to notice is that the missing pixel border probably isn't really missing, it could just be that the native tab drawing doesn't take into account the possibility of being aligned with the tabpanel border, see what the patch of bug 265698 did in gtk2drawing.c (moz_gtk_tab_paint) to manage that.
That means that a correct fix for this bug wouldn't only be in CSS.

Such a fix should be tested with at least every default theme shipped with windows, and perhaps also with WindowBlinds-like themes ?
Shouldn't this bug marked as blocking1.9?
No longer blocks: 122248
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 271146
You need to log in before you can comment on or make changes to this bug.