Steps: 1. Install an elm build before the prefetch patch was applied 2. Look in C:\Windows\Prefetch - Note the FIREFOX.PF files there (should be >0KB and not read only) 3. Update the elm build to the latest build 4. Start the elm build and wait for more than 1 minute Expected: The FIREFOX.pf files should be set to 0 KB as read only. Actual: The FIREFOX.pf was left unmodified at all (still >0 KB and not read only). Checking the logs, it looks like the prefetch service was never ran. Will attach log in comment shortly.

Executing service command clear-prefetch, ID: b650dac1-a333-4afc-bdd8-b7ce99765151 Service command not recognized: clear-prefetch.

app.update.service.prefetchCleared as of right now is set to true on the nightly elm build (5/19). Going to test on other Windows OSes to see what happens.

The update after having an elm service is needed. I think this should be marked as resolved/invalid but please let me know if you can still reproduce when you are sure you have an elm build's service before the update.

(In reply to Brian R. Bondy [:bbondy] from comment #3) > The update after having an elm service is needed. I think this should be > marked as resolved/invalid but please let me know if you can still reproduce > when you are sure you have an elm build's service before the update. I installed the 4/21 elm build and updated to the 5/19 elm build on Win XP (that's how I saw the error, although it does not look like it happens on Vista). What earlier elm builds are allowed to be used then? I don't understand why updating from 4/21 --> 5/19 would not work, as the app.update.service.prefetchCleared is getting set from nothing (starting state, since it does not exist initially) to existing as true.

I think you may have a service installed that is not one of elm's. It takes the largest version number, but you may have a previous Nightly one installed which has the same version number. So your elm install wouldn't update it.

Did this on a clean machine with a 4/20 elm build on Vista updating to latest elm - did not get a reproduction of this (worked as expected).

(In reply to Brian R. Bondy [:bbondy] from comment #5) > I think you may have a service installed that is not one of elm's. It takes > the largest version number, but you may have a previous Nightly one > installed which has the same version number. So your elm install wouldn't > update it. Just checked the machine - there's only one version of Nightly installed on it. Other firefox builds installed on it include: - Mozilla Firefox 13.0 - Aurora 14.0a2 (x86 en-US)

I don't think the code existed on elm on 4/20. Please see Bug 692255 Comment 65.

(In reply to Brian R. Bondy [:bbondy] from comment #8) > I don't think the code existed on elm on 4/20. Please see Bug 692255 > Comment 65. I know. So what happens if I update from a build that doesn't have the code to a build that has the code then? Shouldn't that work?

I'm also confused why this works in Vista, but doesn't work in XP.

(In reply to Jason Smith [:jsmith] from comment #10) > I'm also confused why this works in Vista, but doesn't work in XP. Actually, change that. Also tested this on a different Win 7 64-bit machine. So on Vista & Win 7 64-bit, when I did the update cycle from 4/21 --> 5/19, the pref was set, the PF files were set to 0 KB and read only. However - the same error was thrown (indicating that the service was unavailable). Strange...

> I know. So what happens if I update from a build that doesn't have the code > to a build that has the code then? Shouldn't that work? Then you would hit the 1 time pref in that case. That's part of why we have it. All future updates after that will clear it. > I'm also confused why this works in Vista, but doesn't work in XP. This was probably a testing anomaly. Maybe an elm service already existed or maybe the pref is what actually cleared it. Or maybe it was already cleared. > the same error was thrown (indicating that the service was unavailable). > Strange... I think you mean the error is service command not found right?. This indicates that you are running a service that didn't have this command.

(In reply to Brian R. Bondy [:bbondy] from comment #12) > > I know. So what happens if I update from a build that doesn't have the code > > to a build that has the code then? Shouldn't that work? > > Then you would hit the 1 time pref in that case. That's part of why we have > it. > All future updates after that will clear it. > > > I'm also confused why this works in Vista, but doesn't work in XP. > > This was probably a testing anomaly. Maybe an elm service already existed > or maybe the pref is what actually cleared it. Or maybe it was already > cleared. I just re-tested by completing uninstalling the elm build, installing the 4/21 elm build, starting it with a fresh profile, and updating to 5/19. I'm still seeing the same issue. It doesn't make sense to me right now why this isn't working - a fresh profile doesn't even have the pref set in the 4/21 build. When it hits the 5/19 build, it is getting set, so something has to be happening here. For my own sanity, could you try this user flow on Win XP? > > > the same error was thrown (indicating that the service was unavailable). > > Strange... > > I think you mean the error is service command not found right?. This > indicates that you are running a service that didn't have this command. Okay, so why is this happening with Windows Vista and 7, even though the prefetch service worked correctly? Are we logging incorrect messages here?

> I just re-tested by completing uninstalling the elm build, installing the 4/21 > elm build, starting it with a fresh profile, and updating to 5/19. > I'm still seeing the same issue. What is the issue you are seeing?

Had a weird timing scenario just happen in this user flow: 1. Installed the 5/15 elm build 2. Launched the elm build, waited for prefetch to complete (which was successful) 3. Deleted the firefox prefetch files 4. Flipped the pref 5. Updated to the latest elm build Result: The pref got set, but the FIREFOX.PF file generated had >0KB and is not read only. I also saw the same error in this bug (service not found). (In reply to Brian R. Bondy [:bbondy] from comment #14) > > I just re-tested by completing uninstalling the elm build, installing the 4/21 > > elm build, starting it with a fresh profile, and updating to 5/19. > > I'm still seeing the same issue. > > What is the issue you are seeing? The service not found error in the log - even in the above scenario (it even happens with 5/15 --> 5/19) Executing service command clear-prefetch, ID: 222f35ed-73d5-4f05-b6c1-4e7a963d4d24 Service command not recognized: clear-prefetch. That's 4 machines I've seen this happen on (Win 7, XP, Vista).

maintenanceservice-install.log is the one that contains information about the command being executed after updates by the way.

I ran these 2 tests and they passed: Tested the pref by: 1) Reverting the pref on the profile 2) Clearing old log files 3) Uninstalling old service that I had 4) Unzipping my prefetch files 5) Installing build http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-18-04-02-02-elm/ 6) Waiting a minute for the prefetch command to be issued 7) Checked the maintenanceservice.log and it said prefetch files were cleared 8) Looked in Windows directory and the prefetch files were cleared Testing the update clear operation by: 1) Setting the pref to true on the profile so it won't do the test above after 1 minute if I accidentally keep the browser open for a minute 2) Clearing old log files 3) Uninstalling old service that I had 4) Unzipping my prefetch files 5) Installing build http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-18-04-02-02-elm/ 6) Going to the about dialog and applying the update that was found 7) Checked the maintenanceservice-install.log and it said prefetch files were cleared 8) Looked in Windows directory and the prefetch files were cleared

I do not understand what you mean by "uninstalling the old service that I had."

3) Uninstalling old service that I had 3.1) Went to Control Panel 3.2) Went to Uninstall a program 3.3) Selected Mozilla Maintenance Service (If none exists then you are done this step) 3.4) Right clicked and pressed on uninstall

Now I understand the problem here and what might be a disagreement here. The user expectation I'm expecting here ties updates to the "Firefox" build, not the Mozilla Maintenance service. The above flows in comment 17 are not valid user flows - a typical average user would not understand what the Mozilla Maintenance Service is (very likely they wouldn't touch it as a result). They do understand what firefox programs are and how to update them. A typical user flow would more likely be something like this: 1. Have an installed version of Firefox without the pref set (no prefetch) 2. Update firefox to a version with prefetch enabled 3. Start firefox Result: prefetch pref set, PF files that exist are set to 0 KB and are read only. Sounds like there needs to be a larger discussion on this outside of a bug, cause I really don't agree with the implementation if that's the case.

I wasn't suggesting a user flow.

(In reply to Brian R. Bondy [:bbondy] from comment #21) > I wasn't suggesting a user flow. Why not? It's important to pay attention to what the end-user does here. I don't see a user understanding that they need to uninstall the maintenance service to execute the needed test case. Unless that won't be an issue in release and beta builds.

I think your disagreement is only with having to do #3 right? I think the 2 tests in Comment 17 should be done to test new installs, but it should also be tested without new installs as you are suggesting. The service is not being replaced though either because the version is not higher because of the elm branch, or because of Bug 757711. So both ways should be tested, but if you test the upgrade way you have to make sure the service actually gets updated as well and that the file version gets increased. I think you have to wait to test that way for bug 757711.

(In reply to Brian R. Bondy [:bbondy] from comment #23) > I think your disagreement is only with having to do #3 right? > I think the 2 tests in Comment 17 should be done to test new installs, but > it should also be tested without new installs as you are suggesting. The > service is not being replaced though either because the version is not > higher because of the elm branch, or because of Bug 757711. > > So both ways should be tested, but if you test the upgrade way you have to > make sure the service actually gets updated as well and that the file > version gets increased. I think you have to wait to test that way for bug > 757711. Sounds like the root cause then points to bug 757711 then. If this is a problem in elm only, then the only issue hit is a limitation on testing (it's not a build advertised). Looks like you've got a patch there that's r+ - Could that patch get pushed to elm?

was already pushed there, there should be a build avail soon.

Test case #2 isn't working for me in comment 17 - see bug 758410. Nevertheless, the prefetcher is turning on during update, so this bug isn't valid. Will reopen or open a separate bug if this happens again (better to be tested on nightly though).

> Test case #2 isn't working for me in comment 17 - see bug 758410. > Nevertheless, the prefetcher is turning on during update, so this bug > isn't valid. Will reopen or open a separate bug if this happens again (better > to be tested on nightly though). If you ignore the extra prefetch run, are the prefetch files cleared by the pref after a minute? If not what does the log indicate under maintenanceservice.log after that minute?

(In reply to Brian R. Bondy [:bbondy] from comment #27) > > Test case #2 isn't working for me in comment 17 - see bug 758410. > > Nevertheless, the prefetcher is turning on during update, so this bug > > isn't valid. Will reopen or open a separate bug if this happens again (better > > to be tested on nightly though). > > If you ignore the extra prefetch run, are the prefetch files cleared by the > pref after a minute? If not what does the log indicate under > maintenanceservice.log after that minute? See the other bug (bug 758410) for what happened (let's move the comments over there).