Closed Bug 656348 Opened 13 years ago Closed 4 years ago

open blank "new tab" flashes screen white

Categories

(Firefox :: General, defect)

4.0 Branch
x86_64
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1408122

People

(Reporter: 1A14, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

i have dark green system background color, i also set this in firefox settings to use system colors, when i click "new tab" it flashes white screen within the content pane of the firefox

the problem is that someone has set the color "white" as the default background color and it takes some until it is set to user color, thats why the screen FLASHES white (especially when you use a dark background system color), its really bad effect on a 42inch screen if it flshes white each time creating a blank new tab

with white color (it is the default system background color for conent panes in windows os) you wont see the flash visible

the solution: set the default background color to user color when firefox is started up, dont set default background color for each new tab creation anymore, insted of that use only user color as default background color for each new tab creation

Reproducible: Always
Is your Issue reproducible when you disable the Hardware Acceleration and restart Firefox?

Did it not happen in Firefox 3.6., i.e. is it a Regression?
Version: unspecified → 4.0 Branch
How can i disable the Hardware Acceleration? Please describe.
Go to Options/Advanced/General und untick the Checkbox and - very important - restart Firefox to make the Change take Effect.
ok i did it like you said, but the firefox content pane still flashes white when i click on new tab. looks like it has nothing to do with hardware acceleration enabled or disabled.
Ok, what about

> Did it not happen in Firefox 3.6., i.e. is it a Regression?
It also appears in 3.6.15, but the flashing is lower than in ff4, looks like in ff3 the default background color is grey and a new tab is created twice as fast as in ff4.
Just wanted to add some info I've gathered after some extensive troubleshooting.

===========================
CONFIG
===========================

Firefox 48.0 on Windows 10 (up-to-date).

System:

- i7 4810MQ (2.8 GHz quad core)
- 16GB DDR3 RAM
- SSD HDD
- nVIDIA GeForce GTX 870M 6GB (Driver v368.81)
- Intel(R) HD Graphics 4600

I am running a custom Windows 10 theme using UltraUXThemePatcher.  The theme works quite well but affects few elements in Firefox.  It certainly has no effect on about:newtab / about:blank.

I've tried:

- disabling hardware acceleration in Firefox.
- choosing both display adapters in the nVIDIA Control Panel in association with firefox.exe (restarted firefox each time)
- applying CSS to the xhtml namespace URL (explained below)
- applying CSS to about:newtab / about:blank (partially works / explained below)

... no effect on all attempted solutions.

The problem only manifests when the user initiates a URL-clicking action that opens a new tab, such as:

- user performs right-click > Open new tab on a link
- user performs middle click on a link

What happens:

- the page flashes white before loading the desired web site.  With DOM Inspector addon, the only data that be retrieved (if this bug is properly replicated) is usually only the xhtml namespace data (http://www.w3.org/1999/xhtml).  DOM Inspector also shows that baseURI is "about:blank" and that user/custom CSS is present but for some reason not being applied.  The built-in Inspector shows no content at all.  Built-in Inspector must be invoked by clicking on dev tool icon (wrench) > Inspector (CTRL + SHIFT + C won't work).  The right-click produces no context menu.

Bug is exasperated by slow bandwidth between client and server regardless of ISP bandwidth.

How to replicate / Best Replication:

Use this link:

http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_link_target

- use the example link from W3 above and set the "href" property to an IP on your LAN that doesn't exist (ie. http://192.168.1.3).  Then click "RUN" button to load the HTML into the right pane and test the link in right pane with right-click > New Tab or middle-click.

  It should hang more than long enough to activate the tab and press ESC.  Oddly enough, even from a known invalid host, the DOM Inspector addon will actually show the xhtml namespace (http://www.w3.org/1999/xhtml) as the document being loaded, in addition to the user/custom CSS Rules applied but still not taking effect.  The "baseURI" property in DOM Inspector (under JavaScript Objects view) will still show "about:blank".  So, loading, or trying to load, the xhtml namespace for interpreting the page seems to be a primary part of the issue.  Perhaps somehow this process is interrupting the ability for about:blank / about:newtab to load, only when user activated right-click > New Tab / middle-click on link happens?

NOTE: When using the "Best Replication" method, if you right-click > New Window, then user/custom CSS will be properly applied prior to page loading/failing.  DOM Inspector still shows xhtml namespace as the document being loaded, even from an URL of an invalid host.  The issue appears to specifically be with user activated new tab via "right-click > new tab" or "middle-click" on a link.

=============================
   
I can provide screenshots, but there's not much to see.  All the results are best explained through replication of the bug.
Came across this theme for Firefox that makes the "white flash" go away:

FT DeepDark
https://addons.mozilla.org/en-US/firefox/addon/ft-deepdark/?src=search

Not sure how this should be treated, but it does seem that proper knowledge of the xul layout for the Firefox UI will render this "bug" as "not a bug".

Only odd thing is that applying CSS to about:blank is not sufficient.  It's something different.  And I cant get standard inspectors to reveal what the xul layout is.
This bug should probably be closed.  Here's a fix/explanation:

The "white flash" is the browser object/element.  Simply load the XUL and HTML namespaces in your user CSS file and color the "browser" element to the desired color, perhaps the same as your background-color for HTML and BODY elements.  That's it...

===================================
@namespace xul url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
@namespace html url(http://www.w3.org/1999/xhtml);

browser, html, body { background-color: #000000 !important; }
===================================

The fact that this "white flash" only happens when user does "right-click > Open in new tab" or "middle-click" on link, and not when user performs "right-click > open in new window" may classify it as a bug, but it's very easily worked around with simple old CSS applied to the XUL browser element.
To be more specific, the browser element has to be colored as part of the "chrome://" url.  So the most specific css, at least as far as the Stylish addon is concerned, is the following:

@-moz-document url-prefix("chrome://") {
  browser { backgroulnd-color: #000C17 !important; }
}

The CSS of course could also be global.
Oops, it doesn't "have to be" part of the chrome:// url scheme.  But that is at least more specific.

www_zeeshan_de, is this still an issue? Or can it be closed? Maybe bug 1408122 is related?

Flags: needinfo?(1A14)

Let's dupe this over to a newer bug, as it's been 8 months since the needinfo.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(1A14)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.