Closed Bug 1826198 Opened 2 years ago Closed 2 years ago

Implement "network.authRequired" event

Categories

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

Product:
Remote Protocol
Component:
WebDriver BiDi
Type:
task
Points:
3

Tracking

(firefox122 fixed)

Status:
RESOLVED FIXED
Milestone:
122 Branch
Tracking Flags:
Tracking Status
firefox122 --- fixed

People

(Reporter: whimboo, Assigned: jdescottes)

References

(
URL
)

Details

(Whiteboard: [webdriver:m9], [wptsync upstream])

Attachments

(4 files, 1 obsolete file)

Bug 1826198 - [devtools] Add an optional auth prompt listener to the NetworkObserver
48 bytes, text/x-phabricator-request
Details | Review
Bug 1826198 - [bidi] Add support for the network.authRequired event
48 bytes, text/x-phabricator-request
Details | Review
Bug 1826198 - [devtools] Wait for authPrompt to be handled to avoid test failing on linux.
48 bytes, text/x-phabricator-request
Details | Review
Bug 1826198 - [wdspec] Fix wdspec tests for network.authRequired.
48 bytes, text/x-phabricator-request
Details | Review

This bug will take care of implementing the network.authRequested event.

Blocks: 1826199
Priority: P1 → P2
Whiteboard: [webdriver:m7] → [webdriver:m8]

Updating the title per the latest version on the spec PR https://pr-preview.s3.amazonaws.com/w3c/webdriver-bidi/pull/429.html#event-network-authRequired

This should block continueWithAuth, not the other way around.

Blocks: 1826196
No longer depends on: 1826192, 1826193, 1826196
Summary: Implement "network.authRequested" event → Implement "network.authRequired" event
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Blocks: 1852223
Blocks: 1855149

Depends on D189516

Whiteboard: [webdriver:m8] → [webdriver:m9]

Hi Valentin,

I keep hitting an assert crash on debug builds when trying to implement the authRequired event. The crash looks like:

0:16.39 pid:42251 Assertion failure: LoadConcurrentCacheAccess(), at /builds/worker/checkouts/gecko/netwerk/protocol/http/nsHttpChannel.cpp:1582
 0:16.39 INFO STDOUT: Initializing stack-fixing for the first stack frame, this may take a while...
 0:16.56 pid:42251 #01: mozilla::net::nsHttpChannel::CallOnStartRequest() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xa296f4)
 0:16.56 pid:42251 #02: mozilla::net::nsHttpChannel::OnAuthCancelled(bool) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xa3ebda)
 0:16.56 pid:42251 #03: mozilla::net::nsHttpChannelAuthProvider::OnAuthCancelled(nsISupports*, bool) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x8b92f3)
 0:16.56 pid:42251 #04: NS_InvokeByIndex (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x358c2e)
 0:16.56 pid:42251 #05: CallMethodHelper::Call() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xefd5ab)
 0:16.56 pid:42251 #06: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xefd229)
 0:16.56 pid:42251 #07: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xeff4c1)
 0:16.56 pid:42251 #08: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6bdaab9)
 0:16.56 pid:42251 #09: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6bda2c2)
 0:16.56 pid:42251 #10: js::Interpret(JSContext*, js::RunState&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6beb35b)
 0:16.56 pid:42251 #11: js::RunScript(JSContext*, js::RunState&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6bd94fa)
 0:16.56 pid:42251 #12: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6bda1d8)
 0:16.56 pid:42251 #13: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6bdb7fb)
 0:16.56 pid:42251 #14: js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6fab472)
 0:16.56 pid:42251 #15: js::jit::InterpretResume(JSContext*, JS::Handle<JSObject*>, JS::Value*, JS::MutableHandle<JS::Value>) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x776c426)
 0:16.56 pid:42251 ** Unknown exception behavior: 0

So that's coming from https://searchfox.org/mozilla-central/rev/ac497ae160e664617e2f4286cdce3b03ef912d90/netwerk/protocol/http/nsHttpChannel.cpp#1573-1585

The crash reproduces with https://phabricator.services.mozilla.com/D189515, when running the devtools/shared/network-observer/test/browser/browser_networkobserver_auth_listener.js test in DEBUG mode.

This happens during the test case testAuthRequestWithoutListener where I am immediately trying to forward the auth prompt to the next notification callback because I don't want to either cancel it or provide credentials. If I delay that for a few milliseconds (eg 100) the crash goes away, but simply spinning the event loop doesn't seem to be enough.

I have been trying to compare my implementation and the WebExtensions one, but I don't see major differences. Any idea what could cause this?

Flags: needinfo?(valentin.gosu)

I think there may be an issue with the implementation of asyncPromptAuth & promptAuth in the network observer.
The way the auth provider works is that it calls asyncPromptAuth, and if that throws it then calls promptAuth.
If asyncPromptAuth doesn't throw, the expectation is that it will asynchronously call the callbacks after it returns.

https://searchfox.org/mozilla-central/rev/e37662380b7b5507732a4f37a17da1a2f7802c04/netwerk/base/nsIAuthPromptCallback.idl#10-16

 * Interface for callback methods for the asynchronous nsIAuthPrompt2 method.
 * Callers MUST call exactly one method if nsIAuthPrompt2::promptPasswordAsync
 * returns successfully. They MUST NOT call any method on this interface before
 * promptPasswordAsync returns.
 */
[scriptable, uuid(bdc387d7-2d29-4cac-92f1-dd75d786631d)]
interface nsIAuthPromptCallback : nsISupports

If asyncPromptAuth doesn't throw, we suspend the channel here and wait for the auth callback.

So I think we should:

  1. Not suspend/resume the channel in AuthCredentialsProvidingOwner::onAuthPrompt - not sure why that is necessary.
  2. Make sure we don't catch the exception when calling prompt.asyncPromptAuth in forwardAuthPrompt.
  3. Ensure that onAuthPrompt is called asynchronously from asyncPromptAuth when we don't throw.
Flags: needinfo?(valentin.gosu)

Thanks a lot! I totally missed that. Ensuring that we call the callbacks async after the return indeed fixes my issues! I was also able to remove the suspend / resume from the Class you mentioned.

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

Thanks a lot! I totally missed that. Ensuring that we call the callbacks async after the return indeed fixes my issues! I was also able to remove the suspend / resume from the Class you mentioned.

Spoke a bit too fast. While the simple setTimeout of 1 ms seems to fix the devtools test consistently, I saw the exact same thing happening with a WebDriver BiDi test, and it still occurs. It looks like I need to increase the delay much more in order to get the test to reliably pass in debug mode (eg 1ms always fails, 20ms is intermittent, 100ms passes consistently).

I there something I should wait for to know it's safe to call one of the callbacks?

No longer blocks: 1855149
Depends on: 1855149

Valentin, while investigating the DEBUG crash on phabricator, you mentioned

So I think we need to make sure that when the page navigates we don't call onAuthCancelled again - that should be done automatically.

Should I file a separate bug for this?

Flags: needinfo?(valentin.gosu)
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/01afc774b301 [devtools] Add an optional auth prompt listener to the NetworkObserver r=bomsy,devtools-reviewers,valentin,necko-reviewers https://hg.mozilla.org/integration/autoland/rev/f08806f8c130 [bidi] Add support for the network.authRequired event r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/c8d9b37591bf [wdspec] Add wdspec tests for network.authRequired r=webdriver-reviewers,whimboo
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/42758 for changes under testing/web-platform/tests
Whiteboard: [webdriver:m9] → [webdriver:m9], [wptsync upstream]

It seems that my DevTools browser mochitest is now hitting an assert added in Bug 1856288.

The specific test which fails is the one called testAuthRequestWithWrongCredentialsListener, where I use the onAuthAvailable callback but with invalid credentials.

Assertion failure: !LoadOnStartRequestCalled() (We should not call OnStartRequest twice.), at /builds/worker/checkouts/gecko/netwerk/protocol/http/nsHttpChannel.cpp:8123

The stackframe for the second call is

0:12.41 GECKO(6665) #01: mozilla::net::nsHttpChannel::ContinueOnStopRequest(nsresult, bool, bool) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xa51424)
 0:12.41 GECKO(6665) #02: mozilla::net::nsHttpChannel::ContinueOnStopRequestAfterAuthRetry(nsresult, bool, bool, bool, mozilla::net::HttpTransactionShell*) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xa4fac9)
 0:12.41 GECKO(6665) #03: mozilla::net::nsHttpChannel::OnStopRequest(nsIRequest*, nsresult) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0xa4df9f)
 0:12.41 GECKO(6665) #04: nsInputStreamPump::OnStateStop() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x537b27)
 0:12.41 GECKO(6665) #05: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x536d3f)
 0:12.41 GECKO(6665) #06: non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x537dfd)
 0:12.41 GECKO(6665) #07: already_AddRefed<mozilla::CancelableRunnable> NS_NewCancelableRunnableFunction<CallbackHolder::CallbackHolder(nsIAsyncInputStream*, nsIInputStreamCallback*, unsigned int, nsIEventTarget*)::'lambda'()>(char const*, CallbackHolder::CallbackHolder(nsIAsyncIn (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x2c4c40)
 0:12.41 GECKO(6665) #08: mozilla::RunnableTask::Run() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x309438)
 0:12.41 GECKO(6665) #09: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x300e53)
 0:12.41 GECKO(6665) #10: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x2ff859)
 0:12.41 GECKO(6665) #11: mozilla::TaskController::ProcessPendingMTTask(bool) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x2ffcf7)
 0:12.41 GECKO(6665) #12: mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x30e5a7)
 0:12.41 GECKO(6665) #13: nsThread::ProcessNextEvent(bool, bool*) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x325178)
 0:12.41 GECKO(6665) #14: NS_ProcessPendingEvents(nsIThread*, unsigned int) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x3215ec)
 0:12.41 GECKO(6665) #15: nsBaseAppShell::NativeEventCallback() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x4d22ec2)
 0:12.41 GECKO(6665) #16: nsAppShell::ProcessGeckoEvents(void*) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x4da7b10)
fix-stacks: error: failed to read `/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation`
fix-stacks: No such file or directory (os error 2)
 0:12.41 GECKO(6665) #17: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7c906)
 0:12.41 GECKO(6665) #18: __CFRunLoopDoSource0 (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7c8a9)
 0:12.41 GECKO(6665) #19: __CFRunLoopDoSources0 (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7c686)
 0:12.41 GECKO(6665) #20: __CFRunLoopRun (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7b30a)
 0:12.41 GECKO(6665) #21: CFRunLoopRunSpecific (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7a91c)
fix-stacks: error: failed to read `/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox`
fix-stacks: No such file or directory (os error 2)
 0:12.41 GECKO(6665) #22: RunCurrentEventLoopInMode (/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x2ef3d)
 0:12.41 GECKO(6665) #23: ReceiveNextEventCommon (/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x2ed4e)
 0:12.41 GECKO(6665) #24: _BlockUntilNextEventMatchingListInModeWithFilter (/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x2eaa8)
fix-stacks: error: failed to read `/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit`
fix-stacks: No such file or directory (os error 2)
 0:12.41 GECKO(6665) #25: _DPSNextEvent (/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x3e25c)
 0:12.41 GECKO(6665) #26: -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x3d106)
 0:12.41 GECKO(6665) #27: -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x4da6e8e)
 0:12.41 GECKO(6665) #28: -[NSApplication run] (/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x2f788)
 0:12.41 GECKO(6665) #29: nsAppShell::Run() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x4da82c0)
 0:12.41 GECKO(6665) #30: nsAppStartup::Run() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6972cbc)
 0:12.41 GECKO(6665) #31: XREMain::XRE_mainRun() (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6ae0d00)
 0:12.41 GECKO(6665) #32: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6ae2448)
 0:12.41 GECKO(6665) #33: XRE_main(int, char**, mozilla::BootstrapConfig const&) (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x6ae30ee)
 0:12.41 GECKO(6665) #34: main (/Users/juliandescottes/Development/mozilla/hg/mozilla-unified/objdir.noindex/dist/NightlyDebug.app/Contents/MacOS/firefox + 0xc80)

Sunil: any idea what could be the issue here?

Flags: needinfo?(jdescottes) → needinfo?(smayya)

An additional note: this only fails when setting network.auth.use_redirect_for_retries=true. As suggested by Valentin yesterday, I ran my tests with this preference, but the patch from Bug 1856288 had not landed yet.

Upstream PR was closed without merging

Hey Julian,

Can you send me the log file so that I can analyze the issue in detail?
Thanks

Flags: needinfo?(smayya) → needinfo?(jdescottes)

