Element Picker drowned in dark background

[ghost]

uBlock 0.8.8.0 (stable as well as former RC2) on Firefox 35.0.1 / Win7 x64

When choosing the element picker tool moving the mouse around lightens the hovered area otherwise totally gray ... http://hpics.li/cda0cd6

This never occurred on uBlock 0.8.7.+

[gorhill]

Could there be another add-on modifying the picker's style?

The picker was rewritten in 0.8.8.0 to use an iframe.

[ghost]

That's what I'm checking right now ...
Since uBlock 0.8.7.+ I've added 3 add-ons. I've just checked 2, one last to verify ...

It's not an add-on but a style in Stylish : turning all styles off reverted element picker to normal activation. I'll check which style and let you know.

[gorhill]

svg > path:first-child is supposed to have an opacity of 0.75:

[ghost]

I found the culprit. It's a very small style I've been using since always which avoid white blank page when opening a new page. This style has been operating correctly until uBlock 0.8.8.0 RC2.

/* AGENT_SHEET */
@-moz-document url(chrome://browser/content/browser.xul) {browser[type="content-primary"] {background: #A9BDDE !important;}}
@-moz-document url(about:blank), url(about:newtab) {#newtab-window, html {background: #A9BDDE !important;}}

It's the:

 @-moz-document url(about:blank), url(about:newtab) {#newtab-window, html {background: #A9BDDE !important;}}

which disabled returns things to normal ...

[gorhill]

Can you add the !important directive to the element selected in my pic, see if this makes a difference. If so, I will add it for the next release to be sure no external stylesheet takes over the intended style.

[ghost]

@gorhill commented on 15 févr. 2015 22:50 UTC+1:

Can you add the !important directive to the element selected in my pic, see if this makes a difference. If so, I will add it for the next release to be sure no external stylesheet takes over the intended style.

I'm afraid I can't handle that because I don't understand exactly what you mean : what directive? Sorry, I'm not a cooker!

[gorhill]

Ok let's reverse the duty. Where do I have to enter those CSS styles for me to reproduce locally?

[Deathamns]

User stylesheets will overwrite any page style. Also, !important is already used for background.

[ghost]

The second style is the culprit :
@-moz-document url(about:blank), url(about:newtab) {#newtab-window, html {background: #A9BDDE !important;}}
I have it running within the Stylish add-on. Otherwise it's to be pasted in userchrome.css or usercontent.css (I never remember which one because I don't use them.

The style only handles as mentioned about:blank and about:newtab.

[ghost]

The style's source is : https://userstyles.org/styles/90565/firefox-adjust-white-flash-when-opening-new-tab
with option about:blank + about:newtab (with grid disabled) set to yes

[Deathamns]

Seems like Stylish is not too aggressive with CSS, so the color can be overwritten with the style attribute.
Edit: seems like CSS inside the <style> tag works too.

[Deathamns]

Alternatively you could use a semi-transparent background color.

[ghost]

I've replaced,
@-moz-document url(about:blank), url(about:newtab) {#newtab-window, html {background: #A9BDDE !important;}}
with
@-moz-document url(about:blank) {*:empty:not([style]):not([text]):not([class]):not([onresize]) {background-color: #A9BDDE;}}
and all is fine.
Handles an occasional about:blank correctly and has no incidence on uBlock's element picker

[onestepbeyond]

Thank you very much, Zylinder! I had the same issue with my about:blank page and µBlock 0.8.8.0.
I adapted your style to mine in userContent.css and it works fine.

Before:
@ -moz document url ("about: blank") {
body {background-color: # F1F1F7! important; }
}

Now:
@ -moz document url (about: blank) {
*: empty: not ([style]) {
background-color: # F1F1F7;}
}

As you can see, I removed some elements like [text], [class] and [onresize] because they slowed the display of my Firefox start page (who stayed on about:blank several seconds before displaying my start page).

What do you think of this style, is it enough to work properly in all cases?

[ghost]

@onestepbeyond , well, thank you as well because shortening the restrictions was in my mind but I was not sure about which one(s) to keep.

What I think about your reconfiguration of the style? If it doesn't bother uBlock's element picker anymore and if it doesn't appear in time to parasite a whatever page, then shorter will prove to have been better...

Giving a color to about:blank with a css goes from a rude about:blank -> background to the more sophisticated granular one I posted here after having found it on several sytles over at stylish.org. Not to mention a user who praised academic respect with a css style for about:blank which, if used, has the same effect as any css handling the about:blank with no restriction paintless - proper about:blank -- So, frankly, as a non-techie (neither proud or not of a fact) I just try to cook, silently, picking here and there, testing (empiricism takes time!). With code I feel as a kid who left school too quickly :)

[onestepbeyond]

My initial style was also obtained by series of testings and errors, I like that, that's how we learn :)

I do confirm that the new style works seamless like the old one.

Thank you again for the trick, I would never thought of a connection between the opaque layer in µBlock 0.8.8.0 element picker and my style for the about:blank page.

Edit: Many thanks also to gorhill and Deathamns for this terrific addon!
and sorry for my uncertain english... :'(

[gorhill]

So anyways, the issue was with about:blank customization, something out of control of uBlock. Right?

[onestepbeyond]

Yes, absolutely.
For me, just the about:blank page of Firefox (to which I gave a background color other than white, with a scriptstyle not in relation with μBlock) was impacted.