Scrollbar arrows need some tweaking to properly match the appearance of the native Windows appearance.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

I think the track is affected too. Ignoring other subtle differences, it looks like it’s drawing the track and arrows one device pixel smaller than they should be, effectively leaving a white pixel border; but the thumb is drawn at the full expected width (17px), causing it to seem to jut out into the page, when combined with a white page background. I have been finding this surprisingly disconcerting even on a 2× display!

Stephen, after speaking with you I get the impression that we might want to get a decision from you around scrollbars too. How should we style them on Windows?

Adjusting bug title to reflect the reality that we will want to fine-tune scrollbars entirely (not just arrows) to match the Windows 10 style, which is is expected to be one of the next platforms to see non-native theming enabled.

Tracking non-native theming bugs for Fission Beta milestone (M7).

Stephen, while testing non-native theming on Windows 10, I noticed that:

• Native scrollbar' scroll thumb and gutter have a one-pixel border, while non-native scrollbars have no border.
• Native scrollbars' arrow buttons have NO border between the arrow button and scroll thumb, while non-native scrollbars HAVE a one-pixel border between the arrow button and scroll thumb.

See the attached screenshot comparing a native scrollbar on the left with a non-native scrollbar on the right.

Does your patch fix these scrollbar issues? Or should I file a new bug?

