ToDo: diffs FF122-FF123 #1814
Comments
some bugzilla tickets
|
🎉 |
The above three prefs were actually removed in FF123 but was "accidentally added back" in bug 1783521 (according to bug 1882114 comment 2) so they don't currently do anything. Searchfox didn't manage to pick up on these either so I am just leaving this here for posterity. |
|
thanks @Jee-Hex :) just as well I haven't got them in the user.js since I don't consider View to be a privacy/security issue, unless I'm missing somthing |
These prefs only affect/hide the button but do not outright disable the feature. TBB patched it out in 42037 but you might want to watch bug 1880142? |
yup, totally get that :)
we're not TB and they don't want to enable any outgoing connections if they can help it because mumble mumble timing attacks circuits mumble etc. But that's not why they did this: it requires a Mozilla account which base browser users don't have, so they cleaned up the UI - a button and an about page :) even though "Firefox View does not appear in PB windows" https://support.mozilla.org/en-US/kb/how-set-tab-pickup-firefox-view
|
|
Yeah I am not arguing that there is a privacy/security issue. Just trying to complete @earthlng's collection of bugzilla tickets here :) |
|
nice: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41309#note_3006995
edit @earthlng thanks for the test :) I knew you were good for something :) |
|
loving the silence and stability :)
edit: updated after another two blissfully quiet months |
|
@Thorin-Oakenpants you (and the gang) tweaked it to the maximum perfection. Thank you all ❤️ |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
new (edit: new if not nightly!!)
ahhh this seems like the bugzilla - https://bugzilla.mozilla.org/show_bug.cgi?id=1876406 - ride the train |
|
@rusty-snake I don't use containers .. can you please craft this for me and tell me if it should be active/commented out and what the value should be - TIA 🧀 /* 1703: */
user_pref("browser.link.force_default_user_context_id_for_external_opens", true); |
|
Value: /* 1703: Always open (external links|links from external applications) in the (default container|without a container) [FF123+]
* Some container extensions need this to work correctly. ***/
user_pref("browser.link.force_default_user_context_id_for_external_opens", true); |
|
thanks, I guess. I can't really parse that |
|
OK, I'll try again. It's going to be inactive, I am adding it for the info factor. Containers are a cool tool for (extra) partitioning - hence adding it, and hence we enable it (edit: it being containers, not this new pref). But I don't use containers, MAC, TC or any of that - and I have no idea, or desire, to try and understand the workflows or intricacies of WTF is going on someone will need to write something that ELI5 for readers - for example, I literally cannot parse the previous attempt, and I'm not going to go read some long bugzilla (as a user) Until I can add this, it's a blocker for any more updates - thanks |
|
Maybe something like: Force opening external links in no container (instead of having Firefox choose one automatically). Or: Prevent Firefox from automatically opening external links in a container. Actually I think rusty's suggestion is ok: |
/* 1703: Always open (external links|links from external applications) in the (default container|without a container) [FF123+]
* Some container extensions need this to work correctly. ***/
user_pref("browser.link.force_default_user_context_id_for_external_opens", true);^ still not easily readable or understandable. I cannot tell WTF true or false applies to. External links and links from external applications is the same thing. So /* 1703: set how containers work with external links [FF123]
* [SETUP-WEB] Depending on your container extension(s) and their settings
* true=Firefox will not choose a container (so your extension can)
* false=Firefox will choose the container (default) ***/
// user_pref("browser.link.force_default_user_context_id_for_external_opens", true);Come on you guys ... I can't write everything. This doesn't even seem correct
I literally cannot write this shit or deep dive it - and I refuse to. Either help or I won't bother adding it - thanks |
He's giving you alternatives to choose from.
Container extensions are usually triggered by trying to open a website in no/default container. So if FF has already opened the page in a container, the extension doesn't do anything anymore. no container = default container
The one which most of the pages of the same domain are currently opened in:
|
they're the complete opposite of each other - appreciate the help .. will come back to this after I get back from portugal |
That's the very same thing. |
|
Oh come on ... it's ambiguous at best. The word container implies a .. wait for it .. container .. and without a container implies .. wait for it .. no container = they are not the same. I can't add ambiguous info - it needs to be crystal clear to the reader what is going to happen |
this is better, we could add some |
|
"without a container": What the user sees and think it happens. Which perspective do you prefer? work correctly: (examples)
This heuristic will be expanded in the future. When containers are part of history, this will be taken into account too for example. |
in other words, the default container is no container - this is redundant |
|
speak now if you have issues with it - I will probably land 126 today or tomorrow |
FF123 release date: Feb. 20th 2024
FF123 release notes
FF123 for developers
FF123 security advisories
89 diffs ( 44 new, 30 gone, 15 different )
new in v123.0:
removed, renamed or hidden in v123.0:
changed in v123.0:
7016pref("privacy.partition.network_state.ocsp_cache", true); // prev: false 1874143 - notated in v122 5916d0cignore
click me for details
==NEW
==REMOVED, RENAMED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: