Open Bug 1222674 Opened 9 years ago Updated 2 years ago

<select> elements in devtools don't display dropmarker on dark devtools theme (with floating scrollbars)

Categories

(Core :: Widget: Win32, defect, P5)

Product:
Core
Component:
Widget: Win32
Version:
44 Branch
Platform:
All
Windows
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- wontfix
firefox-esr45 --- wontfix
firefox50 --- wontfix
firefox51 --- fix-optional
firefox52 --- fix-optional
firefox53 --- fix-optional

People

(Reporter: magicp.jp, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: tpi:+)

Attachments

(1 file)

devtools-memory-no-dropmarker-in-select-element-on-dark-theme.png
34.78 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151106030423

Steps to reproduce:

1. Run Nightly 45.0a1
2. Open DevTools > ToolBox Options
3. Enable Memory and Dark theme
4. Open Memory
5. Confirm <select> element


Actual results:

No dropmarker button in <select> element on dark theme.


Expected results:

Enable dropmarker button in <select> element on dark theme.
Has STR: --- → yes
status-firefox44: --- → affected
status-firefox45: --- → affected
Component: Untriaged → Developer Tools: Memory
OS: Unspecified → Windows
Hardware: Unspecified → All
Blocks: memory-frontend
Summary: [DevTools] No dropmarker button in <select> element on dark theme → Restyle memory tool select
STR:
1. Open this "data:" url in a new tab
>   data:text/html,<body style="filter:none;">
2. Open devtools -> Inspector, open "Rules" tab in sidebar, click the circle near "filter" rule

Result:       <select> in popup has no button (dropmarker)
Expectations: <select> should have a dropmarker

The behavior has changed 2 times (maybe more):

1) Before 2015-09-22 there was no dropmarker, but after 2015-09-23 it was "fixed". Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=feceb41f1c3c66031164d5db8701c208f571a9b1&tochange=69881ac19fc0abe419b443a3e40c16b5dd165fd3
2) Before 2015-10-16 the dropmarker displayed properly, but after 2015-10-17 it disappeared. Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33b06ee164424bfec45d78b2bc33a741c87cd4d1&tochange=69e72e323f9c65a83bfb28cb7634ed001e63dcda

NI if you need urls of those builds. Btw this bug could be changed to "Core - Layout: Form Control"
Component: Developer Tools: Memory → Developer Tools
Keywords: regression
Summary: Restyle memory tool select → <select> elements in devtools don't display dropmarker on dark devtools theme
status-firefox46: --- → affected
I believe it would be nice to know exactly what have caused this.
Keywords: regressionwindow-wanted
Hmm.  Well, it seems the select arrow "was fixed" / appeared when I accidentally put nonsense in the namespace URL of floating-scrollbars.css.  Then, I corrected that issue and the select arrow disappeared again.

However, I don't really see how floating-scrollbars.css is related here.  It does not appear to style select arrows (unless they are scrollbar thumbs for some reason...).  Checking with the Browser Toolbox, I did not see styles that are hiding the arrow.

I am able to confirm the issue in the memory tool on Windows (there is no issue on OS X).  Brian, do you have any guesses on what's happening here?
Flags: needinfo?(jryans) → needinfo?(bgrinstead)
By process of elimination, it seems caused by this `scrollbar[orient="vertical"]` rule: https://dxr.mozilla.org/mozilla-central/source/devtools/client/themes/floating-scrollbars.css#17.

Funny thing is the problem goes away if I prefix every selector in that file with `*:not(select) `.  I believe that there is a scrollbar inside of select elements although I don't know why it's not showing up in Browser Toolbox (I imagine it's not returned by the deep tree walker but haven't checked).

Your point in Comment 4 is correct - by breaking the namespace you 'fixed' the problem, which is why the regression was tracked down to Bug 1215081.
Flags: needinfo?(bgrinstead)
If you set devtools.inspector.showAllAnonymousContent=true then open data:text/html,<select multiple></select> you can see the scrollbar inside of the <select>.  However if the multiple attribute is not set then it's not there which makes me think that styling a scrollbar changing the layout of a normal select in windows might be a widget bug
Thanks :bgrins!  

Marking as Windows widget bug based on comment 6.  We could still workaround the issue somehow in our CSS as mentioned in comment 5.
Component: Developer Tools → Widget: Win32
Product: Firefox → Core
Flags: needinfo?(jmathies)
confirmed, still valid.
Flags: needinfo?(jmathies)
status-firefox49: --- → affected
See Also: → 1271063
Flags: needinfo?(jmathies)
Whiteboard: tpi:?
status-firefox44: affected → wontfix
status-firefox45: affected → wontfix
status-firefox48: affected → wontfix
status-firefox49: affected → wontfix
Flags: needinfo?(jmathies)
Priority: -- → P2
Whiteboard: tpi:? → tpi:+
Has Regression Range: --- → yes
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → affected
Summary: <select> elements in devtools don't display dropmarker on dark devtools theme → <select> elements in devtools don't display dropmarker on dark devtools theme (with floating scrollbars)
Blocks: 1276629
status-firefox52: --- → affected
Should be fixed by bug 1276629
This is a Core bug and won't be fixed by some change in devtools CSS (which by the way fixes all _manifestations_ of this bug reported so far). Oh, all other dependencies should be corrected too.

I can reproduce the bug by applying CSS from chrome://devtools/skin/floating-scrollbars-dark-theme.css
(2016-05-26) to <select> using Stylish extension. That shouldn't affect <select> anyhow, but it does.
Also, bug 77790 will allow scrollbar styling via normal CSS, and the bug will become more widespread.
No longer depends on: 1276629
Lowering the priority as the user visible issue is gone.
Priority: P2 → P5
Consensus is that we should fix-optional this given comment 12.
status-firefox52: affected → fix-optional
status-firefox53: affected → fix-optional
Can we get a simple testcase for this? (besides applying all the styles from a chrome stylesheet to a select).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: