329682 - Extension Manager, "Update Now" no longer works.

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[hhh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060307 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060307 Firefox/1.6a1

Clicking the  "Update Now" button in the extension Manager no longer works. Makes no difference if the update was detected manually or automatically.

Reproducible: Always

Steps to Reproduce:
1.Install Adblock Plus 0.5.11.2 from http://ftp.czilla.cz/other/addons/adblock-plus/0.5.11.2/adblockplus-0.5.11.2.xpi, restart Fx
2.Open E.M., click "Find Updates"
3. After update is detected, click "Update Now"
3.

Actual Results:  
Nothing

Expected Results:  
Extension should update and prompt for browser restart.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060307 Firefox/1.6a1 ID:2006030713

Will follow up w/ regression date.

Comment 1

[hhh]

Happens w/ both Gaius and Pacifica builds.

Comment 2

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

Also occurs with extensions other than adblock. Changing the even listener to capture fixes this so this appears to be an event related regression. Verifying which checkin caused this would be the next step.

Comment 3

[Simon Howes]

Updates on MacOS X, just to clarify just Win32.

Mac OS X has never prompted to restart Firefox though, apart from a little message in the Extentions Manager that states the extention will work once the browser is reloaded.  The prompt a win32 thing only?

Comment 4

[hhh]

(In reply to comment #3)
> Mac OS X has never prompted to restart Firefox though, apart from a little
> message in the Extentions Manager that states the extention will work once the
> browser is reloaded.  The prompt a win32 thing only?
> 
No, that's what I meant. I actually considered rephrasing that, dang ;)

Regressed between ID:2006030704 and ID:2006030713.

Sorry, I don't know where the hourly builds are archived.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Is this a regression from bug 234455.
I'll test this later today.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> Changing the even listener to
> capture fixes this so this appears to be an event related regression. Verifying
> which checkin caused this would be the next step.
> 

This sounds like someone is using initEvent in a wrong way in XUL.
I guess changing .initEvent("something..", false, true) to 
.initEvent("something..", true, true) fixes this.

Comment 7

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

(In reply to comment #6)
> This sounds like someone is using initEvent in a wrong way in XUL.
> I guess changing .initEvent("something..", false, true) to 
> .initEvent("something..", true, true) fixes this.
Quite likely

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/extensions/content/extensions.xml&rev=&root=/cvsroot#96
with the call to initEvent above

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/extensions/content/extensions.js&rev=&root=/cvsroot#163
is where the event listener is added

Comment 8

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

with the call to initEvent s/above/below/

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Possible patch

now I should still test this patch ;)
Or can anyone else confirm that this fixes the problem.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 214444 [details] [diff] [review]
Possible patch

yep, it works.

Comment 11

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

Comment on attachment 214444 [details] [diff] [review]
Possible patch

Thanks for the patch!

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #6)
> This sounds like someone is using initEvent in a wrong way in XUL.
> I guess changing .initEvent("something..", false, true) to 
> .initEvent("something..", true, true) fixes this.

What changed such that this used to work but now doesn't?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #13)
> What changed such that this used to work but now doesn't?

Er, never mind.  Bug 329659 comment 3 answers that.