305694 - dragging extension from finder produces infinite "install now" loop

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Krishna Sethuraman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050816 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050816 Firefox/1.0+

When I open a finder window with some (possibly older) .xpi files, I can drag
one into the main deerpark window.  It pops down the "A web site is requesting
to install the following item", and then counts down for 2 seconds before
enabling the 'Install Now' button.

However, on clicking the 'Install Now' button, it simply disables the button,
counts down for 2 seconds again, and re-enables itself.  Repeating the process
appears to produce the same behavior.

Reproducible: Always

Steps to Reproduce:
1. Download a .xpi file to a local directory.
2. Open that directory up in a Finder window.
3. Open a build (within the last week) of Deerpark for the Mac.
4. Drag the .xpi file into the Deerpark window.
5. Wait for the 2-second countdown.
6. 'Install now' will become enabled.
7. Click on 'Install Now' button.
8. If bored, go to step 10.
9. Go to step 5.
10. Go to Tools->Extensions and notice the .xpi hasn't been installed.
Actual Results:  
The extension never got installed.

Expected Results:  
I expected the extension to be installed or at least to have dismissed the
dialog with some kind of error or complaint.

I tried moving my Firefox profile directory (~/Libraries/Application
Support/Firefox -> .../Firefox.old ) and starting Deerpark again, with identical
behavior.  I've noticed this in the last few nightlies, but it may have appeared
prior to that.

MacOSX 10.3.8.

Comment 1

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

Sounds like fallout from bug 239411 and that bug 302265 didn't get completely
fixed by the patch for bug 302136.

Comment 2

[Gary Elshaw]

Krishna, were you seeing this on trunk or branch? Confirmed here on branch:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050823
Firefox/1.0+ (OS X 10.4.2)

Comment 3

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

Gary - from the ua reported with it is on trunk but there are very few
differences between trunk and branch for this code at this time. Glad you found
a bug that describes what you are experiencing. :)

Comment 4

[J Haag]

Seeing the same thing here. 

Build: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
Gecko/20050823 Firefox/1.6a1

I see this whether I drag the file to the window or use "Open File..." on both
trunk and branch builds since 8/16.

Comment 5

[Krishna Sethuraman]

> Krishna, were you seeing this on trunk or branch?

I've been pulling down nightlies using a script, and only now became aware that
there were '1.0+' as well as '1.6a' .mac.dmg files.  I noticed the problem on
20050816 of 1.0+, but reproduced it on the 20050823 1.6a also.

Per http://www.squarefree.com/burningedge, entry for 2005-08-23:

> Trunk builds of Firefox use the version number 1.6a1, which prevents most existing
> extensions from working. You can work around this by setting
app.extensions.version
> in about:config to 1.0+.

I tried this -- but the behavior was identical.

Comment 6

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

Attachment: patch

Benjamin, there were a couple of problems on the Mac I found that didn't affect
Win32. The textbox in the installitem that has the url always took focus so
even after getting the focus and blur straightened out it would still require
two clicks. This was fixed by focusing the button before disabling it. I also
changed the focus listener to not capture events since I don't believe it is
necessary to accomplish the desired behavior and used a boolean to keep track
of focus instead for simplicity... plus I don't trust the value of
_installCountdownInterval to always be what it needs to be for this.

Comment 7

[Benjamin Smedberg]

Comment on attachment 193680 [details] [diff] [review]
patch

I'm not sure I understand how this actually works on windows (or mac, for that
matter, but I bet you've tested it to death on mac). Wouldn't this reset the
counter any time you tab between elements in the dialog?

Comment 8

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

Comment on attachment 193680 [details] [diff] [review]
patch

Grrr... I just noticed that. I'm not sure how best to fix this which is why I
didn't take the bug. I can take a look again this afternoon PDT unless you have
the time to.

Comment 9

[Benjamin Smedberg]

I'll need a couple hours to make a clean-ish mac build... I'll look in a bit. I
hate our focus code!

Comment 10

[Hank Roberts]

Prior head-banging discussion among some of us who were perplexed:

http://forums.mozillazine.org/viewtopic.php?t=308078&start=15&sid=8569a0ff8b742570a65acc58c802bd96

Comment 11

[Jason Reep]

Just another confirmation of this bug.  Since, I think, around the 8-19 trunk
build I've not been able to install any extensions (even maxversion corrected
ones) due to the endless 'Install Now' loop.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050822
Firefox/1.6a1

Comment 12

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

Attachment: patch

Focus is not my friend... I took another look at this and decided using
setTimeout was the best way to achieve the desired behavior. The only problem I
see now is on Win32 where if the browser is not focused during a DnD the
counter isn't reset - strangely enough it does on Mac OS X.
On Mac OS X and Win32 I tested:
tabbing between controls (note: Mac OS X got stuck in the url but that is a
different bug)
install from a web page including blur and focus countdown resets
install from DnD including blur and focus countdown resets

I also fixed bug 305536 and bug 302595 in this patch.

Comment 13

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

Note: "if the browser is not focused during a DnD the counter isn't reset"
refers to if an explorer window has focus when the DnD occurs. After giving
focus to the browser it behaves correctly and from what I can tell this only
affects a user initiated install but there may be other ways to reproduce this
but I believe they would be edge cases.

Comment 14

[Benjamin Smedberg]

Comment on attachment 193784 [details] [diff] [review]
patch

Is the change back from tenths to seconds prompted by Ben/mconnor? Last I heard
mconnor was trying half-seconds.

Thanks for fixing bug 305536 at the same time!

Comment 15

[Benjamin Smedberg]

Need this for b4, may also need this for the rc.

Comment 16

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

Attachment: countdown with whole numbers and 500 ms

Per discussion on irc the countdown decrements every 500 ms and starts at 5

Also, it now calls setWidgetsAfterFocus in init so the initial values can be
set in one place.

Comment 17

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

Checked in on trunk - leaving open for possible 1.8b4 approval

Checking in mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js;
/cvsroot/mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js,v  <-- 
xpinstallConfirm.js
new revision: 1.7; previous revision: 1.6
done

Comment 18

[J Haag]

Downloaded the latest cadence build and it is fixed for me.

OS X 10.4.2

Comment 19

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

Checked in to branch as well

Checking in mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js;
/cvsroot/mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js,v  <-- 
xpinstallConfirm.js
new revision: 1.5.2.2; previous revision: 1.5.2.1
done

Comment 20

[Tracy Walker [:tracy]]

this is working on Deer Park branch build 2005-09-01-05-mozilla1.8