1447406 - Eliminate initial navigation to about:blank

Status: NEW

(GeckoView :: General, task, P3)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

It would be very nice if we could make the initial about:blank navigation stop happening.

1) It makes testing hard, because we have to wait for this to "settle" before doing other stuff.

2) App authors may not expect this, since they did not request it.

One way around this would be to require an initial URI for the GeckoSession. After all, loadUri() is one of the first things you'll want to call anyway. I would like to avoid this, though. There is value in having the default startup state able to load a page without actually doing so.

I looked into this briefly and there seems to be a lot of assumptions made that get in the way of this. You can put 'nodefaultsrc=1' on <browser>, but eventually we seem to get various things calling nsDocShell::CreateAboutBlankContentViewer().

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

bz, do you think this is doable at all?

Comment 2

[Boris Zbarsky [:bzbarsky]]

So... Per spec there should be no such navigation.  Henri looked into eliminating it in Gecko and ran into complications.  I don't know whether he still remembers what those were...

For a Gecko consumer, it may be possible to just call stop() on the webnavigation in the <browser> right after putting it in the DOM and get the desired effect.

CreateAboutBlankContentViewer is _not_ the about:blank navigation.  That's the part that implements https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context steps 6-8 (the URL of the newly-created document is "about:blank" because https://dom.spec.whatwg.org/#concept-document-url says that's what document URLs default to unless stated otherwise.  So whenever you have a browsing context you _will_ have an about:blank document in it if there's nothing else.  But that should happen sync with browsing context creation, per spec.

Comment 3

[Henri Sivonen (:hsivonen)]

Back when I looked at this years ago the situation was as follows:

 * It's hard to get the events right when replacing parser-generated about:blank fully with a docshell-created about:blank.
 * To have any chance of evaluating if we are getting the events right, we have to be able to assert on readyState (i.e. it progresses monotonically for a given doc, no exceptions).
 * To be able to assert on readyState, readyState needs to be solid.
 * readyState progression depends on nsDocLoader::mIsLoadingDocument, which in unreliable.
 * nsDocLoader::mIsLoadingDocument is unreliable, because it's a fundamental design error. Instead of expecting all possible code that can affect whether a document in the browsing context is loading to update the boolean appropriately, we should instead have an object representing a navigation from the point a link is clicked across redirects to the point the document fires its load event such that the browsing context would have a pointer to this kind of object and once the document is created the document would get a pointer to this object, too, and maintain it's readyState on this object. This way, when asking if a browsing context is loading a document, it could check if the current navigation object and the navigation object of the current document are the same, say yes if they aren't and if they are, check if the navigation object has progressed all the way to the load event.

Back when I was looking at this, fixing the last point would have been too large a yak shave. Maybe nsILoadInfo is suitable these days. If it would have been suitable back then, nobody told me so.

Additionally, the history API unit tests were a major source of grief. It was totally unclear which tests accidentally codified Geckoisms and which ones actually tested cross-browser Web compat-relevant behaviors.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> If it would have been suitable back then, nobody told me so.

It didn't exist at all back then.

It's cloned, not just referenced, across redirects, so it's not super-clear whether it would be suitable now.  But we could create a new object and hang it off loadinfo, and pass it through the chain.  Do you know offhand whether there are existing bugs tracking the necessary steps there?  I checked for open bugs mentioning mIsLoadingDocument, and this and bug 1418920 are the only one that come up.

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #4)
> > If it would have been suitable back then, nobody told me so.
> 
> It didn't exist at all back then.
> 
> It's cloned, not just referenced, across redirects, so it's not super-clear
> whether it would be suitable now. 

Probably not then.

> But we could create a new object and hang
> it off loadinfo, and pass it through the chain.  Do you know offhand whether
> there are existing bugs tracking the necessary steps there?  I checked for
> open bugs mentioning mIsLoadingDocument, and this and bug 1418920 are the
> only one that come up.

Looks like we don't have bug for this.

Comment 8

[Chris Peterson [:cpeterson]]

P2 because this bug is not urgent for Focus, but [geckoview:fenix:p1] because Fenix cares about it. If this is a big hassle for GV, the Fenix UI can probably work around the issue by not displaying the about:blank URL in the address bar.

This bug is Focus issue #3473:

https://github.com/mozilla-mobile/focus-android/issues/3473

Comment 9

[Chris Peterson [:cpeterson]]

P1 for Fenix

Comment 10

[Sebastian Kaspari (:sebastian; :pocmo)]

P2 because this bug is not urgent for Focus, but [geckoview:fenix:p1] because Fenix cares about it. If this is a big hassle for GV, the Fenix UI can probably work around the issue by not displaying the about:blank URL in the address bar.

Note that this workaround already exists in our component, we ignore the initial load of about:blank.

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Sebastian Kaspari (:sebastian) from comment #10)

P2 because this bug is not urgent for Focus, but [geckoview:fenix:p1] because Fenix cares about it. If this is a big hassle for GV, the Fenix UI can probably work around the issue by not displaying the about:blank URL in the address bar.

Note that this workaround already exists in our component, we ignore the initial load of about:blank.

Ah, ok. Focus does not. Maybe this isn't a big deal, then, if a-c already works around it?

Comment 12

[Chris Peterson [:cpeterson]]

Deferring until after Fenix MVP because A-C already has a workaround.

Comment 14

[Jan Henning [:JanH]]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #11)

Ah, ok. Focus does not. Maybe this isn't a big deal, then, if a-c already works around it?

As per bug 814110, there could still be problems with aborting and then resuming an initial pageload.
Reloading generally reloads the current page, which in the general case is fine - if after clicking a link you manage to abort the page load quickly enough (before onlocationchange I think?), you remain on the previous page and I suppose it's absolutely expected that hitting reload would continue to reload the previous page.

For the initial page load in a new tab (especially where the page load happens together with opening the tab, like opening a link in a new tab, an external Intent being opened in a new tab, session restoring, etc.) on the other hand, the previous page will be about:blank, and a reload reloading about:blank if you quickly aborted the initial page load will be less helpful.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I'm not at all convinced bug 814110 is really a duplicate of this bug.

In particular, per spec, an initial about:blank is created whether there is a navigation or not. A reload after that via web-exposed APIs should reload that about:blank, unless some other navigation has matured (which in the setup of bug 814110 it has not).

Now the reload button in our UI could have different semantics from location.reload(), of course. But that's unrelated to about:blank navigations or anything like that. In particular, in the setup of bug 814110 the initial about:blank navigation has been canceled already by starting the "real" navigation, so it's really not relevant to the behavior. Am I just missing something?

Comment 16

[Chris Peterson [:cpeterson]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #15)

Now the reload button in our UI could have different semantics from location.reload(), of course. But that's unrelated to about:blank navigations or anything like that. In particular, in the setup of bug 814110 the initial about:blank navigation has been canceled already by starting the "real" navigation, so it's really not relevant to the behavior. Am I just missing something?

I see what you mean. I agree that bug 814110 is not a duplicate of this bug. I'll reopen bug 814110.

Comment 19

[Henri Sivonen (:hsivonen)]

Status update: Bug 543435 is in a pretty good shape when it comes to Web-observable behavior aligning with Chrome. More work is still needed in 2023 to deal with stuff that's not Web-visible but is visible to chrome JS.

Comment 20

[Chris Peterson [:cpeterson]]

Tasks should have severity N/A.