Daniil Zhilin Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170130084100

Steps to reproduce:

I'm using a Stylish style to make the about:blank page black so that the browser didn't flash white every time it loads a page.


Actual results:

Now all these styles seem to not work.

	:Gijs (he/him)
	Comment 1 • 7 years ago

Why is this a Firefox bug? It seems more likely to be an issue with Stylish...

	Daniil Zhilin Reporter
	Comment 2 • 7 years ago

So it is. Doesn't work on stable, even though it hasn't updated in a while, weird.

	Daniil Zhilin Reporter
	Comment 3 • 7 years ago

I've just noticed that about:blank does get styled when it's explicitly loaded. Doesn't this make it a browser issue?

	Daniil Zhilin Reporter
	Comment 4 • 7 years ago

So yeah, the extension also hasn't been updated since August.

	:Gijs (he/him)
	Comment 5 • 7 years ago

(In reply to Daniil Zhilin from comment #3)
> I've just noticed that about:blank does get styled when it's explicitly
> loaded. Doesn't this make it a browser issue?

Not necessarily... depends how/when stylish inserts the CSS.

Does it work if you use a userContent/userChrome css file? ( http://kb.mozillazine.org/index.php?title=UserChrome.css&printable=yes )

How have you configured stylish, exactly, to accomplish the "make about:blank black" thing? What CSS and to what URIs is that being applied?

	Daniil Zhilin Reporter
	Comment 6 • 7 years ago

userContent file has the same problem.

	:Gijs (he/him)
	Comment 7 • 7 years ago

(In reply to Daniil Zhilin from comment #6)
> userContent file has the same problem.

You're not answering all my questions, so I have to repeat: what CSS? Against what URL, if you're using @moz-document or whatever it's called? I expect you need to include both about:blank and moz-safe-about:blank .

	Daniil Zhilin Reporter
	Comment 8 • 7 years ago

As I've implied in the report, I'd tried several ones from userstyles.org. I mainly use this one:
https://userstyles.org/styles/107168/about-pages-dark

Including moz-safe-about:blank doesn't help.

	Michal Čaplygin [:myf]
	Comment 9 • 7 years ago

Cannot confirm.

Tested at Windows 10 (I doubt tis could be platform dependent)
- Firefox 54.0 vanilla profile with e10s disabled (dunno why)
- Nightly 20170203094345 vanilla profile with e10s enabled
Both behaved correctly

Steps taken:
- Started browser
- Ctrl+Shift+A, Search for "Stylish", installed, restart
- visited https://userstyles.org/styles/107168/about-pages-dark.css
- Stylish icon > "Install file", enetered some arbitrary name 
- visited about:blank, about:support and `data:text/html,<iframe></iframe>`

Observed:
All pages and blank iframe were dark as expected.

Reporter,
- could you try the same steps with clean profile at your platform, please?
-- (You can start Firefox with terminal with flags `--no-remote -profile "one-time-profile-deleteme"` to get thrwoaway profile folder in current directory)

	Daniil Zhilin Reporter
	Comment 10 • 7 years ago

Done, no progress on stable Firefox. `data:text/html,<iframe></iframe>` is a small black rectangle on a white background.

	Daniil Zhilin Reporter
	Comment 11 • 7 years ago

Still reproduced on developer edition too. I'd like to reiterate that about:blank gets styled when explicitly loaded.

	:Gijs (he/him)
	Comment 12 • 7 years ago

(In reply to Daniil Zhilin from comment #10)
> Done, no progress on stable Firefox. `data:text/html,<iframe></iframe>` is a
> small black rectangle on a white background.

But that doesn't have about:blank as the URL of the toplevel page, so it's expected, right?

In any case, I see exactly the same problem in 28, so I don't think this is a (recent) regression. STR:

1. install stylish
2. install https://userstyles.org/styles/107168/about-pages-dark
3. in the prefs, turn on 'When I open a link in a new tab, switch to it immediately'
4. open: data:text/html,<a href="http://briangrinstead.com/files/sleepy.php">Click me</a>
5. middle/ctrl-click the link
6. hit stop (or [esc]).

Using the devtools inspector on the <html> element shows that the background color is being applied as far as the inspector knows. But it's not making any difference visually. Adding/removing styles with the inspector also has no effect.

Seems like a layout issue to me.

	Michal Čaplygin [:myf]
	Comment 13 • 7 years ago

(In reply to :Gijs from comment #12)
> (In reply to Daniil Zhilin from comment #10)
> > Done, no progress on stable Firefox. `data:text/html,<iframe></iframe>` is a
> > small black rectangle on a white background.
> 
> But that doesn't have about:blank as the URL of the toplevel page, so it's
> expected, right?

AFAIK not: `@-moz-document url/url-prefix/regex` should be really applied at any URL matching the argument regardless it is displayed as top-level window frame or as deep as in 19th level of "nested" frames.

> In any case, I see exactly the same problem in 28, so I don't think this is
> a (recent) regression. STR:
> 
> 1. install stylish
> (...)
> 6. hit stop (or [esc]).
> 

Ah, now you are talking. At this moment I think you are not looking in fact at about:blank page but at tabbrowser#content in chrome://browser/content/browser.xul:

```
<tabbrowser xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" id="content" flex="1" contenttooltip="aHTMLTooltip" tabcontainer="tabbrowser-tabs" contentcontextmenu="contentAreaContextMenu" autocompletepopup="PopupAutoComplete" selectmenulist="ContentSelectDropdown" style="background-color: rgb(255, 255, 255);"><panel class="autoscroller" mousethrough="always" id="autoscroller"/></tabbrowser>
```

(That hardcoded `style="background-color: rgb(255, 255, 255);"` seems super silly, right?)

You can make such userstyle:
```
/* AGENT_SHEET */
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
@-moz-document url('chrome://browser/content/browser.xul') {
	tabbrowser#content {
		background-color: #300 !important;
	}
}
```
and verify it with your test procedure (or, you can simply focus location bar, press alt+enter and hit escape immediately); you should see dark red instead of white now.

> Using the devtools inspector on the <html> element shows that the background
> color is being applied as far as the inspector knows. But it's not making
> any difference visually. Adding/removing styles with the inspector also has
> no effect.

Yup, I can confirm I there is such "ghost content" visible even in the Browser Toolbox remote debug session. That content is not really rendered. I'd suppose the reason could be that the content document frame is loaded and styles already computed but is "transparent" before initial paint, but nothing in toolbox confirmed this.

	Michal Čaplygin [:myf]
	Comment 14 • 7 years ago

(In reply to Michal Čaplygin [:myf] from comment #13)
> (In reply to :Gijs from comment #12)
> > (In reply to Daniil Zhilin from comment #10)
> > > Done, no progress on stable Firefox. `data:text/html,<iframe></iframe>` is a
> > > small black rectangle on a white background.
> > 
> > But that doesn't have about:blank as the URL of the toplevel page, so it's
> > expected, right?
> AFAIK not: (...)

Ah, sorry, I misunderstood this comment first. Yes, data:uri in the top-level document frame is really unmatched (you are right) so the page remains white; I was talking about implicit `about:blank` location of the <iframe> in the content, which should make it black (and from tests it really does). Sorry for the confusion.

	:Gijs (he/him)
	Comment 15 • 7 years ago

(In reply to Michal Čaplygin [:myf] from comment #13)
> (In reply to :Gijs from comment #12)
> > In any case, I see exactly the same problem in 28, so I don't think this is
> > a (recent) regression. STR:
> > 
> > 1. install stylish
> > (...)
> > 6. hit stop (or [esc]).
> > 
> 
> Ah, now you are talking. At this moment I think you are not looking in fact
> at about:blank page but at tabbrowser#content in
> chrome://browser/content/browser.xul:
> 
> ```
> <tabbrowser
> xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
> id="content" flex="1" contenttooltip="aHTMLTooltip"
> tabcontainer="tabbrowser-tabs" contentcontextmenu="contentAreaContextMenu"
> autocompletepopup="PopupAutoComplete" selectmenulist="ContentSelectDropdown"
> style="background-color: rgb(255, 255, 255);"><panel class="autoscroller"
> mousethrough="always" id="autoscroller"/></tabbrowser>
> ```
> 
> (That hardcoded `style="background-color: rgb(255, 255, 255);"` seems super
> silly, right?)

It is not, in fact, hardcoded. It's set here, when the window is opened and the tabbrowser is constructed:

https://dxr.mozilla.org/mozilla-central/rev/32dcdde1fc64fc39a9065dc4218265dbc727673f/browser/base/content/tabbrowser.xml#4989-4992

so this is controlled via prefs that control content styling generally (the ones in the 'color' dialog of the 'content' section of the prefs).

Sounds like this is invalid, then, though I'm still confused why we don't render the initial about:blank document...

	Michal Čaplygin [:myf]
	Comment 16 • 7 years ago

(In reply to :Gijs from comment #15)
> It is not, in fact, hardcoded. It's [...] controlled via prefs that control 
> content styling generally (the ones in the 'color' dialog of the 'content' 
> section of the prefs).

Oh, excellent, thanks a lot for clarification, it pretty much makes sense now. Never dug deep enough to sort this out.

> Sounds like this is invalid, then, though I'm still confused why we don't
> render the initial about:blank document...

In other words, the remaining mystery probably is why there is a perceivable period of visible tabbrowser background without visible about:blank that "should be there, right above".

(In reply to Daniil Zhilin from comment #0)
> Steps to reproduce:
> 
> I'm using a Stylish style to make the about:blank page black so that the
> browser didn't flash white every time it loads a page.
> 
> Actual results:
> 
> Now all these styles seem to not work.

So "seem to not work" actually means "are applied after bright flash period", is it correct?


Possible workarounds for preventing flashes of default background color in newly: initialised tabs

Workaround 1 : set dark default background color in prefs. (This is not so viable for real world usage, as there are plenty half-styled sites not declaring background and expecting it to be white, producing dark text on dark background with this setting.)(Been there.)

Workaround 2 : use userstyle like the one described in Comment 13 :
@-moz-document url('chrome://browser/content/browser.xul'){#content{background-color:#000!important}}

(Both might produce dark flashes.)

	Daniil Zhilin Reporter
	Comment 17 • 7 years ago

(In reply to Michal Čaplygin [:myf] from comment #16)
> So "seem to not work" actually means "are applied after bright flash
> period", is it correct?
No, I can't notice them ever being applied. Workaround 2 works fine so far.