Firefox updates require me to recustomize some of my settings
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: shopper, Unassigned, NeedInfo)
References
Details
(Whiteboard: QA-not-reproducible)
Attachments
(1 file)
2.29 KB,
application/json
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Steps to reproduce:
Update firefox
Actual results:
Under "Applications" in (General) Settings the action for the content type "pdf" had again! reverted to Save File.
Expected results:
The setting should have remained unchanged: "Use Adobe Acrobat Reader DC." This is not a one-off. This has happened every time I've updated the last few times (I can't say exactly how many) times I've updated firefox
I don't routinely check for my settings to remain unchanged after I upgrade FireFox, because it hasn't been a problem in the past. I don't know how many of my other settings are getting reset like that. And, given my description, I'm aware that this is not a high-priority bug. It's just extremely annoying.
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Preferences' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
The severity field is not set for this bug.
:jaws, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 4•3 years ago
|
||
Hello! I have tried to reproduce the issue using firefox 103.0a1(2022-06-01) updated to 104.0a1(2022-07-20) and 101.0 updated to 102.0.1 on Windows 10 but unfortunately I wasn't able to reproduce the issue.
I will add the QA-not-reproducible tag for the moment since I can't reproduce the issue on my end, but I will try with another machine to see if it's reproducible.
Thank you!
Comment 5•3 years ago
|
||
Since Negritas was unable to reproduce this, I'm going to close this as "works for me". @shopper, can you please report back here after the next update if this does/doesn't happen again?
This did not happen with the latest update (version 103.0.1). I will keep a lookout for the same issue in the next few updates and report if it happens again. Thanks for looking into this, even if you couldn't reproduce it.
Comment 7•3 years ago
|
||
Great, thanks for the reply.
This happened again with the latest update 103.0.2. I can't seem to find the email that I'm supposed to reply to if this bug did show up again, but it did. When I did this update the action reverted to "Save File" for PDFs, when I have repeatedly (in all previous updates) set it to "Use Windows default application." I'm glad that it works for you, but it obviously isn't working for me. What can I do to help you find what's wrong here?
It happened again with the latest update 104.0.1. I'm going to open a new bug since nobody seems to be following these comments.
Comment 11•3 years ago
|
||
Hello Shopper there is no need to open a new bug for this issue. I will reopen it for you and sorry for the long reply time.
Thank you!
Updated•3 years ago
|
Comment 12•3 years ago
|
||
(In reply to shopper from comment #8)
This happened again with the latest update 103.0.2. I can't seem to find the email that I'm supposed to reply to if this bug did show up again, but it did. When I did this update the action reverted to "Save File" for PDFs, when I have repeatedly (in all previous updates) set it to "Use Windows default application." I'm glad that it works for you, but it obviously isn't working for me. What can I do to help you find what's wrong here?
What is the Windows default application for PDFs on your system?
Can you attach your handlers.json file (from inside your profile directory)?
If you restart Firefox without updating (e.g. by going to about:profiles
in the address bar and then clicking the "restart normally" button on the right hand side) and reopen the Firefox settings, does the setting revert then, or really only on updates? I'm asking because updates themselves generally do not touch files in your profiles.
Reporter | ||
Comment 14•3 years ago
|
||
After reading your comment, it dawned on me that I only do updates immediately before a reboot (I don't reboot very often). So I did two things. First I rebooted without doing an update, just to see if the reboot itself was the issue. Apparently it isn't; the action for PDFs remained "Use Windows default application." Next, I did as you suggested: restarted normally from about:profiles. (I didn't know I could do that. Thanks!). The restart wasn't the issue (I didn't think it was; I have restarted FireFox without a reboot in between with no problem), the action remained as it had been set.
The default application for PDFs is Adobe Acrobat Reader. And one more data point, there are currently only five content types I can choose an action for: avif, pdf, svg, xml, and WebP Image. There used to be many, and I don't remember how long ago that changed. That does point to a corrupted file somewhere, doesn't it?
As requested, I have attached handlers.json above.
Comment 15•3 years ago
|
||
(In reply to shopper from comment #14)
The default application for PDFs is Adobe Acrobat Reader. And one more data point, there are currently only five content types I can choose an action for: avif, pdf, svg, xml, and WebP Image. There used to be many, and I don't remember how long ago that changed. That does point to a corrupted file somewhere, doesn't it?
Yep. Are there similarly named handlers.json files with a .corrupt
suffix in the same directory, that correspond roughly in time with when you updated? (if you search the settings for "update" you can find a button that says "show update history" that has times for when updates got applied)
Comment 16•3 years ago
|
||
It seems this bug got stuck trying to get more diagnostic info; we can reopen it if we can narrow this down further with answers to the needinfo request in comment #15.
Reporter | ||
Comment 17•3 years ago
|
||
I apologize for not getting back to you with the info you requested. I never got a notification that there was a comment and I thought that it was just taking you awhile to look into this. And on another note, I am going to be away from my PC starting tomorrow thru Sunday; I'll be back Monday.
I looked in my profile directory and there was only one file with a .corrupt suffix: places.sqlite.corrupt. The date on that file is 12/27/2017. The update history only goes back to May, 2022. I'm sure the issue has been there since before May, but it definitely wasn't there in 2017.
Comment 18•3 years ago
|
||
(In reply to shopper from comment #17)
I apologize for not getting back to you with the info you requested.
No worries, we've taken a long time to try to get anywhere with this bug ourselves. Our rule of thumb is that if it's been 2 weeks since we heard anything, that's unlikely to change.
I looked in my profile directory and there was only one file with a .corrupt suffix: places.sqlite.corrupt. The date on that file is 12/27/2017. The update history only goes back to May, 2022. I'm sure the issue has been there since before May, but it definitely wasn't there in 2017.
Hm. So this is surprising. I'll do some more digging with the file you attached to see if I can get to the bottom of it.
Comment 19•3 years ago
|
||
Struggling to find some time here, gonna needinfo myself to make sure I don't lose track.
Reporter | ||
Comment 20•3 years ago
|
||
I don't know what I'm supposed to do with that last comment. Do you need something from me? If so, what?
Comment 21•3 years ago
|
||
(In reply to shopper from comment #20)
I don't know what I'm supposed to do with that last comment. Do you need something from me? If so, what?
No, nothing right now - I will comment if there's something else I'm missing. I just need to find time to come back to this, but I've got a lot on at the moment so it hasn't happened yet. Sorry for the confusion.
Updated•3 years ago
|
Comment 22•2 years ago
|
||
So I'm still pretty lost here.
There is some code that would explain these changes. It lives here: https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/uriloader/exthandler/ExtHandlerService.sys.mjs#369 .
Basically what it does is it checks an internal feature flag that was added around the Firefox 98 timeframe (browser.download.improvements_to_download_panel
). If true (the default), it checks if your handlers.json file has the isDownloadsImprovementsAlreadyMigrated
property. Your file does not have this. As a result, the migration will run. That migration would make a number of changes (once!) for compatibility reasons (long story) that could potentially explain this, and then set that flag (isDownloadsImprovementsAlreadyMigrated
). That flag will then prevent the migration from being run again.
Somehow, on your machine, this migration is running every time you update (at least, I think that's what it is). What I don't understand is why, unless we're somehow not able to save to that JSON file at all. But then I'd expect the same problem for a "normal" restart... we'd lose any in-memory changes and re-read from disk.
Some questions to try to get more to the bottom of this:
If you make changes to any file's settings in about:preferences, does the handlers.json
file change on disk?
Do you use the builtin Firefox update system to update? Is your handlers.json
file marked "read only" on the file system?
Comment 23•2 years ago
|
||
I'm going to close this out as we haven't been able to get to the bottom of why this issue occurs - we can reopen if more details become available - but fundamentally I think this is going to go away when we fix bug 1822864.
Description
•