295058 - XPInstall dialog does not show when making use of browser.link.open_external:3 (default)

Status: RESOLVED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Przemyslaw Bialik]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050521 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050521 Firefox/1.0+

Tools -> Options... -> Tabs - 'Open links from other applications in:' - 'a new
tab in the most recent window' - this is a good default setting but sadly when
trying to install extensions - by double clicking on the saved filename.xpi
(which is preferred for many method of installing single extensions) the
XPInstall dialog does not show (only new emtpy tab is created).

Reproducible: Always

Steps to Reproduce:
1. Try to install saved extension by double clicking on it
(browser.link.open_external:3)

Actual Results:  
The XPInstall dialog does not show -> extension can not be installed

Expected Results:  
a - The XPInstall dialog does show and allows to install the extension (preferred)
b - Show notification bar similar to the one when "Allow websites to install
software" is unchecked and trying to install extensions

Comment 1

[Przemyslaw Bialik]

If this bug would not be fixed for FF 1.1 then maybe at least change the default
setting to 'Open links from other applications in:' - 'the most recent tab/window' ?

Comment 2

[Daniel Veditz [:dveditz]]

Confirming...

The browser.link.open_external default changed from current window (1) to new
tab (3) between 1.0 and Deer Park (changed to open in new window for trunk
seamonkey). There were good usability reasons for this change--users not losing
an in-progress webmail or blog entry at the whim of an external program for
example--that can't be undone just to fix this bug.

Turning off xpinstall.whitelist.required does not make this start working, so
unfortunately it's not simply a referrer issue.

Comment 3

[Daniel Veditz [:dveditz]]

This window opening style is now the Deer Park default, and clicking on raw .xpi
links appears to be how UMO is set up --> bad combination. Presumptively
blocking Deer Park Alpha 2 to get it on the radar.

Comment 4

[Chris Beard]

can't reproduce, the basic path is working (e.g. UMO or other extensions web
sites), and "drag and drop" to the extension manager also works -- if you still
see a serious problem, please renominate.  is your testcase only around .xpi
files saved to disk? 

Comment 5

[Chris Beard]

nominating for b4 to keep it on the radar

Comment 6

[Bob Clary [:bc] (inactive)]

On Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050720
Firefox/1.0+ with 

browser.link.open_external 3
browser.link.open_newwindow 2
browser.link.open_newwindow.restriction 0

Clicking on an xpi in Windows explorer and clicking on a direct http link to an
xpi on a web page pops up the install dialog without changing the page.

Comment 7

[Jorge Villalobos [:jorgev] (he/him)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050718
Firefox/1.0+ ID:2005071806
This bug is not directly related to the preference. It's more general:
Ctrl-clicking and Middle-clicking on a link that points to an XPI also opens a
blank tab without starting the installer.

Comment 8

[Fred Collier]

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050722 Firefox/1.0+

Possible related observation when double-clicking an xpi file.

When browser.link.open_external is set to 3, I experience the problem as reported.

All is well if browser.link.open_external is set to 2.

When browser.link.open_external is set to 1, the existing window is frozen and
scrolling is impossible with keys or mouse. The install routine also does not start.

Comment 9

[Wladimir Palant]

I can reproduce both problems (opening from external applications and
middle-clicking on the link) in Firefox 1.0.6 as well.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The problem described in comment 8 doesn't occur there so this one is most
probably not related (I can confirm it for the most recent nightly though).

Comment 10

[Przemyslaw Bialik]

(In reply to comment #7)
Yeah it's not about this preference only but about showing XPInstall dialog in
new tab in general but this bug mostly affects only this new tab case so I've
used it as example in my report.

browser.link.open_external:1 is Bug 300114.

Comment 11

[Corinne Bordelon]

Per dveditz, fix for 300800 should also fix this one.

Comment 12

[Boris Zbarsky [:bzbarsky]]

The two issues I saw in bug 300800 don't seem related to this, so I fail to see
how a fix for those issues could possibly fix this bug.  There might be other
issues there, of course.

Comment 13

[Daniel Veditz [:dveditz]]

bug 300800 has nothing to do with this. The fix for bug 298255 did cause similar
bug 300114, but this bug predated that change and in any case bug 300800 doesn't
address the parts of 298255 that caused 300114.

Basically what is happening is that the new tab is in the loading state, and we
don't allow installs during page load to prevent abuse. bug 271567 asks that we
stop blocking those because we have whitelisting now to prevent those types of
abuses in a more general way.

Comment 14

[Daniel Veditz [:dveditz]]

nominating for 1.8b4 because I think this is the main reason bug 300800 was a
release blocker.

Comment 15

[Scott MacGregor]

Dan, so if we plussed this one, do you think we can safely remove 300800 from
the 1.8b4 stop ship list?

Comment 16

[Daniel Veditz [:dveditz]]

fix for bug 271567 checked into trunk.

Comment 17

[Daniel Veditz [:dveditz]]

fix for bug 271567 checked into 1.8 branch