User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030106 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030106 Now that forms are skinned via nsITheme, the rest of the browser that remains unthemed, most notably the scrollbars, stand out as being inconsistent. The few times I do run IE (for things like the Windows Update), it's nice to see a fully themed browser, including the scrollbars. Mozilla shouldn't keep using the old classic style scrollbars. Reproducible: Always Steps to Reproduce:

I think this has already been debated, can't remember the bug # for now.

Actually, listbox scrollbars ARE being themed, just not textarea scrollbars or regular browser scrollbars. Even if there's some reason to NOT theme the regular browser scrollbars - why are listbox scrollbars getting special treatment and not textarea scrollbars? Aren't those both form related elements? (I've done an additional Bugzilla search on WONTFIX and INVALID resolutions to "scrollbar" bugs but still not found an obvious dupe...)

*** This bug has been marked as a duplicate of 81722 ***

Um, no. First of all, bug 81722 was marked FIXED on December 4th of last year - and what I'm reporting is not fixed. Secondly, this bug is not about the just the "Windows classic background colour". It's about Classic, Modern, and all other custom themes, in addition to more than just the colour. I'm attaching a screenshot. I'm using a custom Windows theme along with Mozilla's modern theme. Notice that the listbox scrollbars are themed, while the regular browser scrollbars are not.

Browser scrollbars and textbox scrollbars are skinned when you use the Classic theme or any other skin that uses nsITheme. The modern theme skins them itself therefore doesn't use nsITheme.

Aha! Okay, then. I'll reword the summary here appropriately. And, to rephrase my comments, based on this information, Mozilla's Modern theme should use nsITheme, just as does Mozilla's Classic theme, and should NOT skin the scrollbars itself. It doesn't make any sense that, unlike the Classic theme, the Modern theme would use nsITheme for skinning form elements - but not for textbox scrollbars (also a form element) or for browser scrollbars.

And since this is specific to the Modern theme. -> Themes

Jason, agreed. I think the real bug is that Modern uses nsITheme for form controls, but I suppose it's really a matter of opinion. Either way, consistency would be better than the mismatch we have now.

I haven't seen a bug yet requesting that Modern do away with nsITheme for form controls. However, in my mind, that would be an even *bigger* inconsistency between Classic and Modern. Whatever one does, they should both do. (So, in other words, banish nsITheme completely, from both, or implement it completely, in both. This bug is about the latter.)

Classic uses nsITheme for everything, and that's really the point of Classic: to look like other apps on the system. Modern is its own look and it's not supposed to blend in with other apps on the system. The Modern scrollbars match the rest of the Modern chrome, and I think that's the proper way for it to look. If Modern used nsITheme for everything Classic uses it for, it wouldn't be Modern anymore, it would be Classic with different toolbar button pictures.

As far as I'm concerned, the only difference between themes should be the toolbars, buttons, etc. The actual Windows elements should follow nsIThemes. Mozilla with Modern is a big sore them in that it's the ONLY app I run whose scrollbars are not themed. If all I wanted were those elements themed, I'd use Classic. But there IS a difference between the two and I can't stand the Classic toolbars, buttons, etc. In any case, further argument should be taken elsewhere - another bug to remove all nsITheme support from Modern, newsgroups, or offline private email.

s/sore them/sore thumb/g (Hurry up bug 540!)

I am very happily, yet in puzzlement/astonishment, resolving this bug as WORKSFORME. I just today removed my install of Mozilla via Add/Remove programs, deleted all remaining Mozilla files on my HD (except for my profile directory and plugins) and installed the 1/9/08 build (for another reason than this bug). Oh, and I also created a new profile, used it, then deleted it. So, don't ask me which of these things were responsible, but... Voila! I now have themed scrollbars in all screen elements (textbox scrollbars and browser scrollbars) when using the Modern theme. I don't see any other bugs checked in today that would have caused this fix, so I can only assume it was leftover cruft from my installing nightlies on top of existing installs. Although I'm still a little puzzled why this bug didn't get a lot of WFM comments. (Nor do I quite understand what cruft it could have been that should have been fixed in a recent weeks checkin without me seeing it since I DO perform totally clean installs every couple of weeks.) If there WAS some fix checked in today (or recently), this bug should be reopened and resolved FIXED rather than WORKSFORME.

Further analysis: It was not the latest build nor the clean install that fixed the problem. Trying Mozilla from my wife's XP login (a different Windows profile so a different set of Mozilla profiles), I saw that she still had the old unthemed scrollbars - despite the new Mozilla install. To get Mozilla the use nsITheme with all scrollbars under her login I did the following: 1. Create a new Mozilla profile. 2. Run Mozilla under this new profile. Leave everything at defaults (Classic theme, etc., no need to browse anywhere). 3. Exit Mozilla. 4. Delete new profile. Now, running my wife's profile, all scrollbars were themed under Modern without changing anything. Perhaps this is a bug in terms of what Mozilla *should* be doing, but I'm not complaining.

Whoa! Reopening. Scrollbars are now unthemed again. But I have a 100% reproducible way of getting them themed. It's not the creation and deletion of a new profile that does it. Run Mozilla via "mozilla -profilemanager". If you do that, all scrollbars are themed under Modern. It's not enough to run it with "mozilla -P "profile". It ONLY works if you go through the Profile Manager interface. This is probably the strangest glitch I've yet seen. Now if we can only get them themed all the time regardless of how Mozilla is started.

With the latest builds, the above "bug" of launching Mozilla via the Profile Manager doesn't theme the scrollbars, so this is no longer a workaround.

Tweaking subject for better Bugzilla queries.

Apparently scrollbars in form elements (listboxes) never used nsITheme under Modern either, but the "platform native scrollbars" (even though this looked just the same, and bug 169373 implied that it was being used)...

Scrollbars in Mozilla 1.4b for single selection boxes and textareas are also not properly skinned - they use the default Windows scrollbar (XP in this case). Screenshot attached. Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507

*Correction* The actual scroll bars are now skinned properly. However, the arrow in a single selection list still uses the system's default scroll bar. Screenshot attached.

Max: You are addressing something that's the *opposite* of this bug. This bug is not about *using* Mozilla's skin but getting rid of it. This is about using system default skinning for all form elements (currently form scrollbars are the only form elements not using the system default skin). What you are pointing out is off-topic for this bug - although you are welcome to open a separate bug if you wish. (Which would be in opposition to this one, but don't let that stop you. <grin>)

Er - correction (on my part this time). It's bug 201525 that address form scrollbars using native Windows themes. (Which blocks this one, and which I also filed, hence my confusion.) This bug is actually JUST about getting the main browser scrollbars to use the native Windows theme rather than having them be skinned via Mozilla.

which i think is not a bug at all and is behaving properly and as intended right now.

Sorry guys, I misunderstood the bug title :)

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420