Closed Bug 538372 Opened 15 years ago Closed 14 years ago

Fallback update not offered when update is performed with a fresh profile

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [3.6RC1][4rc1][mozmill])

Attachments

(2 files)

active-update.xml
1.39 KB, text/xml
Details
updates.xml
1.32 KB, text/xml
Details
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4 (.NET CLR 3.5.30729) If you wanna perform an update from Fx3.6b4 or Fx3.6b5 to the RC1 you will not get an fallback update offered when using a fresh profile. Instead you have to re-check for an update and download it again. Modifying the update.status afterward will perform the right action and offer an fallback update. I have discovered that yesterday by running the Mozmill software update tests. Steps: 1. Install Firefox 3.6b5 2. Create a fresh profile 3. Check for updates and update to 3.6rc1 4. Don't apply the update immediately 5. Edit update.status and replace 'pending' with 'failed:6' 6. Restart Firefox After step 6 no software update dialog with the patching failed message opens. Instead you have to manually check for updates again. This behavior is different from all the tests I have been running so far. None of some failed. With the above builds it is the first time.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 The update process works as expected for me using your steps when run manually. This may be a Mozmill problem and not a problem specific to the update process itself.
The steps from comment 0 are manual steps which I can reproduce on XP and Win7 at least. I will check other platforms.
I'm unable to reproduce this at all on WinXp
(In reply to comment #3) > I'm unable to reproduce this at all on WinXp Is there something in your environment which coul point to why this update is not working for you? My environment is a complete vanilla install (no plugins ever installed, all OS updates installed, no firefox ever installed, no third party apps ever installed)
Attached file active-update.xml —
The interesting part here is that the active-update.xml is immediately renamed to updates.xml during the restart. Given that no active update is in the queue anymore and that's why the software update dialog is not shown. Further we supply a complete update which it is served as a partial one (given by Coops email yesterday). As you can see in this file, the partial patch is not selected but it has been marked as failed after I have updated the download status from 'pending' to 'failed:6'. Surprisingly the complete patch has been selected now which state was been 'null' in active-update.xml after the first shutdown. But now it has been gotten 'download-failed'. I will attach both files.
Attached file updates.xml —
This is a regression between 3.6b1 and 3.6b2. Robert, could that have been regressed from your refactoring work for the software update service? Here a list of possible candidates: https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=notsubstring;query_format=advanced;field0-0-0=cf_status_192;value1-0-0=verified1.9.2;type0-0-0=substring;value0-0-0=beta2-fixed;component=Application%20Update;field1-0-0=keywords;product=Toolkit
What specifically did you use to figure out the regression range? Was it how the updates.xml is updated?
(In reply to comment #8) > What specifically did you use to figure out the regression range? Was it how > the updates.xml is updated? I did the steps from comment 0 and checked if the software update dialog gets opened automatically. I can check if I can even get a closer time frame by testing the fallback path with nightly builds.
What is the update url used (In reply to comment #0) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b4) Gecko/20091124 > Firefox/3.6b4 (.NET CLR 3.5.30729) > > If you wanna perform an update from Fx3.6b4 or Fx3.6b5 to the RC1 you will not > get an fallback update offered when using a fresh profile. Instead you have to > re-check for an update and download it again. Modifying the update.status > afterward will perform the right action and offer an fallback update. > > I have discovered that yesterday by running the Mozmill software update tests. > > Steps: > 1. Install Firefox 3.6b5 > 2. Create a fresh profile > 3. Check for updates and update to 3.6rc1 > 4. Don't apply the update immediately > 5. Edit update.status and replace 'pending' with 'failed:6' This should be 'failed: 6' Just tried this and it works for me.
Whether this is the cause or not there have been several bug reports filed by QA where the update.status wasn't formatted properly. It has always required a space between the : and the error number. For example, from Firefox 1.5 http://mxr.mozilla.org/mozilla1.8.0/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1050 If you have any docs on setting the value in update.status I'd appreciate it if you would update them so they state that it is important that the string in the file is formatted properly in that it should be 'failed: 6' followed by a single newline character.
If you could also update the docs with the following from bug 534090 comment #61 > I looked at enforcing reasonable minimums and though it is easy to do so it > then makes the timer manager xpcshell tests take quite a bit longer. At least > for the time being I would prefer it if QA uses the following values when > testing app update. > > The idle time must be less than the interval > user_pref("app.update.idletime", 1); > > checks for updates every 30 seconds > user_pref("app.update.interval", 30); > > timer fires every 30 seconds > user_pref("app.update.timer", 30000);
There was also a bug filed by QA where they modified the update.status and left the updates directory open in explorer which will prevent the deletion of the updates directory on some versions of Windows and thereby cause a failure. Please add a note in the QA docs that after modifying the update.status the update.status file must be closed and that the explorer window open to the directory must also be closed.
Ok, we accidentally used "failed:6" but I haven't had any problem before. All updates work perfectly with Mozmill on 1.9.1 and with 1.9.2b1 with that setting. But starting from beta2 it doesn't work. I have corrected the failure now but the problem still persist. Fallback updates are not possible. I will run some nightly tests now.
Version: 1.9.1 Branch → 1.9.2 Branch
This regressed between the builds 09102305 and 09102305. PASS: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/bf5a0fd5db5c FAIL: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a7e017d058ba Checkins: http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=bf5a0fd5db5c&tochange=a7e017d058ba There is only one checkin which is related to the software updates in this time frame: Bug 512651 - lessen the write access checks during startup and remove final-ui-startup observer
Blocks: 512651
While reading some comments in the patch from bug 512651 I have to state that I don't install Firefox under program files but under "c:\firefox". Eventually that makes the difference.
(In reply to comment #16) > While reading some comments in the patch from bug 512651 I have to state that I > don't install Firefox under program files but under "c:\firefox". Eventually > that makes the difference. But it makes no difference. Also using "C:\Program Files\Mozilla Firefox\" shows up the same behavior.
Enabling app.update.log.all for the profile doesn't produce any output after the restart.
After talking to Rob on IRC I have retested it with app.update.log=true and I still cannot see any reported problems in the Error Console.
(In reply to comment #2) > The steps from comment 0 are manual steps which I can reproduce on XP and Win7 > at least. I will check other platforms. One thing I forgot in the last comments... I cannot reproduce on Win7 so it's really a WinXP only issue which happens with all possible update channels. I have also created a fresh Windows user account for testing but that doesn't make any difference.
Instead of spinning my wheels on this I am going to try to remove whatever is the cause within app update for releng needing to provide both a partial and complete that are the same which should prevent this from happening in the future.
This could be an issue with how multiple, failed updates are handled. I think since 1.5 days, when an update failed twice (we made it fail twice), we would not keep getting the "Update Failed" window. Instead, we would get a fresh new offer after we forced a failed update the second time. For example, I just tried updating from 3.0.16 to 3.0.17, I downloaded the partial, then I forced a fallback update, and then I forced another fallback update after that. Well, the last time I did not get an "Update Failed" dialog; instead I got what appeared to be a new update offer. This, combined with the fact that we are getting complete updates as partials on Windows because of the rebase problem with beta 5, may have something to do with us observing this scenario. If I follow Robert's steps with "fail: 6" in the update.status file, everything works as expected.
(In reply to comment #22) > This, combined with the fact that we are getting complete updates as partials > on Windows because of the rebase problem with beta 5, may have something to do > with us observing this scenario. That doesn't interfere us here because I can also see the same behavior when updating nightly builds starting from 24th Oct (as noted above).
I had another idea which showed me that a particular pref which is existent in an older profile but not in a fresh one is causing this regression. I will run some more tests tomorrow to find out which one it is exactly.
Filed bug 538499 to update the QMO documentation. I hope that suffices in getting the docs used internally by QA updated as well. Thanks
I suspect bug 538533 might fix this but since I'm not positive I didn't patch it in this bug.
(In reply to comment #25) > Filed bug 538499 to update the QMO documentation. I hope that suffices in > getting the docs used internally by QA updated as well. Thanks Thanks Rob. In parallel I have filed bug 538581 to update the software update tests for Mozmill. (In reply to comment #26) > I suspect bug 538533 might fix this but since I'm not positive I didn't patch > it in this bug. Once this patch has been checked into trunk I will re-run my tests. I will wait for now.
(In reply to comment #27) > (In reply to comment #26) > > I suspect bug 538533 might fix this but since I'm not positive I didn't patch > > it in this bug. The fix for bug 538533 didn't helped here. I'm still not able to get fallback updates offered on that XP machine. Running the steps from comment 0 on our qa-mozmill machine I can't see this problem. Rob, which variables come into play when we decide to show up the dialog for a fallback update? Do we query any key from the registry too? I can't really understand why it doesn't work in my XP VM. It makes testing patches for software update tests kinda hard.
I'm not sure what is different when testing on your system. Could you check if either of the following mochitest chrome tests also fail on your system? It might help narrow down what the difference is. btw: it doesn't query the registry at all. http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/test/chrome/test_0083_error_patchApplyFailure_partial_complete.xul http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/test/chrome/test_0084_error_patchApplyFailure_verify_failed.xul
Another note if the above succeeds, is there any way you could see if you can get Anthony to reproduce on one of his system since he was unable to?
(In reply to comment #30) > Another note if the above succeeds, is there any way you could see if you can > get Anthony to reproduce on one of his system since he was unable to? Considering Henrik's VM appears to be the ONLY system which causes this problem, I suggest something has happened to his VM. Henrik, have you tried pulling a clean VM from the VPN and trying to reproduce it there? I know Al updates them monthly. Once we trace it to be something specific to your VM, we can then start isolating what's with your VM which is causing the issue. Do we have other users reporting failed fallback on a fresh profile? I would think the instances of users with a completely fresh profile conducting a fallback update are fairly low. I'm not saying this isn't a valid bug. I just want to make sure we are allocating resources where they are most valuable.
Henrik, can you please followup on this bug so we can finally figure out what's going on and resolve this.
I will try to get to it over the weekend.
Sorry, this one got lost in my bug queue. We haven't discovered this problem on our machines in the QA lab. So I will have to check again, but it could be that the VM, which I have used in April, doesn't exist anymore.
Whiteboard: [3.6RC1][mozmill][mozmill-test-blocked] → [3.6RC1][mozmill]
I tried those steps a couple of times today with and without Mozmill, but I cannot reproduce it on the same WinXP VM anymore. Nothing has been changed on its configuration so something has been fixed the problem for me. Lets call this bug WFM as long as I cannot see it again and can specify more details.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Today we were able to reproduce this issue on both of our Mozmill machines we are using for release and daily tests. The problem can be seen on XP and Vista, but not Win7 so far. Rob, we can create a snapshot of one of those VMs and put it onto the fileserver. This bug is kinda easy to reproduce when using a fresh profile for an fallback update test from any 3.6.x build.
Blocks: 642220
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Whiteboard: [3.6RC1][mozmill] → [3.6RC1][4rc1][mozmill]
Rob, you can download the VM here: http://fs2.office.mozilla.org/public/QA/Mozmill/ You will only have to start Firefox and select the profile 'fresh' to see this issue. A snapshot has been already created so you can always go back. If you need anything more please tell us. Because of this problem our Mozmill tests will report failures for updates on the 1.9.2 branch.
The same can be seen if you are using a different profile for downloading the update and applying the update. Tomorrow I will check if I can find out what part of a single profile is causing this issue)
This issue seems to be bound to a missing compatibility.ini file inside the profile. You should be able to reproduce this issue by simply deleting this file before you restart Firefox.
If the problem is a missing compatibility.ini then please move the bug over to startup since it is responsible for creating this file. I'm recovering from minor surgery atm, will likely be busy on Firefox next work, and that file isn't the responsibility of app update.
Better yet, file a new bug against startup / profile system.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → WORKSFORME
(In reply to comment #40) > If the problem is a missing compatibility.ini then please move the bug over to > startup since it is responsible for creating this file. That is a suspicion and I'm not sure if that's the reason for this issue. The file is getting created and even when I put this file into an existing profile the patch error dialog isn't shown. I have no idea if this is related to startup or the profile system. So lets CC Benjamin and we can decide. Until then I hesitate to create a new bug because of all the collected information on that one.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm not sure what's going on here, but I'm pretty sure I don't care. Having to check for updates again isn't worth worrying about.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
Benjamin, this is blocking our automated update tests with Mozmill. See bug 642220. We have to test fallback updates to ensure that users get the right updates served. Without a fix for this bug we are blocked and can't report valid results to release drivers. Please re-consider your decision, at least to that point that we know how to workaround this issue.
I don't understand what this has to do with mozmill. Is mozmill actually testing multiple profiles? Or is the problem just that the main program has an update pending and then mozmill tests are failing because they run in another profile? If so, shouldn't you just remove the pending update before you start mozmill runs?
The Mozmill tests are always using a fresh profile for update tests. There are two tests we have to perform: Direct updates: * Download patch * Restart Firefox to apply the patch Fallback updates: * Download patch and make it invalid via update.status * Restart Firefox * Check the error window and download the complete patch supplied by this window * Restart Firefox to apply the complete patch Right now we are blocked on testing the fallback updates, which are clearly a part of our release testing cycle.
(In reply to comment #42) > (In reply to comment #40) > > If the problem is a missing compatibility.ini then please move the bug over to > > startup since it is responsible for creating this file. > > That is a suspicion and I'm not sure if that's the reason for this issue. The > file is getting created and even when I put this file into an existing profile > the patch error dialog isn't shown. I have no idea if this is related to > startup or the profile system. So lets CC Benjamin and we can decide. Until > then I hesitate to create a new bug because of all the collected information on > that one. The trouble I have with this is that the vast majority of information in this bug has nothing to do with what you are experiencing even though the symptom may be the same. If anything it is more confusing. If you can reproduce this using steps a user could actually use then please file a new bug with specific steps.
ok, so what is different between using a new computer (no existing Firefox/profiles) and this case? I really don't care about #39 if what you're doing is intentionally messing up compatibility.ini. Also, compatibility.ini should be created normally if you launch Firefox and then close it. Are you force-killing it or something? In any case, the test you're trying to make work seems like a lot of hackery. If you want to test failed-partial updates, just make the partial update fail (perhaps by inserting a HTTP proxy which fails or corrupts that request, or extension equivalent using http-on-modify-request).
(In reply to comment #48) > ok, so what is different between using a new computer (no existing > Firefox/profiles) and this case? That's the question I cannot answer. This issue has started recently again while testing the release candidate builds. Similar to what we had last year for Fx 3.6 RCs. See my comment 37 for a perfect example this time. It's 100% reproducible in that XP VM. > In any case, the test you're trying to make work seems like a lot of hackery. > If you want to test failed-partial updates, just make the partial update fail > (perhaps by inserting a HTTP proxy which fails or corrupts that request, or > extension equivalent using http-on-modify-request). That's the way how we (QA) did update tests in the last couple of years. There are ways for improvements like what you have mentioned. But I'm not sure if this would fix this specific issue.
Given that no reply happened in the last whole week I would assume this bug will stay at wontfix? If that's the case QA will not be able to 100% verify the update paths of fallback updates for releases on 1.9.2 on some of our Windows platforms. Further I will remove the prepared VM (comment 37) if no interests are shown in the next couple of days.
It will stay wontfix. It is also way too late and has been way too late for quite some time to make changes to the client to fix bugs that are only seen with mozmill and the approach bsmedberg stated in comment #48 as I have also essentially stated previously should be taken.
(In reply to comment #51) > It is also way too late and has been way too late for quite some time to make > changes to the client to fix bugs that are only seen with mozmill and the As stated a couple of times this has not only be seen by Mozmill tests. > approach bsmedberg stated in comment #48 as I have also essentially stated > previously should be taken. No, this hasn't been proposed in the past. But I have filed bug 646643 to cover that part.
(In reply to comment #52) > (In reply to comment #51) > > It is also way too late and has been way too late for quite some time to make > > changes to the client to fix bugs that are only seen with mozmill and the > > As stated a couple of times this has not only be seen by Mozmill tests. Bug reports? From what I have seen here and elsewhere what happens is mozmill run into a problem and then steps to reproduce are found that never happen on the client without someone manually deleting / changing files. > > approach bsmedberg stated in comment #48 as I have also essentially stated > > previously should be taken. > > No, this hasn't been proposed in the past. But I have filed bug 646643 to cover > that part. I most definitely have stated that mozmill should only test what unit tests cannot test. I have also stated that we shouldn't change the client to support tests unless absolutely necessary and it is seldom the case that it is absolutely necessary. I have also created patches for mozmill that have fixed mozmill in bugs where you have asked us to change the client.
(In reply to comment #53) > Bug reports? From what I have seen here and elsewhere what happens is mozmill > run into a problem and then steps to reproduce are found that never happen on > the client without someone manually deleting / changing files. See comment 0 and comment 2 on this bug. And the VM I have had uploaded (comment 37) showed exactly this situation when running fallback update tests fully manually. > I most definitely have stated that mozmill should only test what unit tests > cannot test. I have also stated that we shouldn't change the client to support > tests unless absolutely necessary and it is seldom the case that it is I don't want to stress this discussion but I can't remember of any situation we talked about alternatives for the update.status path. Given Benjamin's input I will give the 'http-on-modify-request' path a try. > absolutely necessary. I have also created patches for mozmill that have fixed > mozmill in bugs where you have asked us to change the client. That's partly true. Not all of these issues were bugs in our tests.
(In reply to comment #54) > (In reply to comment #53) > > Bug reports? From what I have seen here and elsewhere what happens is mozmill > > run into a problem and then steps to reproduce are found that never happen on > > the client without someone manually deleting / changing files. > > See comment 0 and comment 2 on this bug. And the VM I have had uploaded > (comment 37) showed exactly this situation when running fallback update tests > fully manually. Which no one else in QA was able to reproduce and there were no bug reports other than the ones you reported. > > I most definitely have stated that mozmill should only test what unit tests > > cannot test. I have also stated that we shouldn't change the client to support > > tests unless absolutely necessary and it is seldom the case that it is > > I don't want to stress this discussion but I can't remember of any situation we > talked about alternatives for the update.status path. Given Benjamin's input I > will give the 'http-on-modify-request' path a try. That is exactly what I am referring to. If the fix for the test involves making the test more complicated vs. the client more complicated I will 100% of the time make the test more complicated. > > absolutely necessary. I have also created patches for mozmill that have fixed > > mozmill in bugs where you have asked us to change the client. > > That's partly true. Not all of these issues were bugs in our tests. The vast majority of the time they were.
(In reply to comment #46) > Fallback updates: > * Download patch and make it invalid via update.status > * Restart Firefox I wonder if this isn't quite right, and what you should be doing is closing Firefox before modifying update.status.
(In reply to comment #55) > > See comment 0 and comment 2 on this bug. And the VM I have had uploaded > > (comment 37) showed exactly this situation when running fallback update tests > > fully manually. > Which no one else in QA was able to reproduce and there were no bug reports > other than the ones you reported. Tracy has seen the same behavior on one of his native WinXP boxes. There is also a closed bug on file which I can't find at the moment. Also see bug 642220 for our boxes in the QA lab which are affected because of this issue. > > will give the 'http-on-modify-request' path a try. > That is exactly what I am referring to. If the fix for the test involves making > the test more complicated vs. the client more complicated I will 100% of the > time make the test more complicated. I'm still at the position that I can say that there is no fix needed for the Mozmill test. It works as expected but the client fails. I can say that for sure because I can reproduce it manually. If the 'http-on-modify-request' is no option I'm happy to wontfix it.
(In reply to comment #57) > (In reply to comment #55) > > > See comment 0 and comment 2 on this bug. And the VM I have had uploaded > > > (comment 37) showed exactly this situation when running fallback update tests > > > fully manually. > > Which no one else in QA was able to reproduce and there were no bug reports > > other than the ones you reported. > > Tracy has seen the same behavior on one of his native WinXP boxes. There is > also a closed bug on file which I can't find at the moment. Also see bug 642220 > for our boxes in the QA lab which are affected because of this issue. Which comes right back to my previous statement in that quote of: "Bug reports? From what I have seen here and elsewhere what happens is mozmill run into a problem and then steps to reproduce are found that never happen on the client without someone manually deleting / changing files." > > > will give the 'http-on-modify-request' path a try. > > That is exactly what I am referring to. If the fix for the test involves making > > the test more complicated vs. the client more complicated I will 100% of the > > time make the test more complicated. > > I'm still at the position that I can say that there is no fix needed for the > Mozmill test. It works as expected but the client fails. I can say that for > sure because I can reproduce it manually. If the 'http-on-modify-request' is no > option I'm happy to wontfix it. Let me put this as plainly as I can. If actual users are experiencing this problem then I have absolutely no problem with trying to find the cause and fixing the bug. If it is mozmill experiencing the problem and not users then trying to fix the problem for mozmill takes my time away from fixing problems that users are experiencing as well as implementing new features that I have been tasked with.
(In reply to comment #58) > > Let me put this as plainly as I can. > > If actual users are experiencing this problem then I have absolutely no problem > with trying to find the cause and fixing the bug. If it is mozmill experiencing > the problem and not users then trying to fix the problem for mozmill takes my > time away from fixing problems that users are experiencing as well as > implementing new features that I have been tasked with. So is the solution here that the QA org has to test updates by hand (a labor intensive process) because you aren't willing to fix issues exposed by our tool and which we need fixed in order to have automated tests for releases? That is the implication of this stance, though I assume you don't explicitly mean it to be such (i.e. you don't mean to cause the QA org to do this by hand). Is there a middle ground where we can get issues fixed to allow the QA org to utilize its resources in an efficient manner as well as the Dev org?
(In reply to comment #59) > (In reply to comment #58) > > > Let me put this as plainly as I can. > > > > If actual users are experiencing this problem then I have absolutely no problem > > with trying to find the cause and fixing the bug. If it is mozmill experiencing > > the problem and not users then trying to fix the problem for mozmill takes my > > time away from fixing problems that users are experiencing as well as > > implementing new features that I have been tasked with. > > So is the solution here that the QA org has to test updates by hand (a labor > intensive process) because you aren't willing to fix issues exposed by our tool > and which we need fixed in order to have automated tests for releases? I would definitely hope not. It is important to keep in mind that this issue exposed by mozmill appears to not happen to users and that there are issues that happen to users that take precedence. It is also important to keep in mind that this specific issue involves the compatibility.ini file not being present. If that is actually the case then whatever about it missing needs to be fixed which won't happen in app update. > That is the implication of this stance, though I assume you don't explicitly > mean it to be such (i.e. you don't mean to cause the QA org to do this by > hand). The last time a similar bug happened I ended up patching the mozmill update tests. At this time I do not have time to work on them or I would. > Is there a middle ground where we can get issues fixed to allow the QA org to > utilize its resources in an efficient manner as well as the Dev org? I suspect that if someone can track down why the app update fails when the compatibility.ini file is missing and provide a patch to fix that then it would be accepted. As previously mentioned, I just don't have the time to do so at this time.
(In reply to comment #60) > It is also important to keep in mind that this specific issue involves the > compatibility.ini file not being present. If that is actually the case then > whatever about it missing needs to be fixed which won't happen in app update. Please forget about the compatibility.ini file, which was probably red herring. Also Mozmill is getting executed in an isolated environment, which means it will not change any system settings. If you have about 5 minutes by next week I can show you the behavior in our WinXP VM by manually executing the fallback updates.
Sure. Is this a VM only issue? Does it ever work on VMs? If so, what is different about the VMs?
We don't have a native Windows machine for testing. It was working brilliant all over the last year, until Anthony has spotted it two weeks ago. We haven't changed anything on those VMs.
It would be helpful if someone in QA checked if it works on a native machine and a new VM. In the future, please file a new bug report if something has been working and then it stops instead of reopening a bug that was filed well before it stopped working again. Thanks
I talked with Rob today and we agreed on that further investigation is not really worth the time. My idea to just add another restart in-front of the test which downloads the update works perfectly. So we have a nice workaround for our update tests on 1.9.2 now. Marking this bug as verified wontfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: