307569 - extension compatibility check doesn't complete

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Asa Dotzler [:asa]]

This but occurs on at least Windows and Mac with today's candidate build. 

Install 1.0.6.
Install Gmail Notifier <https://addons.mozilla.org/extensions/moreinfo.php?id=173>
Install 1.5 Beta 1 candidate

The compatibility wizard comes up and progress meter goes to 100% and just sits
there. On windows, changing focus away from the wizard and back to it via the
taskbar causes it to complete and Gmail Notifier is found to be compatible and
works when Firefox launches. On Mac, the hang cannot be forced through and the
user has to hit cancel.

Comment 1

[Scott MacGregor]

I've gotten the change of focus trick to work on the Mac but I know Marcia has
not. Very strange.

Comment 2

[Jay Patel [:jay]]

I have not seen the focus problem on Win XP at all, but can reproduce
consistently  on Linux (see bug 307567, which probably is a dup of this in some
way).

Comment 3

[Doron Rosenberg (IBM)]

Do we have a timeframe for when this regressed? I too can't reproduce on windows.

Note that it is enough to create a new profile in 1.0.6, install the extension,
restart, close, and open the profile in beta 1.

Also, when this happens, any Javascript errors in the console (given
javascript.options.showInConsole is set to true)?

Comment 4

[Robert Strong (they/them - no direct email)]

Attachment: patch - click it

Not sure exactly why but the wizard doesn't want to close. The xmlHttpRequest
is to blame but why it is to blame is unclear - might have something to do with
this being invoked before the main loop event the same as the wizard. Just
minimizing, unfocus/focus, or moving the wizard will make it close so I send a
click to the cancel button and it fixes it.

Comment 5

[Marcia Knous [:marcia]]

Here are my exact steps to reproduce on the mac.

1. Create a fresh profile and install GMail extension.
2. Restart and confirm that the extension is installed in 1.0.6
3. Launch the 1.5 beta build using the same profile
4. The compatability checker comes up and then freezes (at 100 percent)
5. Putting focus back on the checker does nothing.

This is 100% reproducible on the G5 we have in the office, running 10.4.2 with
the Firefox application installed in a folder on the desktop.

Comment 6

[Doron Rosenberg (IBM)]

(In reply to comment #4)
> Created an attachment (id=195340) [edit]
> patch - click it
> 
> Not sure exactly why but the wizard doesn't want to close. The xmlHttpRequest
> is to blame but why it is to blame is unclear - might have something to do with
> this being invoked before the main loop event the same as the wizard. Just
> minimizing, unfocus/focus, or moving the wizard will make it close so I send a
> click to the cancel button and it fixes it.

Is the request sync or async?
(In reply to comment #4)
> Created an attachment (id=195340) [edit]
> patch - click it
> 
> Not sure exactly why but the wizard doesn't want to close. The xmlHttpRequest
> is to blame but why it is to blame is unclear - might have something to do with
> this being invoked before the main loop event the same as the wizard. Just
> minimizing, unfocus/focus, or moving the wizard will make it close so I send a
> click to the cancel button and it fixes it.

Comment 7

[Robert Strong (they/them - no direct email)]

http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#5245

Comment 8

[Robert Strong (they/them - no direct email)]

Though it is a hack I have tested this on Win32 and Linux and it closes the
dialog automatically... don't have a Mac OS X system handy at the moment but I
suspect it will do the same. On Win32 it didn't find the updated compatibility
info one time but that is another bug... oh joy.

Anyone have any idea why minimizing / maximizing the wizard (e.g. click in in
the taskbar since it doesn't have the controls) would wake it up so it continues on?

Comment 9

[Ria Klaassen (not reading all bugmail)]

Here the compatibility checker either does not appear or disappear.
But weird enough it works in a branch 4 September build (after the regression).

1. I ran Firefox 1.0.6 in a new profile.
2. Went to https://addons.mozilla.org/extensions/?application=firefox and
installed  Flashgot, Adblock and Noscript.
3. Restarted 1.0.6.
4. Ran the latest branch build.
4. Compatibility checker did not appear at all the first time I tried it, the
second a third time it appeared but stayed.

Comment 10

[Benjamin Smedberg]

Rob, it may have something to do with the way we process event queues. Not sure
that helps a whole lot :-(

Comment 11

[Jay Patel [:jay]]

*** Bug 307567 has been marked as a duplicate of this bug. ***

Comment 12

[Jay Patel [:jay]]

I just dupped the bug I logged yesterday.  I am seeing this with Thunderbird
1.5b1 builds on Windows (although I have yet to see it with Firefox), but since
other have seen it, this is definitely a cross-platform, cross-product bug.

I even managed to crash with Thunderbird 1.5b1 when I tried focusing back to the
software update dialog:
Incident ID: 9187565
Stack Signature	RDFContentSinkImpl::OpenMember a7992010
Email Address	[e-mail]
Product ID	Thunderbird15
Build ID	2005090804
Trigger Time	2005-09-09 11:18:24.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	THUNDE~1.EXE + (0009ac21)
URL visited	focus crash
User Comments	software update was hung, switched focus away and back and boom!
Since Last Crash	5189 sec
Total Uptime	5189 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/rdf/base/src/nsRDFContentSink.cpp,
line 1244
Stack Trace 	
RDFContentSinkImpl::OpenMember 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/rdf/base/src/nsRDFContentSink.cpp,
line 1244]
RDFContentSinkImpl::HandleStartElement 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/rdf/base/src/nsRDFContentSink.cpp,
line 472]
nsExpatDriver::HandleStartElement 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 375]
Driver_HandleStartElement 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 87]
contentProcessor 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/expat/lib/xmlparse.c,
line 1942]
prologProcessor 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/expat/lib/xmlparse.c,
line 3618]
prologInitProcessor 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/expat/lib/xmlparse.c,
line 3449]
nsExpatDriver::ParseBuffer 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 855]
nsExpatDriver::ConsumeToken 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/htmlparser/src/nsExpatDriver.cpp,
line 984]
nsParser::Tokenize 
[e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/parser/htmlparser/src/nsParser.cpp,
line 2826]

Hopefully the stack helps us come up with a more complete fix to avoid the crash
as well (if we decide the current patch for passing a click event is not enough).

Comment 13

[Robert Strong (they/them - no direct email)]

Attachment: patch

Benjamin - same as the other patch except this removes the redundant call to
close and the comment is clearer as to why we use a click here.

Comment 14

[Robert Strong (they/them - no direct email)]

Checked in on trunk

Checking in mozilla/toolkit/mozapps/extensions/content/update.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/content/update.js,v  <--  update.js
new revision: 1.18; previous revision: 1.17
done

Comment 15

[Robert Strong (they/them - no direct email)]

Checked in on MOZILLA_1_8_BRANCH

Checking in mozilla/toolkit/mozapps/extensions/content/update.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/content/update.js,v  <--  update.js
new revision: 1.17.2.1; previous revision: 1.17
done

Comment 16

[Robert Strong (they/them - no direct email)]

*** Bug 310489 has been marked as a duplicate of this bug. ***

Comment 17

[Jesse Ruderman]

This was fixed again in bug 314754.

Comment 18

[Robert Strong (they/them - no direct email)]

Specifically it was fixed again using a different method due to a change outside of the EM / extension update code that broke the original method used to fix this.