569047 - Page load in new tab loads <about:blank> first, only then the page

Status: RESOLVED DUPLICATE of bug 610357

(Core :: DOM: Navigation, defect)

Description

[Ben Bucksch (:BenB)]

Reproduction:
1. Overlay the following code in browser.xul:

Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");
function onLoad()
{
  gBrowser.addTabsProgressListener(webProgressListener);
}
window.addEventListener("load", onLoad, false);

var webProgressListener =
{
  // |browser| == <browser> (iframe) which fired the event. != gBrowser
  onStateChange : function(browser, webProgress, request, stateFlags, status)
  {
    if (stateFlags & Ci.nsIWebProgressListener.STATE_STOP)
      onPageLoad(browser);
    return 0;
  },
  onLocationChange: function() {},
  onProgressChange: function() {},
  onStatusChange: function() {},
  onSecurityChange: function() {},
  onLinkIconAvailable: function() {},
  // it's not a real Ci.nsIWebProgressListener
  QueryInterface : XPCOMUtils.generateQI([Ci.nsISupportsWeakReference])
}

function onPageLoad(browser)
{
  var pageURL = browser.currentURI.spec;
  dump("on page load for <" + pageURL + ">\n");
}

2. Start Firefox
3. Click on a link with the middle mouse button, to open it in a new tab
4. Set pref "open windows in tabs"
5. click on some
   <a href="http://www.example.com" target="_blank">
6. onclick="window.open('http://www.example.com', 'foo');"

Actual result:
In steps 3, 5, 6, a new tab opens with the corresponding page.
Each time, on the console, you see:
  on page load for <about:blank>
  on page load for <http://www.example.com>

Expected result:
In steps 3, 5, 6, a new tab opens with the corresponding page.
Each time, on the console, you see:
  on page load for <http://www.example.com>
but not <about:blank>

Importance:
This means that when we load a URL in a new tab, we always open the tab with <about:blank> as content first, and then load the real URL in it immediately afterwards.
That might seem neglectable, but I think each page load (even something as trivial as <about:blank>) has a significant overhead, because it needs to set up a stream, run through Gecko to load it, parse it, construct the presentation frames for it, and in all steps fire all the progress listeners and DOM events.

That's all totally unneeded and useless work. We should just load the new tab with the intended URL directly.

Only catch: Watch out that this doesn't regress any security checks.

Comment 1

[Dão Gottwald [:dao]]

Sounds like this belongs in Core/Document Navigation, although tabbrowser would likely have to adjust to it if this changed.

Comment 2

[Ben Bucksch (:BenB)]

> Sounds like this belongs in Core/Document Navigation

Why? New windows and startup work correctly, they load the target page immediately without <about:blank>. This seems to be a bug in <tabbrowser>.

Comment 3

[Dão Gottwald [:dao]]

We don't seem to explicitly load about:blank anywhere in tabbrowser.xml.

Comment 4

[Ben Bucksch (:BenB)]

That doesn't mean anything. If you open an <iframe>/<browser> without content, it probably loads <about:blank>. The bug is probably that you load the page URL shortly after the tab opened. You should pass the page URL at the time of the construction of the <iframe>/<browser>, so that the docShell is initialized with the page URI, not without URI.

Comment 5

[Dão Gottwald [:dao]]

It's not clear to me what you mean. The addTab method creates a browser element, inserts it into the document and calls loadURIWithFlags. What should it do instead?

Comment 6

[Ben Bucksch (:BenB)]

Create the browser element with src= attribute maybe.
I don't know what the correct way is, but just look what happens at new window load, because it works there. Compare link, right click, "open in new tab" vs. "open in new window", with the above code.

Comment 7

[Dão Gottwald [:dao]]

Opening a link in a new window ends up calling loadURIWithFlags from BrowserStartup.

Comment 8

[Dão Gottwald [:dao]]

(In reply to comment #7)
> Opening a link in a new window ends up calling loadURIWithFlags from
> BrowserStartup.

And BrowserStartup likely runs before your onLoad function, so you'll just miss that state change.

Comment 9

[Ben Bucksch (:BenB)]

> Create the browser element with src= attribute maybe.

Tried that, it didn't work. Wouldn't work with referer and postdata anyways.

> And BrowserStartup likely runs before your onLoad function, so you'll just
> miss that state change.

Ah, possible.

The bug is nevertheless valid as stated, it's still a useless load. Maybe we need a new API for <browser> or whatever. Maybe bz or somebody else who knows docShell can chime in.

Comment 10

[Boris Zbarsky [:bzbarsky]]

We do kick off the about:blank load when the new frame is constructed.  Then we immediately stop it.  There's no "set
up a stream, run through Gecko to load it, parse it, construct the presentation
frames for it, and in all steps fire all the progress listeners and DOM events" involved.  Just an asyncOpen, then a cancel.  Then when the OnStopRequest happens, a STATE_STOP with an error code.

I'm not sure what made you assume that STATE_STOP means "page is loaded" as opposed to "load is done, either because it finished or because it was aborted"...

Comment 11

[Ben Bucksch (:BenB)]

> We do kick off the about:blank load when the new frame is constructed.
> Then we immediately stop it.

Why? Can we avoid it? Why can't we directly load the page we're told to load?

> I'm not sure what made you assume that STATE_STOP means "page is loaded"

I don't remember, sample code or not seeing any other event. (But how *do* I listen to "page is loaded" notification in webprogresslistener?)

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Why?

Compat reasons, largely, for iframes with no src.

> Can we avoid it?

If the src were set at the callsite.

> But how *do* I listen to "page is loaded" notification in webprogresslistener?)

STATE_STOP (though you need also STATE_IS_WINDOW and whatnot), but you need to examine aStatus to see whether the load was successful.