(In reply to Chris Peterson [:cpeterson] from comment #9)

Created attachment 9197999 [details]
screenshot_left-native_right-nonnative.jpg

Stephen, while testing non-native theming on Windows 10, I noticed that:

• Native scrollbar' scroll thumb and gutter have a one-pixel border, while non-native scrollbars have no border.

Unfortunately, as I had to find out the hard way, there is a wide range of discrepancies between scrollbars on Windows 10. Just compare the scrollbars in the File Explorer, Firefox, Microsoft Edge, Terminal etc. So even though the scrollbars in Firefox used to have a one pixel border, the new non-native scrollbars might actually align more with the native Windows 10 style. Since UX has given us some flexibility to make decisions based on our best assumptions, I believe that this is acceptable for now (if not the solution that we'd settle on anyway after having conversations with UX).

• Native scrollbars' arrow buttons have NO border between the arrow button and scroll thumb, while non-native scrollbars HAVE a one-pixel border between the arrow button and scroll thumb.

I could go either way on this one.

See the attached screenshot comparing a native scrollbar on the left with a non-native scrollbar on the right.

Does your patch fix these scrollbar issues? Or should I file a new bug?

If you feel strongly that we should change this, I suggest that we file new bugs that don't block the initial rollout of non-native theming in Nightly on Windows, but the more general non-native theming efforts (so blocking bug 1615105 or even bug 1535761 instead of bug 1687022) and get UX's input on these questions. My personal opinion is that we shouldn't block on rolling non-native theming out to Nightly and delay the gathering of feedback because of this.

The only other thing that I intend to fix in this bug is to tweak the arrows on the arrow buttons to more closely align with the native arrows (which vary widely depending on app as well, unfortunately).

(In reply to Stephen A Pohl [:spohl] from comment #10)

(In reply to Chris Peterson [:cpeterson] from comment #9)

Created attachment 9197999 [details]
screenshot_left-native_right-nonnative.jpg

Stephen, while testing non-native theming on Windows 10, I noticed that:

• Native scrollbar' scroll thumb and gutter have a one-pixel border, while non-native scrollbars have no border.

Unfortunately, as I had to find out the hard way, there is a wide range of discrepancies between scrollbars on Windows 10. Just compare the scrollbars in the File Explorer, Firefox, Microsoft Edge, Terminal etc. So even though the scrollbars in Firefox used to have a one pixel border, the new non-native scrollbars might actually align more with the native Windows 10 style. Since UX has given us some flexibility to make decisions based on our best assumptions, I believe that this is acceptable for now (if not the solution that we'd settle on anyway after having conversations with UX).

Inconsistencies in Microsoft's user interfaces? No way! :)

If you feel strongly that we should change this, I suggest that we file new bugs that don't block the initial rollout of non-native theming in Nightly on Windows, but the more general non-native theming efforts (so blocking bug 1615105 or even bug 1535761 instead of bug 1687022) and get UX's input on these questions. My personal opinion is that we shouldn't block on rolling non-native theming out to Nightly and delay the gathering of feedback because of this.

I don't have strong opinions. I won't bother filing bugs. If anyone else notices these pixel issues and files a bug, we can discuss then. In fact, I prefer the border-less scrollbars of the non-native theme. :) The one-pixel border is so thin it looks like a rendering glitch to me.

One new difference I noticed: the non-native scrollbars are narrower and have smaller arrow buttons than the native scrollbars. This is more than just looks. It affects the usability of the scrollbars.

Does your patch here fix the scrollbar width? If not, then I will file a new bug (but, as you recommend, won't make it block shipping).

(In reply to Chris Peterson [:cpeterson] from comment #11)

One new difference I noticed: the non-native scrollbars are narrower and have smaller arrow buttons than the native scrollbars. This is more than just looks. It affects the usability of the scrollbars.

Does your patch here fix the scrollbar width? If not, then I will file a new bug (but, as you recommend, won't make it block shipping).

Do you have display scale applied? If so, you might be experiencing what's been mentioned in bug 1657191 comment 15 and following. I believe this merits a bug in its own right since it seems related to how scaling works. The expectation is that at 100% scale, scrollbars have the correct size with the patch here.

(In reply to Stephen A Pohl [:spohl] from comment #12)

(In reply to Chris Peterson [:cpeterson] from comment #11)

One new difference I noticed: the non-native scrollbars are narrower and have smaller arrow buttons than the native scrollbars. This is more than just looks. It affects the usability of the scrollbars.

Does your patch here fix the scrollbar width? If not, then I will file a new bug (but, as you recommend, won't make it block shipping).

Do you have display scale applied? If so, you might be experiencing what's been mentioned in bug 1657191 comment 15 and following. I believe this merits a bug in its own right since it seems related to how scaling works. The expectation is that at 100% scale, scrollbars have the correct size with the patch here.

Yes. I think this is a display scaling issue, but it appears to be fixed in your Try build. So I don't think we need a new bug for this scaling issue, but I've changed my mind about filing a bug for one-pixel border issue (but not block shipping non-native theming).

My Windows display scaling ("Change the size of apps and text on main display" system setting) is "250% (Recommend)", the default on my HiDPI Windows 10 laptop. If I set scaling to 100%, the native and non-native scrollbars have the same width using your Try build (though the non-native scrollbars still appear narrower because of the one-pixel border) but regular Nightly builds have a different widths. (The Windows UI is too tiny to be usable on my laptop screen at 100% scaling, but I can see the page layout shift horizontally in the regular Nightly builds and not in your Try build.)

Depends on D102100

Chris, here is a new try build to test out the new arrow styling. It may not be 100% perfect just yet, but hopefully good enough to give this a first go on Nightly:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bBN_VdCSQNSUOj5o8YuW3g/runs/0/artifacts/public/build/target.zip

(In reply to Stephen A Pohl [:spohl] from comment #15)

Chris, here is a new try build to test out the new arrow styling. It may not be 100% perfect just yet, but hopefully good enough to give this a first go on Nightly:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bBN_VdCSQNSUOj5o8YuW3g/runs/0/artifacts/public/build/target.zip

Is there a specific issue you'd like me to look at? I tested your new Try build and the scrollbars and arrow buttons look OK. I don't see any problems that should delay you landing your work.

In your Try build, the highlight when clicking the non-native arrow button is now the full width of the scrollbar, whereas regular Nightly without your patch has a narrower highlight. The new highlight looks better. The highlight of a clicked native arrow button has a one-pixel border, like the scrollbar thumb.

When I zoom the screen (using the Windows-+ keyboard shortcut), the zoomed non-native arrow style is fuzzier than the zoomed native arrow style. I think the non-native arrow has a steeper slope that causes some aliasing when zooming the screen. Just something to note. I don't think that's worth a bug.

The non-native scrollbars are now the same width as the native scrollbars, which is good. (The native scrollbars appear narrower because they have a one-pixel border around the scroll thumb, but we've decided that's not worth a bug unless someone else reports it).

Thanks, Chris. There wasn't any particular issue to look into. I simply wanted to give you a heads up in case you wanted to take this for a spin for yourself. The patches are about to land. Thanks again for all your input!

https://hg.mozilla.org/mozilla-central/rev/73d477e26331
https://hg.mozilla.org/mozilla-central/rev/d5e4017e14dd