geckodriver
geckodriver copied to clipboard
mozilla
Loading a URL with an unknown MIME type runs into a page load timeout
System
- Version: 0.19.1
- Platform: Windows 10, Fall Update
- Firefox: 59.0a1 (2017-11-16)
- Selenium: .NET 3.7.0
Testcase
Provided a csv file (I can provide one if necessary) and a simple HTML with just a <a href="path/to/csv">Click Me</a> in the <body>, call Browser.Driver.Navigate().GoToUrl("path/to/csv"); as a test case, opening the link to the csv directly
Stacktrace
OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL http://localhost:60426/session/3952ee36-afa0-42ce-9650-4c2f7a8b6882/elements timed out after 60 seconds.
----> System.Net.WebException : Timeout für Vorgang überschritten
bei OpenQA.Selenium.Remote.HttpCommandExecutor.MakeHttpRequest(HttpRequestInfo requestInfo)
bei OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
bei OpenQA.Selenium.Remote.DriverServiceCommandExecutor.Execute(Command commandToExecute)
bei OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
bei OpenQA.Selenium.Remote.RemoteWebDriver.FindElements(String mechanism, String value)
bei TrackPilotN.Selenium.Tests.utils.Browser.<>c.<WaitForPageLoad>b__11_0(IWebDriver driver) in C:\Users\oberlaender\Source\Workspaces\PLT\Web\TrackPilotN.Selenium.Tests\utils\Browser.cs:Zeile 149.
bei OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
bei TrackPilotN.Selenium.Tests.utils.Browser.WaitForPageLoad() in C:\Users\oberlaender\Source\Workspaces\PLT\Web\TrackPilotN.Selenium.Tests\utils\Browser.cs:Zeile 148.
bei TrackPilotN.Selenium.Tests.utils.Browser.Goto(String url) in C:\Users\oberlaender\Source\Workspaces\PLT\Web\TrackPilotN.Selenium.Tests\utils\Browser.cs:Zeile 37.
bei TrackPilotN.Selenium.Tests.pages.Data.Addresses.GoTo() in C:\Users\oberlaender\Source\Workspaces\PLT\Web\TrackPilotN.Selenium.Tests\pages\Data.cs:Zeile 66.
bei TrackPilotN.Selenium.Tests.tests.AddressTests.Addresses_ImportTemplate_CanBeDownloaded() in C:\Users\oberlaender\Source\Workspaces\PLT\Web\TrackPilotN.Selenium.Tests\tests\AddressTests.cs:Zeile 76.
--WebException
bei System.Net.HttpWebRequest.GetResponse()
bei OpenQA.Selenium.Remote.HttpCommandExecutor.MakeHttpRequest(HttpRequestInfo requestInfo)
Trace-level log
The console window closes after this for some reason (maybe geckodriver crashed?), but Firefox remains open. I suspect this is because it's still stuck on the csv page, but I'm not sure why
@curtisy1, the attached trace.txt is not a trace level log. Please follow the instructions at https://firefox-source-docs.mozilla.org/testing/geckodriver/geckodriver/TraceLogs.html in how to enable those.
Also if possible provide such a faulty URL for a .csv file.
Thanks.
@whimboo, sorry but could you elaborate on why this is not a trace level log? I already instantiate my WebDriver as mentioned in the docs, like this
FirefoxOptions options = new FirefoxOptions();
options.LogLevel = FirefoxDriverLogLevel.Trace;
IWebDriver driver = new FirefoxDriver(options);
and from what I can see 1510917943650 geckodriver::marionette TRACE -> 45:[0,2,"get",{"url":"http://localhost:31337/"}] (in line 4, just as one example) is the essential part of a trace level log.
As for a faulty URL, I'm setting that up when I get home today.
I'm looking at the referenced attachment in the original comment with the name Trace.txt, and this is indeed not a trace log. Reason is that this output you are referring here comes from geckodriver and its Marionette module, but not from Marionette itself. In such a case it would have to be "Marionette" only.
Here is what I can see in the log:
1510917943650 geckodriver::marionette TRACE -> 45:[0,2,"get",{"url":"http://localhost:31337/"}] 1510917946410 geckodriver::marionette TRACE <- [1,2,null,{}]
This takes 2.8s for loading the URL. Depending on how fast it gets delivered from localhost, it doesn't look too bad. Otherwise the log is too huge, to figure out what exactly doesn't work for you.
Alright, if I understand correctly, the DEBUG lines are not relevant. I'm not sure if I can exclude those though, because using the method given in the docs produces the exact same log I uploaded.
Anyway, as promised here's a (hopefully) faulty URL http://curtisy1.github.io/demo/demo.csv
The CLICK ME can be reached via http://curtisy1.github.io/demo
@curtisy1, so let me rephrase the topic given that I'm not sure what the exact problem is you have here due to lots of different issues mentioned in your initial comment.
When you load the csv file directly via driver.get() the command returns immediately, but when exercising the load via element.click() it takes some seconds before the command returns?
@whimboo sorry for causing confusion. It's actually the exact opposite of what you described.
When I load the csv file via element.click(), the command returns and after that, all commands get properly executed
However when I load the csv file directly via driver.get(), the last thing that happens is a
1511948287848 geckodriver::marionette TRACE -> 63:[0,653,"get",{"url":"http://curtisy1.github.io/demo/demo.csv"}]
operation. After that, the Firefox window kind of "gets stuck" (because it doesn't return anything?) on the page and all following commands fail to get executed.
Ah, now I see. So yes, this is a known problem (bug 1366035) and happens due to the unknown MIME type, and most likely the save as dialog as displayed. You would have to instruct Firefox to not show this dialog. That should actually work, and should be done this way anyway.
The reason why it works for click() is that we stop waiting for the page to load after 5s if no unload event is happening after the beforeunload event was fired. And that is the case here. I feel this is wrong because it does not obey the currently set page load timeout value.
I will make a comment on the bug as mentioned above so we can see how click needs to be adjusted for this scenario.
Thanks for the answer!
You would have to instruct Firefox to not show this dialog
By this you mean browser.helperApps.neverAsk.saveToDisk should be set to application/csv, text/csv and browser.helperApps.alwaysAsk.force set to false, correct? Because I'm already doing that and it still happens
Maybe we should add these prefs to the recommended prefs? Or would that be an overstep?
Oh, I see. The preferences are correctly set, and the dialog does no longer appear. But it doesn't help us here because the wanted page load events are not received still. I think it is better to follow-up with everything else on the bug now, and keep this issue open until the bug is fixed.
@andreastt, no we cannot, because we don't want to add the whole world of available MIME types.
Is this issue fixed? I am using Firefox version 62 & GeckoDriver 0.22.0. Getting Net::ReadTimeOut when downloading file using driver.get(file_url). And driver becomes inaccessible. Is there any way to make driver accessible when I get this exception?
file:// protocol URLs are a known problem with geckodriver. This is in part tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1366035, although there may be separate problems with the file: protocol because of content browser remoteness changes (file: causes the content browser to always move to the main process).
Supporting the file: protocol is not currently a priority because it is not web content and doesn’t block WebDriver conformance.
As long as it's downloading a file, webdriver.get() will get stuck. And this doesn't happen in chromium-based browsers.
Any update or a known workaround for this please? I'm specifically asking about the fact that driver.get(url) hangs on a downloaded file (i.e. the popup has been suppressed using the webdriver options, and the MIME-type settings).
