1999473 - [wdspec] Tests for "browsingContext.downloadWillBegin" and "browser.setDownloadBehavior" need to wait for the download to be finished

Status: RESOLVED FIXED

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

Description

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

We have test timeouts like the following which are caused by a remaining active download when trying to shutdown Firefox. Here a prompt is opened and asking if the downloads should be canceled.

https://treeherder.mozilla.org/logviewer?job_id=534759574&repo=try&task=btsR6Ey3Rt-qURh708ebhw.0&lineNumber=12843-12846

[task 2025-11-07T10:46:46.515+00:00] 10:46:46     INFO - PID 6032 | 1762512406513	RemoteAgent	TRACE	PromptListener: Register prompt listeners for new "null" window
[task 2025-11-07T10:46:46.516+00:00] 10:46:46     INFO - PID 6032 | 1762512406514	RemoteAgent	TRACE	PromptListener: New prompt detected (type: "confirmEx", text: "If you exit now, 1 download will be canceled. Are you sure you want to exit?")
[task 2025-11-07T10:46:46.700+00:00] 10:46:46     INFO - PID 6032 | [Parent 6062, Main Thread] WARNING: g_object_get: assertion 'G_IS_OBJECT (object)' failed: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201
[task 2025-11-07T10:47:13.033+00:00] 10:47:13     INFO - TEST-UNEXPECTED-TIMEOUT | /webdriver/tests/bidi/browsing_context/download_will_begin/download_will_begin.py | expected OK

Until we have a dedicated command for canceling a given download, we should figure out if there is a workaround in canceling these or finding a way to prevent this check for the time being. We could also wait for the downloadEnd event to be fired as first step.

Julian wanted to take a look at it.

Comment 1

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

There is also set_download_behavior/user_context.py which needs to wait for the download to be finished.

Comment 2

[Julian Descottes [:jdescottes]]

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

There is also set_download_behavior/user_context.py which needs to wait for the download to be finished.

I am not 100% sure this is the same issue. The trigger_download fixture seems to try to wait for download_end in the "regular" case. Maybe the 0.5s timeout is too short in some cases and we timeout before getting the event and then quickly shutdown the test? In any case here I would simply increase the timeout.

Comment 3

[Julian Descottes [:jdescottes]]

Attachment: Bug 1999473 - [wdspec] Wait for download_end events in bidi download tests

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f2288771b8b0
https://hg.mozilla.org/integration/autoland/rev/5643a8904539
[wdspec] Wait for download_end events in bidi download tests r=whimboo

Comment 5

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

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

Comment 6

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/5643a8904539

Comment 7

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

Upstream PR merged by moz-wptsync-bot

Comment 9

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

Julian, I see a lot of failures for this hang during shutdown on beta. We probably should consider uplifting the patch.

Comment 10

[Julian Descottes [:jdescottes]]

As I said on https://bugzilla.mozilla.org/show_bug.cgi?id=1630162#c291 I don't think the patch helped that much? The failure frequency seems stable and now the tests fail while waiting for the fixture to receive a downloadEnd event. I think there's another root issue which leads to the hangs, unless we have a proper fix it doesn't seem useful to uplift?

Comment 11

[Julian Descottes [:jdescottes]]

Ok all right that was only one failure which related to the new fixture. The other central/autoland failures seem linked to unrelated tests. We can try to uplift.

Comment 12

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

And to add... this fix is helpful so that we do not hang on an open dialog which prevents shutdown. The failure for the debug build is a timeout for waiting for the event, which is way better.

Comment 13

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Frequent shutdown hangs during wdspec tests
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: low
• Explanation of risk level: Test only update
• String changes made/needed: N/A
• Is Android affected?: yes

Comment 14

[Julian Descottes [:jdescottes]]

Attachment: Bug 1999473 - [wdspec] Wait for download_end events in bidi download tests

Original Revision: https://phabricator.services.mozilla.com/D272423

Comment 15

[Dianna Smith [:diannaS]]

Comment on attachment 9530008 [details]
Bug 1999473 - [wdspec] Wait for download_end events in bidi download tests

This missed the Fx146 beta cycle. It can ride with the 147 release. There is also an intermittent regression that should be looked at. Feel free to request a release uplift if you want it to be considered for the planned 146 dot release

Comment 16

[Julian Descottes [:jdescottes]]

(In reply to Dianna Smith [:diannaS] from comment #15)

Comment on attachment 9530008 [details]
Bug 1999473 - [wdspec] Wait for download_end events in bidi download tests

This missed the Fx146 beta cycle. It can ride with the 147 release. There is also an intermittent regression that should be looked at. Feel free to request a release uplift if you want it to be considered for the planned 146 dot release

Oh right, this cycle is already at the end. The regression seems to be a very low intermittent failure (at least a lot less frequent than the initial intermittent this fixes), but not sure that's worth uplifting to release.

Comment 17

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

(In reply to Julian Descottes [:jdescottes] from comment #16)

Oh right, this cycle is already at the end. The regression seems to be a very low intermittent failure (at least a lot less frequent than the initial intermittent this fixes), but not sure that's worth uplifting to release.

The frequency of out tests run on beta/release is lower than on mozilla-central / autoland. So I would expect a lower volume. We can see and wait what results we get once beta is merged to release. We could request the uplift at any time if really needed, but probably not.