Open Bug 1837949 Opened 1 year ago Updated 5 months ago

A navigation within a browsing context should not be affected by an already ongoing one

Categories

(Remote Protocol :: Agent, defect, P2)

Product:
Remote Protocol
Component:
Agent
Type:
defect

Tracking

(Not tracked)

People

(Reporter: whimboo, Unassigned)

References

(Blocks 4 open bugs)

Details

That's an issue I have seen here:
https://treeherder.mozilla.org/logviewer?job_id=418942864&repo=mozilla-central&lineNumber=1916-1940

As it can be seen the load of about:blank is already happening and while it's not done yet another navigation request by the client has been requested. Instead of waiting for the page of the new request to be loaded, we return with the first stop state of the progress listener:

[task 2023-06-12T08:33:25.553Z] 08:33:25     INFO - PID 2804 | 1686558805551	RemoteAgent	DEBUG	WebDriverBiDiConnection 26c0d637-60a9-45ea-841a-fe44f87f6b7f -> {"id":3,"method":"browsingContext.navigate","params":{"context":"b1ebd34c-d0eb-40bb-ba05-ffba8b70bf67","url":"http://web-platform.test:8000/webdriver/tests/support/inline.py?doc=%3C%21doctype+html%3E%0A%3Cmeta+charset%3DUTF-8%3E%0A%0A+ ... %2Bsit%2Bamet.%253C%252Fdiv%253E%26mime%3Dtext%252Fhtml%26charset%3DUTF-8%27%3E%3C%2Fiframe%3E&mime=text%2Fhtml&charset=UTF-8","wait":"complete"}}
[task 2023-06-12T08:33:25.553Z] 08:33:25     INFO - PID 2804 | 1686558805551	RemoteAgent	TRACE	Module root/browsingContext.jsm found for ROOT
[task 2023-06-12T08:33:25.553Z] 08:33:25     INFO - PID 2804 | 1686558805551	RemoteAgent	TRACE	Received command browsingContext.navigate for destination ROOT
[task 2023-06-12T08:33:25.553Z] 08:33:25     INFO - PID 2804 | 1686558805551	RemoteAgent	TRACE	Module root/browsingContext.jsm found for ROOT
[task 2023-06-12T08:33:25.557Z] 08:33:25     INFO - PID 2804 | 1686558805551	RemoteAgent	TRACE	Received command browsingContext._getBaseURL for destination WINDOW_GLOBAL
[task 2023-06-12T08:33:25.558Z] 08:33:25     INFO - PID 2804 | 1686558805551	RemoteAgent	TRACE	Module windowglobal-in-root/browsingContext.jsm found for WINDOW_GLOBAL
[task 2023-06-12T08:33:25.559Z] 08:33:25     INFO - PID 2804 | 1686558805552	RemoteAgent	TRACE	Module windowglobal/browsingContext.jsm found for WINDOW_GLOBAL
[task 2023-06-12T08:33:25.560Z] 08:33:25     INFO - PID 2804 | 1686558805552	RemoteAgent	TRACE	Module windowglobal-in-root/browsingContext.jsm found for WINDOW_GLOBAL
[task 2023-06-12T08:33:25.560Z] 08:33:25     INFO - PID 2804 | 1686558805552	RemoteAgent	TRACE	Received command browsingContext._getBaseURL for destination WINDOW_GLOBAL
[task 2023-06-12T08:33:25.562Z] 08:33:25     INFO - PID 2804 | 1686558805553	RemoteAgent	TRACE	Module windowglobal/browsingContext.jsm found for WINDOW_GLOBAL
[task 2023-06-12T08:33:25.563Z] 08:33:25     INFO - PID 2804 | 1686558805553	RemoteAgent	TRACE	Module windowglobal/browsingContext.jsm found for WINDOW_GLOBAL
[task 2023-06-12T08:33:25.563Z] 08:33:25     INFO - PID 2804 | 1686558805554	RemoteAgent	TRACE	[3] ProgressListener Start: expectNavigation=true resolveWhenStarted=false unloadTimeout=200 waitForExplicitStart=true
[task 2023-06-12T08:33:25.564Z] 08:33:25     INFO - PID 2804 | 1686558805554	RemoteAgent	TRACE	[3] ProgressListener Document already loading about:blank
[task 2023-06-12T08:33:25.565Z] 08:33:25     INFO - PID 2804 | 1686558805554	RemoteAgent	TRACE	[3] ProgressListener Skip setting the unload timer
[task 2023-06-12T08:33:25.566Z] 08:33:25     INFO - PID 2804 | console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.sys.mjs", 399))
[task 2023-06-12T08:33:25.567Z] 08:33:25     INFO - PID 2804 | 1686558805559	RemoteAgent	TRACE	[3] ProgressListener Check loading state: isStart=0 isStop=16
[task 2023-06-12T08:33:25.568Z] 08:33:25     INFO - PID 2804 | 1686558805563	RemoteAgent	TRACE	[3] ProgressListener Check loading state: isStart=1 isStop=0
[task 2023-06-12T08:33:25.570Z] 08:33:25     INFO - PID 2804 | 1686558805563	RemoteAgent	TRACE	[3] ProgressListener state=start: http://web-platform.test:8000/webdriver/tests/support/inline.py?doc=%3C%21doctype+html%3E%0A%3Cmeta+charset%3DUT ... %2Bsit%2Bamet.%253C%252Fdiv%253E%26mime%3Dtext%252Fhtml%26charset%3DUTF-8%27%3E%3C%2Fiframe%3E&mime=text%2Fhtml&charset=UTF-8
[task 2023-06-12T08:33:25.579Z] 08:33:25     INFO - PID 2804 | 1686558805577	Marionette	TRACE	Remoteness change detected. Set new top-level browsing context to 3
[task 2023-06-12T08:33:25.581Z] 08:33:25     INFO - PID 2804 | JavaScript error: chrome://remote/content/shared/Realm.sys.mjs, line 183: TypeError: argument is not a global object
[task 2023-06-12T08:33:25.582Z] 08:33:25     INFO - PID 2804 | JavaScript error: resource://devtools/client/jsonview/Sniffer.sys.mjs, line 50: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIChannel.contentType]
[task 2023-06-12T08:33:26.537Z] 08:33:26     INFO - PID 2804 | 1686558806536	RemoteAgent	TRACE	[3] ProgressListener Check loading state: isStart=0 isStop=16
[task 2023-06-12T08:33:26.539Z] 08:33:26     INFO - PID 2804 | 1686558806536	RemoteAgent	TRACE	[3] ProgressListener state=stop: about:blank
[task 2023-06-12T08:33:26.539Z] 08:33:26     INFO - PID 2804 | 1686558806536	RemoteAgent	TRACE	[3] ProgressListener Stop: has error=false
[task 2023-06-12T08:33:26.540Z] 08:33:26     INFO - PID 2804 | 1686558806536	RemoteAgent	DEBUG	WebDriverBiDiConnection 26c0d637-60a9-45ea-841a-fe44f87f6b7f <- {"id":3,"result":{"navigation":null,"url":"about:blank"}}

We should figure out if a new navigation request should actually cancel an ongoing navigation so that interference like that can be avoided.

Blocks: 1832587
No longer blocks: 1837945

Thanks for filing this. So it looks like with the fix from Bug 1832891 it's now made it clear that we also have frequent issues with simply waiting for the initial tab. And it's not only about overlapping navigations, it can also affect tests which are trying to execute a script, such as Bug 1835369.

We could of course increase the default timeout a bit, but we already know that on Android we will most likely reach it for every test so we would have to be careful about increasing too much.

A workaround could also be to try to use new tabs for tests as much as possible? I imagine in this case we would not be impacted by the initial tab being loaded or not?

(In reply to Julian Descottes [:jdescottes] from comment #1)

We could of course increase the default timeout a bit, but we already know that on Android we will most likely reach it for every test so we would have to be careful about increasing too much.

Do you know if that holds true for both Fission enabled and disabled?

A workaround could also be to try to use new tabs for tests as much as possible? I imagine in this case we would not be impacted by the initial tab being loaded or not?

I don't think that this is actually the problem here. When a new session is started and no navigation takes place it should be all fine, but if e.g. during startup about:blank gets loaded we run into this problem. I wonder if it would help if we start Firefox with the about:blank URL explicitly specified via the command line. As such we should not stick on the initial document, or do we?

And as discussed in the meeting an ongoing navigation should always be canceled when a follow-up command is triggering another navigation, except for the new session command where this behavior should not take place.

Whiteboard: [webdriver:triage]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #2)

(In reply to Julian Descottes [:jdescottes] from comment #1)

We could of course increase the default timeout a bit, but we already know that on Android we will most likely reach it for every test so we would have to be careful about increasing too much.

Do you know if that holds true for both Fission enabled and disabled?

Both.

A workaround could also be to try to use new tabs for tests as much as possible? I imagine in this case we would not be impacted by the initial tab being loaded or not?

I don't think that this is actually the problem here. When a new session is started and no navigation takes place it should be all fine, but if e.g. during startup about:blank gets loaded we run into this problem. I wonder if it would help if we start Firefox with the about:blank URL explicitly specified via the command line. As such we should not stick on the initial document, or do we?

Not sure what you mean. The issue is that the context where we are trying to run a command (either a navigation, or a script evaluation) is going to experience a navigation. If instead we create a new tab, this will trigger a navigation which we expect to monitor (that was the purpose of the fix on Bug 1832891). Therefore we should have a fully navigated tab available, with no potential navigation which should break the next command.

"When a new session is started and no navigation takes place it should be all fine" -> This is not the case though? Most of the failures I see on those bugs are coming from the initial tab which is still loading when we resolve the new session, not from an additional navigation?

And as discussed in the meeting an ongoing navigation should always be canceled when a follow-up command is triggering another navigation, except for the new session command where this behavior should not take place.

This will not help with use cases where the late navigation breaks a script execution (eg Bug 1835369).

The severity field is not set for this bug.
:whimboo, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(hskupin)
Severity: -- → S3
Flags: needinfo?(hskupin)
Priority: -- → P2

Good test cases for this can be found on bug 1522790 comment 53 for wpt tests. Hereby opening a new tab in GeckoView via window.open() and awaiting the load event does still not wait long enough until the window has been finished loading. It means the browser-delayed-startup-finished is getting sent out when there is already an ongoing navigation for the initial page load of the new windows / tab. Triggering another navigation at the same time causes the navigation to get stuck.

We may be able to reproduce with a Marionette test by not waiting for the browser-delayed-startup-finished notification. I'll check that.

Blocks: 1891028
See Also: → 1891008

Just as note there was some investigation done for the WebExtension related API where a similar behavior (unusuable tab) was observed. See bug 1797558 comment 23.

See Also: → 1797558
You need to log in before you can comment on or make changes to this bug.