Compatibility checker checks endlessly

RESOLVED FIXED

Status

()

RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: ria.klaassen, Assigned: rstrong)

Tracking

({fixed1.8, regression})

unspecified
x86
Windows XP
fixed1.8, regression
Points:
---
Bug Flags:
blocking1.8b4 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

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.

Comment 1

13 years ago
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.
(Reporter)

Comment 2

13 years ago
In branch I get nearly the same result:
1.8b4_2005083106 (works) - 1.8b4_2005083120 (fails).

Comment 3

13 years ago
Confirming on Firefox and Thunderbird!
(Reporter)

Comment 4

13 years ago
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.
(Reporter)

Updated

13 years ago
Severity: minor → normal

Comment 5

13 years ago
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 ?

(Reporter)

Comment 7

13 years ago
Peter - builds and settings make really no difference, only the date of the
build counts.

Comment 9

13 years ago
(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.

Comment 10

13 years ago
(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.

Updated

13 years ago
Keywords: regression

Updated

13 years ago
Flags: blocking1.8b4?
(Reporter)

Updated

13 years ago
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] 

Comment 12

13 years ago
*** Bug 307307 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
Per email discussion making this a 1.5b1 blocker
Flags: blocking1.8b4? → blocking1.8b4+

Comment 14

13 years ago
See bug 307376 - if this is caused by checking for updates to the default theme,
it should be very simple to solve.

Comment 15

13 years ago
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.

Comment 18

13 years ago
(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.

Comment 19

13 years ago
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})

Comment 20

13 years ago
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.

Comment 21

13 years ago
(And in fact we are going to require that extensions on AMO not use a custom
updateURL).

Comment 22

13 years ago
cc'ing some addons.mozilla.org folks in case comment 19 is true.

Comment 23

13 years ago
If you load that URL in your browser, you will see that it has no content. 

Comment 24

13 years ago
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.

Comment 27

13 years ago
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.

Comment 28

13 years ago
> 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?

Comment 30

13 years ago
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.

Comment 33

13 years ago
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.

Comment 34

13 years ago
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.

Comment 37

13 years ago
(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!

Comment 47

13 years ago
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);

Comment 49

13 years ago
Patch landed on VersionCheck.php.  Still an issue?

Comment 50

13 years ago
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. 

Comment 51

13 years ago
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.

Comment 53

13 years ago
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.

Comment 56

13 years ago
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.   
Created attachment 195225 [details] [diff] [review]
use xmlHttpRequest to retrieve data

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+

Comment 59

13 years ago
Additional testing: Netcraft toolbar is unaffected.  Google and Yahoo toolbars
both cause this bug (hang when 1.5 starts checking extension compat).
Created attachment 195227 [details] [diff] [review]
patch for checkin with niits picked

carrying forward mconnor's r+ and requesting 1.8b4
Attachment #195225 - Attachment is obsolete: true
Attachment #195227 - Flags: review+
Attachment #195227 - Flags: approval1.8b4?

Comment 61

13 years ago
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 62

13 years ago
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+

Comment 63

13 years ago
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.

Comment 65

13 years ago
adding fixed1.8 keyword. Thanks a lot Rob.
Keywords: fixed1.8
resolving fixed... and you're welcome.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
*** Bug 307464 has been marked as a duplicate of this bug. ***

Comment 68

13 years ago
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

Comment 69

13 years ago
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!

Comment 70

13 years ago
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 71

13 years ago
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 72

13 years ago
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 74

13 years ago
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.

Comment 75

13 years ago
(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. 

Comment 76

13 years ago
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.

Comment 77

13 years ago
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.

Comment 84

13 years ago
(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.

Comment 86

13 years ago
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.
Filed bug 308099 for addressing the comments.

Comment 89

13 years ago
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.