1873880 - BiDi fetchError tests require more time to reach the error page on Windows

Status: RESOLVED FIXED

(Remote Protocol :: WebDriver BiDi, defect, P2)

Description

[Julian Descottes [:jdescottes]]

The wdspec tests for network.fetchError try to fetch or navigate to an invalid URL: "https://not_a_valid_url/". The corresponding request fails with NS_ERROR_UNKNOWN_HOST.

On Linux and macos, the request fails very quickly, but on Windows (on CI at least, I can not test locally for now), the requests usually take more than 2 seconds to error. Since our default "wait" timeout is set to 2 seconds, those tests very frequently fail on windows. We should investigate why this is the case and if we should increase the timeout or try to fix an underlying issue.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Out of interest does that also happen for the browsingContext.navigate command or is really fetch only affected by that? Maybe it's an issue with XMLHttpRequest?

Comment 2

[Julian Descottes [:jdescottes]]

I think it only impacts fetch

Comment 3

[Julian Descottes [:jdescottes]]

Hi Valentin,

Do you know if Windows can be slower to error for some requests? In our tests for now we mostly use an unknown host (https://not_a_valid_url/ which should fail with NS_ERROR_UNKNOWN_HOST) and we expect the request to error rather quickly.

But on Windows CI, it takes more than 2 seconds to receive the BiDi network.fetchError event, even with opt builds. Technically this event takes its root in the onInputStreamReady callback of our response listener.

If this is expected we can just adjust our test timeouts, but if not we can investigate.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

It's possible that what you're seeing is a delay caused by either mDNS or DNS suffixes on Windows.
That means when resolving the not_a_valid_url hostname on Windows, it also tries to see if not_a_valid_url.local (mDNS) and not_a_valid_url.lan ( or not_a_valid_url.corp or whatever DNS suffix the windows is using).

You can try making the URL fully qualified by using https://not_a_valid_url.test/ or even https://not_a_valid_url./ - that should indicate that this is the actual host we are trying to resolve. I recommend the .test variant.

Let me know if that works.

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for the suggestion! Let's see if that helps: https://treeherder.mozilla.org/jobs?repo=try&revision=28dba0585771d6abdcf1db5067d7fd3c4df0a18a

Edit: seems to work fine, thanks!

Comment 6

[Julian Descottes [:jdescottes]]

Attachment: Bug 1873880 - [wdspec] Update invalid url for bidi fetchError tests

Using https://not_a_valid_url might cause delays on windows because it will attempt to use mDNS or DNS suffixes.
Using a fully qualified URL avoids the additional delay.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/830d3304af3d
[wdspec] Update invalid url for bidi fetchError tests r=webdriver-reviewers,Sasha

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44203 for changes under testing/web-platform/tests

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/830d3304af3d

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot