(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #6)
(In reply to Julian Descottes [:jdescottes] from comment #5)
Since waitForInitialNavigation should only ever have to wait for an about:blank load (and not a custom URL which might be slow to answer for good reasons), it sounds acceptable to come up with a hardcoded timeout value, potentially with a platform specific multiplier applied.
What about cases like
window.open("https://example.org")? Here we open a new window (and tab) which might load the temporary
about:blank first, but then loads immediately
https://example.org. So I don't think that we can always assume we only load
about:blank. Or do I miss something?
At the moment, I think we only use
waitForInitialNavigation when we open new tabs/windows without providing a URL. Apart from tests, there are 3 call sites I think:
- browsingContext.create from BiDi
- newSession from marionette
- newWindow from marionette
In all three cases, I don't think we can provide a URL, so the commands should return only with an about:blank load (might be missing something for marionette).
In the general case where a script opens a window, using eg
window.open, in BiDi we would only rely on events to monitor that. Not sure if classic/marionette monitors this navigation in some other way? But at least it doesn't seem to rely on
Another option would be to keep relying on the current unloadTimeout mechanism, but use a much higher value when called from waitForInitialNavigation. We would use that instead of
This might be another good alternative which then only affects the case around unloading. We would still have the problem when the page is not finishing the load, but that could be handled by a different bug.
Henrik: Should we go for the first option here and add a
timeout option to ProgressListener + attempt to cancel the navigation? If yes we should split that in a separate bug, in case of backouts. Otherwise the second option is much simpler. Let me know what you think.
I like the 2nd option more as well. So maybe lets try that one first.
Canceling a possible navigation might still be a question that should be discussed. It's not clear if that should be up to the client or the remote end to handle it.
Ok, that sounds good to me as well. I had started a prototype for handling timeout + cancelling requests, I might just file a bug and have the patch around in case it's useful to support a future
Thanks for the feedback.