Closed Bug 1845345 Opened 9 months ago Closed 2 months ago

Remove the experimental flag for network intercept features

Categories

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

task
Points:
1

Tracking

(firefox124 fixed)

RESOLVED FIXED
124 Branch
Tracking Status
firefox124 --- fixed

People

(Reporter: jdescottes, Assigned: jdescottes)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webdriver:m10][webdriver:relnote])

Attachments

(1 file)

We have several bugs to implement the individual pieces of network interception (add intercept, remove intercept etc...).

However we should not expose those commands to end users until we have at least one meaningful user story implemented, which will most likely be after Bug 1826196.

At this point we can consider removing the experimental flag for those features.

Severity: -- → S3
Points: --- → 1
Priority: -- → P2
Whiteboard: [webdriver:m8]
Whiteboard: [webdriver:m8] → [webdriver:m8:blocked]
Whiteboard: [webdriver:m8:blocked] → [webdriver:m9]

We will not get to remove the flag in milestone 9. As such lets target it for M10.

Whiteboard: [webdriver:m9] → [webdriver:m10]

Now that continueWithAuth landed, we could actually remove the experimental flag for network interception requests, because you can intercept and resume an authentication request.

The downside is that intercepts for any other phase cannot be resumed. We could still keep the experimental flag when people try to use addIntercept with other phases. The other option is to block this on the other continue commands (failRequest, continueRequest, continueResponse, provideResponse).

Whiteboard: [webdriver:m10] → [webdriver:triage][webdriver:m10]

Let's check with puppeteer team if they need the continueWithAuth feature, otherwise we can keep it behind the flag until we have more APIs.

We are currently blocked by our work on implementing request interception in general so we won't be able to make use continueWithAuth. I think it makes sense to turn it on once more interception APIs are ready. We could experiment with it being behind the flag in the meantime.

Thanks Alex. So lets leave it as experimental for now and we will remove it when required by Puppeteer or when we got the remaining APIs added. Lets block on those related bugs.

Whiteboard: [webdriver:triage][webdriver:m10] → [webdriver:m10]

Given the wpt.fyi results I wonder why those are failing given that for Nightly the experimental APIs should be enabled. Maybe we should remove the flag for the network request interception methods now even with optional arguments not being supported yet?

Flags: needinfo?(jdescottes)

This link is an old run using a Nightly from Feb 5 which didn't have my patch.

Tests are now passing:

Regarding the flag, I agree we can remove it, but this should not impact puppeteer tests or wpt.fyi.

Flags: needinfo?(jdescottes)

Oh including the Android results in the list, which didn't seem to have newer results, caused the results to be outdated. Thanks for pointing that out.

Nevertheless once Nightly rides the trains to beta it would be broken. So yes, lets remove the flag and not wait for bug 1850680, bug 1853882, and bug 1853887.

No longer depends on: 1850680, 1853882, 1853887
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b69847c15584
[bidi] Remove the experimental flag for network intercept features r=webdriver-reviewers,whimboo
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 124 Branch

With enabling network interception we should announce all the available APIs in the MDN release notes of the next Firefox release.

Whiteboard: [webdriver:m10] → [webdriver:m10][webdriver:relnote]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: