Closed
Bug 401213
Opened 17 years ago
Closed 2 years ago
The full page zoom changes the size of XUL scrollbars with non-native themes
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
INVALID
People
(Reporter: spitfire.kuden, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [nv])
Attachments
(2 files, 1 obsolete file)
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.
Updated•17 years ago
|
Version: unspecified → Trunk
Updated•17 years ago
|
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
Reporter | ||
Comment 3•17 years ago
|
||
Native appearance scrollbar default/zoom in (scrollbar size is the same)
Reporter | ||
Comment 4•17 years ago
|
||
UL scrollbar zoom in/zoom out
Attachment #286268 -
Attachment is obsolete: true
Reporter | ||
Comment 5•17 years ago
|
||
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.
Comment 6•17 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Updated•17 years ago
|
Summary: full page zoom changes the size of XUL scrollbar → The full page zoom changes the size of 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?
Comment 8•17 years ago
|
||
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.
Flags: blocking1.9?
Comment 9•17 years ago
|
||
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...
Comment 10•17 years ago
|
||
+'ing this with P3. Neil, can you take a look at this?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Updated•17 years ago
|
Assignee: nobody → enndeakin
Comment 11•17 years ago
|
||
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.
Comment 12•17 years ago
|
||
So why do native scrollbars avoid this? Is there a way to piggy-back on their method?
Comment 13•17 years ago
|
||
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.
![]() |
||
Comment 14•17 years ago
|
||
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.
Comment 16•17 years ago
|
||
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?
Comment 17•17 years ago
|
||
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.
Updated•17 years ago
|
Flags: wanted1.9+
Comment 20•17 years ago
|
||
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.
Comment 21•17 years ago
|
||
(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.
Comment 25•16 years ago
|
||
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.
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
Comment 28•15 years ago
|
||
Noming for 1.9.2, since this now effects a default theme (Faststripe) on Windows CE.
Flags: blocking1.9.2?
Updated•15 years ago
|
Assignee: enndeakin → nobody
Component: GFX → XUL
Flags: blocking1.9.2? → blocking1.9.2+
Product: Core Graveyard → Core
QA Contact: general → xptoolkit.widgets
Comment 30•15 years ago
|
||
(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.
Whiteboard: [nv]
Comment 32•15 years ago
|
||
After triage discussion, this does not block 1.9.2.
Flags: blocking1.9.2+ → blocking1.9.2-
![]() |
||
Updated•14 years ago
|
Summary: The full page zoom changes the size of XUL scrollbars → The full page zoom changes the size of XUL scrollbars with non-native themes
Comment 35•14 years ago
|
||
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.
Updated•14 years ago
|
Comment 37•14 years ago
|
||
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.
Keywords: regression
Comment 40•10 years ago
|
||
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.
Updated•10 years ago
|
status-firefox35:
--- → affected
Comment 42•9 years ago
|
||
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?
Comment 43•9 years ago
|
||
This is still present in SeaMonkey 2.44a1 (Gecko/Toolkit 47.0a1). (Not that I'd expect it to disappear spontaneously.)
QA Whiteboard: [seamonkey-2.44-affected]
Updated•2 years ago
|
Severity: minor → S4
Comment 44•2 years ago
|
||
The severity field for this bug is relatively low, S4. However, the bug has 11 duplicates, 18 votes and 51 CCs.
:enndeakin, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(enndeakin)
Comment 45•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(enndeakin)
Comment 46•2 years ago
|
||
No longer applicable.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•