Closed Bug 1191663 Opened 9 years ago Closed 5 years ago

Firefox 38.0.5 - "Never check for updates" - IS BROKEN

Categories

(Toolkit :: Application Update, defect, P3)

38 Branch
x86_64
macOS
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: steven.goss, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150630154324 Steps to reproduce: Uhmmm ..backed off of the BROKEN OsX Firefox 39, to Firefox 38.0.5. TURNED OFF UPDATES...via the configuration "Advanced" tab because I don't want the BROKEN-NESS of v39 again. (39 won't work in a VM, has serious problem with Yosemite, even bare-metal) but that is not what I'm reporting here). Actual results: After 3 or 4 launches (executions) of Firefox 38.0.5 (OsX) it pops up a Mac notiification banner, via Notification Center, with "Firefox Update" and the notification/banner won't go away. There are no buttons on the window, for a "user choice" because it's just a notification. The next time i launch FireFox...i have the BROKEN 39 version of Firefox Installed again. THIS IS WRONG FOLKS. Firefox used to be the darling of browsers, but the choices being made at Mozilla over the past year have changed that. Expected results: YOU SHOULD NEVER UPDATE A USER'S SYSTEM AGAINST THEIR WILL. If someone takes issue with that, then they are narcisstic. FURTHER, it is not my problem that some decision maker (at Mozilla) allowed version 39 (a complete abortion) to go out the door. This bug report is not about v39, and further I will not give any bug report on v39. It's obvious that someone (or many) did not care what the impact of v39 would be on the public. Thus, I don't care what happens to anything with v39 label. I just don't want v39 on or near my computers ...Capiche?
Severity: normal → critical
OS: Unspecified → Mac OS X
Priority: -- → P1
Hardware: Unspecified → x86_64
Version: 39 Branch → 38 Branch
QA Whiteboard: [bugday-20150803]
Component: Untriaged → Application Update
Product: Firefox → Toolkit
spohl, could you figure out what is going on with this bug?
Flags: needinfo?(spohl.mozilla.bugs)
Was able to reproduce. Looking into it.
Assignee: nobody → spohl.mozilla.bugs
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(spohl.mozilla.bugs)
The initial start of Firefox triggers an update check. Changing the update setting to "Never check for updates" any time after the initial start of Firefox does not have any effect. The download continues and the update is applied, regardless of the update choice. Robert, do we require the update choice to be made via prefs.js before the initial start of Firefox? Or should we check the update choice once more before applying the update, and/or before resuming the download of the update should the browser have been restarted before the download of the update could complete?
Flags: needinfo?(robert.strong.bugs)
(In reply to Stephen A Pohl [:spohl] from comment #3) > The initial start of Firefox triggers an update check. Changing the update > setting to "Never check for updates" any time after the initial start of > Firefox does not have any effect. The download continues and the update is > applied, regardless of the update choice. I should clarify that the update choice works fine for any subsequent update checks. It doesn't work in this scenario because an update check has already occurred by the time the update choice is changed.
(In reply to Stephen A Pohl [:spohl] from comment #3) > The initial start of Firefox triggers an update check. Changing the update > setting to "Never check for updates" any time after the initial start of > Firefox does not have any effect. The download continues and the update is > applied, regardless of the update choice. If an update download is already started that pref has no affect. There is a bug about cancelling the download if the pref is flipped while an update download is happening. > Robert, do we require the update choice to be made via prefs.js before the > initial start of Firefox? The background check for an update happens well after the profile is loaded so this is a non-issue. > Or should we check the update choice once more > before applying the update, and/or before resuming the download of the > update should the browser have been restarted before the download of the > update could complete? Definitely not since it can be a manual update with auto check for updates turned off. If that is what is happening then this should be duped to that other bug and the other bug fixed. The one issue is what the UX should be for when the user disables auto check for updates when there is a download in progress. I *think* it should warn the user.
Flags: needinfo?(robert.strong.bugs)
It would be good to verify that is what happened to the reporter as well. This could be due to that bug I fixed and uplifted to all of the branches that made it into 39
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5) > (In reply to Stephen A Pohl [:spohl] from comment #3) > > The initial start of Firefox triggers an update check. Changing the update > > setting to "Never check for updates" any time after the initial start of > > Firefox does not have any effect. The download continues and the update is > > applied, regardless of the update choice. > If an update download is already started that pref has no affect. There is a > bug about cancelling the download if the pref is flipped while an update > download is happening. The closest I could find was bug 300922, but this asking for an option to cancel the update from the 'update download screen' rather than when the pref is flipped. I'm guessing there's a different bug for the pref?
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #6) > It would be good to verify that is what happened to the reporter as well. Steven, could you read comment 3 and see if what I've experienced matches what you saw when you reported this bug? Thanks.
Flags: needinfo?(steven.goss)
There is a very good chance >70 % that is what happened. I had many things going on at the time, that's why the uncertainty. (To insure that it doesn't happen again, I went into the about:config and destroyed the URLs that FireFox uses to connect to mommy...cut the umbilical). I also firewalled it, just in case. Please put a case into your release regression suite that tests for such kind of bug. You can't anger users (or destroy faith in Firefox) any faster than doing things to user's computers that they don't want (even if that is just a bug).
Flags: needinfo?(steven.goss)
Already understood. The difficulty is balancing resources available to work on these types of bugs that affect very few users vs. bugs that affect alot of users. It would be good to know if after restoring the preferences and setting the pref to not check for updates if you still experience this bug.
Assignee: spohl.mozilla.bugs → nobody
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #11) > It would be good to know if after restoring the preferences and setting the > pref to not check for updates if you still experience this bug.
Flags: needinfo?(steven.goss)
Hi Firefox Team! This is pretty important to my team because we want to ensure that our product works well on firefox. Currently we use WebDriver to run our functional tests, and the latest version of WebDriver only supports up to Firefox 38 so far... I'm sure it will be updated eventually. https://raw.githubusercontent.com/SeleniumHQ/selenium/master/java/CHANGELOG > v2.47.0 > ======= > > ** Java 7 is now requried, but you really should be on 8, since 7 is EOL ** > > > WebDriver: > * Supports native events for Firefox version 31 (immediately previous > ESR). Native event support has been discontinued for versions of > Firefox later than 33. Synthetic events tested on Firefox versions 31 > (immediately previous ESR), 38 (immediately previous release and current > ESR), and 39 (current release). Anyways, the reason this issue is critical is because we have a number of servers that have Firefox 38 installed and basically many of them randomly updated even though we set the "Never check for updates" in the actual FirefoxProfile before installing it. This is really bad for us because if there is no guarantee that Firefox will remain at 1 version, we can't really support that version. I'm sure you have many other bugs you need to get to, but this could be bad for other Teams that are relying on this option for the sake of testing. Thanks for your consideration!
UPDATE. Ghetto workaround... We are working around this issue w/ the last comment in this post: https://support.mozilla.org/en-US/questions/1003777 > so here is what i did, when you get that message that there is an update and it ask you to re-start so it > can be updated, just go to the program files where firefox is installed you will find a folder named updated > ... delete it .... and the you can close firefox and open it again and you will get an error message that > the update failed .... > > then i uninstalled the maintenance service, and deleted files maintenanceservice and > maintenanceservice_installer from firefox mozilla folder ... also renamed updater.exe to updater.exe.old > .... and now firefox never forced to update anymore > > hope this can help. Thanks!
I still have this problem. Firefox keeps updating again and again, even though I have set it to never check for updates. I just got upgraded from 53 (?) to 56.
Blocks: up-prefs
Flags: needinfo?(steven.goss)
Priority: P1 → P3

Is there any chance a different profile is ever used? If so, that will cause Firefox to update.

There is also the ability to disable updating with newer versions using policies
https://github.com/mozilla/policy-templates/blob/master/README.md#disableappupdate

Flags: needinfo?(steven.goss)

No response to the question in comment #16 so resolving as incomplete. If you can provide the information requested in comment #16 I'll reopen this bug. Thanks!

Note: this is likely due to the setting being in the profile and there is another bug to move it outside of the profile.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(steven.goss)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.