celenity/Phoenix

Fork 18

[WEB COMPAT] SharedArrayBuffer issue breaks websites #139

New issue

Closed

opened 2025-06-08 03:05:10 +02:00 by aescgar · 4 comments

aescgar commented

2025-06-08 03:05:10 +02:00

Confirmation

Please confirm that you have already checked the Website Compatibility wiki page (https://phoenix.celenity.dev/compat), and that this issue is NOT currently listed.

Which domain(s) are you experiencing this issue on?

Domains which require SharedArrayBuffer usage have problems. Two examples are below, and neither site has an issue on stock Firefox.

What version of Phoenix are you using?

2025.06.06.1

What version of Firefox are you using with Phoenix?

139.0.1

What operating system are you experiencing this issue on?

Ubuntu

Other

No response

Please explain the issue you are experiencing.

When going to websites which require SharedArrayBuffer, an error occurs. In the example of https://eden.net.nz/test/sab.html, this can be seen easily. When SAB is working, you will see a message that says, "SharedArrayBuffer OK." When SAB is not working, you will see a message that says, "SharedArrayBuffer not available."

I have been tinkering with settings for weeks, and I have come to the conclusion that the setting
dom.postMessage.sharedArrayBuffer.withCOOP_COEP to true is (supposedly) the correct fix. However, when I change it to true in about:config or using a user.js/config override, the SharedArrayBuffer error persists. If I change it to true in the phoenix.js/phoenix-desktop.js, suddenly the error goes away. Why does the SharedArrayBuffer pref switch only work if set using the phoenix.js and not any other way? To clarify, dom.postMessage.sharedArrayBuffer.withCOOP_COEP does show as true in about:config when changed in user.js/config setup, so the setting is actually changing, but it doesn't seem to actually enable SharedArrayBuffer unless it is set at the phoenix.js level. I can even set it to false with the config, and SharedArrayBuffer still works if it is set to true at phoenix.js.

It's like Firefox recognizes and saves the config setting, but somehow, the actual permission to use SharedArrayBuffer still comes from phoenix.js/phoenix-desktop.js.

### Confirmation - [x] Please confirm that you have already checked the Website Compatibility wiki page (https://phoenix.celenity.dev/compat), and that this issue is NOT currently listed. ### Which domain(s) are you experiencing this issue on? Domains which require SharedArrayBuffer usage have problems. Two examples are below, and neither site has an issue on stock Firefox. - https://eden.net.nz/test/sab.html - https://demo.actualbudget.org ### What version of Phoenix are you using? 2025.06.06.1 ### What version of Firefox are you using with Phoenix? 139.0.1 ### What operating system are you experiencing this issue on? Ubuntu ### Other _No response_ ### Please explain the issue you are experiencing. When going to websites which require SharedArrayBuffer, an error occurs. In the example of https://eden.net.nz/test/sab.html, this can be seen easily. When SAB is working, you will see a message that says, "SharedArrayBuffer OK." When SAB is not working, you will see a message that says, "SharedArrayBuffer not available." I have been tinkering with settings for weeks, and I have come to the conclusion that the setting `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` to `true` is (supposedly) the correct fix. However, when I change it to `true` in about:config or using a user.js/config override, the SharedArrayBuffer error persists. If I change it to `true` in the phoenix.js/phoenix-desktop.js, suddenly the error goes away. Why does the SharedArrayBuffer pref switch only work if set using the phoenix.js and not any other way? To clarify, `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` does show as `true` in about:config when changed in user.js/config setup, so the setting is actually changing, but it doesn't seem to actually enable SharedArrayBuffer unless it is set at the phoenix.js level. I can even set it to `false` with the config, and SharedArrayBuffer still works if it is set to `true` at phoenix.js. It's like Firefox recognizes and saves the config setting, but somehow, the actual permission to use SharedArrayBuffer still comes from phoenix.js/phoenix-desktop.js.

aescgar added the

web compat

label

2025-06-08 03:05:10 +02:00

celenity self-assigned this

2025-06-08 09:57:51 +02:00

celenity commented

2025-06-08 10:07:29 +02:00

Owner

So I took a look, and I'm unable to replicate the issue (tested on Fedora 42). I can confirm that https://eden.net.nz/test/sab.html displays SharedArrayBuffer not available., but after setting dom.postMessage.sharedArrayBuffer.withCOOP_COEP to true and restarting Firefox, I see it states SharedArrayBuffer OK.

To confirm, did you restart the browser after changing the value of dom.postMessage.sharedArrayBuffer.withCOOP_COEP? Changing the value of this preference appears to requires a restart to take effect.

I just added demo.actualbudget.org & eden.net.nz to the Web Compat page, so thanks for that.

So I took a look, and I'm unable to replicate the issue *(tested on Fedora 42)*. I can confirm that `https://eden.net.nz/test/sab.html` displays `SharedArrayBuffer not available.`, but after setting `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` to `true` and restarting Firefox, I see it states `SharedArrayBuffer OK`. To confirm, did you restart the browser after changing the value of `dom.postMessage.sharedArrayBuffer.withCOOP_COEP`? Changing the value of this preference appears to requires a restart to take effect. ___ I just added `demo.actualbudget.org` & `eden.net.nz` to the [Web Compat page](https://phoenix.celenity.dev/compat), so thanks for that.

aescgar commented

2025-06-08 15:13:33 +02:00

Author

TL;DR: skip to the bottom, I think I am on the right path to figuring out the problem.

I did restart each time since I noticed that's required to take effect. Since you weren't able to replicate it, I created a new test profile with the exact same setup (same user.js/config, since that's all I had done with the first test profile). For some reason, the second profile behaves correctly/as expected. When I went back to the first profile, the problem was still there. I compared everything. As far as I can tell, they're identical profiles with same user.js and everything. I've been seeing similar problems before, where tweaking about:config and/or a custom config file several times can lead to some settings no longer taking effect and "sticking" to Phoenix defaults, even though about:config shows the custom config changes I haven't nailed down a rhyme or reason for why it happens, but I'm working on that.

Edit: It happened again, and creating a new profile did not solve the problem. dom.postMessage.sharedArrayBuffer.withCOOP_COEP is set to true via the config file, but in practice, it's still acting like it's false and having settings based on the Phoenix defaults. I have tried restarting Firefox, uninstalling and reinstalling Phoenix, creating a fresh profile, etc. The only thing that prevents the SharedBufferArray errors is if I change the pref in phoenix-desktop.js. Setting it to true in the config file, although it shows it as set correctly, still causes the error to be thrown. It's basically showing the correct specialized config settings in the about:config page, but the browser is behaving like there is no specialized config being used. Only changing phoenix-desktop.js affects the browser behavior for this setting for me.

Edit 2: PROGRESS! Reproducible progress. I have learned that if I change the dom.postMessage.sharedArrayBuffer.withCOOP_COEP pref in a config file, it does reflect in about:config as changed correctly, but it does not actually go into effect (still see error on websites). However, if I do NOT put the pref in the config file at all and ONLY change it in the about:config GUI, the setting is properly implemented - no more errors. How/why is that? Why would the config file setting reflect in prefs.js and/or about:config but not have the same effect on websites as changing it in the about:config GUI? Isn't the point of the user.js/config file setup to avoid having to go into about:config for every single setting?

Results Summary for the SharedArrayBuffer `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` issue:

WHAT WORKS
Set to true in phoenix-desktop.js --> works (no error)
Set to true manually in about:config --> works (no error)
Set pref to true directly in user.js --> works (no error)

WHAT DOES NOT WORK
Set to true in special config file --> shows value correctly in about:config but does not work (throws SharedArrayBuffer error as if were still set to false)

So is the problem something upstream with Mozilla and how they are implementing either the AutoConfig stuff or something to do with this specific pref? Or is this a Phoenix bug?

Also, it may be worth noting that it took me an embarrassingly long time to realize that just deleting the user.js file was not enough to detach the profile from the special config file. I didn't think about the fact that I would need to remove the config file pref from the prefs.js file (or about:config), so that may be worth a short blurb in the Extended Configs setting of the Wiki or README.

TL;DR: skip to the bottom, I think I am on the right path to figuring out the problem. I did restart each time since I noticed that's required to take effect. ~~Since you weren't able to replicate it, I created a new test profile with the exact same setup (same user.js/config, since that's all I had done with the first test profile). For some reason, the second profile behaves correctly/as expected. When I went back to the first profile, the problem was still there. I compared everything. As far as I can tell, they're identical profiles with same user.js and everything.~~ I've been seeing similar problems before, where tweaking about:config and/or a custom config file several times can lead to some settings no longer taking effect and "sticking" to Phoenix defaults, even though about:config shows the custom config changes I haven't nailed down a rhyme or reason for why it happens, but I'm working on that. Edit: It happened again, and creating a new profile did not solve the problem. `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` is set to `true` via the config file, but in practice, it's still acting like it's `false` and having settings based on the Phoenix defaults. I have tried restarting Firefox, uninstalling and reinstalling Phoenix, creating a fresh profile, etc. The only thing that prevents the SharedBufferArray errors is if I change the pref in phoenix-desktop.js. Setting it to `true` in the config file, although it shows it as set correctly, still causes the error to be thrown. It's basically showing the correct specialized config settings in the about:config page, but the browser is behaving like there is no specialized config being used. Only changing phoenix-desktop.js affects the browser behavior for this setting for me. Edit 2: **PROGRESS!** Reproducible progress. I have learned that if I change the `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` pref in a config file, it does reflect in about:config as changed correctly, but it does not actually go into effect (still see error on websites). However, if I do NOT put the pref in the config file at all and ONLY change it in the about:config GUI, the setting is properly implemented - no more errors. How/why is that? Why would the config file setting reflect in prefs.js and/or about:config but not have the same effect on websites as changing it in the about:config GUI? Isn't the point of the user.js/config file setup to avoid having to go into about:config for every single setting? ### Results Summary for the SharedArrayBuffer `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` issue: WHAT WORKS Set to true in phoenix-desktop.js --> works (no error) Set to true manually in about:config --> works (no error) Set pref to true directly in user.js --> works (no error) WHAT DOES NOT WORK Set to true in special config file --> shows value correctly in about:config but does not work (throws SharedArrayBuffer error as if were still set to false) So is the problem something upstream with Mozilla and how they are implementing either the AutoConfig stuff or something to do with this specific pref? Or is this a Phoenix bug? _Also, it may be worth noting that it took me an embarrassingly long time to realize that just deleting the user.js file was not enough to detach the profile from the special config file. I didn't think about the fact that I would need to remove the config file pref from the prefs.js file (or about:config), so that may be worth a short blurb in the Extended Configs setting of the Wiki or README._

aescgar commented

2025-06-08 22:15:30 +02:00

Author

Original comment:

~~Okay, maybe this should be a separate issue, but in trying to understand how everything is working and isolate the root of the conflicts I've been noticing, I've discovered something else confusing. Often, when I create a new profile, there is an unexpected result in relation to the phoenix-desktop.js. Here are the reproducible steps I've taken several times:

Delete ALL of the content of /etc/firefox/defaults/pref/phoenix-desktop.js (I know normally you wouldn't touch this, but this was just for troubleshooting/testing purposes).
Add a single pref: pref("browser.phoenix.status.empty", "empty phoenix config applied", locked);. Save the phoenix-desktop.js file.
Create brand new profile.
Result: The new test pref is set as expected in the new profile, but all the normal Phoenix default settings are also set, as if I didn't delete them from the phoenix-desktop.js file prior to creating the profile. Shouldn't the lack of anything within the phoenix-desktop.js file mean that the Phoenix settings don't get set? Where else are the phoenix-desktop.js prefs getting stored and pulled when I create a new profile?

Another example of weirdness suggesting that these Phoenix prefs are stored and pulled from somewhere else:

Leave phoenix-desktop.js in its normal state after installation.
Add to the end: pref("browser.phoenix.status.test", "test success", locked);.
Change any Phoenix default back to its Mozilla default. For example, set: pref("dom.postMessage.sharedArrayBuffer.withCOOP_COEP", true); Save the phoenix-desktop.js file.
Create brand new profile.

I would expect the new profile to have the test success pref value and have the dom.postMessage pref be true. Instead, the test success is present, but dom.postMessage.sharedArrayBuffer.withCOOP_COEP is still false. How could this be?

Sometimes, if I uninstall and reinstall Phoenix, things go back to working as I expect (where emptying phoenix-desktop.js removes all Phoenix prefs), but somewhere along the way, this or some similar issue begins occurring, throwing a wrench into my web compat troubleshooting. It seems like prefs get "stuck" and are being stored somewhere globally that isn't phoenix-desktop.js sometimes.

Maybe this is expected, but my understanding was that the profiles pulled their "default" settings from phoenix-desktop.js unless they were overridden with a different config, so how is the new profile still showing all of the Phoenix prefs? (I am trying to root out why how everything is working and why I'm having unexpected results because I'm having web compat issues. I can't troubleshoot which prefs are causing the web compat problems if I can't get my prefs/configs to behave in a reliable manner and understand how it's working. Thanks for any insight you can offer.)

Edit: To clarify, I don't think any of this ^ needs a "fix" since I have quickly rectified it by uninstalling and reinstalling Phoenix, I'm just wondering how the "stuck" prefs could happen in the first place so I can better understand how this works for further troubleshooting.~~

I'm leaving the original comment below in case it helps you troubleshoot any of these weird settings issues, but I'll probably need to wait for this new below problem to reoccur predictably and report under a new issue, if appropriate. However, of course feel free to respond to my below confusion if you know the explanation off the top of your head. Original comment: ~~Okay, maybe this should be a separate issue, but in trying to understand how everything is working and isolate the root of the conflicts I've been noticing, I've discovered something else confusing. Often, when I create a new profile, there is an unexpected result in relation to the phoenix-desktop.js. Here are the reproducible steps I've taken several times: 1. Delete ALL of the content of /etc/firefox/defaults/pref/phoenix-desktop.js (I know normally you wouldn't touch this, but this was just for troubleshooting/testing purposes). 2. Add a single pref: `pref("browser.phoenix.status.empty", "empty phoenix config applied", locked);`. Save the phoenix-desktop.js file. 3. Create brand new profile. 4. Result: The new test pref is set as expected in the new profile, but all the normal Phoenix default settings are also set, as if I didn't delete them from the phoenix-desktop.js file prior to creating the profile. Shouldn't the lack of anything within the phoenix-desktop.js file mean that the Phoenix settings don't get set? Where else are the phoenix-desktop.js prefs getting stored and pulled when I create a new profile? Another example of weirdness suggesting that these Phoenix prefs are stored and pulled from somewhere else: 1. Leave phoenix-desktop.js in its normal state after installation. 2. Add to the end: `pref("browser.phoenix.status.test", "test success", locked);`. 3. Change any Phoenix default back to its Mozilla default. For example, set: `pref("dom.postMessage.sharedArrayBuffer.withCOOP_COEP", true);` Save the phoenix-desktop.js file. 4. Create brand new profile. I would expect the new profile to have the `test success` pref value and have the `dom.postMessage` pref be true. Instead, the test success is present, but `dom.postMessage.sharedArrayBuffer.withCOOP_COEP` is still `false`. How could this be? Sometimes, if I uninstall and reinstall Phoenix, things go back to working as I expect (where emptying phoenix-desktop.js removes all Phoenix prefs), but somewhere along the way, this or some similar issue begins occurring, throwing a wrench into my web compat troubleshooting. It seems like prefs get "stuck" and are being stored somewhere globally that isn't phoenix-desktop.js sometimes. Maybe this is expected, but my understanding was that the profiles pulled their "default" settings from phoenix-desktop.js unless they were overridden with a different config, so how is the new profile still showing all of the Phoenix prefs? (I am trying to root out why how everything is working and why I'm having unexpected results because I'm having web compat issues. I can't troubleshoot which prefs are causing the web compat problems if I can't get my prefs/configs to behave in a reliable manner and understand how it's working. Thanks for any insight you can offer.) Edit: To clarify, I don't think any of this ^ needs a "fix" since I have quickly rectified it by uninstalling and reinstalling Phoenix, I'm just wondering how the "stuck" prefs could happen in the first place so I can better understand how this works for further troubleshooting.~~

celenity commented

2025-06-12 07:31:36 +02:00

Owner

Also, it may be worth noting that it took me an embarrassingly long time to realize that just deleting the user.js file was not enough to detach the profile from the special config file. I didn't think about the fact that I would need to remove the config file pref from the prefs.js file (or about:config), so that may be worth a short blurb in the Extended Configs setting of the Wiki or README.

Great point, I'll make sure to note this - I never thought about that before. Thanks.

Maybe this is expected, but my understanding was that the profiles pulled their "default" settings from phoenix-desktop.js unless they were overridden with a different config

That's correct.

so how is the new profile still showing all of the Phoenix prefs?

It's hard to say, but it sounds like something is preventing your changes to the phoenix-desktop.js file from taking effect. Next time this happens for you, can you please check the contents of file:///etc/firefox/defaults/pref/phoenix-desktop.js from within Firefox, to ensure it displays pref("browser.phoenix.status.empty", "empty phoenix config applied", locked); instead of Phoenix's default preferences? That'll help rule that out.

I can't troubleshoot which prefs are causing the web compat problems if I can't get my prefs/configs to behave in a reliable manner and understand how it's working. Thanks for any insight you can offer.)

Fair enough, thanks for taking the time to troubleshoot and understand the project - it definitely helps a lot, very much appreciated.

> *Also, it may be worth noting that it took me an embarrassingly long time to realize that just deleting the user.js file was not enough to detach the profile from the special config file. I didn't think about the fact that I would need to remove the config file pref from the prefs.js file (or about:config), so that may be worth a short blurb in the Extended Configs setting of the Wiki or README.* Great point, I'll make sure to note this - I never thought about that before. Thanks. > Maybe this is expected, but my understanding was that the profiles pulled their "default" settings from phoenix-desktop.js unless they were overridden with a different config That's correct. > so how is the new profile still showing all of the Phoenix prefs? It's hard to say, but it sounds like something is preventing your changes to the `phoenix-desktop.js` file from taking effect. Next time this happens for you, can you please check the contents of `file:///etc/firefox/defaults/pref/phoenix-desktop.js` from within Firefox, to ensure it displays `pref("browser.phoenix.status.empty", "empty phoenix config applied", locked);` instead of Phoenix's default preferences? That'll help rule that out. > I can't troubleshoot which prefs are causing the web compat problems if I can't get my prefs/configs to behave in a reliable manner and understand how it's working. Thanks for any insight you can offer.) Fair enough, thanks for taking the time to troubleshoot and understand the project - it definitely helps a lot, very much appreciated.

celenity closed this issue

2025-06-13 23:06:55 +02:00