Work - Select popups have ugly gap in item highlight

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: jimm, Unassigned)

Tracking

Trunk
x86_64
Windows 8.1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [forms] feature=work)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 725875 [details]
screen cap

see screenshot.

Updated

6 years ago
Blocks: 841214
Blocks: 855434
No longer blocks: 841214

Comment 1

6 years ago
I don't see this in select pop-ups in Bugzilla. Is this magically fixed or  am I looking at the wrong select widgets?
Ditto I'm not seeing this. I wondering what jimm is doing differently to be able to reproduce it.
(Reporter)

Comment 3

6 years ago
Created attachment 730346 [details]
testcase
I don't reproduce with the test case. The highlight goes across and doesn't look like the screenshot.  I think my text isn't as big as yours too. Maybe this is a dpi setting thing.
(Reporter)

Comment 5

6 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #4)
> I don't reproduce with the test case. The highlight goes across and doesn't
> look like the screenshot.  I think my text isn't as big as yours too. Maybe
> this is a dpi setting thing.

Sounds reasonable. Asa can you confirm with one of your high-dpi tablets?

Comment 6

6 years ago
(In reply to Jim Mathies [:jimm] from comment #5)
> (In reply to Brian R. Bondy [:bbondy] from comment #4)
> > I don't reproduce with the test case. The highlight goes across and doesn't
> > look like the screenshot.  I think my text isn't as big as yours too. Maybe
> > this is a dpi setting thing.
> 
> Sounds reasonable. Asa can you confirm with one of your high-dpi tablets?

Indeed, this shows up for me on a high-dpi device (11" device at full HD).
(Reporter)

Comment 7

5 years ago
Created attachment 733490 [details]
odd box

This shows up when the menu overflows (scrolls). There's something funny in our css, note the little gray box on the lower right. Whatever that is it's the cause of this gap.
(Reporter)

Updated

5 years ago
Whiteboard: dupeme → [forms]

Updated

5 years ago
Blocks: 859003

Updated

5 years ago
Whiteboard: [forms] → [forms] feature=defect c=Content_features u=metro_firefox_user p=0

Updated

5 years ago
Summary: Select popups have ugly gap in item highlight → Defect - Select popups have ugly gap in item highlight
(Reporter)

Updated

5 years ago
Whiteboard: [forms] feature=defect c=Content_features u=metro_firefox_user p=0 → [forms] feature=defect c=Content_features u=metro_firefox_user p=3
Jim's point estimate=3
Whiteboard: [forms] feature=defect c=Content_features u=metro_firefox_user p=3 → [forms] feature=defect c=Content_features u=metro_firefox_user p=0
(Reporter)

Updated

5 years ago
Depends on: 861853
(Reporter)

Updated

5 years ago
No longer depends on: 861853
(Reporter)

Updated

5 years ago
Blocks: 861853

Updated

5 years ago
Assignee: nobody → sfoster
Blocks: 855905
No longer blocks: 859003
Priority: -- → P1
QA Contact: jbecerra
Whiteboard: [forms] feature=defect c=Content_features u=metro_firefox_user p=0 → [forms] feature=defect c=Content_features u=metro_firefox_user p=3

Updated

5 years ago
Status: NEW → ASSIGNED
I can only reproduce this when I have the windows "text sizing" set to 150%. 125% and lower seems fine. 
When the select popup initial appears when you touch/focus the select menu, no item is selected and it renders and scrolls as expected. Once you touch and item to select it and  get the popup back up by touching the select menu again, the gap appears. 

I took the following measurements with the DOM inspector: 

Initial State (150%)
xul:scrollbox: overflow:auto,
xul:box:
scrollbar (orient horizontal)     
     box model: box width: 147, box height: 0, margin-top: 
     scrollbarbutton: width/height 0
     scrollbarbutton: width/height 0
     xul:slider: box width: 139, box height: 8,
          xul:thumb: 139, 8
     scrollbarbutton: (sbattr scrollbar-up-bottom, sborient horizontal) width/height 0
     scrollbarbutton: (sbattr scrollbar-down-bottom, sborient horizontal) width/height 8,8
scrollbar (orient vertical)
     box model: box width: 8, box height: 260
     scrollbarbutton: width/height 0
     scrollbarbutton: width/height 0
     xul:slider: box width: 8, box height: 252,
          xul:thumb: 8,57
     scrollbarbutton: (sbattr scrollbar-up-bottom, sborient vertical) width/height 0
     scrollbarbutton: (sbattr scrollbar-down-bottom, sborient vertical) width/height 8,8
scrollcorner box w/h: 0,0

listitem
     cs: min-height; 37px, min-width: 133px, width: 147.367px, display: -moz-grid-line, font-size: 16px, text-overflow: clip, outline: none
     bm: width: 147, height: 37

2nd state (150%)
xul:scrollbox: overflow:auto,
xul:box:
scrollbar (orient horizontal)
     box model: box width: 138, box height: 0, margin-top: 
     scrollbarbutton: (horizontal) width/height 0
     scrollbarbutton: (horizontal) width/height 0
     xul:slider: box width: 130, box height: 8,
          xul:thumb: 130, 8
     scrollbarbutton: (sbattr scrollbar-up-bottom, sborient horizontal) width/height 0
     scrollbarbutton: (sbattr scrollbar-down-bottom, sborient horizontal) width/height 8,8
scrollbar (orient vertical)
     box model: box width: 17, box height: 260
     scrollbarbutton: width/height 0
     scrollbarbutton: width/height 0
     xul:slider: box width: 17, box height: 252,
          xul:thumb: 17,57
     scrollbarbutton: (sbattr scrollbar-up-bottom, sborient vertical) width/height 0
     scrollbarbutton: (sbattr scrollbar-down-bottom, sborient vertical) width/height 17,8
scrollcorner box w/h: 9,0

listitem.selected: 
     cs: min-height; 37px, min-width: 133px, width: 138.033px, , text-overflow: clip, outline: none
listitem
     cs: min-height; 37px, min-width: 133px, width: 138.033px, 
     bm: width: 138, height: 37
     
You can see around 9px is introduced to the scrollbar elements in the 2nd case, which accounts for the ugly gap that gives this bug its name. I have had no success so far finding a CSS rule or other assignment that would explain this.
(In reply to Sam Foster [:sfoster] from comment #9)
> I can only reproduce this when I have the windows "text sizing" set to 150%.
> 125% and lower seems fine.

Based on this, I suppose some lengths are getting rounded differently and pushing the box into overflow (because the contents are bigger than the container, after rounding).  Maybe the 3px padding on the richlistbox is involved, since 150% would enlarge it to exactly 4.5 screen pixels.

I couldn't reproduce this on my own machine, which does not have a high-DPI display.  I set the desktop scale to 150% and tested in both Metro and -metrodesktop modes.

If the overflow theory is correct, the real problem is that we are not properly hiding the scrollbox elements.  Can you check their "display" properties?  Do we need to override the "display: -moz-box !important" on the scrollcorner?  Do we need to set "visibility: collapse" on scrollbar and scrollcorner?
If we modify the rules for scrollcorner and scrollbar around https://mxr.mozilla.org/mozilla-central/source/toolkit/content/xul.css#945, to display: none and visibility:collapse, we get the right behavior. Obviously we need a more targeted fix for metro and for this popup. I'm stumped right now as my efforts to add overriding rules in browser/metro/theme/forms.css are being ignored: 

#select-commands scrollcorner, #select-commands scrollbar {
  display: none !important;
  visibility: collapse!important;
}

.. so I'm obviously missing something. Halp?
Flags: needinfo?(fyan)

Updated

5 years ago
Assignee: sfoster → nobody
No longer blocks: 855905, 861853
Status: ASSIGNED → NEW
Priority: P1 → --
Summary: Defect - Select popups have ugly gap in item highlight → Work - Select popups have ugly gap in item highlight
Whiteboard: [forms] feature=defect c=Content_features u=metro_firefox_user p=3 → [forms] feature=work

Comment 12

5 years ago
I can't seem to reproduce this at all. :(
Are you still seeing it?
Flags: needinfo?(fyan)
(Reporter)

Comment 13

5 years ago
Seems to have gone away now that we display normal scroll bars. If we plan on getting rid of those when interacting with touch, I'll bet it will come back. If not, then I think we can resolve this.
(Reporter)

Comment 14

5 years ago
this is fixed. tested on a surface pro, which is what I originally reported it on.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

4 years ago
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.