Closed Bug 1677482 Opened 4 years ago Closed 11 months ago

updates of firefox overwrite privacy settings

Categories

(Core :: Widget: Gtk, defect)

Firefox 82
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: richard.palo, Unassigned)

Details

Attachments

(1 file)

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

Steps to reproduce:

update firefox (on archlinux, both x86_64 and aarch64à

Actual results:

privacy settings for cookies are unset

Expected results:

as by default I disable cookies but enable them site by site, I find after an update that I need to declick 'default' permissions for cookies where the previous setting comes back.
This means I need to update dozens and dozens of sites each upgrade!

We currently do not have an archlinux device but I will set a component for this issue and maybe one of our developers might be able to reproduce this issue.

Im not sure what the steps for this issue are @Richard can you confirm these steps ?

  1. Start an older version of Firefox and from about:preferences#privacy you have the Standard Enhanced protection set,
  2. Reach any website like bbc.com for instance and you manualy add the bbc.com to the Exceptions list (with ALLOW) in the about:preferences#privacy > Cookies and Site Data section > Manage Exceptions list.
  3. Update the browser.
  4. Reach the Exceptions list from about:preferences#privacy > Cookies and Site Data section and bbc.com website is no longer listed to the allowed list ?

Are these the correct steps ?

I tried reproducing this issue on a Windows 10 machine but after an Update is performed the Exceptions are still saved. Might be related to the aarchlinux build ?

Component: Untriaged → Widget: Gtk
Flags: needinfo?(richard.palo)
Product: Firefox → Core

Sorry, totally blew past your request...
Yes, more or less the case as you present it. Nota bene: I'm running with the french language pack.

Also, I notice as well, even without a version update, refresh seems to do it as well.
That is, for some confounded reason, frequently the package update will give a message to 'refresh' firefox.
If that is postponed, and all the cookies (and popups) and re-enabled for the critical sites, when finally I get around
to doing the 'refresh', I lose not only the cookies and popups settings, but also my saved passwords!

Flags: needinfo?(richard.palo)

just updated with the same problem to
Nom Firefox
Version 86.0.1
Identifiant de compilation 20210311122254
ID de distribution archlinux
Agent utilisateur Mozilla/5.0 (X11; Linux aarch64; rv:86.0) Gecko/20100101 Firefox/86.0
Système d’exploitation Linux 5.11.4-1-ARCH #1 SMP Sun Mar 7 23:46:10 UTC 2021

I ran as well the profile upgrader (on bottom of page when Firefox loads) which explicitly lists that all these things are supposedly treated, but not all seem correctly done.

Is there perhaps a problem related to the fact that $HOME is an NFS mount?

This is truly a PITA!

BTW, now I'm running Linux odroid-001e06336dd6 5.11.4-1-ARCH #1 SMP Sun Mar 7 23:46:10 UTC 2021 aarch64 GNU/Linux

BTW, here is the buildconfig in case there is something to correct:

Build Configuration
Source

Built from https://hg.mozilla.org/releases/mozilla-release/rev/79d8545221202e234cf587c0b36c9aaa6cdc3a41
Build platform
target
aarch64-unknown-linux-gnu
Build tools
Compiler Version Compiler flags
/usr/lib/distcc/bin/clang -std=gnu99 11.1.0 -march=armv8-a -O2 -pipe -fno-plt -g0 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/usr/lib/distcc/bin/clang++ -std=gnu++17 11.1.0 -Qunused-arguments -D_FORTIFY_SOURCE=2 -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wno-error=deprecated-copy -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-psabi -Wno-unknown-warning-option -fno-sized-deallocation -fno-aligned-new -march=armv8-a -O2 -pipe -fno-plt -g0 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g0 -O2 -fomit-frame-pointer -funwind-tables
/usr/bin/rustc 1.50.0 -Cdebuginfo=0
Configure options

--enable-application=browser MOZILLA_OFFICIAL=1 --enable-update-channel=release MOZBUILD_STATE_PATH=/build/firefox/src/mozbuild --disable-tests '--enable-optimize=-g0 -O2' CC=clang CXX=clang++ 'MOZ_DEBUG_FLAGS= ' RUSTFLAGS=-Cdebuginfo=0 --enable-linker=lld AR=llvm-ar NM=llvm-nm --enable-alsa --enable-jack --enable-rust-simd --with-mozilla-api-keyfile=/build/firefox/src/firefox-86.0.1/mozilla-api-key --with-google-location-service-api-keyfile=/build/firefox/src/firefox-86.0.1/google-api-key --with-google-safebrowsing-api-keyfile=/build/firefox/src/firefox-86.0.1/google-api-key --disable-webrtc --with-unsigned-addon-scopes=app,system --allow-addon-sideload --with-system-nss MOZ_APP_REMOTINGNAME=firefox MAKE=/usr/bin/make --disable-crashreporter --enable-official-branding --disable-updater --prefix=/usr --with-distribution-id=org.archlinux

Well, I was able to easily recreate this on local (rebind) $HOME on x86_64... just need to go to about:support and 'repair'...
so, if it's arch specific, it's everybody on arch...

This is really frustrating, it is not only the cookies settings, but almost all the settings.
Download setting is always reset not to ask each time, so I need to re-update it to always ask.
The search engine is always reset back to g$$gle, so I need to re-update it to something reasonable.
Also, under applications, pdf is always reset back to open in Firefox, so I need to re-update it to always ask
(as only save to... or open with system default is acceptable for us).

I checked that I am correctly the owner of all files under .mozilla/firefox, is it possible that the profile bits bug out on nfs home directories?
It is a REAL PITA to have set these and dozens and dozens of sites back each update.

If you're using Firefox from pacman, then you should probably report this downstream.

Yeah, did so already this morning in hope of finding some others experiencing the same exasperation.

https://bugs.archlinux.org/task/71012

cheers

I see the same behavior from the official releases. Isn't this kind of settings reset the expected fallout from doing a "Refresh" of the profile?

But it happens by default upon upgrade... or when the message is displayed (and acted) that things should be optimised
(I'll do a screen capture next time I see this before doing it)
I just mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1677482#c2 that it can be reproduced with 'reset'.

Apparently its gotta be related to something going on with permissions.sqlite
Is there any way/where to get a verbose log when launching firefox the first time after an upgrade?

The message (as indicated in the attached screenshot) is somewhat strange:
"It seems you have not started Firefox for a while. Would you like to refresh it for a better navigation?
Nice to see you again!" then a button to 'repair' Firefox (presumably the same as found in about:support)

What is strange is that Firefox is [naturally] used daily!

I see the same behavior from the official releases. Isn't this kind of settings reset the expected fallout from doing a "Refresh" of the profile?

Yes. The fact that the Arch updates do it on every update, or causes the message to be displayed, sounds very much like an Arch bug, but it must also be quite uncommon as else of course every Arch user would be quite upset. I wonder if OP's profile got mangled somehow? Maybe that's what comment 11 refers to?

I'm going to close this, the updating doing a "refresh" is as far as I can tell not caused by Firefox, so there isn't really anything that can be fixed on our side.

Status: UNCONFIRMED → RESOLVED
Closed: 11 months ago
Resolution: --- → INVALID

OP, if you're still reading this, I would try creating an entirely new profile (https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles). You'll lose your settings (again), but then hopefully it will be the last time?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: