Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre ID:2008030607 Normally I updated my Minefield trunk build manually in the past. But due to I forgot it some days and had to download the full mar package I switched back to automatic mode ("automatically download and install the update"). Now, after the switch Minefield doesn't update itself anymore. Even the download isn't triggered. The only thing I get is the alert notification (bug 391598). That means the update was found but no automatic download is triggered. I have to manually trigger the download via the help menu to get the update downloaded and installed the next time I start Firefox.

Do you have extensions.checkCompatibility set to false? I noticed this too, but discovered it was caused by a combination of that pref and the "Warn me if this will disable any of my addons" pref. Disabling the "Warn me" option "fixed" the problem.

Correct. The compatibility check is set to false. I'll give it a try and will report later if it works for me.

(In reply to comment #1) > Disabling the "Warn me" option "fixed" the problem. In other words, this bug could be morphed into "isCompatible should always return true if extensions.checkCompatibility is false".

Here is the problem. There are multiple things that determine whether an add-on is allowed to run with a given version of an application. The checkCompatibility pref makes the EM ignore just one of them for the majority of cases. When determining whether an add-on will be able to run in a future version of an application we do not know all of the different things that that future version takes into consideration so we cannot for sure say that an add-on will work, regardless of the checkCompatibility setting. We can however make a good guess that if an add-on is marked as compatible with that future application that it meets all the requirements of that future application. The truth of the matter is that getIncompatibleItemList already ignores useful information from the blocklist and doesn't get the new toolkit version information necessary to determine compatibility anyway.

But why is that affecting software update? Anything that potentially damages our ability to ship security updates blocks for resolution, IMO.

(In reply to comment #5) > But why is that affecting software update? Anything that potentially damages > our ability to ship security updates blocks for resolution, IMO. Because you have extensions installed not compatible with the next version, and software update is set to not download the next version if you have extensions that might be disabled by it.

Dave, but the update also doesn't happen when there is no difference in the build id. Upgrading from an beta5pre to a beta5pre doesn't work with the pref set to true.

After some clarification with Mossop, I'm de-blocking on this bug. What would be a blocker is if the changes in bug 391598 resulted in users with extensions not being forced to make a choice about fetching and applying an update within 24 hours of Firefox noticing that update was available. Bug 391598 made it so that users were interrupted less, which is virtuous, but they still need to be asked about that choice.

I have just verified that even when you have compatibility checking disabled and you have incompatible addons installed you will still get prompted to install a detected update after a period of time.

I would add that Firefox 3 does not update at all on Mac OS X, regardless whether it is set to automatic or manual. I've been checking since this past Wednesday 7/16/08, when the 3.0.1 update was supposed to be available. No update has ever been detected by Firefox 3, even if I disable all extensions prior to checking. The feature is no good if it doesn't work; it just forces users to download the whole new package again, which is what the update feature was designed to prevent. It needs to be fixed immediately.

Mulder - do you have extensions.checkCompatibility set to false? If you go to tools -> add-ons does it give a warning at the top that compatibility checking is turned off? If not please file your own bug (and cc me again!)

Henrik, I suspect this is at the very least much better now if not altogether fixed. Could you check the current behavior and either resolve accordingly or summarize what still needs to be done? Thanks

For now I believe I haven't seen this issue for a long time. The only thing which triggers me mostly each day is bug 407508. I'll mark this bug as WFM for now.