Closed Bug 1777712 Opened 2 years ago Closed 2 years ago

TBird/FFox profiles, update fail -- Blame Gecko?

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Version:
Firefox 101
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1772940

People

(Reporter: markfilipak.mozilla, Unassigned)

Details

Attachments

(3 files, 1 obsolete file)

Mark's_changes.txt
1.50 KB, text/plain
Details
Some testing after going back to home-local profiles.
5.09 KB, text/plain
Details
Highlights, going back to home-local profiles.
5.09 KB, text/plain
Details

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

Steps to reproduce:

Linux Mint 20.3, TBird 91.9.1, FFox 101.0.1.

New FFox history are saved to my FFox profile:
/media/sf_LinuxFFox/ckls0yge.default-release
New TBird emails are saved to my TBird profile:
/media/sf_LinuxTBird/0ysydkep.default
UI changes/settings and TBird Oauth2 tokens are not.

The only common factor that I know of is Gecko -- implemented at TBird v.68 to the best of knowledge.

These used to work in TBird 52.7.

Hang on. I see I'm one VBox update behind. The new one is:
VirtualBox-6.1.34a-150636-Win.exe
I will update VBox and come back here with the results.

Actual results:

UI changes I make do not survive restarts.

Expected results:

UI changes, passwords, Oauth2 tokens, etc. should all be saved to the respective profile.

I updated VBox from Version 6.1.32 r149290 (Qt5.6.2) to Version 6.1.34 r150636 (Qt5.6.2).
Host is Windows 7.
The symptoms have not changed. UI changes I make to both FFox and TBird do not survive restarts. For example, the FFox Menu Bar, TBird Unified Folders, TBird Oauth2 tokens (passwords), Norm/Max window states, and many, many more.
I am assuming that the problem is that profiles are in VBox shared folders. On request, I will test whether they work if the profiles are in my home directly, but I seem to remember that I've already confirmed that.

I should add some background info.
The Pale Moon browser works with my profile -- note: different from FFox profile! -- in a shared folder.
The Pale Moon browser works even if residing on a virtual USB plugged into the virtual machine.
Even this works: Thunderbird-91.10_20220525135609.AppImage, when residing on a virtual USB plugged into the virtual machine, though, of course, I experience the same problems I document in this report.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Thanks for reporting this. Steps to reproduce do not include any UI changes but that's suddenly mentioned under "Actual results". Please provide complete and specific steps to reproduce something. Thanks.

Flags: needinfo?(markfilipak.mozilla)

(In reply to Andre Klapper from comment #4)

Thanks for reporting this. Steps to reproduce do not include any UI changes but that's suddenly mentioned under "Actual results". Please provide complete and specific steps to reproduce something. Thanks.

Install Oracle VirtualBox
Create a Linux Mint virtual machine
In the VBox VM, create a shared folder named SHAREDFOLDER.
( In the VM, VBox will automount SHAREDFOLDER, here: /media/sf_SHAREDFOLDER )
Create a FFox profile -- suppose the profile that FFox assigns is named FFPROFILE
Quit FFox
Move PROFILE to here: /media/sf_SHAREDFOLDER/FFPROFILE
Launch FFox via 'firefox --profile /media/sf_SHAREDFOLDER/FFPROFILE'
Make UI changes.
Quit FFox
Launch FFox via 'firefox --profile /media/sf_SHAREDFOLDER/FFPROFILE'
Observe that the UI changes did not survive

Component: Audio/Video: Playback → DOM: Workers
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Component: DOM: Workers → Preferences: Backend

Important info...

I launch FFox thusly:
/usr/lib/firefox/firefox --profile /media/sf_LinuxFFox/ckls0yge.default-release
FFox's "About Profiles" shows NO profile.

I launch TBird thusly:
/usr/lib/thunderbird/thunderbird --profile /media/sf_LinuxTBird/0ysydkep.default
TBird's "About Profiles" shows NO profile.

Step 0: Command line with explicit '--profile' argument, permanent profile void
Step 1: Command line with inferred profile argument, permanent profile exists
Step 2: Command line with explicit '--profile' argument, permanent profile exists

Step 0: Command line with explicit '--profile' argument, permanent profile void

'firefox --profile /media/sf_LinuxFFox/ckls0yge.default-release'

'/home/mark/.mozilla/firefox/profiles.ini'

(void)

'/home/mark/.mozilla/firefox/installs.ini'

(void)

Result: UI changes do not survive restart.

Step 1: Command line with inferred profile argument, permanent profile exists

'firefox'

'/home/mark/.mozilla/firefox/profiles.ini'

[Install4F96D1932A9F858E]
Default=ckls0yge.default-release
Locked=1

[Profile0]
Name=default-release
IsRelative=0
Path=/media/sf_LinuxFFox/ckls0yge.default-release

[General]
StartWithLastProfile=1
Version=2

'/home/mark/.mozilla/firefox/installs.ini'

[4F96D1932A9F858E]
Default=2xvvmob6.Default User
Locked=1

Result: UI changes do not survive restart.

Step 2: Command line with explicit '--profile' argument, permanent profile exists

'firefox --profile /media/sf_LinuxFFox/ckls0yge.default-release'

'/home/mark/.mozilla/firefox/profiles.ini' exists

(same as in Step 1)

'/home/mark/.mozilla/firefox/installs.ini'

(same as in Step 1)

Result: UI changes do not survive restart.

Attached file Cases 0, 1, and 2 (obsolete) —
Attached file Mark's_changes.txt —

How about this for a troubleshooting idea?

I'll have 2 profiles, one here:
'/media/sf_LinuxFFox/ckls0yge.default-release',
AND the other here:
'/.mozilla/firefox/ckls0yge.default-release'.
I'll launch FFox via:
firefox --profile /media/sf_LinuxFFox/ckls0yge.default-release
do some things, and see what FFox changes in '/.mozilla/firefox/ckls0yge.default-release'?
That will reveal what parts of FFox fetch the profile location from '~/.mozilla/firefox/profile.ini' instead of honoring the command line.

That will take a long time to repeatedly test-quit-results-launch-test-quit-results-... But I'm not going to do that if I don't start getting some action here -- that means: responses from FFox staff.

Attachment #9283953 - Attachment is obsolete: true
Flags: needinfo?(kwright)

This looks like an issue with your profiles, not with libpref.

Component: Preferences: Backend → Startup and Profile System
Flags: needinfo?(kwright)
Product: Core → Toolkit

I agree. If the FFox & TBird profiles are rooted here:
'/.mozilla.firefox/'
'/thunderbird/'
then all is Joy. But if the FFox & TBird profiles are rooted on VirtualBox shared folders, then history, cookies, and email work but UI changes and new passwords don't survive restarts.

What do FFox & TBird have in common that would explain this? I believe it's called "Gecko".

I'll bet that some operations in common code honor the command lines:
firefox --profile /media/sf_LinuxFFox/ckls0yge.default-release
thunderbird --profile /media/sf_LinuxTBird/0ysydkep.default
while other operations try to read the 'profiles.ini' files and silently fail (because those 'ini' files don't exist).

If you like, I can exhaustively test both setups for both apps and make a chart of what operations succeed and what operations fail for the following scenarios:
no '--profile' + 'ini' in usual path pointing to usual profile <= this works -- is usual setup
no '--profile' + 'ini' in usual path pointing to profile in VBox
'--profile' in VBox + no 'ini'
'--profile' in VBox + 'ini' in the usual place pointing to profile in VBox

That would cut down the code searches for breakages considerably.

I have wonderful news. I put my FFox & TBird profiles on virtual USBs, not in VirtualBox shared folders or on virtual hard disks.
Everything seems to work 100%.

They must be virtual USBs in order to get mounted automatically.
Virtual HDs don't get mounted automatically, that's why I was getting inconsistent results while testing.
For example, if I opened TBird 2nd, after nemo, then I'd get good results, but if I opened TBird 1st, it failed.

I still don't know why putting FFox & TBird profiles in shared folders doesn't work.

My workaround doesn't solve the bug. Putting FFox & TBird profiles in VBox shared directories would be a better solution. My workaround may give a clue. So, what do FFox & TBird have in common that fails only in a shared folder (which apparently is something called a "systemd unit file", whatever that is), but only fails for passwords, UI changes, and perhaps others (and fails silently), but succeeds for new mail, new history, and perhaps others.

I'm still willing to sort out all the profile things that succeed and that fail if you think that would help.
For now, I'm using virtual USBs for the profiles. Unless contacted for further testing, I will not return here.

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)

Can you elaborate on what "UI changes" means here? What specifically isn't getting persisted between restarts and what is?

Severity: -- → S4
Flags: needinfo?(dtownsend) → needinfo?(markfilipak.mozilla)

Hello Dave.

"UI changes" means the sizes of TBird & FFox windows (e.g., maximized v. non-maximized), the state of TBird folders view (e.g., All Folders v. Unified Folders), the state of TBird Quick Filter (e.g., displayed v. not displayed), and similar UI settings in FFox (and maybe other UI settings). Also, new Oauth2 tokens did not survive and needed to be reacquired from Gmail on each TBird launch.

As I noted in comment 24, I discovered that if I put the profiles in virtual USB drives rather than shared folders, then the problem is resolved. When I made that discovery, I stopped troubleshooting -- I figured that I'd 'fingered' Gecko sufficiently. However, I am willing to reconfigure TBird & FFox profiles back to using VBox shared folders for further testing upon request. Apparently, TBird & FFox cookies and the TBird mail store (maildir) are not affected by the bug.

I hope this helps.

Flags: needinfo?(markfilipak.mozilla)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way? What do the file permissions on that file look like as far as the linux guest is concerned?

Flags: needinfo?(markfilipak.mozilla)

(In reply to Dave Townsend [:mossop] from comment #29)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way?

While I was having the bug or now that the profiles are out on virtual USBs?

What do the file permissions on that file look like as far as the linux guest is concerned?

This problem -- UI changes not saved if profile is in a VBox shared folder -- was not a permissions problem. Trust me. If it was, I wouldn't have been able to make new cookies or new bookmarks or save emial. Yes, I did check permissions anyway. It is not a permissions problem.

Flags: needinfo?(markfilipak.mozilla)

Dear Dave,

To be clear:
The issue (bug) was when I had TBird & FFox profiles in VBox shared folders. Note that I've never, ever had problems with shared folders in the past.
The profiles WERE written for things like bookmarks, cookies, new mail, etc. -- if it was a permissions problem, they would have also failed.
The profiles WERE NOT written for UI changes or for Oauth2 tokens -- that is the real (only) problem.
I put the profiles out on virtual USBs (instead of shared folders) and that works.

(In reply to markfilipak.mozilla@gmail.com from comment #30)

(In reply to Dave Townsend [:mossop] from comment #29)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way?

While I was having the bug or now that the profiles are out on virtual USBs?

When you were having the bug.

What do the file permissions on that file look like as far as the linux guest is concerned?

This problem -- UI changes not saved if profile is in a VBox shared folder -- was not a permissions problem. Trust me. If it was, I wouldn't have been able to make new cookies or new bookmarks or save emial. Yes, I did check permissions anyway. It is not a permissions problem.

Given that those are all different files accessed by different code it doesn't strictly follow that just because they work then there isn't an issue with file permissions.

(In reply to markfilipak.mozilla@gmail.com from comment #31)

The profiles WERE written for things like bookmarks, cookies, new mail, etc. -- if it was a permissions problem, they would have also failed.
The profiles WERE NOT written for UI changes or for Oauth2 tokens -- that is the real (only) problem.

What do you mean by Oauth2 tokens? Website logins are generally stored in cookies but you say that those were working so what is this referring to?

Flags: needinfo?(markfilipak.mozilla)

(In reply to Dave Townsend [:mossop] from comment #32)

(In reply to markfilipak.mozilla@gmail.com from comment #30)

(In reply to Dave Townsend [:mossop] from comment #29)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way?

While I was having the bug or now that the profiles are out on virtual USBs?

When you were having the bug.

What do the file permissions on that file look like as far as the linux guest is concerned?

This problem -- UI changes not saved if profile is in a VBox shared folder -- was not a permissions problem. Trust me. If it was, I wouldn't have been able to make new cookies or new bookmarks or save emial. Yes, I did check permissions anyway. It is not a permissions problem.

Given that those are all different files accessed by different code it doesn't strictly follow that just because they work then there isn't an issue with file permissions.

I thought you referred to Linux file permissions. (which do not change). If you refer to "different files accessed by different code", then you refer to 'permissions' that are not Linux file permissions and that are unknown to me. Please clarify. In all cases, the profiles' LInux file permissions were/are/have been 'rwxrwxrwx', owner: 'mark' (me), group: 'vboxsf'.

(In reply to markfilipak.mozilla@gmail.com from comment #31)

The profiles WERE written for things like bookmarks, cookies, new mail, etc. -- if it was a permissions problem, they would have also failed.
The profiles WERE NOT written for UI changes or for Oauth2 tokens -- that is the real (only) problem.

What do you mean by Oauth2 tokens? Website logins are generally stored in cookies but you say that those were working so what is this referring to?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity
https://datatracker.ietf.org/doc/rfc6749/
Oauth2 tokens (October 2012) are in addition/alternate to passwords. Oauth2 tokens are required by Amazon, Google, Facebook, Microsoft, and Twitter. GMail in particular will not function without Oauth2 tokens.

Flags: needinfo?(markfilipak.mozilla)

(In reply to markfilipak.mozilla@gmail.com from comment #33)

(In reply to Dave Townsend [:mossop] from comment #32)

(In reply to markfilipak.mozilla@gmail.com from comment #30)

(In reply to Dave Townsend [:mossop] from comment #29)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way?

Can you answer this? It would help narrow down where the issue might be happening.

What do the file permissions on that file look like as far as the linux guest is concerned?

This problem -- UI changes not saved if profile is in a VBox shared folder -- was not a permissions problem. Trust me. If it was, I wouldn't have been able to make new cookies or new bookmarks or save emial. Yes, I did check permissions anyway. It is not a permissions problem.

Given that those are all different files accessed by different code it doesn't strictly follow that just because they work then there isn't an issue with file permissions.

I thought you referred to Linux file permissions. (which do not change). If you refer to "different files accessed by different code", then you refer to 'permissions' that are not Linux file permissions and that are unknown to me. Please clarify. In all cases, the profiles' LInux file permissions were/are/have been 'rwxrwxrwx', owner: 'mark' (me), group: 'vboxsf'.

I was referring to linux file permissions, which can and do change. And as they are different files they can have different file permissions.

(In reply to markfilipak.mozilla@gmail.com from comment #31)

The profiles WERE written for things like bookmarks, cookies, new mail, etc. -- if it was a permissions problem, they would have also failed.
The profiles WERE NOT written for UI changes or for Oauth2 tokens -- that is the real (only) problem.

What do you mean by Oauth2 tokens? Website logins are generally stored in cookies but you say that those were working so what is this referring to?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity
https://datatracker.ietf.org/doc/rfc6749/
Oauth2 tokens (October 2012) are in addition/alternate to passwords. Oauth2 tokens are required by Amazon, Google, Facebook, Microsoft, and Twitter. GMail in particular will not function without Oauth2 tokens.

Oh right this is Thunderbird. Ok those are saved in the password manager, is Firefox's password manager similarly affected?

Flags: needinfo?(markfilipak.mozilla)

(In reply to Dave Townsend [:mossop] from comment #34)

(In reply to markfilipak.mozilla@gmail.com from comment #33)

(In reply to Dave Townsend [:mossop] from comment #32)

(In reply to markfilipak.mozilla@gmail.com from comment #30)

(In reply to Dave Townsend [:mossop] from comment #29)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way?

Can you answer this? It would help narrow down where the issue might be happening.

What do the file permissions on that file look like as far as the linux guest is concerned?

This problem -- UI changes not saved if profile is in a VBox shared folder -- was not a permissions problem. Trust me. If it was, I wouldn't have been able to make new cookies or new bookmarks or save emial. Yes, I did check permissions anyway. It is not a permissions problem.

Given that those are all different files accessed by different code it doesn't strictly follow that just because they work then there isn't an issue with file permissions.

I thought you referred to Linux file permissions. (which do not change). If you refer to "different files accessed by different code", then you refer to 'permissions' that are not Linux file permissions and that are unknown to me. Please clarify. In all cases, the profiles' LInux file permissions were/are/have been 'rwxrwxrwx', owner: 'mark' (me), group: 'vboxsf'.

I was referring to linux file permissions, which can and do change. And as they are different files they can have different file permissions.

To help us, I will do the following:
1 - Reapply VBox shared folders.
2 - Reconfirm that TBird & FFox UI changes do not survive restarts.
3 - Record and paste here the Linux file permissions for every file in the respective profiles.

(In reply to markfilipak.mozilla@gmail.com from comment #31)

The profiles WERE written for things like bookmarks, cookies, new mail, etc. -- if it was a permissions problem, they would have also failed.
The profiles WERE NOT written for UI changes or for Oauth2 tokens -- that is the real (only) problem.

What do you mean by Oauth2 tokens? Website logins are generally stored in cookies but you say that those were working so what is this referring to?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity
https://datatracker.ietf.org/doc/rfc6749/
Oauth2 tokens (October 2012) are in addition/alternate to passwords. Oauth2 tokens are required by Amazon, Google, Facebook, Microsoft, and Twitter. GMail in particular will not function without Oauth2 tokens.

Oh right this is Thunderbird. Ok those are saved in the password manager, is Firefox's password manager similarly affected?

FFox does not use Oauth2 that I am aware of. Solely TBird and solely for Gmail to the best of my knowledge/experience.

Flags: needinfo?(markfilipak.mozilla)

To clarify: TBird's ordinary passwords can be created and persist, even for profiles in VBox shared folders -- I will reconfirm this. Only Oauth2 tokens do not survive restarts for profiles in VBox shared folders (and that's for TBird, only, as FFox apparently has no need/demand for Oauth2).

Of course, the most probable cause is that some code is hardcoded to solely find profiles at
~/.thunderbird/<profilename>
and
~/.mozilla/firefox/<profilename>
-- thus, the code works for most users but fails for users with profiles in VBox shared folders. The most probable code is code that stores UI changes.

Why TBird storage of Oauth2 tokens fails is unknown.

Why moving the profiles from shared folders to virtual USBs works is unknown.

I will perform the following tests:
1 - Put both profiles in the 'usual' places to confirm that they work.
2 - Put both profiles in VBox shared folders to cofirm that UI changes and Oauth2 tokens do not survive restarts.

Please stand by...

Oops! Correction: TBird storage of Oauth2 tokens does succeed, they just don't suvive restarts.

(In reply to markfilipak.mozilla@gmail.com from comment #35)

(In reply to Dave Townsend [:mossop] from comment #34)

(In reply to markfilipak.mozilla@gmail.com from comment #33)

(In reply to Dave Townsend [:mossop] from comment #32)

(In reply to markfilipak.mozilla@gmail.com from comment #30)

(In reply to Dave Townsend [:mossop] from comment #29)

This sounds like a permissions problem. In the broken state if you make changes to the UI and quit do you see the file xulstore.json in the profile folder change in any way?

Can you answer this? It would help narrow down where the issue might be happening.

What do the file permissions on that file look like as far as the linux guest is concerned?

This problem -- UI changes not saved if profile is in a VBox shared folder -- was not a permissions problem. Trust me. If it was, I wouldn't have been able to make new cookies or new bookmarks or save emial. Yes, I did check permissions anyway. It is not a permissions problem.

Given that those are all different files accessed by different code it doesn't strictly follow that just because they work then there isn't an issue with file permissions.

I thought you referred to Linux file permissions. (which do not change). If you refer to "different files accessed by different code", then you refer to 'permissions' that are not Linux file permissions and that are unknown to me. Please clarify. In all cases, the profiles' LInux file permissions were/are/have been 'rwxrwxrwx', owner: 'mark' (me), group: 'vboxsf'.

I was referring to linux file permissions, which can and do change. And as they are different files they can have different file permissions.

To help us, I will do the following:
1 - Reapply VBox shared folders.
2 - Reconfirm that TBird & FFox UI changes do not survive restarts.
3 - Record and paste here the Linux file permissions for every file in the respective profiles.

Please also answer the specific question above about xulstore.json. The permissions are one thing but it is important to know if the file's contents or modification times change in any way.

(In reply to markfilipak.mozilla@gmail.com from comment #31)

The profiles WERE written for things like bookmarks, cookies, new mail, etc. -- if it was a permissions problem, they would have also failed.
The profiles WERE NOT written for UI changes or for Oauth2 tokens -- that is the real (only) problem.

What do you mean by Oauth2 tokens? Website logins are generally stored in cookies but you say that those were working so what is this referring to?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity
https://datatracker.ietf.org/doc/rfc6749/
Oauth2 tokens (October 2012) are in addition/alternate to passwords. Oauth2 tokens are required by Amazon, Google, Facebook, Microsoft, and Twitter. GMail in particular will not function without Oauth2 tokens.

Oh right this is Thunderbird. Ok those are saved in the password manager, is Firefox's password manager similarly affected?

FFox does not use Oauth2 that I am aware of. Solely TBird and solely for Gmail to the best of my knowledge/experience.

Yes but both Firefox's passwords and Thunderbird's Oauth2 tokens are stored by the same storage system so knowing whether Firefox passwords persist might help us understand if it is a general problem with the storage system or something more specific to Thunderbird.

(In reply to markfilipak.mozilla@gmail.com from comment #37)

Of course, the most probable cause is that some code is hardcoded to solely find profiles at
~/.thunderbird/<profilename>
and
~/.mozilla/firefox/<profilename>
-- thus, the code works for most users but fails for users with profiles in VBox shared folders. The most probable code is code that stores UI changes.

We have plenty of users (myself included) who run with their profile located in non-standard locations. If that was the only cause we'd see far more users reporting issues.

Using VBox shared folders, /media/sf_TBird_profile/ & /media/sf_FFox_profile/
When I make UI changes In either/both TBird & FFox,
1, UI changes do not survive restarting, and
2, xulstore.json.tmp exists but xulstore.json no longer exists.

(In reply to markfilipak.mozilla@gmail.com from comment #40)

Using VBox shared folders, /media/sf_TBird_profile/ & /media/sf_FFox_profile/
When I make UI changes In either/both TBird & FFox,
1, UI changes do not survive restarting, and
2, xulstore.json.tmp exists but xulstore.json no longer exists.

Ah now that is interesting. When writing out xulstore.json we first write out the xulstore.json.tmp file and then should rename it to the correct name. It seems like that last step is failing for some reason. Barret, do you have any idea what might be going on here?

Flags: needinfo?(brennie)

Contents:
Section 1: mark@mark-VirtualBox:/media/sf_TBird_profile/0ysydkep.default$ ls -l
Section 2: mark@mark-VirtualBox:/media/sf_FFox_profile/ckls0yge.default-release$ ls -l
Note that User: mark (that's me) is in Group: vboxsf.

mark@mark-VirtualBox:/media/sf_TBird_profile/0ysydkep.default$ ls -l
total 27791
-rwxrwx--- 1 root vboxsf 902 Sep 6 2016 0xCBCD72DA346F84A5_rev.asc
-rwxrwx--- 1 root vboxsf 19845 Jun 10 00:38 abook.mab
-rwxrwx--- 1 root vboxsf 262144 Jun 12 23:37 abook.sqlite
-rwxrwx--- 1 root vboxsf 0 Sep 8 17:26 abook.sqlite-wal
-rwxrwx--- 1 root vboxsf 6588 Sep 7 21:33 addons.json
-rwxrwx--- 1 root vboxsf 524288 Sep 6 2016 addons.sqlite
-rwxrwx--- 1 root vboxsf 3490 Jul 19 04:33 addonStartup.json.lz4
-rwxrwx--- 1 root vboxsf 1137 Sep 8 16:49 AlternateServices.txt
-rwxrwx--- 1 root vboxsf 524288 Mar 4 2021 blist.sqlite
-rwxrwx--- 1 root vboxsf 1225533 Nov 9 2020 blocklist-addons.json
-rwxrwx--- 1 root vboxsf 34379 May 26 22:12 blocklist-gfx.json
-rwxrwx--- 1 root vboxsf 139100 Oct 19 2020 blocklist-plugins.json
drwxrwx--- 1 root vboxsf 0 Nov 15 2018 blocklists
-rwxrwx--- 1 root vboxsf 970016 May 11 2021 blocklist.xml
drwxrwx--- 1 root vboxsf 0 Jun 23 23:00 browser-extension-data
drwxrwx--- 1 root vboxsf 0 Nov 20 2019 Cache
drwxrwx--- 1 root vboxsf 0 Sep 8 17:26 cache2
-rwxrwx--- 1 root vboxsf 1 May 19 2017 CACHE_CLEAN
drwxrwx--- 1 root vboxsf 0 Sep 8 17:26 calendar-data
-rwxrwx--- 1 root vboxsf 671744 Jun 21 22:36 cert8.db
-rwxrwx--- 1 root vboxsf 458752 Aug 24 13:28 cert9.db
-rwxrwx--- 1 root vboxsf 83 Sep 6 2016 cert_override.txt
-rwxrwx--- 1 root vboxsf 98304 Sep 6 2016 chromeappsstore.sqlite
drwxrwx--- 1 root vboxsf 8192 May 12 2021 chrome_debugger_profile
-rwxrwx--- 1 root vboxsf 163 Sep 2 15:21 compatibility.ini
-rwxrwx--- 1 root vboxsf 229376 Aug 18 23:53 content-prefs.sqlite
-rwxrwx--- 1 root vboxsf 524288 Jul 19 18:00 cookies.sqlite
-rwxrwx--- 1 root vboxsf 524288 Apr 17 2019 cookies.sqlite.bak
-rwxrwx--- 1 root vboxsf 524288 Sep 6 2016 cookies.sqlite.bak-rebuild
-rwxrwx--- 1 root vboxsf 32768 Jun 21 22:27 cookies.sqlite-shm
-rwxrwx--- 1 root vboxsf 0 Sep 8 17:26 cookies.sqlite-wal
drwxrwx--- 1 root vboxsf 0 Sep 8 17:27 crashes
drwxrwx--- 1 root vboxsf 4096 Sep 8 17:25 datareporting
-rwxrwx--- 1 root vboxsf 126 Aug 13 15:34 directoryTree.json
-rwxrwx--- 1 root vboxsf 98304 Jun 12 23:35 enigmail.sqlite
-rwxrwx--- 1 root vboxsf 563 Jun 25 05:11 extension-preferences.json
drwxrwx--- 1 root vboxsf 0 Jul 19 04:33 extensions
-rwxrwx--- 1 root vboxsf 162 Jun 21 22:26 extensions.ini
-rwxrwx--- 1 root vboxsf 35666 Sep 7 21:35 extensions.json
-rwxrwx--- 1 root vboxsf 1708 Sep 6 2016 extensions.log
-rwxrwx--- 1 root vboxsf 4522 Sep 6 2016 extensions.rdf
-rwxrwx--- 1 root vboxsf 458752 Sep 6 2016 extensions.sqlite
drwxrwx--- 1 root vboxsf 0 Sep 6 2016 ExternalMailFolders
-rwxrwx--- 1 root vboxsf 5242880 Jun 22 01:50 favicons.sqlite
-rwxrwx--- 1 root vboxsf 5242880 Jun 22 01:46 favicons.sqlite.corrupt
-rwxrwx--- 1 root vboxsf 32768 Jun 20 20:22 favicons.sqlite-shm
-rwxrwx--- 1 root vboxsf 163 Oct 11 2019 flexible-dentity.json
-rwxrwx--- 1 root vboxsf 9365 Sep 8 17:26 folderTree.json
-rwxrwx--- 1 root vboxsf 262144 Jun 20 15:02 formhistory.sqlite
-rwxrwx--- 1 root vboxsf 1245184 Jul 5 23:35 global-messages-db.sqlite
drwxrwx--- 1 root vboxsf 0 Dec 21 2018 gmp
-rwxrwx--- 1 root vboxsf 460 Sep 5 15:47 handlers.json
-rwxrwx--- 1 root vboxsf 2378 Oct 16 2019 history.mab
-rwxrwx--- 1 root vboxsf 262144 Jun 12 23:37 history.sqlite
-rwxrwx--- 1 root vboxsf 0 Sep 8 17:26 history.sqlite-wal
drwxrwx--- 1 root vboxsf 4096 Jun 30 2018 ImapMail
-rwxrwx--- 1 root vboxsf 717 Sep 6 2016 indexfile.txt
-rwxrwx--- 1 root vboxsf 16384 Jun 21 22:36 key3.db
-rwxrwx--- 1 root vboxsf 294912 Oct 15 2018 key4.db
-rwxrwx--- 1 root vboxsf 2752512 May 26 22:12 kinto.sqlite
-rwxrwx--- 1 root vboxsf 65507 Sep 6 2016 localstore.rdf
-rwxrwx--- 1 root vboxsf 2152 Sep 6 2016 localstore-safe.rdf
-rwxrwx--- 1 root vboxsf 106905 Aug 29 17:23 logins-backup.json
-rwxrwx--- 1 root vboxsf 107572 Aug 29 17:23 logins.json
drwxrwx--- 1 root vboxsf 0 Sep 16 2020 logs
drwxrwx--- 1 root vboxsf 20480 Nov 20 2019 Mail
-rwxrwx--- 1 root vboxsf 504 Sep 6 2016 mailViews.dat
-rwxrwx--- 1 root vboxsf 5660 May 28 21:23 mimeTypes.rdf
drwxrwx--- 1 root vboxsf 8192 Jul 20 2018 minidumps
drwxrwx--- 1 root vboxsf 8192 Nov 20 2019 News
-rwxrwx--- 1 root vboxsf 229376 Jun 12 23:35 openpgp.sqlite
-rwxrwx--- 1 root vboxsf 205791 Sep 8 17:37 panacea.dat
-rwxrwx--- 1 root vboxsf 0 Nov 17 2018 parent.lock
-rwxrwx--- 1 root vboxsf 196608 Sep 8 16:45 permissions.sqlite
-rwxrwx--- 1 root vboxsf 819 Aug 23 17:05 persdict.dat
-rwxrwx--- 1 root vboxsf 456 Jun 18 19:41 pkcs11.txt
-rwxrwx--- 1 root vboxsf 1343488 Aug 24 23:17 places.sqlite
-rwxrwx--- 1 root vboxsf 32768 Jun 20 20:10 places.sqlite.corrupt-shm
-rwxrwx--- 1 root vboxsf 32768 Jun 21 22:29 places.sqlite-shm
-rwxrwx--- 1 root vboxsf 179 Jun 20 20:39 pluginreg.dat
-rwxrwx--- 1 root vboxsf 141855 Apr 6 2018 prefs-1.js
-rwxrwx--- 1 root vboxsf 28672 Apr 16 2018 prefs-2.js
-rwxrwx--- 1 root vboxsf 144131 Nov 16 2018 prefs-3.js
-rwxrwx--- 1 root vboxsf 148827 Sep 22 2019 prefs-4.js
-rwxrwx--- 1 root vboxsf 173021 Sep 8 17:37 prefs.js
-rwxrwx--- 1 root vboxsf 149882 May 12 2017 prefs.js.bak
-rwxrwx--- 1 root vboxsf 150058 May 10 2017 prefs-save-1.js
-rwxrwx--- 1 root vboxsf 150029 May 10 2017 prefs-save-2.js
-rwxrwx--- 1 root vboxsf 131867 May 13 2017 prefs-save-3.js
-rwxrwx--- 1 root vboxsf 10860 Apr 25 2017 revocations-1.txt
drwxrwx--- 1 root vboxsf 0 Dec 21 2018 safebrowsing
drwxrwx--- 1 root vboxsf 8192 Sep 1 09:00 saved-telemetry-pings
-rwxrwx--- 1 root vboxsf 17134 Sep 6 2016 search.json
-rwxrwx--- 1 root vboxsf 268 Sep 8 17:26 search.json.mozlz4
-rwxrwx--- 1 root vboxsf 2 Sep 6 2016 search-metadata.json
-rwxrwx--- 1 root vboxsf 65536 Sep 6 2016 search.sqlite
-rwxrwx--- 1 root vboxsf 131072 Jun 18 23:36 secmod.db
-rwxrwx--- 1 root vboxsf 0 Jun 21 22:36 SecurityPreloadState.txt
drwxrwx--- 1 root vboxsf 0 Jun 12 23:36 security_state
-rwxrwx--- 1 root vboxsf 53 Sep 8 17:26 sessionCheckpoints.json
-rwxrwx--- 1 root vboxsf 379 Sep 6 2016 session_error_20150909233352233.json
-rwxrwx--- 1 root vboxsf 255 Sep 22 2019 session_error_20190923020422626.json
-rwxrwx--- 1 root vboxsf 394 Sep 8 16:54 session.json.backup
-rwxrwx--- 1 root vboxsf 380 Sep 8 17:31 session.json.tmp
-rwxrwx--- 1 root vboxsf 3732 Sep 7 21:35 SiteSecurityServiceState.txt
drwxrwx--- 1 root vboxsf 0 Sep 2 17:10 startupCache
drwxrwx--- 1 root vboxsf 0 Jun 13 10:42 storage
-rwxrwx--- 1 root vboxsf 3072 Sep 6 2016 storage.sdb
-rwxrwx--- 1 root vboxsf 4096 Sep 7 19:41 storage.sqlite
-rwxrwx--- 1 root vboxsf 4 Jun 20 10:41 Telemetry.ShutdownTime.txt
-rwxrwx--- 1 root vboxsf 26213 May 13 2017 'temp working.txt'
-rwxrwx--- 1 root vboxsf 26212 May 12 2017 'temp working.txt.bak'
-rwxrwx--- 1 root vboxsf 953947 Sep 6 2016 TestPilotErrorLog.log
drwxrwx--- 1 root vboxsf 4096 Sep 6 2016 TestPilotExperimentFiles
-rwxrwx--- 1 root vboxsf 98304 Sep 6 2016 testpilot_week_in_the_life_results.sqlite
-rwxrwx--- 1 root vboxsf 25 Sep 6 2016 times.json
-rwxrwx--- 1 root vboxsf 53999 Sep 6 2016 training.dat
-rwxrwx--- 1 root vboxsf 8 Sep 6 2016 traits.dat
-rwxrwx--- 1 root vboxsf 0 Sep 6 2016 urlclassifier2.sqlite
-rwxrwx--- 1 root vboxsf 0 Sep 6 2016 virtualFolders-1.dat
-rwxrwx--- 1 root vboxsf 0 Sep 6 2016 virtualFolders-2.dat
-rwxrwx--- 1 root vboxsf 5590 Sep 8 17:26 virtualFolders.dat
-rwxrwx--- 1 root vboxsf 110504 Jun 12 23:27 virtualIdentity.rdf
-rwxrwx--- 1 root vboxsf 98304 Jun 20 20:48 webappsstore.sqlite
-rwxrwx--- 1 root vboxsf 32768 Jun 20 20:42 webappsstore.sqlite-shm
-rwxrwx--- 1 root vboxsf 0 Sep 8 17:26 webappsstore.sqlite-wal
-rwxrwx--- 1 root vboxsf 5056 May 13 2017 'what I did.txt'
-rwxrwx--- 1 root vboxsf 3402 May 13 2017 'what I did.txt.bak'
-rwxrwx--- 1 root vboxsf 3688 Sep 8 16:54 'xulstore (copy).json'
-rwxrwx--- 1 root vboxsf 1709 Sep 8 17:26 xulstore.json.tmp

mark@mark-VirtualBox:/media/sf_FFox_profile/ckls0yge.default-release$ ls -l
total 30349
-rwxrwx--- 1 root vboxsf 212999 Jul 6 19:44 activity-stream.discovery_stream.json
-rwxrwx--- 1 root vboxsf 3569 Sep 8 17:30 addons.json
-rwxrwx--- 1 root vboxsf 7912 Sep 8 17:30 addonStartup.json.lz4
-rwxrwx--- 1 root vboxsf 230127 Sep 8 17:28 AlternateServices.txt
drwxrwx--- 1 root vboxsf 8192 Sep 8 11:48 bookmarkbackups
-rwxrwx--- 1 root vboxsf 216 Sep 8 17:37 broadcast-listeners.json
drwxrwx--- 1 root vboxsf 4096 Sep 8 17:30 cache2
-rwxrwx--- 1 root vboxsf 65536 Feb 17 2018 cert8.db
-rwxrwx--- 1 root vboxsf 917504 Jul 13 12:07 cert9.db
-rwxrwx--- 1 root vboxsf 513 Dec 21 2020 cert_override.txt
drwxrwx--- 1 root vboxsf 0 Jul 5 21:36 chrome
-rwxrwx--- 1 root vboxsf 163 Sep 7 17:10 compatibility.ini
-rwxrwx--- 1 root vboxsf 939 Jun 25 12:56 containers.json
-rwxrwx--- 1 root vboxsf 229376 Sep 7 23:06 content-prefs.sqlite
-rwxrwx--- 1 root vboxsf 2097152 Sep 8 17:27 cookies.sqlite
-rwxrwx--- 1 root vboxsf 459120 Sep 8 17:37 cookies.sqlite-wal
drwxrwx--- 1 root vboxsf 0 Sep 8 17:31 crashes
drwxrwx--- 1 root vboxsf 4096 Sep 8 17:28 datareporting
-rwxrwx--- 1 root vboxsf 811 Jun 25 18:07 ExperimentStoreData.json
-rwxrwx--- 1 root vboxsf 1824 Jun 25 22:17 extension-preferences.json
drwxrwx--- 1 root vboxsf 4096 Sep 5 21:22 extensions
-rwxrwx--- 1 root vboxsf 63644 Sep 8 16:48 extensions.json
-rwxrwx--- 1 root vboxsf 6619136 Sep 8 17:30 favicons.sqlite
-rwxrwx--- 1 root vboxsf 196784 Sep 8 17:37 favicons.sqlite-wal
-rwxrwx--- 1 root vboxsf 327680 Sep 8 11:21 formhistory.sqlite
drwxrwx--- 1 root vboxsf 0 Jun 27 03:51 gmp-gmpopenh264
drwxrwx--- 1 root vboxsf 0 Jul 1 22:15 gmp-widevinecdm
-rwxrwx--- 1 root vboxsf 365 Aug 31 11:57 handlers.json
-rwxrwx--- 1 root vboxsf 16384 Feb 17 2018 key3.db
-rwxrwx--- 1 root vboxsf 294912 Jul 14 2020 key4.db
-rwxrwx--- 1 root vboxsf 230141 Sep 7 14:53 logins-backup.json
-rwxrwx--- 1 root vboxsf 230141 Sep 7 16:34 logins.json
drwxrwx--- 1 root vboxsf 0 Jun 25 12:56 minidumps
-rwxrwx--- 1 root vboxsf 471 Sep 7 17:10 notificationstore.json
-rwxrwx--- 1 root vboxsf 98304 Sep 8 16:57 permissions.sqlite
drwxrwx--- 1 root vboxsf 8192 Jun 25 18:30 personality-provider
-rwxrwx--- 1 root vboxsf 476 Jun 25 12:56 pkcs11.txt
-rwxrwx--- 1 root vboxsf 15728640 Sep 8 17:30 places.sqlite
-rwxrwx--- 1 root vboxsf 360744 Sep 8 17:31 places.sqlite-wal
-rwxrwx--- 1 root vboxsf 28554 Jun 28 18:10 prefs-1.js
-rwxrwx--- 1 root vboxsf 28554 Jun 28 18:10 prefs-2.js
-rwxrwx--- 1 root vboxsf 29078 Jul 7 16:54 prefs-3.js
-rwxrwx--- 1 root vboxsf 0 Jul 21 02:56 prefs-4.js
-rwxrwx--- 1 root vboxsf 31602 Sep 8 17:37 prefs.js
-rwxrwx--- 1 root vboxsf 65536 Sep 8 17:30 protections.sqlite
drwxrwx--- 1 root vboxsf 20480 Sep 8 17:27 safebrowsing
drwxrwx--- 1 root vboxsf 20480 Sep 8 17:27 safebrowsing-updating
drwxrwx--- 1 root vboxsf 4096 Sep 8 17:31 saved-telemetry-pings
-rwxrwx--- 1 root vboxsf 3456 Sep 8 17:30 search.json.mozlz4
drwxrwx--- 1 root vboxsf 0 Jun 25 20:04 security_state
-rwxrwx--- 1 root vboxsf 6492 Sep 8 16:48 serviceworker.txt
-rwxrwx--- 1 root vboxsf 90 Sep 8 17:30 sessionCheckpoints.json
drwxrwx--- 1 root vboxsf 4096 Sep 8 17:38 sessionstore-backups
drwxrwx--- 1 root vboxsf 0 Jun 25 18:15 settings
-rwxrwx--- 1 root vboxsf 18 Jun 25 12:56 shield-preference-experiments.json
-rwxrwx--- 1 root vboxsf 38741 Sep 8 17:40 SiteSecurityServiceState.txt
drwxrwx--- 1 root vboxsf 4096 Sep 8 17:31 startupCache
drwxrwx--- 1 root vboxsf 4096 Jun 25 12:56 storage
-rwxrwx--- 1 root vboxsf 56320 Sep 8 17:30 storage.sqlite
drwxrwx--- 1 root vboxsf 0 Sep 8 12:29 thumbnails
-rwxrwx--- 1 root vboxsf 50 Jun 25 12:56 times.json
drwxrwx--- 1 root vboxsf 0 Jun 25 19:00 weave
-rwxrwx--- 1 root vboxsf 2097152 Jul 13 11:29 webappsstore.sqlite
-rwxrwx--- 1 root vboxsf 1547 Sep 8 16:52 'xulstore (copy).json'
-rwxrwx--- 1 root vboxsf 83 Sep 8 17:31 xulstore.json.tmp

Why are all the files owned by root rather than mark? What are the permissions on the directories themselves?

(In reply to Dave Townsend [:mossop] from comment #41)
[snip]

Ah now that is interesting. When writing out xulstore.json we first write out the xulstore.json.tmp file and then should rename it to the correct name. It seems like that last step is failing for some reason. Barret, do you have any idea what might be going on here?

XULStore was migrated to IOUtils on July 28th, 4 weeks after this bug was filed, so its likely not the root cause of the failure. However, its weird that xulstore.json no longer exists, but the tmp file is there.

xulstore.json is written here which ends up in IOUtils::WriteSync eventually.

tmpFile is specified so we write to xulstore.json.tmp (1)

Then we move overrwrite xulstore.json (2). If this fails it should throw an error that would be visible in the browser console (3).

The overwriting on *nix is done with rename(2) (4) falling back to copy and delete if they are on separate devices, but they are in the same directory so that shouldn't be an issue.

:markfilipak, if you open the browser console, do you see any errors that look like:

Could not move temporary file(/path/to/profile/xul.store.tmp) to destination(/path/to/profile/xul.store)

We unfortunately don't keep the original error code there and ovewrite it with NS_ERROR_FILE_COPY_OR_MOVE_FAILED / DOMException OperationError

Flags: needinfo?(brennie) → needinfo?(markfilipak.mozilla)

:markfilipak, if you open the browser console, do you see any errors that look like:

Could not move temporary file(/path/to/profile/xul.store.tmp) to destination(/path/to/profile/xul.store)

We unfortunately don't keep the original error code there and ovewrite it with NS_ERROR_FILE_COPY_OR_MOVE_FAILED / DOMException OperationError

Is there a log file where that would appear, or do I have to reconfigure again and run TBird/FFox to test for it? I have all 6 profiles: (TBird v. FFox) x (home root v. shared folders v. virtual USBs) and I've preserved each of them, so if there's a log file, then it still exists and I can read it.

Flags: needinfo?(markfilipak.mozilla)

You would have to run Firefox and open the browser console. Set devtools.chrome.enabled to true and then open it via Hamburger Menu -> More Tools -> Browser Toolbox (docs)

(In reply to Barret Rennie [:barret] (they/them) from comment #46)

You would have to run Firefox and open the browser console. Set devtools.chrome.enabled to true and then open it via Hamburger Menu -> More Tools -> Browser Toolbox (docs)

??

Is the important file xulstore.json or xul.store? I'm getting confused.

Is there a log file in the 'bad' profile that in which xul...whatever resides that I can look at without having to reconfigure once again?

(In reply to markfilipak.mozilla@gmail.com from comment #47)

Is the important file xulstore.json or xul.store? I'm getting confused.

I think that was a mistake on Barret's part. It is xulstore.json.

Is there a log file in the 'bad' profile that in which xul...whatever resides that I can look at without having to reconfigure once again?

No there isn't.

Okay, I'll reconfigure once again and try to see/capture some sort of browser console output. I'd like to make the effort as fruitful as possible, as I'm sure you do, also. I have questions.

Suppose the problem is only when TBird & FFox are quit -- I'm pretty sure that is correct. How can I be running a console at the time? How can the console survive the quitting? I don't see how that's possible.

No log file, and no user-facing error notice, either, eh? That's unfortunate.

Barret suggests, "You would have to run Firefox and open the browser console. Set devtools.chrome.enabled to true and then open it via Hamburger Menu -> More Tools -> Browser Toolbox".

I'd like to rehearse it with TBird right now, but I see no way to submit "about:config" in order to enable the TBird equivalent of Brower Toolbox. I see these:

Important Modified Preferences
Name Value
browser.cache.disk.amount_written 0
browser.cache.disk.capacity 0
browser.cache.disk.filesystem_reported 1
browser.cache.disk.hashstats_reported 1
browser.cache.disk.smart_size_cached_value 358400
browser.cache.disk.smart_size.enabled false
browser.cache.disk.smart_size.first_run false
browser.cache.disk.smart_size.use_old_max false
browser.display.auto_quality_min_font_size 14
browser.display.use_document_fonts 14
browser.fixup.alternate.enabled false
browser.search.region US

But I don't find a way to submit "about:config" in order to "Set devtools.chrome.enabled to true". I would think that the way to enable devtools is via a argument to 'thunderbird %U' on launch.

I will try reheasing in FFox (instead of in TBird) right now, but I can't be writing in this comment at the time, so I'll close this now and try to rehease Barret's procedure.

Please stand by...

Okay. I just tried to rehease Barret's procedure. I failed.

I set devtools.chrome.enabled to 'true' and tried Hamburger Menu -> More Tools -> Browser Toolbox. "Browser Toolbox" is grayed out and will not 'select'.

Now what?

A THOUGHT:

I currently have both
virtual USBs: '/media/mark/FFox profile/' & '/media/mark/TBird profile/' -- no issues -- and
shared folders: '/media/sf_FFox_profile/' & '/media/sf_TBird_profile/' -- provokes this bug --
at the same time.

I notice that:
the contents of a virtual USB is Owner: mark, Group: vboxsf, and
the contents of a shared folder is Owner: root, Group: vboxsf <-- mark is a member of vboxsf.

Since shared folders is where the problem lies, is TBird/FFox doing something 'wrong'/'different' while attempting to rename/rewrite xulstore.json.tmp to xulstore.json when Owner==root and Group==vboxsf? Something having to do with ownership v. group privilages?

Perhaps when they try the xulstore.json.tmp renaming, TBird & FFox are trying to do it as 'owner' instead of using my (mark) credentials?

Scratch that last suggestion. It doesn't really make sense.

I've finally managed to reproduce at least some UI persistence problems. And the good news is that those issues are fixed in the current 105 betas. I suspect that it was fixed by bug 1772940. I've been unable to spot issues saving logins or noticed any other problems. Mark at this point I'd suggest testing with 105 builds (it moves to release next week if you don't want to try betas) and reporting back on whether you still see problems and if so specific steps to reproduce the issue.

Flags: needinfo?(markfilipak.mozilla)

(In reply to Dave Townsend [:mossop] from comment #54)

I've finally managed to reproduce at least some UI persistence problems. And the good news is that those issues are fixed in the current 105 betas. I suspect that it was fixed by bug 1772940. I've been unable to spot issues saving logins or noticed any other problems.

I'd like to clarify. Ordinary password logins are not involved in this issue. The storage and persistence of Oauth2 tokens are involved in this issue.

Mark at this point I'd suggest testing with 105 builds (it moves to release next week if you don't want to try betas) and reporting back on whether you still see problems and if so specific steps to reproduce the issue.

Hearty congratulations for your successes. I run Linux Mint:
Kernel: 5.4.0-125-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 Desktop: MATE 1.26.0 wm: marco dm: LightDM Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal
I don't know how to test 105 builds.

Flags: needinfo?(markfilipak.mozilla)

(In reply to markfilipak.mozilla@gmail.com from comment #55)

(In reply to Dave Townsend [:mossop] from comment #54)

I've finally managed to reproduce at least some UI persistence problems. And the good news is that those issues are fixed in the current 105 betas. I suspect that it was fixed by bug 1772940. I've been unable to spot issues saving logins or noticed any other problems.

I'd like to clarify. Ordinary password logins are not involved in this issue. The storage and persistence of Oauth2 tokens are involved in this issue.

Yes however Oauth2 tokens are stored in the same storage system as passwords so if the storage systems is at fault (which would seem likely) then passwords should be affected as well. If they aren't it would probably make sense to file a new Thunderbird bug on the issues with Oauth2 tokens as the problem is likely to be Thunderbird specific and not related to the UI persistence problems.

Mark at this point I'd suggest testing with 105 builds (it moves to release next week if you don't want to try betas) and reporting back on whether you still see problems and if so specific steps to reproduce the issue.

Hearty congratulations for your successes. I run Linux Mint:
Kernel: 5.4.0-125-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 Desktop: MATE 1.26.0 wm: marco dm: LightDM Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal
I don't know how to test 105 builds.

I don't know anything about Linux Mint but presumably they will pick up 105 when it moves to release next week. You could also download the beta builds from here https://www.mozilla.org/en-US/firefox/channel/desktop/ if you wanted to try sooner.

Flags: needinfo?(markfilipak.mozilla)

Well, Dave, I'm going to need more help because what you wrote doesn't make sense to me.

(In reply to Dave Townsend [:mossop] from comment #56)

(In reply to markfilipak.mozilla@gmail.com from comment #55)

(In reply to Dave Townsend [:mossop] from comment #54)

I've finally managed to reproduce at least some UI persistence problems. And the good news is that those issues are fixed in the current 105 betas. I suspect that it was fixed by bug 1772940. I've been unable to spot issues saving logins or noticed any other problems.

I'd like to clarify. Ordinary password logins are not involved in this issue. The storage and persistence of Oauth2 tokens are involved in this issue.

Yes however Oauth2 tokens are stored in the same storage system as passwords so if the storage systems is at fault (which would seem likely) then passwords should be affected as well.

They're not.

If they aren't it would probably make sense to file a new Thunderbird bug on the issues with Oauth2 tokens as the problem is likely to be Thunderbird specific and not related to the UI persistence problems.

Using VBox shared folders for profiles, I experience both Oauth2 & UI persistence problems, both TBird & FFox. Using VBox virtual USBs for profiles, I experience no problems. Perhaps you can explain to me how that is solely a TBird problem worthy of additional bug report. Now, when v.105 arrives, if it fixes the UI problems in both TBird & FFox with profiles in VBox shared folders -- thought I sincerely doubt that 105 will fix them -- then, if Oauth2 tokens remain the only problem, then I will submit a bug report on it of course.

Flags: needinfo?(markfilipak.mozilla)

(In reply to markfilipak.mozilla@gmail.com from comment #57)

Well, Dave, I'm going to need more help because what you wrote doesn't make sense to me.

(In reply to Dave Townsend [:mossop] from comment #56)

(In reply to markfilipak.mozilla@gmail.com from comment #55)

(In reply to Dave Townsend [:mossop] from comment #54)

I've finally managed to reproduce at least some UI persistence problems. And the good news is that those issues are fixed in the current 105 betas. I suspect that it was fixed by bug 1772940. I've been unable to spot issues saving logins or noticed any other problems.

I'd like to clarify. Ordinary password logins are not involved in this issue. The storage and persistence of Oauth2 tokens are involved in this issue.

Yes however Oauth2 tokens are stored in the same storage system as passwords so if the storage systems is at fault (which would seem likely) then passwords should be affected as well.

They're not.

If they aren't it would probably make sense to file a new Thunderbird bug on the issues with Oauth2 tokens as the problem is likely to be Thunderbird specific and not related to the UI persistence problems.

Using VBox shared folders for profiles, I experience both Oauth2 & UI persistence problems, both TBird & FFox. Using VBox virtual USBs for profiles, I experience no problems. Perhaps you can explain to me how that is solely a TBird problem worthy of additional bug report. Now, when v.105 arrives, if it fixes the UI problems in both TBird & FFox with profiles in VBox shared folders -- thought I sincerely doubt that 105 will fix them -- then, if Oauth2 tokens remain the only problem, then I will submit a bug report on it of course.

Ok. Please report back when you have tested with 105. As I say I could reproduce problems with 104 that went away with 105 so either you will see an improvement or we are seeing different problems.

Flags: needinfo?(markfilipak.mozilla)

Do you know how versions of TBird & FFox are linked?

Here's what I currently have:
TBird 91.11.0
FFox 104.0.2

To the best of my knowledge, FFox doesn't use Oauth2 tokens. Is that correct?

I will test UI change persistence in v.105 when FFox update reaches that point and come back here.

Greetings.

Flags: needinfo?(markfilipak.mozilla)

(In reply to markfilipak.mozilla@gmail.com from comment #59)

Do you know how versions of TBird & FFox are linked?

Here's what I currently have:
TBird 91.11.0
FFox 104.0.2

Ah right. Thunderbird releases only track Firefox ESR releases, so it would be nearly a year before an official Thunderbird release comes out with the fix. Thunderbird 105 betas are available currently: https://www.thunderbird.net/en-US/download/beta/

To the best of my knowledge, FFox doesn't use Oauth2 tokens. Is that correct?

Correct.

I suggest reopen if this fails TB 105 or 06 beta.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE

FFox Version 105.0 (64-bit) with profile in VBox shared directory.
Some things are fixed. Some are not.
If I open a link in a new window and use 'Quit' in that window, the new window survives a restart.
However, If I open a link in a new window and use 'Quit' in a different window, the new window does not survive a restart.

Note: I could not find a way to reopen this issue.

Oh, sorry -- no way to add to the previous comment -- xulstore.json is now being update okay.

Sorry again. What I should have written is that xulstore.json.tmp is being renamed xulstore.json, but obviously xulstore.json is not being updated correctly because the new window is not surviving a restart as described in comment 62.

(In reply to markfilipak.mozilla@gmail.com from comment #62)

FFox Version 105.0 (64-bit) with profile in VBox shared directory.
Some things are fixed. Some are not.
If I open a link in a new window and use 'Quit' in that window, the new window survives a restart.
However, If I open a link in a new window and use 'Quit' in a different window, the new window does not survive a restart.

Ok that is something that wouldn't be stored in xulstore.json. reopening previous windows is a part of the session storage. Do you have restoring windows after quitting enabled? Either way I think it would be best to file a new bug for this issue, pretty much none of the previous discussion in this bug is relevant to it.

"Do you have restoring windows after quitting enabled?"
Yes.
I've filed this: https://bugzilla.mozilla.org/show_bug.cgi?id=1792371

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

Attachment

General

Creator:
Created:
Updated:
Size: