User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102601 Minefield/3.0a9pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102601 Minefield/3.0a9pre Full page zoom (Bug 4821 and Bug 389628) changes the size of XUL scrollbar (No native appearance scrollbar). (Full page zoom does not changes the size of Native appearance scrollbar.) Reproducible: Always Steps to Reproduce: 1. use Third party theme with XUL scrollbar 2. open some Web page to which scrollbar is displayed 3. press key 'Ctrl + +' or 'Ctrl + -'. 4. XUL scrollbar zoom in/out Actual Results: full page zoom changes the size of XUL scrollbar. Expected Results: full page zoom does not changes the size of XUL scrollbar.
I'm sorry. This screenshot is Littlefox for Firefox.
Created attachment 286293 [details] Winstripe Native appearance scrollbar default/zoom in (scrollbar size is the same)
Created attachment 286294 [details] Phoenity Modern XUL scrollbar zoom in/zoom out
Well, is this a specification? When fullpage zooming, the scrollbar size doesn't change in the native appearance scrollbar of Firefox 3, IE7, and Opera. When page zoom in, the large scrollbar narrows the content area. When page zoom out, the scrollbar is very small and hard to grasp. This is not used easily. Externals both look strange. People distinguish the user interface by look and feel, the size, and the position, etc. and recognize it. The XUL element that is not the native appearance on the content area zoom in/out by the full page zoom. It differs from other XUL elements, the scrollbar is always used in the Web browsing. The scroll bar should not receive the influence by the full page zoom.
Not sure why this bug was still unconfirmed, this is easy to check with any theme that uses XUL scrollbars (I just did that with the "NASA Night Launch" theme from https://addons.mozilla.org/en-US/firefox/addon/4908). It also affects the default OS/2 theme where we don't have anything else than the XUL scrollbars.
I can confirm that this bug exists in Windows XP as well. I have a number of themes with non-native scrollbars. They all show this effect. I have one theme - very similar in other ways to two other themes - which has native scrollbars. It does not show a change in scrollbar size, where its sibs with non-native scrollbars show this effect. This is a real problem with those of us who like to enlarge our text to read. Not only do the scrollbars crowd into the reading space as they enlarge, but the scrollbar buttons, being small raster images, get ugly as they are enlarged. Does this has any relation to bug #378272?
Ed, yes, bug 378272 and bug 399671 seem related indeed. But there the problem is that the DPI setting of the target device is used while for the full page zoom the DPI is just used as a base to apply extra scaling on top. So the fix _might_ be different, and this is not a pure duplicate of those bugs.
Oops, I actually wanted to comment that I nominate this for blocking as this is very annoying to theme developers who spent time to get nice looking scrollbars. And to users who spend time to search for a particularly cool theme and then are disappointed by any theme that use XUL scrollbars...
+'ing this with P3. Neil, can you take a look at this?
I don't think there's an easy fix for this, as the scrollbars are children of the frame, rather than part of the parent document, so they get sized according to the scale of the frame.
So why do native scrollbars avoid this? Is there a way to piggy-back on their method?
Native theme code returns widget sizes in device pixels which don't scale, whereas element using normal layout are calculated using CSS pixels. I investigated special-casing scrollbars to calculate sizes using device pixels. It becomes harder as scrollbars are made up of several pieces, <scrollbar>, <slider>, <scrollbarbutton> and <thumb> all of which need to be handled.
Can't <scrollbar> somehow inherit some "use device pixels" scheme to its descendants?
I don't think this should block. It's not easy to fix, it doesn't affect the default themes, it only happens when the user uses Full Zoom, and even then it isn't crippling. The cleanest way to fix this would probably be to add a new Mozilla-only unit for unscaled device pixels, that themes could use where necessary. But I'm afraid that Web sites might try to use it, even though they shouldn't ... so we'd have to restrict it to chrome-only or something, and that's more work. This should be "wanted", though, since we'd take a patch if someone produced one.
I would like to at least take a look because this hurts appearance on OS/2. But can somebody tell me where in the code the widgets that Neil points out in comment 13 are implemented?
It probably easier to implement a new unit type, for themes only, as roc suggests. The scrollbar implementation is in layout/xul/base/src/nsSliderFrame, and nsScrollbarFrame.cpp nsScrollbarButtonFrame.cpp. The <thumb> element is just a box.
-'ing based on comment #15.
Request this be marked as a regression.
I'm creating firefox theme. (http://fullflat.web.fc2.com/) (Latest Version:http://fullflat.web.fc2.com/full_flat3.0b1.4.jar), My theme is also troubled with this bug. I really want this bug fixed. Because, theme creator like as me will be claimed from many users.
(In reply to comment #15) > The cleanest way to fix this would probably be to add a new Mozilla-only unit > for unscaled device pixels, that themes could use where necessary. That doesn't solve the problem of scaled background images.
Quite nasty problem.
Even nastier: I use the All-in-One Gestures extension, which has the ability to enlarge text only with a scrollwheel gesture. That does not enlarge the scrollbars (when you want to enlarge an image, you put your cursor over the image and use the same gesture). Problem: when I close out a tab which has the text only enlarged, the next tab has everything enlarged, including scrollbars. I suppose I should file a bug on the stickiness of the enlargement setting, but I have Bug fatigue ATM.
Still present in the recently released Firefox 3.5
Noming for 1.9.2, since this now effects a default theme (Faststripe) on Windows CE.
(In reply to comment #28) > Noming for 1.9.2, since this now effects a default theme (Faststripe) on > Windows CE. adding [nv] in whiteboard.
After triage discussion, this does not block 1.9.2.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100701 Lightning/1.1a1pre SeaMonkey/2.1a3pre - Build ID: 20100701101320 I see this behaviour, and I like the visual indication that my current zoom factor is other than 100%. Obviously, some other users dislike the same behaviour, and I don't think it would be reasonable to say that "those who dislike it should use the default theme, and those who like it should use other themes". I wonder what would be best. -- Is this really a "major" bug (major loss of function)? Looks to me more like "trivial" (cosmetic problem like misspelled words or misaligned text) or "minor" at most (minor loss of function, or other problem where easy workaround is present). OTOH, the bug history shows alternating blocking+ and blocking-, usually set at different times by the same person, for various 1.9.x versions. OK, let's set status1.9.3? while waiting for the 2.0 flags to be added to BMO.
Please, give a little attention to this bug. It's very annoying. There are a lot of users using the page zoom feature in Firefox, these users of course blame theme developers that have chosen XUL scrollbars for their themes.
Note that this bug might affect/cause/relates to bug 1066934 where the scrollbar thumb could disappear with themed scrollbars and non-100% full page zoom level.
Could you program zooming so it specifically excludes <scrollbar>, and all related elements? As in, create an element blacklist of things to not be zoomed?
This is still present in SeaMonkey 2.44a1 (Gecko/Toolkit 47.0a1). (Not that I'd expect it to disappear spontaneously.)