(In reply to Sunil Mayya from comment #16)

Hey Julian,

Can you send me the log file so that I can analyze the issue in detail?
Thanks

Sure! The one from the backout comment should have similar information: https://treeherder.mozilla.org/logviewer?job_id=433768291&repo=autoland&lineNumber=4331

Flags: needinfo?(jdescottes) → needinfo?(smayya)

Hello Julian,

I reproduced the issue locally and found out the root cause.

In this case, after getting the credentials we begin redirecting.
However, the channel gets cancelled from the DocLoader during the redirection

0:10.25 GECKO(2663) [Parent 2663: Main Thread]: D/nsHttp nsHttpChannel::Cancel [this=143f6f300 status=804b0002, reason=nsDocLoader::Stop]      0:10.25 GECKO(2663) [Parent 2663: Main Thread]: D/nsHttp channel canceled during wait for redirect callback

It looks like we are making an attempt to open the redirected channel even though the channel has been cancelled.
The assertion gets hit as we are making an attempt to call onstart request twice.
The OnStartRequest in this case gets called from here.

Flags: needinfo?(smayya)
Depends on: 1861885

I just retried to run the formerly broken test devtools/shared/network-observer/test/browser/browser_networkobserver_auth_listener.js with the patches as attached on this bug and it does no longer fail. As such I assume we can try to re-land this. To be sure I pushed a try build and if that succeeds I'm going ahead with the landing:

https://treeherder.mozilla.org/jobs?repo=try&revision=ae0891973bce9954fcad1286824f5eec7df14a10

Flags: needinfo?(moz.valentin)
Pushed by hskupin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c50d12ac515b [devtools] Add an optional auth prompt listener to the NetworkObserver r=bomsy,devtools-reviewers,valentin,necko-reviewers https://hg.mozilla.org/integration/autoland/rev/081fda2ff03d [bidi] Add support for the network.authRequired event r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/a7ad7ccbc6a3 [wdspec] Add wdspec tests for network.authRequired r=webdriver-reviewers,whimboo

Backed out for causing dt failures in browser_networkobserver_auth_listener.js.

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | devtools/shared/network-observer/test/browser/browser_networkobserver_auth_listener.js | network event has the expected ResponseStart flag - Got false, expected true
Flags: needinfo?(jdescottes)

This is strange. Why didn't the test fail on try but on autoland all the time? I cannot reproduce the failure locally as well.

Upstream PR merged by moz-wptsync-bot

Sasha is taking a look while Julian is out.

Flags: needinfo?(jdescottes) → needinfo?(aborovova)
Attachment #9355604 - Attachment is obsolete: true
Pushed by aborovova@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/904ba152ee1b [devtools] Add an optional auth prompt listener to the NetworkObserver r=bomsy,devtools-reviewers,valentin,necko-reviewers https://hg.mozilla.org/integration/autoland/rev/6eeca933dd74 [devtools] Wait for authPrompt to be handled to avoid test failing on linux. r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/b44f9d35fc17 [bidi] Add support for the network.authRequired event r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/496ceb3605c9 [wdspec] Fix wdspec tests for network.authRequired. r=webdriver-reviewers,whimboo
Flags: needinfo?(aborovova)
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/43360 for changes under testing/web-platform/tests
Regressions: 1866795
Regressions: 1866815
Upstream PR merged by moz-wptsync-bot

Hi Sasha, I think we have a case of partial sync due to backouts here.

I was looking at the changes from https://phabricator.services.mozilla.com/D189517 and it seems that the we are out of sync between wpt and mozilla-central. Current mozilla-central is missing the following code:

    # Note that here we explicitly do not navigate to the auth_url and instead
    # simply do a fetch, because otherwise Firefox fails to cleanly cancel the
    # authentication prompt on test teardown.
    asyncio.ensure_future(fetch(auth_url, context=new_tab, method="GET"))

which can be found on the wpt repository at https://github.com/web-platform-tests/wpt/blob/7468a42acb9ab23720055cfb697fba3ca2fc8587/webdriver/tests/bidi/network/response_started/response_started.py#L224-L227 (it's been there for ~1 month)

This change landed and was backed out twice. I'm quite confused about the history, but it seems that the new file network/auth_required/auth_required.py remained in tree (maybe there was an additional sync on this file between the backouts?) so when we landed the final version, we missed the changes in response_started.py.

In any case the repos are now out of sync. I can sync it as part of https://phabricator.services.mozilla.com/D196424, since that's where I spotted the discrepancy. What do you think?

Flags: needinfo?(aborovova)

Created a PR to sync wpt with m-c, I think that's the most logical here.

Flags: needinfo?(aborovova)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: