358632 - XUL tab rendering on Windows

Status: RESOLVED DUPLICATE of bug 271146

(Core :: Widget: Win32, defect)

Description

[Chris Cook]

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.

Comment 1

[Chris Cook]

Attachment: image showing the bug and fix on Gnome

Comment 2

[Chris Cook]

Attachment: image showing the bug and fix on Windows

Comment 3

[Chris Cook]

Attachment: This patch adjusts the padding to resolve the issue. It has no effect on browser tabs.

Comment 4

[Chris Cook]

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.

Comment 7

[Julien "_FrnchFrgg_" RIVAUD]

Attachment: Redo CSS for tabboxes in winstripe

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)

Comment 8

[Brian Polidoro]

Attachment: Current rendering

Comment 9

[Brian Polidoro]

Attachment: Rendering with patch

I don't make builds myself.  So instead I edited tabbox.css myself making the changes from the patch.

Comment 10

[Brian Polidoro]

Note: Those screenshots were with Windows set to Extra Large Fonts.  

Comment 11

[Julien "_FrnchFrgg_" RIVAUD]

So this is not completely enough, but it's a good start. Brian: how does this compares with tabs in other apps ?

Comment 12

[Brian Polidoro]

Attachment: native tabs

The main problem I see is the focus ring.  It should not overlap the orange at the top.

Comment 13

[Brian Polidoro]

Attachment: Rendering with patch - normal fonts

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. ??

Comment 14

[Julien "_FrnchFrgg_" RIVAUD]

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 ?

Comment 15

[Filippo]

Shouldn't this bug marked as blocking1.9?