Closed Bug 829221 Opened 12 years ago Closed 11 years ago

Please temporarily specify promptWaitTime as 6 hours for Nightly snippets

Categories

(Release Engineering :: General, defect, P2)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: akeybl, Assigned: nthomas)

References

Details

Attachments

(1 file)

active-update.xml
1.19 KB, text/plain
Details
When possible, please temporarily specify promptWaitTime as 6 hours for Nightly snippets. QA will verify that the update notification prompt occurs 6 hours after the update ping instead of the default 12. Once that verification is completed, and we've had a day or so of bake time, we can move forward with the bug to do similar on Aurora.
Blocks: 829222
Assignee: nobody → nthomas
Component: General → Release Engineering
Product: www.mozilla.org → mozilla.org
QA Contact: anthony.s.hughes
Version: unspecified → other
Anthony, I've set up the nightlytest channel with a 600 second wait time. Please take a Nightly build from 2013-01-15 or older, eg https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/01/2013-01-15-03-09-36-mozilla-central/ and flip it over to the nightlytest channel. You should get a prompt to restart ~10 minutes after the download is completed and staged.
Priority: -- → P2
Note for RelEng: cron for nightly channel, ffxbld@aus3-staging */3 /home/ffxbld/bin/add-promptWaitTime.py -p /opt/aus2/incoming/2/Firefox/mozilla-central -w 21600
Results of first attempt using the 2013-01-15 Firefox 21.0a1 Nightly as advised: Mac: prompted after ~3 minutes, update.xml contains promptWaitTime="600" Win: still not prompted after 15 minutes, update.xml contains promptWaitTime="600" Lin: prompted after ~12 minutes, update.xml contains promptWaitTime="600" It would seem that results are inconsistent, even though the change to update.xml seems correct.
There might be a bug with the staging implementation. On Windows could you set app.update.staging.enabled to false and try again to see if it prompts in the correct amount of time? Also, if you are checking manually this might be throwing the results off since this is prompting for when there is a background update.
(In reply to Robert Strong [:rstrong] (do not email) from comment #4) > There might be a bug with the staging implementation. On Windows could you > set app.update.staging.enabled to false and try again to see if it prompts > in the correct amount of time? With app.update.staging.enabled=false I get the small Windows notification by the system tray immediately once the download is staged. With it set to true (default) I don't see this notification. In either case, I still don't get the dialog prompt asking me to restart Firefox like I do on Linux and Mac. > Also, if you are checking manually this might be throwing the results off > since this is prompting for when there is a background update. Yup, I'm only checking for background updates here.
Strange... we also have tests for this that do show this same UI... no idea what is going wrong.
Maybe it is due to the service. If you have time try it again with app.update.service.enabled set to false as well as app.update.staging.enabled.
(In reply to Robert Strong [:rstrong] (do not email) from comment #7) > Maybe it is due to the service. If you have time try it again with > app.update.service.enabled set to false as well as > app.update.staging.enabled. * Update is found and downloaded after ~2 minutes * Once download is complete, a Windows notification appears (as in comment 5) * I received a Software Update prompt after ~10 minutes Let me try again without changing those settings.
> app.update.service.enabled=true > app.update.staging.enabled=true No Software Update dialog prompt after 20 minutes > app.update.service.enabled=false > app.update.staging.enabled=true AUS:SVC gCanStageUpdates - unable to stage updates. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsILocalFile.create]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: resource://gre/components/nsUpdateService.js :: testWriteAccess :: line 347" data: no] > app.update.service.enabled=true > app.update.staging.enabled=false Software Update dialog prompts after 10 minutes > app.update.service.enabled=false > app.update.staging.enabled=false Software Update dialog prompts after 10 minutes Based on these results, it would seem that app.update.staging.enabled=false is the pref that makes the difference here.
rstrong - does that shed any light on what's going on here?
Flags: needinfo?(robert.bugzilla)
Not yet and looking into this is in my queue of things to do
Flags: needinfo?(robert.bugzilla)
I had to set up the test snippets again. Same as comment #1 (nightlytest) except use a build from 2013-01-27 or older, eg http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/01/2013-01-27-03-10-42-mozilla-central/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/01/2013-01-27-03-10-42-mozilla-central-l10n/ RelEng, FYI: cd /opt/aus2/incoming/2/Firefox/ rsync -a --delete mozilla-central/ mozilla-central-test/ /home/ffxbld/bin/add-promptWaitTime.py -p /opt/aus2/incoming/2/Firefox/mozilla-central-test -w 600
Status: rstrong to look into prompting on windows. Once that's all sorted out we'd do comment #2 to modify the nightly channel.
Putting this to tracking FF22 since that is what is on nightly and will be the first affected by this.
tracking-firefox22: --- → +
tracking-firefox22: + → ---
(In reply to Robert Strong [:rstrong] (do not email) from comment #11) > Not yet and looking into this is in my queue of things to do Any free cycles?
With bug 882007 fixed on Nightly and Aurora this should now work. Anthony, can you verify? Thanks!
Flags: needinfo?(anthony.s.hughes)
(In reply to Robert Strong [:rstrong] (do not email) from comment #17) > With bug 882007 fixed on Nightly and Aurora this should now work. Anthony, > can you verify? Thanks! Sorry Rob, I don't know what you're asking me to do. Are you asking me to verify bug 882007 is fixed? If so, lets deal with that on that bug.
Flags: needinfo?(anthony.s.hughes)
That's fine, the verification is the same as the steps performed for verifying this bug is working as expected.
Sorry, I'm still unclear about what needs to happen. Do I just need to repeat my test from comment 3? Does repeating that test verify both bugs are fixed? Is the custom snippet from comment 1 still available for testing?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #20) > Sorry, I'm still unclear about what needs to happen. > > Do I just need to repeat my test from comment 3? The test you performed that resulted in your findings in this bug would need to be performed. It is fine with me to just verify bug 882007 using those steps if you prefer. > Does repeating that test verify both bugs are fixed? If the server side implementation is implemented, you use the server side implementation for your test, and the notifications are shown then yes. > Is the custom snippet from comment 1 still available for testing? nthomas, can you answer that?
Flags: needinfo?(nthomas)
I've set up nightlytest again with a 600 second promptWaitTime, please use a build which is from 20130624 or older to get an update. Same for auroratest. [RelEng: same steps as comment #12, with extra call to add-promptWaitTime.py against mozilla-aurora-test dir]
Flags: needinfo?(nthomas)
Changed from 600 to 120 seconds at ashughes request, both channels.
And back to 600 to avoid any issues with being close to the same period as the timer (like we've had in the past).
btw: that happened in the past when manually setting a value in about:config that is specified in milliseconds and not seconds. I added clamps awhile ago to prevent that from happening for most if not all of the cases where that used to happen (hence why we haven't seen new bugs about it).
One last question before I test this. Does promptWaitTime control the toast notification or the pop-up dialog?
(In reply to Robert Strong [:rstrong] (do not email) from comment #27) > The dialog. Thanks.
It seems to be working now on Windows 7 for Nightly but not for Aurora. Firefox 24.0a1 2013-06-22 (nightlytest): I was prompted after ~10 minutes and updated to Firefox 25.0a1 2013-06-25 on restart. Firefox 23.0a2 2013-06-22 (auroratest): I waited 20 minutes but received no pop-up notification. Restarting did not apply the staged update. Checking for updates after restart via the About dialog found and installed an update.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #29) > It seems to be working now on Windows 7 for Nightly but not for Aurora. Nevermind, this *should not* be working on Aurora as given by bug 882007. I'll follow up on that bug and then we can finish up here.
akeybl, should we go ahead with the 6 hour prompt on Nightly now ? What about the bugs for aurora & beta ?
Flags: needinfo?(akeybl)
ashughes will have latest status on verfication and testing. Once we get the thumbs up, let's go! :)
Flags: needinfo?(akeybl)
Hmm, this doesn't seem to be working now with Firefox Nightly 21.0a1 2013-01-27. The snippet contains promptWaitTime=600: > https://aus3.mozilla.org/update/3/Firefox/21.0a1/20130127031042/WINNT_x86-msvc/en-US/nightlytest/Windows_NT%205.1.3.0%20%28x86%29/default/default/update.xml But after 20 minutes I still haven't seen a dialog pop-up.
promptWaitTime controls how long after the update has been downloaded in the background that the user is prompted to restart. Are you sure that the update was downloaded in the background?
A background update can be triggered from the error console with the following all on one line. const Ci = Components.interfaces; const Cc = Components.classes; Cc["@mozilla.org/updates/update-service;1"].getService(Ci.nsIApplicationUpdateService).QueryInterface(Ci.nsITimerCallback).notify(null);
I can only assume that it's done as I see the following in Error Console: > AUS:SVC Downloader:onProgress - progress: 30803371/30803371 > AUS:SVC Downloader:onStopRequest - original URI spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/07/2013-07-25-03-02-12-mozilla-central/firefox-25.0a1.en-US.win32.complete.mar, final URI spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/07/2013-07-25-03-02-12-mozilla-central/firefox-25.0a1.en-US.win32.complete.mar, status: 0 > AUS:SVC Downloader:onStopRequest - status: 0, current fail: 0, max fail: 10, retryTimeout: 2000 > AUS:SVC Downloader:_verifyDownload called > AUS:SVC Downloader:_verifyDownload downloaded size == expected size. > AUS:SVC Downloader:_verifyDownload hashes match. > AUS:SVC Downloader:onStopRequest - setting state to: pending-service > AUS:SVC gCanStageUpdates - able to stage updates because we'll use the service > AUS:SVC UpdateService:applyUpdateInBackground called with the following update: Nightly 25.0a1 > AUS:SVC readStatusFile - status: applied, path: C:\Documents and Settings\mozilla\Local Settings\Application Data\Mozilla\Firefox\Nightly\updates\0\update.status > AUS:SVC UpdateManager:refreshUpdateStatus - Notifying observers that the update was staged. state: applied-service, status: applied > AUS:SVC readStatusFile - status: applied-service, path: C:\Documents and Settings\mozilla\Local Settings\Application Data\Mozilla\Firefox\Nightly\updates\0\update.status > UTM:SVC TimerManager:notify - notified @mozilla.org/updates/update-service;1 The last two lines repeat several times.
Can you attach the active-update.xml for this update?
Attached file active-update.xml —
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #33) > Hmm, this doesn't seem to be working now with Firefox Nightly 21.0a1 > 2013-01-27. You won't have the fix from bug 882007 with that build. Could you retest with a nightly only a couple of days old ?
Thanks for catching that Nick!
Looks like it's working for Nightly 25.0a1 2013-07-20: > [13:55:03.744] AUS:SVC UpdateManager:refreshUpdateStatus - Notifying observers that the update was staged. state: applied-service, status: applied > [14:04:32.421] UTM:SVC TimerManager:notify - notified @mozilla.org/updates/update-service;1 At this point I received a pop-up window asking me to restart to install Firefox 25.0a1. Also, the snippet contains promptWaitTime=600: > https://aus3.mozilla.org/update/3/Firefox/25.0a1/20130720030214/WINNT_x86-msvc/en-US/nightlytest/Windows_NT%205.1.3.0%20(x86)/default/default/update.xml Feel free to push this live for Nightly.
(In reply to Nick Thomas [:nthomas] from comment #31) > What > about the bugs for aurora & beta ? Looks like I forgot to answer this here (although I think I answered it elsewhere?). Once this has been enabled for a few days on Nightly, we can enable on Aurora (even if around the merge day). Let's wait until FF24 on Beta before pushing there.
Ok, this is live on the nightly channel with a promptWaitTime of 6 hours (21600 seconds). Any new builds will have that added within 5 minutes of being uploaded. [RelEng: see cron for ffxbld@aus3-staging] eg: https://aus3.mozilla.org/update/3/Firefox/21.0a1/20130213040206/WINNT_x86-msvc/en-US/nightly/Windows_NT%205.1.3.0%20%28x86%29/default/default/update.xml <?xml version="1.0"?> <updates> <update type="minor" displayVersion="25.0a1" appVersion="25.0a1" platformVersion="25.0a1" buildID="20130804030207"> <patch type="complete" URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/08/2013-08-04-03-02-07-mozilla-central/firefox-25.0a1.en-US.win32.complete.mar" hashFunction="sha512" hashValue="d4cb3487180242beba23f4b40de17756ca17ff7e3c1277897984a4243159107898901e46c6077ac47952930283cb1ce10e3acc01fb4338bf360c94d9a57f9bff" size="33602647"/> </update> </updates> Leaving open to remove it again afterwards.
It looks like this is working as expected. I tried this using Firefox 25.0a1 2013-08-01 on the nightly channel and I get a promptWaitTime of 21600 (6 hours).
Let's call this resolved/fixed, so we can move forward with bug 829222 at the end of the week.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
I've turned the cron job that's adding 6 hours off again.
... but the updates will continue to include it until the next nightly comes along for each locale.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: