Closed Bug 1495513 Opened Last year Closed 7 months ago

Perma TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/get_current_url/get.py | expected OK

Categories

(Testing :: geckodriver, defect, P2)

All
Windows
defect

Tracking

(firefox65 disabled, firefox66 disabled, firefox67 fixed)

RESOLVED FIXED
mozilla67
Tracking Status
firefox65 --- disabled
firefox66 --- disabled
firefox67 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: whimboo)

References

(Depends on 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

This is actually a hang in "Webdriver:Navigate" when loading `file:///`:

> 14:17:55     INFO - PID 5280 | 1538057875037	Marionette	TRACE	0 -> [0,78,"WebDriver:Navigate",{"url":"file:///"}]
> 14:17:55     INFO - PID 5280 | 1538057875045	Marionette	DEBUG	[6442450945] Received DOM event beforeunload for about:blank
> 14:17:55     INFO - PID 5280 | 1538057875060	Marionette	DEBUG	[6442450945] Received DOM event pagehide for about:blank
> 14:17:55     INFO - PID 5280 | 1538057875061	Marionette	DEBUG	[6442450945] Received DOM event unload for about:blank
> 14:17:55     INFO - PID 5280 | 1538057875062	Marionette	DEBUG	[6442450945] Received observer notification outer-window-destroyed
> 14:17:55     INFO - PID 5280 | 1538057875360	Marionette	DEBUG	[8589934593] Frame script loaded
> 14:17:55     INFO - PID 5280 | 1538057875366	Marionette	DEBUG	[8589934593] Frame script registered
> 14:17:55     INFO - PID 5280 | 1538057875411	Marionette	DEBUG	[8589934593] Check readyState uninitialized for about:blank
[..]
> 14:19:09     INFO - TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/get_current_url/get.py | expected OK

I will mark the test as disabled via my patch on bug 1370636.
OS: Unspecified → Windows
Hardware: Unspecified → All
Summary: Intermittent TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/get_current_url/get.py | expected OK → Perma TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/get_current_url/get.py | expected OK
I think the problematic section in the code is here:
https://dxr.mozilla.org/mozilla-central/rev/dcba2a476ccfb77f859b3614d2c77ed3cc06a225/testing/marionette/listener.js#148-165

Maybe it is a race between checking for the `document.readyState` and adding the event listeners for `DOMContentLoaded` and `pageshow`. 

But what makes me wonder is why this hang only happens for the wdspec tests, but not the Marionette unit tests in test_navigation.py, which also contains a couple of page loads for `file:///`.
This actually seems to be a problem with Firefox on Windows. Even in a regular profile I'm not able to load `file:///`. But I can load `file:///C:/`. So I assume that if no drive letter has been specified, loading this URL fails.

Bob, can you shed some light on that? AFAIR you worked on loading such URLs not too long ago. Thanks.
Flags: needinfo?(bobowencode)
I'm fairly sure that the expected result should be an error page similar when trying to open `file:///c:/` under Linux or MacOs.
(In reply to Henrik Skupin (:whimboo) [away 12/05-12/16] from comment #3)
> This actually seems to be a problem with Firefox on Windows. Even in a
> regular profile I'm not able to load `file:///`. But I can load
> `file:///C:/`. So I assume that if no drive letter has been specified,
> loading this URL fails.
> 
> Bob, can you shed some light on that? AFAIR you worked on loading such URLs
> not too long ago. Thanks.

Sorry about the delay here, I've been a bit slow on needinfos recently, but I must have missed this one or I'd have answered earlier.
I worked on the process that they load in, but not the actual loading itself.
I guess it comes under networking ... is this a regression?
Flags: needinfo?(bobowencode)
(In reply to Bob Owen (:bobowen) (PTO until 3rd Jan) from comment #6)
> I guess it comes under networking ... is this a regression?

I cannot say if that is a regression or not because we didn't run the test on Windows before. Which kind of extra logs would be helpful to investigate this problem?
Flags: needinfo?(bobowencode)
(In reply to Henrik Skupin (:whimboo) [away 12/21-01/01] from comment #7)
> (In reply to Bob Owen (:bobowen) (PTO until 3rd Jan) from comment #6)
> > I guess it comes under networking ... is this a regression?
> 
> I cannot say if that is a regression or not because we didn't run the test
> on Windows before. Which kind of extra logs would be helpful to investigate
> this problem?

I've just tried mozregression to load firefox 31.0a1 on Windows and file:/// does not work.
It appears to just do nothing.
So, it looks like this needs fixing in the test.
Flags: needinfo?(bobowencode)
(In reply to Bob Owen (:bobowen) (PTO until 3rd Jan) from comment #8)
> I've just tried mozregression to load firefox 31.0a1 on Windows and file:///
> does not work.
> It appears to just do nothing.

This won't work given that Marionette at this time wasn't that feature packed and only starting from Firefox 56 can load file:// URLs. I implemented that via bug 1332122.

> So, it looks like this needs fixing in the test.

No, the test is fine and works in other browsers. So I will ask my question again, which kind of logs would be helpful for you so we can further investigate it.
Flags: needinfo?(bobowencode)
(In reply to Henrik Skupin (:whimboo) [away 12/21-01/01] from comment #3)
> This actually seems to be a problem with Firefox on Windows. Even in a
> regular profile I'm not able to load `file:///`. But I can load
> `file:///C:/`. So I assume that if no drive letter has been specified,
> loading this URL fails.

Actually.... I missed that I already found the reason why it is failing. So maybe you can just verify that this behavior is correct and that we cannot assume that loading `file:///` on Windows (and vice versa) will work.

But I still wonder why it just hangs. So I assume there might still be a bug in Firefox?
(In reply to Henrik Skupin (:whimboo) [away 12/21-01/01] from comment #9)
> (In reply to Bob Owen (:bobowen) (PTO until 3rd Jan) from comment #8)
> > I've just tried mozregression to load firefox 31.0a1 on Windows and file:///
> > does not work.
> > It appears to just do nothing.
> 
> This won't work given that Marionette at this time wasn't that feature
> packed and only starting from Firefox 56 can load file:// URLs. I
> implemented that via bug 1332122.

I wasn't using Marionette, just Firefox.

> > So, it looks like this needs fixing in the test.
> 
> No, the test is fine and works in other browsers. So I will ask my question
> again, which kind of logs would be helpful for you so we can further
> investigate it.

file:/// doesn't appear to work in IE or Chrome on Windows either.

> Actually.... I missed that I already found the reason why it is failing. So
> maybe you can just verify that this behavior is correct and that we cannot
> assume that loading `file:///` on Windows (and vice versa) will work.
> 
> But I still wonder why it just hangs. So I assume there might still be a bug
> in Firefox?

Possibly, the other browsers give some sort of error which makes more sense, presumably the test is reacting to that error.
However, like I said in comment 6, I don't think I'm the correct person to look at file:// URL loading issues, you probably want someone from the network team.
Flags: needinfo?(bobowencode)
I thought the hang with file:/// was a known thing because file:/// urls are run in a seperate process and we don't handle the procesess change correctly in marionette?
(In reply to James Graham [:jgraham] from comment #12)
> I thought the hang with file:/// was a known thing because file:/// urls are
> run in a seperate process and we don't handle the procesess change correctly
> in marionette?

No, process changes are working quite well for some time with Marionette, otherwise we wouldn't be able to load a lot of URLs those days due to multiple content processes. This is an underlying Firefox bug.

(In reply to Bob Owen (:bobowen) (PTO until 3rd Jan) from comment #11)
> > Actually.... I missed that I already found the reason why it is failing. So
> > maybe you can just verify that this behavior is correct and that we cannot
> > assume that loading `file:///` on Windows (and vice versa) will work.
> > 
> > But I still wonder why it just hangs. So I assume there might still be a bug
> > in Firefox?
> 
> Possibly, the other browsers give some sort of error which makes more sense,
> presumably the test is reacting to that error.
> However, like I said in comment 6, I don't think I'm the correct person to
> look at file:// URL loading issues, you probably want someone from the
> network team.

Maybe Patrick can help or redirect to the right person here. Just to summary the problem... while file:/// is a valid URL on *nix systems, it cannot be loaded on Windows. Usually it should result in a not found error, but currently Firefox on Windows loads this page forever. Do you have an idea why this happens? Thanks

It looks like Patrick isn't with us anymore. Valentin, maybe you could help out, or maybe know the person who has knowledge in that area? Please see my last comment. Thanks!

Flags: needinfo?(valentin.gosu)

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

It looks like Patrick isn't with us anymore. Valentin, maybe you could help out, or maybe know the person who has knowledge in that area? Please see my last comment. Thanks!

Indeed, I would expect that loading file:/// would fail on windows, but if it just keeps loading forever, that seems like a bug. I'll take a look at it.

Valentin, do you know when you will be able to have a look at this bug? Maybe we should file a new one under networking?

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

Valentin, do you know when you will be able to have a look at this bug? Maybe we should file a new one under networking?

Hi Henrik, I was away from my windows machine and I have a high priority project I have to take care of, but I should be able to get to it next Monday, if that's OK.
Otherwise I can try a building in a VM, if it's urgent.

No, it's not urgent. I only wanted to check if you already had a chance to take a look. Thanks.

The problem seems to be coming from here:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.loadURI]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/actors/WebNavigationChild.jsm :: loadURI/< :: line 126"  data: no]
    loadURI resource://gre/actors/WebNavigationChild.jsm:126
    _wrapURIChangeCall resource://gre/actors/WebNavigationChild.jsm:63
    loadURI resource://gre/actors/WebNavigationChild.jsm:125
    receiveMessage resource://gre/actors/WebNavigationChild.jsm:43
    receiveMessage resource://gre/modules/ActorManagerChild.jsm:160

_wrapURIChangeCall in WebNavigationChild.jsm doesn't propagate the errors it gets from loadURI/LoadURIFromScript, so it just stalls. When I removed the try {} block _wrapURIChangeCall, the load failed immediately. Also, in non-e10s, loading file:/// fails immediately.

Flags: needinfo?(valentin.gosu) → needinfo?(kmaglione+bmo)

Mike, maybe you could also have a look at Valentin's reply? Maybe Kris is not around those days. Thanks!

Flags: needinfo?(mconley)

_wrapURIChangeCall was added in bug 1241085, but even before then we had a try/catch around the loadURIWithOptions call:

https://hg.mozilla.org/mozreview/gecko/rev/dea0a728eec67a7c78ac57ce34e83f7d554136fa#l1.58

that try/catch was added in bug 798249.

Can you tell me more about this bug? Does it only manifest for Marionette, or is this something that could impact our users? If so, what are the STR?

Flags: needinfo?(mconley) → needinfo?(hskupin)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #23)

Can you tell me more about this bug? Does it only manifest for Marionette, or is this something that could impact our users? If so, what are the STR?

Just open Firefox on Windows and try to load file:/// via the location bar. The spinner will run forever. So yes, it impacts users.

Flags: needinfo?(hskupin) → needinfo?(mconley)

STR:

  1. Load file:///INVALID in the URL bar and press enter

ER:

The file URI is invalid, and should result in some kind of error message in the tab.

AR:

The tab blanks out, and seems to load forever (the tab throbber throbs).

Component: geckodriver → Document Navigation
Flags: needinfo?(mconley)
Product: Testing → Core
Summary: Perma TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/get_current_url/get.py | expected OK → Navigating to an invalid file:// URI ends up loading forever
Version: Version 3 → unspecified
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1180876
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Navigating to an invalid file:// URI ends up loading forever → Perma TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/get_current_url/get.py | expected OK

This is a test failure, so please don't move to a different component, or dupe it. Thanks for investigating, Mike.

Component: Document Navigation → geckodriver
Flags: needinfo?(kmaglione+bmo)
Product: Core → Testing

Maybe we should just use different file URIs for Windows and Linux/MacOS, so we can make sure that we will always get correct content displayed.

So we can basically use server_config["doc_root"] and prefix it with file:// to hopefully have it platform independent.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e03a210ac9d5384e131f543edd8ad5d1e5c4bb9e

Assignee: nobody → hskupin
Status: REOPENED → ASSIGNED
Priority: P5 → P2
Attachment #9045250 - Attachment description: Bug 1495513 - [wdspec] Fix get_current_url test for file protocol on Windows. r?ato → Bug 1495513 - [wdspec] Add tests for file protocol. r?ato
Pushed by hskupin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/be197c4fadf0
[wdspec] Add tests for file protocol. r=ato
Status: ASSIGNED → RESOLVED
Closed: 7 months ago7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15547 for changes under testing/web-platform/tests
Upstream PR merged
You need to log in before you can comment on or make changes to this bug.