Closed Bug 1985258 Opened 1 year ago Closed 8 months ago

Throw an exception when subscribing to "browsingContext.downloadWillBegin" and "browsingContext.downloadEnd" on Android

Categories

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

task
Points:
2

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jdescottes, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [webdriver:backlog])

Attachments

(1 file)

As explained on Bug 1985252, the browsingContext.downloadWillBegin event doesn't work on Android at the moment.
One option in the meantime is to explicitly throw if a client tries to subscribe to this event on Android.

Blocks: 1919018
Points: --- → 2
Priority: -- → P3
Whiteboard: [webdriver:m17]
Whiteboard: [webdriver:m17] → [webdriver:m18]

The same is actually the case when clients want to subscribe to browsingContext.downloadEnd events. So we should raise an unsupported operation error in both cases.

Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Summary: Throw an exception when subscribing to browsingContext.downloadWillBegin on Android → Throw an exception when subscribing to "browsingContext.downloadWillBegin" and "browsingContext.downloadEnd" on Android

So there are actually two problems which we would need to solve if we really want to get this bug fixed. Here the try build as reference:
https://treeherder.mozilla.org/jobs?repo=try&revision=777048e6c34895b2a4206c7800e9100aac5ec8fe

  1. For the wdspec tests related to downloadWillBegin and downloadEnd we need different expectations (FAIL vs ERROR) in the meta data and I don't know why this is happening. Maybe something related to the subscribe_events fixture and when the inner method is raising an error?

  2. Tests that are subscribing the events on a module level are failing as well. At the moment most of them make use of the browsingContext module. We could use another module here but it would as well require quite some changes to existing tests. So I'm not sure if that is what we really want.

I'm going to put this bug back into our triage queue so that we can decide if the time spent on these additional changes is worth or if we should better reach out to the GeckoView team and hopefully get them to add events that we can make use of.

Assignee: hskupin → nobody
Status: ASSIGNED → NEW
Whiteboard: [webdriver:m18] → [webdriver:m18][webdriver:triage]
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INACTIVE
Whiteboard: [webdriver:m18][webdriver:triage] → [webdriver:backlog][webdriver:triage]

We agreed on that this is not required and that we should focus on getting Android support added.

Whiteboard: [webdriver:backlog][webdriver:triage] → [webdriver:backlog]
Resolution: INACTIVE → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: