ToDo: diffs FF68-FF69 #766
Comments
some bugzilla tickets
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
There will be a new value in FF69 for 2030 and they added migration code which will change 2030 to the new value 5 for those who'd set media.autoplay.allow-muted to false. /* 2030: disable autoplay of HTML5 media [FF63+]
* 0=Allow all, 1=Allow muted media (default in FF67+), (2=Prompt - removed in FF66,) 5=Block all autoplay (FF69+)
* [NOTE] You can set exceptions under site permissions
* [SETTING] Privacy & Security>Permissions>Autoplay>Settings>Default for all websites ***/
// user_pref("media.autoplay.default", 5);AFAIK the title for 2032 is also incorrect: it blocks all media autoplay "until in foreground", not just audio. /**
* When the pref "media.block-autoplay-until-in-foreground" is on,
* Gecko delays starting playback of media resources in tabs until the
* tab has been in the foreground or resumed by tab's play tab icon.
* - When Gecko delays starting playback of a media resource in a window,
* it sends a message to call activeMediaBlockStarted(). This causes the
* tab audio indicator to show.
* - When a tab is foregrounded, Gecko starts playing all delayed media
* resources in that tab, and sends a message to call
* activeMediaBlockStopped(). This causes the tab audio indicator to hide.
*/ |
|
|
|
enforceRemoteTypeRestrictions is enabled by default on Desktop but not Mobile. It is a security related pref - doesn't have any privacy implications. Ticket is still hidden because there is followup work to be done once some blockers are dealt with. separatePrivilegedMozillaWebContentProcess is another security feature with no privacy implications. Again, once we deal with blockers we can finish the work there. |
nvm, I see that it's only enabled in nightly at the moment. Is it serious enough that we should enable it already as well? |
I don't want to go into too much detail about it; but if it was an imminent threat we wouldn't let it linger in Nightly while we kick the tires and so forth. That said, the tires have been kicked for over a month at this point; so if you want what seems like a relatively small chance for odd behavior you can always flip it. |
|
Oh yeah, separatePrivilegedMozillaWebContentProcess doesn't sound good to me either. Sure, I can see the security benefit to an extent but "privileged" usually also means they can do things that no other site can do, and it usually also means that extensions are locked out fe no way to block GA on AMO or blocking JS in general. Probably makes sense for the masses but not exactly my cup of tea. |
|
ah okay, thanks @tomrittervg |
In this case; this doesn't change anything with regards to what extensions can and can't do and where. That's other prefs. Once the bug becomes public more details will be available, but I would strongly recommend against disabling this (once we can enable it). It isolates components for security (unrelated to extensions.) |
|
there were no more pref changes in the final release since RC2. I'll update the 1st post and title. re: samesite - the web is probably not ready yet for samesite=lax and the prefs are not even enabled in nightly at this point. I think it's best to ignore them for now. |
and others
FF69 is scheduled for release Sept. 3rd
FF69 release notes [when ready]
FF69 for developers
FF69 compatibility
FF69 security advisories
246 diffs ( 177 new, 33 gone, 36 different )
new in v69.0:
removed, renamed or hidden in v69.0:
ALL DONE- 66cdb72, also see 810045e1405pref("gfx.downloadable_fonts.woff2.enabled", true); 15569912033pref("media.autoplay.allow-muted", true); 15623312030new value replacingmedia.autoplay.allow-muted- 8d1c95c , b47982b1802pref("plugins.click_to_play", true); 1519434changed in v69.0:
2701pref("network.cookie.cookieBehavior", 4); // prev: 0 - 4d72ad9ignore
click me for details
==NEW
==REMOVED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: