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.
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.
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.
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
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.
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.
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.
(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.
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.
Ursula, can you help with comment 8? Thanks.
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.
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.
You need to log in before you can comment on or make changes to this bug.