515535 - Always draw scrollbar thumb grippy lines even to 15px (or Windows minimum size)

Status: UNCONFIRMED

(Core :: Widget: Win32, defect)

Description

[[not reading bugmail]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090909 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090909 Minefield/3.7a1pre (.NET CLR 3.5.30729)

Discuss bug 502292 comment 25: should we always draw scrollbar thumb grippy lines even at the minimum size of 15px?  

"Windows apps are not consistent for this behavior, IE always draws the grippy
lines but notepad doesn't when the thumb size is less than 17px."  [Is notepad an outdated comparison?]

"Bug 502292 asks the Windows theme about the minimum thumb size and
uses that value.

On the other hand, the grippy lines are only drawn if there are enough room
(that check was introduced in bug 448704).

It happens that at 96 dpi the minimum thumb size returned by Windows is 15px
and the check to see if there's enough room to drop the grippy lines returns
false so they are not drawn.

If the content to be scrolled makes the thumb be sized to 16px, the grippy
lines are drawn.

Note that if you have your system configured to more than 96dpi, the grippy
lines are always visible. using 110% font size always shows the
grippy lines (the thumb minimum size is 17px in that case).

But maybe we should always draw the grippy lines even if the thumb size is 15px
large. That's what Chrome does apparently."


Reproducible: Always

Steps to Reproduce:
1. using 96 dpi, default theme, Vista, 1024x768 resolution
2. Open latest trunk, load bug 435296 for example (or very long webpage)
3. observe thumb at minimum size
Actual Results:  
Grippy lines disappear

Expected Results:  
Maybe grippy should/can always be visible

see bug 502292 and bug 448704

Comment 1

[Kai Liu]

I think that this should be a WONTFIX for two reasons:

1) The difference between IE and Notepad is that Notepad uses native widgets and controls.  All browsers (including IE, Firefox, Chrome, and Opera) use their own custom widgets and controls that *mimics* the appearance of native Windows controls.  IE's mimicry is surprisingly poor, which is why it draws the gripper.  And native isn't "outdated"; "modern" native UIs like the new Windows Control Panel or the new Start Menu does exactly what Notepad does.  Our goal is to mimic native apps as best as possible, and to that end, we should be looking at other native apps, like Windows Explorer and Notepad for guidance, not IE, Chrome, or Safari.  If they are all drawing grippers, then they are all at fault.

2) We should never make assumptions about the size and required margins of the gripper and we should always use the data that uxtheme provides programmatically.  Although Microsoft does not officially support third-party Windows themes, many do exist.  There are no guarantees that a third-party OS theme would have a gripper that falls within our assumed constraints.  And what if in a future version of Windows, Microsoft decides to significantly enlarge the gripper size?  It's unlikely, but I don't think that's an assumption that we should make.

Comment 2

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)