Closed Bug 1312738 Opened 9 years ago Closed 6 years ago

Restart button for FF 49.0.2 does not trigger upgrade

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
49 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dannyfox, Unassigned)

Details

Attachments

(5 files)

308046B0AF4A39CB.zip
6.81 KB, application/x-zip-compressed
Details
moz-update-new-last-update.log
3.13 KB, text/plain
Details
308046B0AF4A39CB_02.zip
881.09 KB, application/x-zip-compressed
Details
308046B0AF4A39CB_03.zip
5.13 KB, application/x-zip-compressed
Details
308046B0AF4A39CB_04.zip
3.11 KB, application/x-zip-compressed
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20161019084923 Steps to reproduce: Run the usual update process - click on Update Now. Restart FF by the button when download complete. Actual results: FF restarted (or reloaded) but was still FF 49.0.1. I quit FF and manually restarted from the icon. Windows securitry asked if OK to run (OK). Then FF reloaded OK as 49.0.2. Happened on TWO Win 7 machines. (Thought first time I might have had two FFs open. Second time, the update window was the only instance.) Expected results: Old FF quits and restarts normally as the upgraded product.
Component: Untriaged → Application Update
Product: Firefox → Toolkit
Dan, just to verify... was this in the about dialog? when you clicked the button Firefox didn't restart but everything else worked as expected?
Flags: needinfo?(dannyfox)
Hi Bob... >> was this in the about dialog? Yes. I pulled down HELP/ABOUT as usual. Current version was 49.0.1, with new version button "Upgrade to 49.0.2". I clicked it, FF downloaded 9.4 mb, then the "Restart FF to Upgrade" button appeared, which I clicked. This was all in the HELP/ABOUT dialogue box. Then after the supposed upgrade, I checked HELP/ABOUT (again as usual for me) to verify -- and the upgrade had NOT occurred. I manually quit FF ("X") and relaunched it from the icon. I did this process twice (tower and laptop), and each time the "upgrade" went too quickly -- FF essentially quit and reloaded in a heartbeat. First time, there might have been a second window open, so I thought nothing of it -- it's easy to understand that a resident program might not get updated. But it happened immediately afterward on the laptop too, where I know FF had not been running and I was being cautious, so to me it looked like a bug in the flow. >> when you clicked the button Firefox didn't restart but everything else worked as expected? Firefox DID restart (too quickly) but it did not run the upgrade at this time. I didn't try to run this window however (except for HELP/ABOUT and closing the window), so I can't say whether anything else worked or not but I have no reason to suspect otherwise -- it was the intact 49.0.1 AFAIK. I know sometimes an update might simply require reloading to reload a new module or parameter, and sometimes it might involve an active change to something. The manual close/re-launch triggered the Windows security window (approval to run an update program - OK) in both cases -- don't usually see this on a normal restart/upgrade sequence, but it's not unexpected either -- I knew what it was doing. Eventually the update did run (after the manual intervention), and then ABOUT showed the new version afterward. I've been running FF several times since (including now) with no problems, so in those regards "everything else worked as expected".
Flags: needinfo?(dannyfox)
The button just restarts Firefox and this sounds like the firefox.exe process might not have exited which can prevent the update.
Just for background, my Bug 1303187 describes how I had been getting remnants of FF remaining resident in memory (as per Windows TASK Manager), but I haven't seen them for awhile -- including none today. In fact I had just closed off the issue, which was how I happened to be in FF already this morning when I ran the update. I mention that because, during testing, we ran across a few instances -- apparently normal -- where FF took several seconds to unload. For example, I might close FF and relaunch it (from the icon) in a private window (or vice versa), and the new launch would pop up a window to say "Firefox is already running..." and request closure to continue, but then would continue on its own after a second or two anyway. This particular delay thing happens only rarely. Happening twice, and on two different machines, is unlikely. (There were no popups on either machine.) [[ On my tower, I had just recently been in Task Manager to record that no remnants remained and the main FF had vacated too. Then I went to Bugzilla to update the bug, then did the update. I'm just not 100% sure if I ran the update in the same window (I thought I did) or perhaps ran something else in the meantime, which is why I originally believed there may have been a second FF window open on the first update. But the second update (on the laptop) for sure was one single instance of FF, cleanly launched, one tab in one window. ]] In any case, FF fully re-appeared each time with no hint of a delay or problem. But it took long enough -- that is, its window disappeared and then reappeared -- to believe it really did quit and restart, it didn't just go back to the existing window which had initiated the HELP/ABOUT update sequence.
The Window disappearing isn't an indicator of the process completely exiting. There have been numerous bugs over the years of that type and there is a delay before updating gives up which can account for the delay you are seeing.
Please try to reproduce using 49.0.1 and when you do please attach (using the 'Add an attachment' link above) the following files which can be located as follows: In the File Explorer path box enter %LOCALAPPDATA% and press return Navigate to the Mozilla\updates\ directory. If you had multiple installs there may be multiple sub-directories. Find the one with an update.mar file. If there is more than one we'll need to figure out the right one so post in the bug that there is more than one if that is the case. Attach the update.status file which should be alongside the update.mar file. Attach the update.log file if it is present alongside the update.mar file. Attach the last-update.log file if it is present which should be in the parent directory of the directory that contains the update.mar file. Attach the backup-update.log file if it is present which should be in the parent directory of the directory that contains the update.mar file.
Flags: needinfo?(dannyfox)
Reply to Comment 5: There was no delay -- when I clicked the "Upgrade to 49.0.2" button following the download, FF closed immediately and came back up immediately. I'm just saying there was enough of a pause such that I'm sure it was a close and relaunch -- FF did disappear from the screen and immediately reappeared -- and not just an erase and re-display of the current window. As for the current request (Comment 6): I can't see those files. I do have "last-update.log" (time-stamp corresponds to my paper log this morning) and "backup-update.log" (time-stamp agrees with my note that FF49 had auto-updated to 49.0.1). [[ I had been running a "clean" profile to test the remnant bug, and unbeknown to me it had the auto-update switch enabled by default. ]] There is also "active-update.html" and "updates.xml" time-stamped a minute later than the others (ie- "after" the update, and according to the time it seems to be after the manual quit+relaunch). I'll attach a ZIP of this folder in a moment. (Another two folders are empty and from 2015, irrelevant I would guess.) If these files are not suitable for you, I do have a netbook (recently shelved) with 49.0.1 on it. But before I update it (since I don't have a way to regress back again), I just want to make sure I'm giving you the right stuff. Just to be clear, today I was running 49.0.1 and updated to 49.0.2 -- so when you say test it on 49.0.1, I think I'm just going to get the same files. Or are you wanting me to somehow regress to v49 and then update TO 4901? Those updates went OK manually in two cases when I did them, and because of my testing of the remnant bug, the "clean" profile I was using at the time did an auto-update of v49 to 49.0.1 without ever asking to run, so it obviously went fine too. That would be the "backup-update.log" file.
Attached file 308046B0AF4A39CB.zip —
Reply to Comment 6 info request: ZIP File containing update log files as they exist on my tower, following today's update from FF 49.0.1 to 49.0.2 -- that is, run on v4901 and upgrade to v4902.
Flags: needinfo?(dannyfox)
Yes, "Please try to reproduce using 49.0.1" so install 49.0.1 and try to reproduce. The files should be present if you are able to reproduce and the update fails.
Hi Robert... I've downloaded the FF 49.0.1 from your link -- thanks. I presume I should run the large full installer (not the stub)? Do I need to worry about saving/losing profile information? I've never regressed before -- is there any kind of warning or safeguard I need to be aware of? And I think you're not telling me something: What happened to today's files? If the install failed, why aren't the files there now? I'm guessing that perhaps the manual quit/relaunch (and subsequent successful update) erased them. If so, I suppose I should check for the files all along the process, and capture them when available / before they disappear. Otherwise, re-running from 49.0.1 would give the same result. It's been a long day here -- I'll work on this tomorrow morning (EDT) when I can start fresh...
(In reply to Dan Pernokis from comment #11) > Hi Robert... > > I've downloaded the FF 49.0.1 from your link -- thanks. I presume I should > run the large full installer (not the stub)? Do I need to worry about > saving/losing profile information? I've never regressed before -- is there > any kind of warning or safeguard I need to be aware of? Full installer. People install older versions quite often without issue and there should be no issues installing 49.0.1 after 49.0.2. > And I think you're not telling me something: What happened to today's files? > If the install failed, why aren't the files there now? I'm guessing that > perhaps the manual quit/relaunch (and subsequent successful update) erased > them. If so, I suppose I should check for the files all along the process, > and capture them when available / before they disappear. Otherwise, > re-running from 49.0.1 would give the same result. Several of the update files are removed after a successful update. I need the state that they are in when you experience the failure and not after you have successfully updated to 49.0.2 as you commented you had done.
Robert, I'm trying to duplicate the bug on my tower. I've reset to 49.0.1 twice, and ran the HELP/ABOUT update sequence. Both times, when it would normally DL the update, it jumped immediately to "Restart to Update" instead of first taking a few seconds to DL 9.4 mb as it did yesterday -- must already be in cache somewhere. And both times, the update proceeded normally: FF closed/quit, there was a pause with the Windows "waiting" circle, then FF launched OK as 49.0.2. While searching for the 4902 update files to delete, I came across the attached log file in my user local app area \TEMP folder, timestamped with yesterday's update (before manual relaunch). Can I delete UPDATER.EXE and try again? (I notice the log attempts to do so.) Meanwhile, I am booting up my netbook and waiting for Norton to finish its update & fixes so I can run it. Unfortunately this is a s-l-o-w machine and everything takes awhile...
I updated the netbook in the usual way. ABOUT said 49.0.1 and offered "Update to 49.0.2" -- OK. It DL'd 9.4 mb, then "Restart FF to Update" which I clicked. FF closed/quit and restarted with the message: "Update failed. The partial download could not be applied. FF will try again by downloading a full update." It then proceeded to DL 49.8 mb, and "Restart FF to Update" which I clicked. FF closed/quit in the normal way, I got the Windows wait circle, there was a brief flash of "Checking Extensions...", and then FF relaunched OK. Version was 49.0.2. There were no anomalies in the process (other than retrying, which I've only seen once in a blue moon). Everything appeared to be straightforward and normal. And the .mar error files were not present (successful install). But one oddity: While poking around the TEMP folders, I found a Google Chrome update log time-stamped during the brief time while FF was downloading or waiting for my OK. Their auto-update (which can run at any time in the background) had failed too in some way (writing to the registry, mainly), but the program loads and runs OK, and it shows the current version correctly. I've never looked at these logs before, so I can't say whether the failures are normal, and I've never seen any popup warning (including none today), so I suspect this is a usual quiet occurrence. So it looks like I can't reproduce the bug. Perhaps it had something to do with recent history on the tower and laptop -- we run similar things, and both were equally up-to-date wrt Norton, Windows, FF + plugins, Chrome, etc. The laptop was slightly behind, then Norton jumped ahead, Chrome updated, and there had been no previous FF runs since boot-up. However, if I can get rid of the 4902 update, I can retry.
Flags: needinfo?(robert.strong.bugs)
>> The laptop was slightly behind, I mean the NETBOOK was slightly behind...
To get rid of the update clear web content in Tools->Options-Advanced->Network, exit Firefox, remove the files mentioned in comment #6 along with the active-update.xml you saw, reinstall, and try to update again.
Flags: needinfo?(robert.strong.bugs)
I flushed the files and was able to do a few re-runs. I didn't duplicate the original bug (failed update by restart button) but I did replicate the "update failure" as documented for the netbook (Comment 14). And then the update worked perfectly! I will post three ZIPs of the update folder files as soon as I finish this note. (1) I regressed to FF 49.0.1, then flushed the web content files (cache and user data) as per instructions, and closed FF. I checked -- there were NO files in the update folder. Then I proceeded with the update as usual -- was 49.0.1, "Update to 40.0.2", DL 9.4 mb, "Restart FF to Update". I clicked OK, FF closed/quit and reloaded, then popped up the message I got on the netbook: "Update failed. The partial download could not be applied. FF will try again by downloading a full update." I ZIP'd the folder (ZIP 02) to capture events at that point -- no .mar files. On the update failure notice, I clicked OK but nothing happened other than the window went away. I clicked HELP/ABOUT and there was no update button available -- twice. Then I went to OPTIONS/ADVANCED to locate an update function, saw none. But there was the option to "Show Update History" and as soon as I clicked it, the full update/DL started -- 49.8 mb -- then it automatically applied the update, then gave me the option of restart-by-button or I could just "wait until next time" I started FF. I opted for the button (closest to the bug scenario) and FF closed/quit, got the waiting circle, then FF relaunched as 49.0.2. I ZIP'd the folder again (ZIP 03) -- the usual update files from before, no .mar files). (2) I regressed to 49.0.1 again, and carefully flushed & re-ran step by step as above. Again no update files present. HELP/ABOUT said "49.0.1", I clicked "Update to 49.0.2", DL 9.4 mb (normal), then "Restart FF to update". EVERYTHING RAN AS NORMAL! -- FF closed/quit, got the circle, FF relaunched as 49.0.2 -- no errors, nothing. I ZIP'd the folder again (ZIP 04). I'm wondering if maybe the DL files are different?? (I presume they come from multiple servers.) They failed twice in the same way on two machines yesterday (no proper restart). Then they failed today in a different same way (both failed on partial update and triggered the full update). And then it worked fine. So maybe my DL was three different variants of the update.
ZIP 02 -- FF update folders after update-by-restart failed on partial update (before full update).
ZIP 03 -- FF update folders after full-update invoked by restart (completed OK).
ZIP 04 -- FF update folders after normal update (everything worked fine). (End of ZIPs)
(In reply to Dan Pernokis from comment #18) > Created attachment 8804860 [details] > 308046B0AF4A39CB_02.zip > > ZIP 02 -- FF update folders after update-by-restart failed on partial update > (before full update). For this set of logs what did you click to restart? Was it in the about dialog?
The processes preceding the logs (ZIPs) are documented as ZIP_02/03/04 in Comment 17. I always used the ABOUT dialog, except when the "update failed" window appeared. (i) I always start FF from my icon (except following installation, where I let to installer launch it (ii) just to check version). (iii) I always began an update by HELP/ABOUT and the "Update to 49.0.2" it presents. (iv) I always restart FF by the "Restart FF to Update" button as presented (except below). In the case of the update failure notices, I clicked the OK button. Then sometimes had to do something else to trigger the update. On the netbook (which is slow to respond to things), I had clicked OK and nothing seemed to happen (window remained for awhile) -- then the DL started as I was trying to look for how to continue -- not sure where I was when it started. On the tower following the first regression attempt, I clicked OK and nothing happened (except window closed). When I clicked on SHOW HISTORY on the OPTIONS/ADVANCED/UPDATE page, the DL started immediately. In both cases, it might be coincidental that the DL started when I did something (not the same something) -- perhaps the DL was just invoking itself off-screen before showing me. (Many programs including FF do this all the time when launching stuff...) Hope that helps.
Just to make sure, the answer to the question in comment #21 is the about dialog?
Sorry... Here's a summary, followed by details: ZIP_02 = after restart FF from ABOUT dialogue (restart worked but partial update failed) ZIP_03 = after restart FF from Restart Now choice on full update window ZIP_04 = after restart FF from ABOUT dialogue (normal restart -- worked correctly) For ZIP_02 "this set of logs": I had clicked "Restart FF to Update" in the ABOUT dialogue box (as offered following a normal update download of 9.4 mb). This was *before* the bug could appear. (I would have to do this before capturing the log, right? You said to capture files before I manually quit & re-launched.) But I never got to manually quit & relaunch FF (as per the bug) because it either failed to update, or it worked fine. This restart failed and brought up the "Update has failed" window. At this point, *before* I clicked OK in that window, I captured the files in ZIP_02. For ZIP_03: After "OK" in the "Update has failed" window, it eventually did a full update (DL 49.8 mb) and waited for me to restart FF. It would update next time I ran FF, or I could restart now by its button -- I chose the button as that was closest to the bug scenario. Again, the bug would have not yet happened because the bug occurs during the restart -- yeah, I know, a different restart. So ZIP_03 contains logs of an eventually successful update. ZIP_04 follows a completely normal update, beginning in ABOUT and restarting FF from ABOUT. Nothing failed, everything worked.
Thanks. All I was asking was the case for ZIP_02 so I guess "after restart FF from ABOUT dialogue (restart worked but partial update failed)" is the answer
Yes... But in hindsight I guess this statement isn't quite true: >> This was *before* the bug could appear. (I would have to do this before capturing >> the log, right? You said to capture files before I manually quit & re-launched.) The bug has to be there (and hopefully it's in the logs) -- because otherwise, in the bug I wouldn't have had to manually quit & relaunch. But this time, it did initiate an update which just happened to fail, whereas in the bug, it didn't appear to initiate anything -- the manual quit/relaunch did that. So you might not see anything unusual in the logs after all.
Does this still reproduce in current versions?
Flags: needinfo?(dannyfox)
FYI, "current" for me is FF 61.0.1 which I'm running on my laptop and tower. Both are Windows 7/32 PCs. Over the past two years, on laptop //or// tower, I've had occasional (but rare) instances of closing FF, relaunching, and getting the "FF is running" popup. This always resolves itself either by FF continuing anyway or by relaunching FF. >> Does this still reproduce in current versions? I've also had one or two updates not work (as described above) on either machine, which I figured may have been either (i) multiple FF instances open or (ii) a closed instance that hadn't quite vacated. But I don't recall any failures where it happened on //both// machines for the same update. So I would say no, not reproduced (in the sense of things failing multiple times on both machines). However, I have regularly seen Thunderbird updates that ran fine on the tower but say "partial update failed" on the laptop and need the full download. Last few updates went OK as I recall, so it was possibly a TB bug now fixed, but could have been just an operational quirk -- I can't say.
Flags: needinfo?(dannyfox)

Based on comment #28 this is works for me. If there are issues with Firefox not exiting with or without an update please file a Toolkit -> Startup and Profile System bug which also handles shutdown.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME

Is this bug in any way related to Bug #1544001? In that bug, the older version of FF does not vacate fully when FF restarts the new version. The new continues OK, while it seems the old one triggers a FF crash pop-under window. This has happened since FF early-60's versions right through to my current 66.0.5. But this new bug occurs only on my Tower (running Windows 7 Pro/32) and not our Laptop (identical software setup AFAIK).

So could we have just traded one bug for another here? The behaviour described in THIS bug no longer exists (see my Comment #28 above) but may have just evolved into the new behaviour.

Very doubtful given that this bug's symptoms occurred on both of your systems and that bug only occurs on one of your systems.

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

Attachment

General

Creator:
Created:
Updated:
Size: