General Settings Page empty after deleting URL in app.update.url.manual
Categories
(Toolkit :: Application Update, defect)
Tracking
()
People
(Reporter: zaza484-lotro, Assigned: nrishel)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
Steps to reproduce:
Normally i customize firefox by editing firefox-branding.js in every build. This worked for years until now that Firefox 97 is the first version that makes problems.
Normally i delete URL for option app.update.url.manual
Standard:
pref("app.update.url.manual", "https://www.mozilla.org/%LOCALE%/firefox/new?reason=manual-update");
Modified:
pref("app.update.url.manual", "");
There are other modifications also done in firefox-branding.js but this one is the setting that breaks stuff.
You can also test this by deleting the url in the app.update.url.manual option in about:config directly in firefox and then restarting firefox.
Actual results:
Help -> About Firefox
No Update Check happening, Option is missing / not displaying
Settings -> General
Page General is completely empty, no Settings are shown.
Pages Homne, Search, Privacy & Security working normal.
Expected results:
Help -> About Firefox
"Checking for updates" should be displayed and then showing the information "Firefox is up to date" or that an Update is required.
Settings -> General
Page General should show settings.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
(In reply to Tynth from comment #0)
Normally i delete URL for option app.update.url.manual
Why do you want to be able to do this? I can't think of any reason to. It seems like the only real change this would cause is to break the link that Firefox shows you if an update fails. But if you don't want to use the link, can't you just not click on it? Why is it necessary to break it?
It's kind of inevitable that if you screw up your prefs enough, it will break things. And I would consider removing the manual update URL to be a form of screwing up your prefs.
Assignee | ||
Comment 3•3 years ago
|
||
I know what's causing this; it's a trivial fix so I'll go ahead and handle it.
Thanks for reporting this Tynth. Definitely still curious why you go through the hassle of modifying these prefs. :)
Assignee | ||
Comment 4•3 years ago
|
||
Comment 6•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Nick, this is a recent regression would that be a good candidate for uplifting in our last betas or should it bake more and ship with 99? Thanks
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 8•3 years ago
|
||
Pascal, the fix is straightforward and low risk. We also assumed it's rare to trigger; there's no obvious reason people would be playing with this config. If this is being triggered more than we assumed it may be a good candidate for uplifting, but I was assuming it didn't make sense to give this extra attention.
Comment 9•3 years ago
|
||
(In reply to Nick Rishel [:nrishel] from comment #8)
Pascal, the fix is straightforward and low risk. We also assumed it's rare to trigger; there's no obvious reason people would be playing with this config. If this is being triggered more than we assumed it may be a good candidate for uplifting, but I was assuming it didn't make sense to give this extra attention.
Sorry, I should have highlighted this when I set flags - this came up a second time in bug 1756450, so apparently this isn't as isolated as we might want/assume/think reasonable. I don't really know why - perhaps some misguided tutorial on the web suggests changing this update URL. A quick google finds at least https://www.reddit.com/r/firefox/comments/bxuvsn/how_to_completely_block_update_checks/ and https://superuser.com/questions/1325421/how-to-stop-firefox-update-notifications both mention the pref, but there's probably other places. :-(
Comment 10•3 years ago
|
||
Go ahead and nominate this for Beta & ESR approval when you get a chance. It grafts cleanly to both.
Assignee | ||
Comment 11•3 years ago
|
||
Comment on attachment 9263360 [details]
Bug 1754409 - Add catch for invalid manual update url. r=bytesized
Beta/Release Uplift Approval Request
- User impact if declined: Blank settings page when user modifies about:config
app.update.url.manual
to an invalid url. - Is this code covered by automated tests?: Unknown
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This adds catch to handle exception when attempting to parse an invalid url. The change is small and easy to verify.
- String changes made/needed:
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Results in blank settings page when users modify
app.update.url.manual
, which seems common for individuals attempting to block updates. Fix is trivial. - User impact if declined: Settings page becomes inaccessible for users modifying
app.update.url.manual
. - Fix Landed on Version: 99
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This adds catch to handle exception when attempting to parse an invalid url. The change is small and easy to verify.
Comment 12•3 years ago
|
||
Comment on attachment 9263360 [details]
Bug 1754409 - Add catch for invalid manual update url. r=bytesized
Approved for 98 beta 9, thanks.
Comment 13•3 years ago
|
||
bugherder uplift |
Comment 14•3 years ago
|
||
Comment on attachment 9263360 [details]
Bug 1754409 - Add catch for invalid manual update url. r=bytesized
Approved for 91.7esr.
Comment 15•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 16•3 years ago
|
||
I have reproduced this issue using Firefox 99.0a1 (2022.02.09) on Win 10 x64.
I can confirm this issue is fixed, I verified using Firefox 98.0, 99.0a1 (latest nightly) and 91.7.0esr on Win 10 x64, macOS 10.15 and Ubuntu 20.04 x64.
Description
•