[3.6.0] Login does not work correctly

[foobartel]

Describe the bug
When trying to log in, nothing happens after 'enter' or clicking the login button. When I then reload the page, I am logged in and the panel opens. Network panel says the login fetch failed.

Screenshots

Kirby Version
3.6.0-alpha.1

Console output

index.js:1 TypeError: Cannot read property 'contentWindow' of undefined
    at a.<anonymous> (index.js:1)
    at Array.<anonymous> (vendor.js:6)
    at Yt (vendor.js:6)
(anonymous) @ index.js:1
(anonymous) @ vendor.js:6
Yt @ vendor.js:6
Promise.then (async)
qt @ vendor.js:6
Qt @ vendor.js:6
t.$nextTick @ vendor.js:6
fatal @ index.js:1
hn.run @ vendor.js:6
pn @ vendor.js:6
(anonymous) @ vendor.js:6
Yt @ vendor.js:6
Promise.then (async)
qt @ vendor.js:6
Qt @ vendor.js:6
(anonymous) @ vendor.js:6
hn.update @ vendor.js:6
ct.notify @ vendor.js:6
set @ vendor.js:6
SET_FATAL @ index.js:1
(anonymous) @ vendor.js:11
(anonymous) @ vendor.js:11
(anonymous) @ vendor.js:11
Vs._withCommit @ vendor.js:11
Vs.commit @ vendor.js:11
Vs.commit @ vendor.js:11
fatal @ index.js:1
(anonymous) @ vendor.js:11
Vs.dispatch @ vendor.js:11
Vs.dispatch @ vendor.js:11
click @ index.js:1
Bt @ vendor.js:6
n @ vendor.js:6
Zr.i._wrapper @ vendor.js:6

login:1 Autofocus processing was blocked because a document already has a focused element.
The FetchEvent for "https://foobartel.local:8890/panel/login" resulted in a network error response: an "opaqueredirect" type response was used for a request whose redirect mode is not "manual".

Promise.then (async)
(anonymous) @ serviceworker.js:98

index.js:1 GET https://foobartel.local:8890/panel/login net::ERR_FAILED

request @ index.js:1
go @ index.js:1
reload @ index.js:1
t.$reload.window.panel.$reload @ index.js:1
login @ index.js:1
async function (async)
login @ index.js:1
submit @ index.js:1
Bt @ vendor.js:6
n @ vendor.js:6
Zr.i._wrapper @ vendor.js:6
index.js:1 Uncaught (in promise) TypeError: Failed to fetch
async function (async)
go @ index.js:1
reload @ index.js:1
t.$reload.window.panel.$reload @ index.js:1
login @ index.js:1
async function (async)
login @ index.js:1
submit @ index.js:1
Bt @ vendor.js:6
n @ vendor.js:6
Zr.i._wrapper @ vendor.js:6

Desktop (please complete the following information):

• OS: macOS 11.4
• Browser: Chrome
• Version: 91

[afbora]

I couldn't reproduce the issue on Windows & Chrome.

[distantnative]

I think this issue and #3508 (comment) are related/same cause and there's something wrong (bug or setup) with the network communication.

Especially reading

The FetchEvent for "https://foobartel.local:8890/panel/login" resulted in a network error response: an "opaqueredirect" type response was used for a request whose redirect mode is not "manual".

What makes me wonder right now is the mention of serviceworker.js - where does that file originate in our setup? Or is it from a plugin @foobartel?

[foobartel]

The serviceworker.js is a single file that runs on my site and caches things, e.g to display when offline, etc. Could have something to do with it in that case. Not sure why it would cache the panel, but the panel might need to be excluded I would assume…

[distantnative]

Based on the error message, I would think that this service worker.js is doing something that corrupts the Panel's requests

[foobartel]

I think I would agree ;) It works fine and as expected with 3.5.6 and 3.5.7, so I assume something changed in 3.6 that triggers this issue.

[distantnative]

That's true, it surely origins from the switch to our new Fiber framework handling those requests: https://github.com/getkirby/kirby/blob/develop/panel/src/config/fiber.js

Maybe you could share the serviceworker.js, so we could look into it together and see if we find what's going wrong.

[foobartel]

Sure, happy to try and do that!
The service worker can be found here: https://foobartel.com/serviceworker.js As far as I can tell it should not do anything with the panel, but apparently that might not be correct…

Original source mentioned at the top, maybe this last comment on source has something to do with it? https://gist.github.com/adactio/fbaa3a5952774553f5e7#gistcomment-3557236

[distantnative]

And how does serviceworker.js get loaded?
I would think it's somehow loaded in the context of the Panel as well and this line https://gist.github.com/adactio/fbaa3a5952774553f5e7#file-basicserviceworker-js-L48 starts grabbing our fetch requests.

[foobartel]

Looks like it, even though it should not work in the panel context… Currently the SW is loaded with <link rel="serviceworker" href="/serviceworker.js"> in a header.php snippet.

[distantnative]

Any clues from the console/Network developer tab how/where the SW script is loaded inside the Panel?

[foobartel]

Apologies for the delayed follow-up on this. I could not find any further info on this and it's a mystery to me how the serviceworker made it into the panel.

The good news is that this error does not persist in the latest release 3.6.0-alpha.2. I think this issue can be closed. Thanks!