Open
Bug 1366035
Opened 7 years ago
Updated 1 year ago
Timeout when navigating to a URL with an unknown MIME type
Categories
(Remote Protocol :: Marionette, defect, P2)
Tracking
(Not tracked)
NEW
People
(Reporter: github, Unassigned)
References
(Blocks 2 open bugs, )
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20170223233003 Steps to reproduce: I'm using geckodriver to launch Firefox. I tell Firefox to navigate (with the selenium request "/session/:SESSION/url" to a URL which serves a downloadable file (for example, http://mirrors.kernel.org/debian/README). Actual results: Geckodriver blocks for a while and then replies to my selenium request with error code 408 Timeout, "Timeout loading page after 300000ms" Expected results: The request should fail (or succeed) right away without the long timeout.
Comment 1•7 years ago
|
||
I can see this with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170514030207 CSet: 73b3fc64525b6816842c737e104ef2ac5482d217. We might have to wait until I can continue with bug 1333458. Usually the modal dialog handler should capture this dialog, and `get` should return. But somehow this is not happening here. I thought that we already had such a bug filed but cannot find it yet.
Blocks: webdriver
Status: UNCONFIRMED → NEW
Depends on: webdriver-navigate
Ever confirmed: true
Summary: marionette times out when navigating to non-html → Timeout when navigating to a URL with an unknown MIME type
Comment 2•7 years ago
|
||
But do note that we are unable to fix this in Firefox 51.
This problem also occurs if the modal dialog "Where do you want to save this file" doesn't appear, and instead the file just automatically downloaded into the Download directory.
Comment 4•7 years ago
|
||
It's not clear yet how we can best handle this situation. So I would have to spend more time in investigating it and cross-checking with the webdriver and HTML specs. Given that no workaround is known right now, I bump this bug up to P1.
Priority: -- → P1
Updated•6 years ago
|
Priority: P1 → P3
Comment 5•6 years ago
|
||
Please note that when using click to open such a URL, the command will return after 5s because of the missing `unload` event. When we get this implemented we have to also check what needs to be updated for `click` to make it behave correctly.
Comment 6•6 years ago
|
||
Olli, the page load handler of Marionette registers event listeners for the various page load events on the tabchildglobal. When Marionette has to load a URL like `http://curtisy1.github.io/demo/demo.csv`, we only see the listener for `beforeunload` fired, but nothing else. Do you know why that is the case? Can't framescripts in content processes receive any other kinds of events because those are only available in the parent process? Or would we have to change all of our code from handling events to a webprogresslistener? Could that one stay in the parent process, or would it have to be kept in the framescript? Thanks.
Flags: needinfo?(bugs)
Updated•6 years ago
|
Priority: P3 → P2
Comment 7•6 years ago
|
||
So beforeunload fires because we start the load to a new url, but then we realize that load won't end up to the current browsing context, so there won't be unload event, since nothing is unloaded. Do you want to effectively cancel loads which would trigger that modal dialog or what? Or handle such loads specially? Ursula is, I think, working on adding a flag to docshell to prevent external loads. Another option which might be ok for WebDriver is to override "@mozilla.org/uriloader/external-helper-app-service;1" service.
Flags: needinfo?(bugs)
Updated•6 years ago
|
Blocks: webdriver-navigate
No longer depends on: webdriver-navigate
Comment 8•6 years ago
|
||
(In reply to Olli Pettay [:smaug] (unusual timezone [JST] for a week) from comment #7) > So beforeunload fires because we start the load to a new url, but then we > realize that load won't end up to the current browsing context, so there > won't be unload event, since nothing is unloaded. Ah, I assume that this also applies to XPI files which will trigger the extension installation notification? > Do you want to effectively cancel loads which would trigger that modal > dialog or what? > Or handle such loads specially? More the latter for now. Currently we just hang in Marionette because no DOMContentLoaded nor load event fires. When I read the above correctly we might be able to get some kind of notification when we would watch the page load process from the parent process? Right now all the page load handling code is running in the frame script of the content process. Would I have to move all that? Or is there still a chance to figure such a situation by having the code running in the content process? Also would I need a progress listener then? > Ursula is, I think, working on adding a flag to docshell to prevent external > loads. > Another option which might be ok for WebDriver is to override > "@mozilla.org/uriloader/external-helper-app-service;1" service. Would that affect any MIME type, also XPIs? I don't want to get in conflict with add-on installation, but wouldn't worry about other application settings because generally we don't want that users can trigger unexpected launches of external applications during automated tests.
Flags: needinfo?(bugs)
Comment 9•6 years ago
|
||
As of now, doing it all in child process should work. And you may want to ask Ursula, what kind of thing they need for about:newtab.
Flags: needinfo?(bugs)
Comment 11•6 years ago
|
||
Hey Henrik, I don't know much about the external helper app service and whether overriding it affects MIME types and such, but I can provide some context on what Olli was mentioning about the docshell. Olli is referring to bug 1417779, which I was working on, but got de-prioritized a while back. What we were encountering on about:newtab was when we attempt to get an image for one of the highlights, if that image redirects to an external protocol, we would attempt to open that file with some application that can handle that protocol (like mailto:). So in terms of what we need for about:newtab, it would be a way to prevent external protocols from being loaded specifically via a redirect. However, when I was working on bug 1417779, I noticed that when we open a new tab and it launches the external application via the STR in the bug, we never actually hit the helper app dialog code, and I wasn't able to debug why. So I'm not sure overriding the external helper app service would fix the issue for about:newtab anyways, but if it fixes the issues during automated tests, I don't see any problems there. I'm happy to share my findings on bug 1417779 with your further, Henrik, if you think it might be valuable to pursue for this issue.
Flags: needinfo?(usarracini)
Comment 12•6 years ago
|
||
Thank you for the detailed answer Ursula! If I find the time I would like to try to override the external-helper-app-service. Do you know of an example somewhere? I cannot find anything in our tree, and don't know where to start from. An example for overriding another service might also help.
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 16•4 years ago
|
||
Running the code below with a recent version of Firefox I can see the following output:
self.marionette.navigate("http://curtisy1.github.io/demo/demo.csv")
1600249481046 Marionette TRACE Received observer notification toplevel-window-ready
So maybe we can just handle that notification and early abort the command until the override for the external-helper-app-service is available. The only question is if this dialog is detected as modal dialog but following tests. Maybe not.
Updated•2 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•