1771191 - OneDrive never loads when accessed via Waffle Menu from another MS web app

Status: RESOLVED INVALID

(Core :: DOM: Service Workers, defect)

Description

[Chris Martin [:cmartin]]

I can reproduce this on my own machine, and I have several family members who are also seeing this behavior.

Steps to Reproduce:

1. Open up a Microsoft web app that isn't OneDrive (I used https://outlook.live.com)
2. Click on the 9-dot "Waffle Menu" in the upper-left corner
3. Select "OneDrive"

Result:

• New tab pops open
• URL is https://onedrive.live.com/?login_hint=foobar%40live.ca
• New tab spins forever and never actually loads OneDrive
• With DevTools open, "Network" tab shows a single line with the following:
  Status: 200
  Method: Get
  Domain: onedrive.live.com
  File: /?login_hint=[e-mail]
  Initiator: document
  Type: html
  Transferred: service worker
  Size: 0 B

Differential:

• Go to https://onedrive.live.com from address bar: SUCCESS
• Go to https://onedrive.live.com?login_hint=foobar%40live.ca from address bar: FAILURE
• Go to https://onedrive.live.com?login_hint=foo from address bar: FAILURE
• Go to https://onedrive.live.com?login_hint= from address bar: SUCCESS
• Go to https://onedrive.live.com?foo=bar from address bar: SUCCESS

So, it seems to be specifically the login_hint=... query string that triggers the behavior.

(MozRegression to follow)

Comment 1

[Chris Martin [:cmartin]]

Looks like the regression happened in D136215 landed in Bug 1750515

Comment 2

[Chris Martin [:cmartin]]

As another point, the problem is fixed if I go to about:config in the address bar and set the dom.serviceWorkers.navigationPreload.enabled preference to false

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1750515

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1750515

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

Is this still broken? It seems it works for me even when login_hint is still there.

Comment 6

[Chris Martin [:cmartin]]

It seems that Microsoft may have changed something on their end, because this no longer reproduces even on the build that I originally used to reproduce it

Closing as INVALID

Comment 7

[Eden Chuang[:edenchuang]]

Following is the debugging log for NavigationPreload.

It seems that the FetchEvent handling is completed before the preload response promise is resolved. From here, we have no idea if the ServiceWorker script intents to do that or not. However, we probably need to know more about how ServiceWorker handles the FetchEvent.

I tried loading with ServiceWorker launching to ensure the preload response is ready before ServiceWorker boots up. And the page is loaded without problem. So I guess the issue is probably in how ServiceWorker uses the preload response.

[Parent 74277: Main Thread]: D/Fetch FetchService::Fetch aRequest[12d225ac0], aChannel[1faf8e850], mOffline: false
[Parent 74277: Main Thread]: D/Fetch FetchInstance::Initialize [148ab5820] aChannel[1faf8e850]
[Parent 74277: Main Thread]: D/Fetch FetchInstance::Fetch [148ab5820], mRequest URL: https://0ptvq.sharepoint.com/?firefoxNavigationPreload=true mPrincipal: https://0ptvq.sharepoint.com/?firefoxNavigationPreload=true
[Parent 74277: Main Thread]: D/Fetch FetchService::Fetch entry[11d029de0] of FetchInstance[148ab5820] added

Above is FetchService setup a fetch for NavigationPreload.

[Child 76723: Worker Launcher]: D/FetchEventOpProxy FetchEventOpProxy::Initialize [10a6a2680] Request url: https://0ptvq.sharepoint.com/?firefoxNavigationPreload=true
[Child 76723: Worker Launcher]: D/FetchEventOpProxy FetchEventOpProxy::Initialize [10a6a2680] ServiceWorkerOp [10a4a8700]
[Child 76723: DOM Worker]: D/ServiceWorkerOp FetchEventOp::DispatchFetchEvent [10a4a8700] FetchEvent [10a6933c0]

Dispatch a FetchEvent to ServiceWorker.

[Child 76723: DOM Worker]: D/ServiceWorkerEvent FetchEvent::RespondWith [10a6933c0] waiting promise: 10a490df0, mPreloadResponse: 10a48b820
[Child 76723: DOM Worker]: D/ServiceWorkerEvent FetchEvent::RespondWith [10a6933c0] request url: https://0ptvq.sharepoint.com/?firefoxNavigationPreload=true
[Child 76723: DOM Worker]: D/ServiceWorkerEvent FetchEvent::RespondWith [10a6933c0] mPreloadResponse state: Pending
[Child 76723: DOM Worker]: D/ServiceWorkerEvent FetchEvent::RespondWith [10a6933c0] waiting promise state: Pending

When FetchEvent.respondWith() is called. The FetchEvent.preloadResponse(mPreloadResponse) and the passed in promise(waiting promise) are still pending. Basically, these two should refer to the same promise instance. Pending promises are reasonable here.

[Child 76723: DOM Worker]: D/ServiceWorkerOp FetchEventOp::ResolvedCallback [10a4a8700]
[Child 76723: DOM Worker]: D/ServiceWorkerOp FetchEventOp::ResolvedCallback [10a4a8700], Resolve RespondWithPromise with response
[Child 76723: Worker Launcher]: D/FetchEventOpProxy FetchEventOpProxy [10a6a2680] RespondWithPromise success callback
[Child 76723: Worker Launcher]: D/FetchEventOpProxy [10a6a2680] response type is error: false
[Child 76723: Worker Launcher]: D/FetchEventOpProxy [10a6a2680] response status: (200)

ResolvedCallback is called, which means the waiting promise is resolved.
Notice that the preload response is not used because we did not get any preload response resolved in the log.

[Parent 74277: Main Thread]: D/FetchEventOp FetchEventOpChild::RecvRespondWith [1de6dee00], call FetchService::CancelFetch promises 11d029de0
[Parent 74277: Main Thread]: D/Fetch FetchService::CancelFetch aPromises[11d029de0]
[Parent 74277: Main Thread]: D/Fetch FetchInstance::Cancel() [148ab5820]
[Parent 74277: Main Thread]: D/Fetch FetchInstance::OnResponseEnd [148ab5820]
[Parent 74277: Main Thread]: D/Fetch FetchInstance::OnResponseEnd end with eAborted
[Parent 74277: Main Thread]: D/Fetch FetchService::CancelFetch entry [11d029de0] removed

The above shows that the preload response fetching is canceled since the FetchEvent operation is completed before preload fetching finishes.