863303 - Documents queued for deferred load by the session saver have readyState set to complete

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Matthew Gertner]

When I start Firefox, the session saver opens a number of tabs from my previous session. My extension loops over all tabs and checks the readyState. The documents in the background tabs are not loaded (the content is an empty HTML document) but the location is set to the real URL and the readyState is set to complete. I would expect the readyState to be loading or something else.

When I switch to the tab, the document is loaded and DOMContentLoaded is filed as expected.

Comment 1

[Jonathan Kew [:jfkthame]]

Just curious - when you switch to the tab, do you get readystatechange events corresponding to a change to "loading" and then back to "complete" (and perhaps "interactive" in between)?

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

The ready state is complete because they have 'about:blank' completely loaded. As soon as the tab gets restored we kick off a browser.loadURI() call that then navigates to a different URL - the one the tab pretends to have while not yet restored.

Comment 3

[Jonathan Kew [:jfkthame]]

But shouldn't such a tab report its location as being "about:blank", then?

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Restoring tabs on demand is an optimization. Features like switch-to-tab etc. need to work with that - that's why the to-be-restored tab reports the URL it will have when restored, not about:blank.

Comment 5

[Jonathan Kew [:jfkthame]]

OK. In that case we're back to the original issue: the tab is not reporting its state accurately to script that wants to know about it. It reports the "intended" URL as its location, and it claims to be "complete". But it's not; far from it.

Comment 6

[Matthew Gertner]

I agree that returning about:blank as the location would be wrong, but the current implementation is really problematic. For example, we have a bootstrapped extension. When it "wakes up", it sees a bunch of open tabs. All of them return "complete" as their readyState. There is no way to know whether the extension has just been enabled with a bunch of tabs open (in which case they are really loaded) or the browser has just been started and the session saver has opened the tabs from the last session (in which case they aren't).

Unless I come up with a better workaround, I'm going to have to check if the page HTML is empty in order to distinguish the two cases.

Comment 7

[Jonathan Kew [:jfkthame]]

>Unless I come up with a better workaround, I'm going to have to check if the page HTML is
>empty in order to distinguish the two cases.

...which (a) is an ugly hack that an add-on author shouldn't have to use, and (b) won't be totally reliable, as there could be tabs whose "real" content is the same empty HTML as about:blank - in which case you'd conclude they -aren't- ready when in fact they are.

ISTM such tabs should have a readyState of "loading", or better still a new state such as "waiting" or "deferred" or "unloaded".

I think "loading" would probably be better than "ready", as it makes it clear that the page that the tab claims as its location is not actually ready to be used in any way; but it's not strictly true until the tab actually gets restored, and could lead to other kinds of confusion.

For example, imagine an add-on that aims to monitor for sites that are excessively slow to load, so as to do something (suggest alternatives? disable downloadable fonts and images on slow sites? who knows...) that might improve the user experience....