User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

I used the new wasm+webgl version of google earth

Actual results:

it only runs in single-threaded mode (even with firefox nightly), resulting in lower speed and responsiveness, despite many of my cpu cores are not utilized.

Expected results:

ALL other browsers tested (the new edge, google chome, opera) support "WebAssembly with Threads" mode, so should firefox.

Please feel free to provide clear steps how someone can use "the new wasm+webgl version of google earth".

Andre: Simply browser to: https://www.google.com/intl/de/earth/

ALL other major browsers seem to support wasm threads now and ship it even turned on by default, only firefox still lags it - instead firefox developers chose to re-design the URL bar yet again ;)

Hi Gerhard,

Would you mind submiting a video of your issue please?

So I can try to replicate on my end

I visited https://www.google.com/intl/en/earth/ english version, "launch earth" will redirect user to the new webassembly version?

Thanks in advance,

Clara

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Gerhard, thanks for your report. What Andre and Clara are asking you is how you can tell (objectively) that threads are not being used by the site. When I go to the site you point to, I don't see any clear indication of whether I'm using the threaded version or not. How can I tell?

It's true that we don't have threads yet in webassembly; they have been disabled due to security concerns and we are in the process of mitigating those concerns and re-enabling the feature. See bug 1477743.

(I'm also curious whether you see different results if you go to about:config in Nightly and enable the preference "dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled", as this is supposed to enable threads.)

Just saw this report (because I am also interested in webassembly threads and miss it a lot) and tried to reproduce it.

It is rather easy:

1. go to: https://earth.google.com/web/
2. wait until it has loaded
3. click the hamburger button on the top left
4. read the info at the bottom of the appearing menu:

Firefox Nightly: Version 9.3.111.1 - WebAssembly
Chrome 83: Version 9.3.111.1 - WebAssembly with threads

Thanks.

I note that enabling dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled in Nightly is not sufficient to make Earth use threads in Firefox Nightly :-/

Thanks for the additional details. I was able to reproduce. Chrome shows Versión 9.3.112.3 - WebAssembly with threads while ff doesn't. I can reproduce in Release 77.0 (64-bit), Beta 78.0b5 (64-bit) (64-bit) and Firefox Nightly 79.0a1 (2020-06-12) (64-bit)
I will adjust flags accordingly. Thanks.
Best,
Clara

Still getting the non-threads version in Nightly, though we have full thread support. So this is likely either (a) webcompat or (b) an Earth issue, eg, not serving the proper headers. I'm guessing (a). Given that threads have barely shipped (FF79 started shipping yesterday), I think we'll wait another month or so to see if the situation changes before kicking this up to the webcompat team.

Luke, do you know if progress is being made on this?

If i use the User-agent switcher addon to pretend I'm using Chrome on Linux, and set dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled to true, then I'm getting the WebAssembly threads version. The two actions are required: one won't be sufficient to get the threaded version of the website.

I'll try to email the Earth team, it sounds like they need to make some changes on their end for FF to get the threaded version.

(In reply to Luke Wagner [:luke] from comment #13)

I'll try to email the Earth team, it sounds like they need to make some changes on their end for FF to get the threaded version.

Did you hear back from them?

(More of a Lars question now.)

Just stumbled over this bug report and gave it a try - Firefox still gets the version without threading - I've sent them "Feedback" about this issue over the last few months over and over again, but it seems the either don't read it or don't care.

All in all I have to admit google earth runs a lot better / more responsive using Chrome.

Yeah, aware of it. Will attempt to re-message them.

I also just stumbled over this bug and can verify that it still exists in the latest nightly.

yes, it still exists.

every time i use google earth i send feedback asking them to remove this limitation (attaching a screenshot of the version / mode information on the left). I guess this makes as much sense as reporting website compatibility bugs to Microsoft back in 2000 ;)
They have browser monopoly, so interop is not something they really seem to care a lot.

I discussed this issue with Google. Google Earth is blocked on credentialless coep (bug 1731778 for our implementation) in order to use SharedArrayBuffer and hence wasm threads. They are using a "reverse" origin trial to continue using SAB in Chrome in the mean time.