Closed Bug 1257348 Opened 7 years ago Closed 7 years ago

GCLI close button disappears when hover.


(DevTools Graveyard :: Graphic Commandline and Toolbar, defect)

47 Branch
Not set


(firefox46 unaffected, firefox47+ fixed, firefox48+ verified)

Firefox 48
Tracking Status
firefox46 --- unaffected
firefox47 + fixed
firefox48 + verified


(Reporter: johngraciliano, Assigned: philip.chee)



(Keywords: regression, Whiteboard: [btpp-fix-now])


(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160315004019

Steps to reproduce:

Start Firefox (Developer Edition 47.0a2 or Nightly 48.0a1).
Press Shift-[F2] to display the 'command line'
Move the 'mouse pointer' on top of the close button ('x at the end') of the GCLI.

Actual results:

The close button becomes invisible.

Expected results:

The close button remain visible, perhaps just change its appearance, but not disappear.  In previous releases, it simply fades a little.
Component: Untriaged → Developer Tools
The button now has the class 'close-icon' (it was 'devtools-closebutton') for which chrome://global/skin/global.css has:

  .close-icon {
    list-style-image: url("chrome://global/skin/icons/close.png");
    -moz-image-region: rect(0, 20px, 20px, 0);

  .close-icon:hover {
    -moz-image-region: rect(0, 40px, 20px, 20px);

  .close-icon:hover:active {
    -moz-image-region: rect(0, 60px, 20px, 40px);

But in chrome://browser/skin/browser.css it states for 

  #developer-toolbar-closebutton {
    list-style-image: url("chrome://devtools/skin/images/close.png");
    opacity: 0.6;
  #developer-toolbar-closebutton:hover {
    opacity: 0.8;
  #developer-toolbar-closebutton:hover:active {
    opacity: 1;

But chrome://devtools/skin/images/close.png has only one 'sprite' hence the problem.*

I suggest to include:
    -moz-image-region: auto;
in the rule for #developer-toolbar-closebutton inside browser.css.  That will solve issue even if min-resolution: 1.1dppx.

*The image size is also different 16×16 vs 20×20 with the class resource.
Component: Developer Tools → Developer Tools: Graphic Commandline and Toolbar
The button also appears smaller than it should be when not hover and the reason is in the asterisk of comment 1.
It's due to bug 1239464. Maybe bug 1225184 will fix it.
Blocks: 1239464
Depends on: 1225184
Ever confirmed: true
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
Flags: needinfo?(zer0)
Whiteboard: [multiviewport] [triage]
@Loic, I don't think bug 1239464 is related at all; could you please elaborate? It didn't touch the GCLI close icon or any stylesheet related to GCLI.
Flags: needinfo?(zer0)
Flags: needinfo?(epinal99-bugzilla2)
Regressed by bug 1252479.
Blocks: 1252479
No longer blocks: 1239464
Flags: needinfo?(epinal99-bugzilla2) → needinfo?(philip.chee)
Whiteboard: [multiviewport] [triage] → [btpp-fix-now]
Thank you Tim.  The class change in allows the button to be styled by rules in global.css.  But these the rules for the id in browser.css have precedence and overide most of them.  However, there is no overide for the -moz-image-region property.  You may either add the line I suggest at the end of comment 1 or clean/simplify browser.css so the button can be styled with the code in common.css.  There should be a good reason for the change in class regarding SeaMonkey, isn't there?  Otherwise, it may be best to revert the class to what it was.

But if the intention is to change the button appearance as that in tabs and elsewhere, cleaning/simplifying code in browser.css is the needed.
I originally did not remove the styles for #developer-toolbar-closebutton because I thought something else was using this id. But now I see that the toolbox.xul close button is using class="devtools-closebutton" so now we can remove all the #developer-toolbar-closebutton styles from:
Flags: needinfo?(philip.chee)
> +:root[devtoolstheme="dark"] #developer-toolbar > .close-icon:not(:hover) > image {
> +  filter: invert(1);

In dark theme the toolkit close button image is very hard to notice - if not impossible so I've inverted the colours. But in light theme I avoid inverting the colours for the same reason.
Assignee: nobody → philip.chee
Attachment #8732648 - Flags: review?(jwalker)
Comment on attachment 8732648 [details] [diff] [review]
Fix close button styles

Review of attachment 8732648 [details] [diff] [review]:

I'm going to forward this review to Brian, who I hope can get to it more quickly that me. Sorry for the delay.
Attachment #8732648 - Flags: review?(jwalker) → review?(bgrinstead)
Comment on attachment 8732648 [details] [diff] [review]
Fix close button styles

Review of attachment 8732648 [details] [diff] [review]:

Works for me, thanks

::: devtools/client/themes/
@@ +59,5 @@
>    width: 16px;
>    height: 16px;
>  }
> +:root[devtoolstheme="dark"] #developer-toolbar > .close-icon:not(:hover) > image {

Please add a comment above this as in Comment 10.  Something like: "The toolkit close button is low contrast in the dark theme so invert it"
Attachment #8732648 - Flags: review?(bgrinstead) → review+
Comment on attachment 8732648 [details] [diff] [review]
Fix close button styles

Approval Request Comment
[Feature/regressing bug #]: bug 1252479
[User impact if declined]: disappearing developer toolbar close icon on hover
[Describe test coverage new/current, TreeHerder]: local testing, will soon be in Nightly (currently in mozilla-inbound)
[Risks and why]: low, simple CSS change
[String/UUID change made/needed]: none
Attachment #8732648 - Flags: approval-mozilla-aurora?
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
It regressed on linux, see bug 1260751.
Hello Johngraciliano, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(johngraciliano)
Comment on attachment 8732648 [details] [diff] [review]
Fix close button styles

Recent regression, Aurora47+
Attachment #8732648 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 1263683
No longer blocks: 1260751
Depends on: 1260751
I have successfully reproduce this bug on firefox nightly 48.0a1 (2016-03-16)
with windows 7 (32 bit)
Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0

I found this fix on latest aurora 47.0a2 (2016-04-19)

Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID : 20160419004026

I also found fix on latest nightly 48.0a1 (2016-04-19)

Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID :20160316030233 

Flags: needinfo?(johngraciliano)
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.