247161 - scrollbar arrows rendered incorrectly with <meta http-equiv="MSThemeCompatible" content="no"/>

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect, P3)

Description

[Lukas Petrovicky (CZilla)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 (JTw)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 (JTw)

if you look on scrollbar arrows on the supplied URL (doesn't matter if they're
main page scrollbars or scrollbars in a text-area), you'll see that they're
smaller than usual and are on a different place (attached image).

I noticed this only on a given site and only with the latest release (0.9), no
nightlies did this before.

also, it's not caused by extensions, because I use the same sort of extensions
for more than 14 days and these problems occured only few days ago.

Reproducible: Always
Steps to Reproduce:
1. just take a look at the URL

Actual Results:  
scrollbars are rendered incorrectly

Expected Results:  
scrollbars should be rendered as they're rendered wherever else.

Comment 1

[Lukas Petrovicky (CZilla)]

Attachment: here, you can see what do I talk about

Comment 2

[Martijn Wargers (dead)]

It's because you have this in your html-code:
<meta http-equiv="MSThemeCompatible" content="no">
See bug 222888 for more info on this.
But the scrollbar arrow is rendered in the wrong at the wrong place still.

Comment 3

[Peter Weilbacher]

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7) Gecko/20040629 Firefox/0.9.1

I see the same thing on OS/2 with a fresh profile. Not sure that this is the
same bug, because for me it is not related to a specific webpage (there is no
MSThemeCompatible in the source of the Firefox start page). I see this even on
very simple ones like http://www.uni-sw.gwdg.de that do not use CSS.

I only see this with the default Firefox theme, others (e.g. Qute) are OK. If I
could get the DOM-Inspector to tell me the ID of the arrow buttons, I would
start to investigate why they are off center.

Comment 4

[PikeUK]

This happened because Winstripe shrank the size of the arrow buttons causing
them not to take up the whole space in scrollbars (this is only visible when
Firefox itself is drawing the bars, rather than the OS). Replacing the arrow
icons with the ones from the suite fixes the problem. See also Bug 250355.

Confirming on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040707
Firefox/0.9.0+

Comment 5

[Mike Connor [:mconnor]]

Kevin, is this on your radar yet?

Comment 6

[Mike Connor [:mconnor]]

reassing to Kevin, this is not super-high priority, but there's some weirdness here.

Comment 7

[Nian Liu(n/a in a long time)]

WFM, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 Firefox/0.9.1+

Comment 8

[Peter Weilbacher]

Nian, I think this was never a problem on Linux (Unix?). FF seems to use native
GTK scrollbars there (at least that's what they look like), so the arrows always
appear centered and in the right proportions.
With yesterday's build I could still see the problem on OS/2.

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

Not a "blocker"

Comment 10

[PikeUK]

*** Bug 262990 has been marked as a duplicate of this bug. ***

Comment 11

[David Elliott Bell]

Same problem on some sites (Wall Street Journal, bugzilla.mozilla.org) with
Firefox 1.0 preview running on Mac OS X 10.3.5.  Other sites do not exhibit this
behavior (my site, www.star-property.com).

Comment 12

[Peter Weilbacher]

Attachment: scrollbars.css change to correct scrollbar position

This might not be a good fix for the problem on Windows where it only occurs on
certain websites. But it most definitely improves the situation on OS/2 in that
it puts the arrows closer to the center of the buttons, so that they look more
natural.

Comment 13

[José Jeria]

Kevin, any chance in getting this trivial issue for 1.5?

Comment 14

[Ronny Perinke]

Attachment: updated patch; diff against current MOZILLA_1_8_BRANCH

Comment 15

[Mike Kaply [:mkaply]]

It's easy to make this happen on Windows XP:

create a userContent.css with:

* { -moz-appearance: none !important; }

I did a simpler fix for this in:

https://bugzilla.mozilla.org/show_bug.cgi?id=314982

Comment 16

[Peter Weilbacher]

Attachment: simplify patch, similar fix for qute

OK, this takes mkaply's simpler patch from bug 314982 (attachment 201777 [details] [diff] [review]) and extends it also to qute which fixes a similar issue in Thunderbird, too. I guess the html|div scrollbarbuttons also need the same fix, hence I included that in this patch, too.

Comment 17

[Peter Weilbacher]

*** Bug 314982 has been marked as a duplicate of this bug. ***

Comment 18

[Peter Weilbacher]

Problem not only occurs on WinXP with special HTML page content, but also more generally on Win98 (Bug 314982) and OS/2.

Comment 19

[Kevin Gerich]

Comment on attachment 211528 [details] [diff] [review]
simplify patch, similar fix for qute

Looks good. Thanks for the patch. Just to clarify: This issue exists in Qute/Thunderbird as well? If not, let's check in just the Winstripe change. Also, we don't need a ui-review on this trivial bug.

Comment 20

[Peter Weilbacher]

Attachment: TB screenshot with off-center scrollbar arrow

Thanks a lot Kevin, for looking at this long overdue bug.

Yes, it does happen for TB, as you can see in this screenshot. At least on OS/2. Hmm, but now that you ask I finally notice that it only happens for the downwards arrow. The reason is that the down one (arrow-dn*.gif) is 5x11px while the up one (arrow-up*.gif) is 11x11px. If there is no good reason for this difference then I can try to convert the up arrows into down arrows and attach them for Qute, instead of patching the CSS.

Comment 21

[Peter Weilbacher]

Kevin, did you decide which way to go (CSS fix as in attachment 211528 [details] [diff] [review] or editing of the PNGs)? If the CSS changes are the way to go, could you please check them in?

Comment 22

[Peter Weilbacher]

As there is no progress here I will (try to) solve this in a platform specific manner on OS/2 in Bug 336997 instead.

Comment 23

[IU]

This bug still exists and looks like it's destined for 2.0

Comment 24

[j.j.]

Attachment: simple testcase

Comment 25

[j.j.]

Someone with rights should add "testcase" keyword and change product/component to core/themes.

Comment 26

[Lukas Petrovicky (CZilla)]

Not reproducible on Linux, marking this as Windows-specific.

Comment 27

[Nicholas Furgiuele]

This bug still appears in latest Firefox trunk nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070628 Minefield/3.0a6pre

as well as Firefox 2.

Example URL:
http://www.xboxworld.com.au/

Comment 28

[Jonathan Haas]

This is a trivial bug with a patch and some sites look very odd with it.

I suggest to either fix this bug or drop "support" for MSThemeCompatible as it seems useless and not in any standard.

Comment 29

[Daniel.S]

The reason behind MSThemeCompatible is understandable. However, it is actually causing nothing but ugliness (to the user) which clearly isn't intended.

The bug caused by this appears every once in a while on forums, etc.

Like Jonathan says: It should be fixed or removed. To keep the buggy state is not the way to go.

Comment 30

[Jonathan Haas]

There is another reason, why the current implementation is ugly.

If there is any site, which is incompatible with native controls and the author uses MSThemeCompatible to disable native theming, then Linux and Mac people will still see the native controls and probably will have the same rendering problems as the windows people would have.

So I think there are two solutions: 

1. Drop support for MSThemeCompatible. I think that this is the best solution, because I think, that fixing the scrollbars maybe difficult, and I can't think of any reason, why native controls would make any problems.

2. Make MSThemeCompatible work ans let it also apply on Linux and Mac controls. I don't like this because it says _MS_ThemeCompatible (there is no LinuxThemeCompatible, is it?) and I think it would be easier for Firefox 3 to just remove support instead of this larger change.

Comment 31

[philippe (part-time)]

(In reply to comment #30)

1. It (MSThemeCompatible) actually applies on Mac.
2. When present, the scrollbars vanish completely (on Mac). See bug 420363. Form controls also suffer some usability issues.

Comment 32

[Daniel.S]

Why was this moved to SeaMonkey?

The testcases clearly show that this is a Gecko problem drawing the scrollbars. (the problem is visible in most Gecko based browsers).

Comment 33

[Kai Liu]

(In reply to comment #32)
> Why was this moved to SeaMonkey?
> 

Fallout from the BMO reorg (for which there is a notice at the top of this page).
https://bugzilla.mozilla.org/show_bug.cgi?id=bmo-reorg

Comment 34

[Daniel.S]

(In reply to comment #33)
> Fallout from the BMO reorg (for which there is a notice at the top of this
> page).

I though so at first, but in the Bug Activity page the change was dates to 2008-06-29 so I guesst I couln't have been the reorg. Well anyway, sorry for bugspam.

Comment 35

[Samuel Sidler (old account; do not CC)]

Not going to block a maintenance release on a long-standing issue.

Comment 36

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch for toolkit applications v1.0

This patch fixes this bug on all toolkit applications.
# I'm not sure why attachment 211528 [details] [diff] [review] is not in trunk.

However, I think that this approach is wrong. If theme is disabled, we should render the widgets with classic widget rendering methods in nsNativeThemeWin. But this patch is enough for now.

Comment 37

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

gavin: would you review the patch?

Comment 38

[Neil Deakin]

Comment on attachment 342733 [details] [diff] [review]
Patch for toolkit applications v1.0

Looks OK, but I think the other Neil should review as well.

Comment 39

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

landed.