Closed Bug 307235 Opened 19 years ago Closed 19 years ago

Compatibility checker checks endlessly

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ria.klaassen, Assigned: robert.strong.bugs)

References

(
URL
)

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file, 1 obsolete file)

patch for checkin with niits picked
6.83 KB, patch
robert.strong.bugs
: review+
mtschrep
: approval1.8b4+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050906 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050906 Firefox/1.6a1 When I run alternately a trunk and a branch build the compatability checker doesn't finish its task. Seems to have broken between these two builds: 1.9a1_2005083107 (works) and 1.9a1_2005083111 (fails). Reproducible: Always Steps to Reproduce: 1. Run a trunk build 2. Run a branch build 3. Watch the compatability checker Actual Results: Checks endlessly. Expected Results: Should finish its task and disable some extensions if necessary.
Please note that this is not a common real world scenario. Although I do agree that there should be at least a timelimit to the compatibility checker in these kind of situations.
In branch I get nearly the same result: 1.8b4_2005083106 (works) - 1.8b4_2005083120 (fails).
Confirming on Firefox and Thunderbird!
There is really a very consistent and obvious difference between those two builds. Not an occasional "slow line". The checker seems not able to finish the task.
Severity: minor → normal
dupe of bug 288054?
Ria, 1. do you see the same between the 20050905 (FF1.0+) and 20050907 (FF1.4) branch builds ? 2. Which options are checked/unchecked in Options->Advanced->Update ?
Peter - builds and settings make really no difference, only the date of the build counts.
(In reply to comment #1) > Please note that this is not a common real world scenario. I can confirm this behavior with update from Branch Nightly 20050905 to Branch Nightly 20050906 (the first one labeled Firefox/1.4), so this is indeed a real world scenario. I let the checker "run" more than 10 minutes before canceling it, this is definitely going to confuse a normal User.
(In reply to comment #5) > dupe of bug 288054? No, install software is allowed here. Something that may be related and I forgot to say: With Nightly 20050905 I installed the new MDHashTool 0.4 Extension (only compatible with 1.0). Upon installation it said "Deer Park is checking for a compatibility update..." and stayed there. In EM the Extension was then grayed out and impossible to uninstall also after restarts etc., had to delete the staged xpis folder and the 3 extensions.* files.
Keywords: regression
Flags: blocking1.8b4?
Summary: Compatability checker checks endlessly → Compatibility checker checks endlessly
(In reply to comment #8) Common checkins for Tr/Br for those periods: bug 265028 [Core]-Clearing cache sometimes fails [All] bug 306502 [Core]-[FIXr]Hang loading page with mimetype application/javascript [All] bug 306504 [Core]-Numbers with decimal point but no digits following considered valid [All] bug 306591 [Core]-String static methods call with primitive value causes crash [Win]
*** Bug 307307 has been marked as a duplicate of this bug. ***
Per email discussion making this a 1.5b1 blocker
Flags: blocking1.8b4? → blocking1.8b4+
See bug 307376 - if this is caused by checking for updates to the default theme, it should be very simple to solve.
Ben, Can you take a look? Mike
Assignee: nobody → bugs
How to simulate the upgrade condition: open compatibility.ini in your profile directory and change the buildID number value to something else. open prefs.js in your profile and remove the "lastAppVersion" preference start the browser, it will think an upgrade has occurred and it should update your extensions.
There seem to be some real issues with compatibility checking. I'm going to look at this this afternoon, unless anyone has time to jump in sooner.
(branch build) After many iterations where this worked and worked, I finally got it to hang. It was trying to check for the flashgot extension to see if a compatible version existed. Here's the information for the check for updates request: *** RDFItemUpdater:checkForUpdates sending a request to server for: https://addo ns.mozilla.org/update/VersionCheck.php?reqVersion=1&id={19503e42-ca3c-4c27-b1e2- 9cdb2170ee34}&version=0.5.9.91&maxAppVersion=1.6&appID={ec8030f7-c20a-464f-9b0e- 13a3a9e97384}&appVersion=1.4&appOS=WINNT&appABI=x86-msvc, item = ({id:"{19503e42 -ca3c-4c27-b1e2-9cdb2170ee34}", version:"0.5.9.91", installLocationKey:"app-prof ile", minAppVersion:"1.0", maxAppVersion:"1.6", name:"FlashGot", xpiURL:"none", iconURL:"chrome://mozapps/skin/xpinstall/xpinstallItemGeneric.png", updateRDF:"" , type:2}) WARNING: NS_ENSURE_TRUE(nsDoc) failed, file c:/build/trees/1.5fxdbg/mozilla/cont ent/xul/content/src/nsXULElement.cpp, line 2583 Adn we never get an Addon Update ended response to this query. Does anything jump out at anyone in the syntax above? maxAppVersion says 1.6.
Could this be the problem? On a tip from Asa, I downloaded the resizeable text area extension using 1.0.6. This extension does not specify an update URL at all and is not hosted on addons.mozilla.org either. When I started up a branch build, I got the hang while checking for updates for this extension. The odd thing is that we are hitting addons.mozilla.org to check for an update for this extension even though this extension doesn't mention addons.mozilla.org at all. In the case of no updateURL, maybe we end up asking addons. And just maybe VersionChecks.php on addons doesn't know how to handle version checking extensions it knows nothing about so we never get an answer back from the server? *** RDFItemUpdater:checkForUpdates sending a request to server for: https://addo ns.mozilla.org/update/VersionCheck.php?reqVersion=1&id={5E8D157E-DA96-44e8-A461- 236DD8CC243C}&version=0.1a&maxAppVersion=1.0.1&appID={ec8030f7-c20a-464f-9b0e-13 a3a9e97384}&appVersion=1.4&appOS=WINNT&appABI=x86-msvc, item = ({id:"{5E8D157E-D A96-44e8-A461-236DD8CC243C}", version:"0.1a", installLocationKey:"app-profile", minAppVersion:"0.9", maxAppVersion:"1.0.1", name:"Resizeable Textarea", xpiURL:" none", iconURL:"chrome://mozapps/skin/xpinstall/xpinstallItemGeneric.png", updat eRDF:"", type:2})
Scott, that could very well be the case. It is by design that if there is no updateURL, we check with AMO. If AMO is not responding to unknown IDs then we should fix AMO.
(And in fact we are going to require that extensions on AMO not use a custom updateURL).
cc'ing some addons.mozilla.org folks in case comment 19 is true.
If you load that URL in your browser, you will see that it has no content.
URL: https://addons.mozilla.org/update/Ver...
for grins I manually changed extensions.update.url to point to a bogus server instead of addons.mozilla.org for my bad extension. When I ran firefox, we pinged the bogus server, got no response and promptly said no updates are available for this extension. That makes me think the problem really is with addons.mozilla.org and the version checker script. I think if we returned the right http error code instead of an empty document that we'd fix this bug. Either that or maybe some document that says no updates available (I don't know enough about the format of the response to this request to know what it should say).
I'd like to point out that (yes, if the server's broke, we should fix it, but...) the client side issue of the client hanging should be fixed anyway. We should never depend on the server to be functioning in order for the end-user to have a good user experience with something that's being forced on them by default. The client needs to have a sensible timeout and give up on the server soon enough for the end-user to not get impatient and dump the whole app in the trash because it doesn't work. (First impressions are everything). Each extension has its own update URL. Not all of them point at us. What if someone else's update URL does something weird?
A while back (March) there was some discussion about the way Firefox handles updates. As far as I know, it handles "blank" RDFs properly -- as Scott said -- by just assuming there is no update for a non-existent extension (an extension that may exist on the client-side but not on AMO). I think we can narrow down our problems to: a) How the client responds to a timeout. b) Whether or not timeouts and/or hangs for these requests are actually happening (and how to resolve them). c) Does the client get the right results for this specific type of check? How does this output differ from routine requests sent to VersionCheck.php? That said, here is a part of an email I sent in a discussion about cases for this update script, to clear up any confusion people might have about what's 'expected'. If these are wrong, please correct me: Let's assume we're updating an extension named "FooFoo" and your version is 0.7. Right now the RDF that VersionCheck.php generates has the following cases: 1) UMO has information on 0.8 and it's compatible with your OS. Description is provided along with update link. 2) UMO has information on 0.8 but it's not compatible with your OS. RDF is "blank", Firefox thinks there is no update. 3) UMO has no idea what FooFoo is. RDF is "blank", Firefox thinks there is no update. 4) UMO gets bad or missing arguments. XML error occurs and PHP dies and displays a message; Firefox thinks there is no update. 5) UMO has information on 0.7 (your current version), and it is the most current version for your OS. RDF sends back information about the current version.
fixing the client "right" is well beyond our capacity for 1.5: our rdf-loading mechanism's are torturously bad. I think that as long as we fix amo and make sure that the "cancel" button works we're doing bout as much as we can.
> 3) UMO has no idea what FooFoo is. > > RDF is "blank", Firefox thinks there is no update. the problem is that we are not returning a "blank" rdf. We're returning an empty page, which is not well-formed xml.
I'm not sure what changed but this was working previously with AMO. Perhaps the rdf service changed to handle the blank return differently?
Rob, are you sure the change to send extensions that have no update URL to addons.mozilla.org when doing the version check is something that wasn't added during the extensions update re-write for 1.5? This would be the first real test of us bumping the version string after the extension re-write I believe. So if that introduced the change that caused extensions without update urls to end up hitting addons.mozilla.org, then this could be the first time we're seeing the blank pages getting returned from the update server. As Benjmain said, getting an actual blank RDF file would probably fix this bug too. The problem is that we're getting an empty file all together.
Here is a plan of attack: 1) update VersionCheck.php to hand out properly formatted XML instead of a blank document 2) verify that this fixes the bug 3) verify that this does not cause regressions 4) push to production ASAP Ben, does that sound reasonable?
Assignee: bugs → morgamic
To determine the regressiondate I put one extension "Enhanced Bookmarks Search" with a changed ID and a maxVersion of 1.0 in the folder extensions. Then I run a build with a quite different LastVersion than the previous one. Like always the Compatibility checker appeared. In builds before 2005-08-31 the updater disabled and listed the extension. In builds after 2005-08-31 the checker disabled the extension and then got lost, showing only the green indicator until I clicked Cancel.
Mike, we think that's a great plan of attack for beta 1. We'll file a bug to try to make the extension update checker smart enough to handle an empty file on our end but that won't happen tonight for beta. If you post a test URL for us, we can manually change: extensions.update.url to point to the test site to help verify this fix.
QA, here are some straightforward steps to reproduce: 1) In Firefox 1.0.6, install the resize text box extension (http://www.extensionsmirror.nl/index.php?showtopic=2796) 2) Now run today's 1.8 branch build of Firefox. You should see the wizard come up that looks for extension updates. Before the server side fix, you should see the update dialog spin forever while looking for extension updates.
mscott - it did change during the rewrite nnd afterwards as well but I also tested this specifically several times (though I may have missed this scenario but I don't see how) and it was working just a few weeks ago. I also agree that returning valid data as bsmedberg stated would be a good thing and probably fix this as well.
(In reply to comment #36) > Ok - if you process this: > https://update-staging.mozilla.org/~morgamic/tip/update/VersionCheck.php?reqVersion=1&id={5E8D157E-DA96-44e8-A461-236DD8CC243C}&version=0.1a&maxAppVersion=1.0.1&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.4&appOS=WINNT&appABI=x86-msvc > > Does that alleviate the problem? Yup, the check for extension updates completes, informs me that no updates are available and then Firefox launches. This fixes the problem for me.
As mentioned earlier, no situation of any type encountered on the server end should cause the app to hang. The app needs to be fixed. I'm not sure if we have a separate bug for the server issue but there should be one. Mike's taking care of the server-side issue only.
Assignee: morgamic → bugs
There were no changes for nsExtensionManager.js when comparing a build that works to a build that doesn't. After a quick debug I found the following evaluates to true with the build that works and no longer evaluates to true with a build that doesn't work which appears to be the cause of this bug when the result returned from AMO is blank. if (!aDatasource.GetAllResources().hasMoreElements()) { So, I suspect something has changed outside of the EM in regards to how RDF datasources are handled. Since this can affect users when the datasource is not AMO I believe a fix on the client side would be a good thing. One possibility is to use xmlHttpRequest to first retrieve the datasource since it has more available in regards to seeing the state when retrieving the data prior to parsing it with RDF.
So - also looking at this and it seems that in the RDFItemUpdater.checkForUpdates function, the remote datasource is not already cached (rds.loaded = false), so the RDFItemUpdater is added to the RDFXMLSink as an observer. The implementation of nsIRDFXMLSinkObserver.onBeginLoad is then called. Nothing else happens! No onInterrupt/onResume/onEndLoad or onError.
My test case for invoking the compatibility checker appears flawed now, I'm reproducing this by creating a profile that is shared between 1.0.x and a deer park build, alternating back and forward causes this UI to appear every time the deer park build is loaded. You can see this same failure when an incompatible xpi tries to phone home to check for version info updates - in a v=1.4 branch build go to toolbar.google.com and try and install the google toolbar for Firefox, the entry in the list is stuck on "checking for a compatible version..." and never completes, same set of logging in the js console.
Re: if (!aDatasource.GetAllResources().hasMoreElements()) { I only repro'd this once and can't now... something very strange going on with RDF.
Rob - try going to toolbar.google.com and installing the toolbar for Firefox. You get the same underlying problem when the phone home check occurs
In this case, the return document is blank, and the content type defaults to text/html. This results in CNavDTD being used to parse the document, instead of the appropriate XML parser. So, from what I know, the RDF system used to gracefully handle the case when content type was inappropriately sent, and basically return null or something. That appears to no longer be the case. I'm not sure why or how.
I see the same with the google toolbar and I confirm regarding what appears to be a change with the RDF system. When I was writing the patch in bug 245082 I wanted to change the retrieving of data to use xmlHttpRequest since it is friendlier in regards to error handling. This could then hand off the retrieved data to the RDF system and doing this should fix this bug. If you like I can put together a patch that only does the items to fix this bug.
Rob - that would be great. I wish we had used a simple XML format (such as that used by aus) in the first place!
How would you hand off xmlhttprequest to rdf? rdf is parsed with a content sink, not a dom porocessor...
By doing something like this from the patch in bug 245082 + var rdfparser = Components.classes["@mozilla.org/rdf/xml-parser;1"] + .createInstance(Components.interfaces.nsIRDFXMLParser) + var ds = Components.classes["@mozilla.org/rdf/datasource;1?name=in-memory-datasource"] + .createInstance(Components.interfaces.nsIRDFDataSource); + rdfparser.parseString(ds, request.channel.URI, request.responseText); + + this.onDatasourceLoaded(ds, aItem);
Patch landed on VersionCheck.php. Still an issue?
If this change is now in production then I think that's good enough for beta one (once QA can verify it). We should leave this bug open and set the blocking1.8b5 for the client side fixes that Ben and others are discussing.
This appears to be fixed. I can now start Firefox 1.4/winxp without hanging in the compatibility update check. I tried this several times, and in all cases _except one_, it worked fine. I have not been able to reproduce the problem again. I would appreciate additional testing from others though.
With the version check change this WFM with AMO. The google toolbar ext. still exhibits the same bug since it does not check for updates on AMO. I should have a client side patch finished this evening.
Nice work on getting this patched server side this eve. Rob - are you saying the Google toolbar hangs on update still?
Mike - most assuredly yes. Something changed with the RDF system as Ben noted. The google toolbar version check returns essentially the same data as the AMO version check prior to the change to AMO so it hangs during the version check that happens during and upgrade as well as doesn't finish the install due to this change to the RDF system. This will affect any extension that provides its own updateURL that similar data as well and iirc from my previous testing there are a couple that don't on mozdev as well. I have already ported the relevant portions of the patch from bug 245082 and my tests so far show that it does fix this bug on the client side. I am going to do some more testing and post the patch afterwards in a couple of hours.
BTW: I emailed the authors of those extensions letting them know what was wrong but only heard back from one of them... I suspect some of them have been abandoned and I no longer have notes as to which ones.
Rob - thanks very much for the additional info. We spun a 1.5b1RC1 not too long ago - so depending on the time and risk of your patch drivers will have to figure out whether to re-spin a 1.5RC2 or not.
Don't know who to ask for review from at this stage so I'm leaving it open for any takers. This is based on the work done by Darin for the app update code and I tested it very thoroughly when I wrote it originally and also tested it tonight.
Assignee: bugs → rob_strong
Status: NEW → ASSIGNED
Attachment #195225 - Flags: review?
Comment on attachment 195225 [details] [diff] [review] use xmlHttpRequest to retrieve data >+ LOG("RDFItemUpdater:checkForUpdates sending a request to server for: " + >+ dsURI + ", item = " + aItem.objectSource); just for correctness, use uri.spec here for the log, since there might be a difference >+ var rdfparser = Components.classes["@mozilla.org/rdf/xml-parser;1"] >+ .createInstance(Components.interfaces.nsIRDFXMLParser) nit: interCaps >+ onXMLError: function(aEvent, aItem) { >+ try { >+ var status = aEvent.target.status; >+ var request = aEvent.target; >+ } >+ catch (e) { >+ request = aEvent.target.channel.QueryInterface(Components.interfaces.nsIRequest); >+ status = request.status; >+ } can you move request before status in the try block, just a little consistency thing that confused me when I skimmed the patch. Or even just move var status = request.status; after the try/catch, save a duplicated line. Other than that, this seems correct, to my understanding of the current state of update/EM.
Attachment #195225 - Flags: review? → review+
Additional testing: Netcraft toolbar is unaffected. Google and Yahoo toolbars both cause this bug (hang when 1.5 starts checking extension compat).
carrying forward mconnor's r+ and requesting 1.8b4
Attachment #195225 - Attachment is obsolete: true
Attachment #195227 - Flags: review+
Attachment #195227 - Flags: approval1.8b4?
I think we need a triple check from at least Ben, Benjamin and Darin on this before we look at re-spinning for this. IMHO.
Comment on attachment 195227 [details] [diff] [review] patch for checkin with niits picked a=schrep per discussion on email this is being approved so we can have a set of builds to test tomorrow a.m.
Attachment #195227 - Flags: approval1.8b4? → approval1.8b4+
I'll land this patch on the branch if I don't hear back from Rob in the next 20 minutes (I don't know if your still up or not Rob :)).
Landed on MOZILLA_1_8_BRANCH and Trunk.... I'm going to hold off on resolving this for a short while unless I'm told otherwise.
adding fixed1.8 keyword. Thanks a lot Rob.
Keywords: fixed1.8
resolving fixed... and you're welcome.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 307464 has been marked as a duplicate of this bug. ***
Verfied to work for me on the 9-8-07 Nightly build on windows. Tried the following: a) Ran 1.0.6 with Google Toolbar b) Ran branch build
Verfied to work for me on the 9-8-07 Nightly build on windows with the google toolbar. Leaving as Resolved because I would like a secondary verificaiton. Thanks Rob!
This one is still not fixed for me!!!! The offending extensions are text/plain 1.1.5 and IE View 1.2.4.0509020922 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 I was previously running a nightly branch from 9/5 I believe. The "Nightly Testing Tools" extension did not allow me to fix these to work with this build. I ran the updater several times in order to get to this current version. THIS BUG SHOULD BE REOPENED! Thanks.
sasquatch, this fix has nothing to do with making extensions which are listed as not being compatible actually show up as being compatible. You have to wait until the extension author retests and changes the maxversion of the extension. This bug is about a hang when trying to check for extension updates. As I've said to you before, please stop yelling in bugs. Thanks. (In reply to comment #70) > This one is still not fixed for me!!!! > > The offending extensions are text/plain 1.1.5 and IE View 1.2.4.0509020922 > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 > > I was previously running a nightly branch from 9/5 I believe. The "Nightly > Testing Tools" extension did not allow me to fix these to work with this build. > I ran the updater several times in order to get to this current version. > > THIS BUG SHOULD BE REOPENED! > > Thanks.
Comment on attachment 195227 [details] [diff] [review] patch for checkin with niits picked I'd like a followup bug: in this code we can safely assume that XMLHttpRequest is always available, so I'd like to avoid the dual codepaths. Secondly, what is the onXMLProgress function for? Can't we just omit it altogether?
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 -07 build this looks ok. I tested with a 1.0.6 profile with Yahoo toolbar and a few other extensions installed. When I launched the nightly I did not experience the hang. We should also verify this on Mac and Linux to make sure it works as expected.
Comment on attachment 195227 [details] [diff] [review] patch for checkin with niits picked patch looks good. here's some nit-picks fwiw: >Index: toolkit/mozapps/extensions/src/nsExtensionManager.js.in >+ // Only use xmlhttprequest if it is available - fallback to using only RDF >+ if ("@mozilla.org/xmlextras/xmlhttprequest;1" in Components.classes) { >+ var request = Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"] Define a constant for this ContractID so you don't have to duplicate it twice. >+ // AMO does not return responseXML when the installed version is the same >+ // as the lastest version so it must be handled seperately to avoid s/lastest/latest/ s/seperately/separately/ >+ request = aEvent.target.channel.QueryInterface(Components.interfaces.nsIRequest); Is this QI really necessary? nsIChannel inherits from nsIRequest.
(In reply to comment #71) > sasquatch, this fix has nothing to do with making extensions which are listed as > not being compatible actually show up as being compatible. You have to wait > until the extension author retests and changes the maxversion of the extension. > > This bug is about a hang when trying to check for extension updates. I had and continue to have these two extensions "hang" (in red in extensions manager) with "Deer Park is checking for a compatibility update to <name here>." I mentioned trying to make them compatible as my attempt to get around it, but it did not work.
If there is something I can check or look up to help resolve this, please let me know. I also tried reinstalling both extensions, but they are still hung up.
http://img327.imageshack.us/img327/870/compatibilitybroken9ew.jpg Screenshot showing that it is checking alongside the current version info.
Sasquatch - the problem that caused this bug has been fixed. I don't doubt that you are having problems but it isn't due to this bug. Perhaps a different bug, invalid extension data possibly caused by this bug or an extension, etc. If you want support please take it to the forums. If you can provide steps to reproduce what you are experiencing and it is a problem with the app then please file a new bug.
This doesn't appear to be fixed on Linux. I went from 1.0.6 with adblock and gmailnotifier installed. deleted that build and installed todays 1.4 build. The extension compatibility spun endlessly. "Cancel" to get app to launch, check for updates in EM shows no updates available for the two extensions.
Tracy - I ported / tested the patch on linux and it WFM... is it possible you have a build that doesn't have the fix?
Using Fedora Core 3 with the latest build, I did not experience the hang and I did get the "Incompatible Components" dialog.
(In reply to comment #79) > This doesn't appear to be fixed on Linux. I went from 1.0.6 with adblock and > gmailnotifier installed. deleted that build and installed todays 1.4 build. The > extension compatibility spun endlessly. "Cancel" to get app to launch, check > for updates in EM shows no updates available for the two extensions. Just tried the exact same steps on Windows. It also failed. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
I've tested it on both win32 and linux successfully though I haven't tested on Mac OS X... the only thing that comes to mind is possibly some interaction with app update but what I don't know. bug 307559 is one recent issue that has come to light.
(In reply to comment #78) > ...that caused this bug has been fixed. I don't doubt that > you are having problems but it isn't due to this bug. ... ???
(In reply to comment #84) > (In reply to comment #78) > > ...that caused this bug has been fixed. I don't doubt that > > you are having problems but it isn't due to this bug. ... > > ??? I'm not sure what you are speifically asking for but here goes comment #0 it describes the problem In several other comments the problem described in comment #0 was diagnosed and identified to be a change with the rdf system. Also, the differences between a build that did work and a build that didn't were identified as also stated in the comments which is how this change in behavior of the rdf system was further identified. A patch was created, tested, and landed that fixed the problem.
After further reproduction it looks like we've found one possibly unrelated reproducable case - documented in 307569.
bug 307569 is a regression caused by the patch for this bug though why exactly is not clear. Regretfully, when I wrote the patch I ported this patch from the upgrade extension update wizard didn't auto-close as it does now when it gets to 100% and all extensions are compatible or I probably would have seen bug 307569 sooner.
Depends on: 307569
Filed bug 308099 for addressing the comments.
ok, for people still having this bug I think it's realted to bug #308522, how I did trigger the bug: 1)having Nightly Tester Tools 0.7.9.1 (not the lasted version) 2)switching between Trunk and 1.4 (Beta 1). 3)the update dialog hung Nightly Tester Tools url for update don't seems to resolve: in Tools->Extensions if I click "Find Updates" the status stay at "Looking for updates to Nightly Tester Tools ..."
Yep, this bug is fixed and bug 308522 is another problem that I am currently working on a fix for.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: