401213 - The full page zoom changes the size of XUL scrollbars with non-native themes

Status: RESOLVED INVALID

(Core :: XUL, defect, P3)

Description

[AKIHIRO Misaki (a.k.a Kuden)]

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.

Comment 1

[AKIHIRO Misaki (a.k.a Kuden)]

Attachment: Screenshot

Nautipolis for Firefox

Comment 2

[AKIHIRO Misaki (a.k.a Kuden)]

I'm sorry. This screenshot is Littlefox for Firefox.

Comment 3

[AKIHIRO Misaki (a.k.a Kuden)]

Attachment: Winstripe

Native appearance scrollbar
default/zoom in (scrollbar size is the same)

Comment 4

[AKIHIRO Misaki (a.k.a Kuden)]

Attachment: Phoenity Modern

UL scrollbar
zoom in/zoom out

Comment 5

[AKIHIRO Misaki (a.k.a Kuden)]

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

[Peter Weilbacher]

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.

Comment 7

[Ed Hume]

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

[Peter Weilbacher]

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.

Comment 9

[Peter Weilbacher]

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

[Damon Sicore (:damons)]

+'ing this with P3.  Neil, can you take a look at this?

Comment 11

[Neil Deakin]

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

[Ed Hume]

So why do native scrollbars avoid this? Is there a way to piggy-back on their method?

Comment 13

[Neil Deakin]

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

[Robert Kaiser]

Can't <scrollbar> somehow inherit some "use device pixels" scheme to its descendants?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Peter Weilbacher]

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

[Neil Deakin]

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.

Comment 18

[Damon Sicore (:damons)]

-'ing based on comment #15.

Comment 19

[Ed Hume]

Request this be marked as a regression.

Comment 20

[fullflat_firefox]

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

[[e-mail]]

(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 24

[DonGato]

Quite nasty problem.

Comment 25

[Ed Hume]

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.

Comment 26

[DonGato]

Still present in the recently released Firefox 3.5

Comment 28

[Justin Dolske [:Dolske]]

Noming for 1.9.2, since this now effects a default theme (Faststripe) on Windows CE.

Comment 30

[Tony Chung [:tchung]]

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

Comment 32

[Johnathan Nightingale [:johnath]]

After triage discussion, this does not block 1.9.2.

Comment 35

[Tony Mechelynck [:tonymec]]

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.

Comment 37

[Pardal Freudenthal (:ShareBird)]

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.

Comment 40

[Avi Halachmi (:avih)]

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.

Comment 42

[rexyrexy2]

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

[Tony Mechelynck [:tonymec]]

This is still present in SeaMonkey 2.44a1 (Gecko/Toolkit 47.0a1). (Not that I'd expect it to disappear spontaneously.)

Comment 44

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 45

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 46

[Gregory Pappas [:gregp]]

No longer applicable.