Authenticated media service worker does not properly run in non-local builds

[turt2live]

Steps to reproduce

1. Try to use authenticated media on app.element.io, staging.element.io, develop.element.io or any self-hosted production build.

Outcome

What did you expect?

For media requests to be intercepted and replaced with authenticated versions upon detection of server support

What happened instead?

Literally nothing. Running the code with yarn start locally does not reproduce this issue, however.

Operating system

Windows 11

Browser information

Chrome 126.0.6478.127 (Official Build) (64-bit)

URL for webapp

develop.element.io

Application version

Element version: dd685934a3ae-react-e097cc00d069-js-30a26813ec4b Crypto version: Rust SDK 0.7.1 (431263d), Vodozemac 0.6.0

Homeserver

matrix.org w/ Synapse 1.111.0 base

Will you send logs?

No

[turt2live]

My develop.element.io build has https://github.com/element-hq/element-web/pull/27758 but is not being called. I think this is because webpack is mangling the JS somehow.

Localhost (yarn start):

develop:

(screenshots from chrome://serviceworker-internals/?devtools)

Critically, the two registrations differ in fetch handler states, which may explain why develop is not intercepting requests.

[turt2live]

What's extra confusing is the static call graph for both appears identical, though of course localhost has a bunch of webpack hot reload stuff (which won't work).

I'm somewhat suspicious of headers or some other security mechanism preventing the serviceworker from properly registering itself.

I've also confirmed this behaviour is exactly the same in Firefox as well as Chrome, so it's not a platform issue (I think).

[williamkray]

curious about the use of the O-Uncommon label here, considering this affects every deployment of element-web except those running local to the matrix server (if i'm following the description correctly)?

[turt2live]

There's not currently user impact, so it's hard to determine what the correct O level would be I think. Either way, it needs fixing regardless of triage.

[turt2live]

https://github.com/element-hq/element-web/pull/27891 might address this for the reasons contained within

[turt2live]

I'm having issues replicating this locally and on develop.element.io with production builds, but Netlify PR builds are breaking for me again, so I'm hoping to use those.

https://github.com/matrix-org/matrix-react-sdk/pull/12871 reduces the size of the service worker significantly, which both helps debugging and appears to change webpack's strategy for compilation. Hopefully it works. Size shouldn't be a concern, but Chrome is still failing to register the fetch handler for broken builds (as I'm writing, I'm waiting for the Netlify PR build to finish on that PR so I can test it).

[turt2live]

https://github.com/matrix-org/matrix-react-sdk/pull/12871 works for me instantaneously, so I'm assuming the Webpack theory is correct (or there's an undocumented size limit??)

[turt2live]

I'm considering this fixed by https://github.com/matrix-org/matrix-react-sdk/pull/12871 until evidence proves otherwise