Closed Bug 300114 Opened 17 years ago Closed 17 years ago
XPInstall dialog does not show when making use of browser
.link .open _external:1 (default on aviary1 .0)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050708 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050708 Firefox/1.0+ Since 20050707 builds installing extensions by double clicking on the saved filename.xpi is not possible anymore. Also after unsuccessful calling of the xpinstall dialog dragging and dropping files (extensions) on the browser window is not possible. This bug is probably caused by the one of security bugs that were fixed in this build (bug 298255 and bug 298892). Reproducible: Always Steps to Reproduce: 1. Try to install saved extension by double clicking on it (browser.link.open_external:1) = Tools -> Options... -> Tabs - 'Open links from other applications in:' - 'the most recent tab/window' Actual Results: The XPInstall dialog does not show -> extension can not be installed. Expected Results: The XPInstall dialog does show and allows to install the extension.
very related to bug 295058
(In reply to comment #1) Yeah but this bug showed lately and the mentioned bug probably never 'worked'.
Adding dependency because I'm rather sure that this was caused by a checkin for Bug 298255 (.xpi -> chrome://mozapps/content/xpinstall/xpinstallConfirm.xul). Confirming also on aviary1.0.5 - note that on 1.0.x the default is to open external links in current tab/window so this bug there has higher impact. On trunk the default is to open in new tab but this is another - bug 295058 doh! Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.9) Gecko/20050708 Firefox/1.0.5
Assignee: xpi-engine → dveditz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Dan, are we going to support local installs of XPIs? If so, then we probably need to address this. If not, can you minus?
Flags: blocking1.8b4? → blocking1.8b4+
Per dveditz, the fix for 300800 should also fix this one.
This is the same thing as bug 295058: Installs during pageload are blocked. I think what changed is that 298255 added an explicit clearing of the current content for external loads making it more like the new-tab case. Before, apparently, we'd see that the current (old) page was fully loaded and allow the install. Although bug 300800 fixes up aspects of the change for bug 298255, it's not going to do anything for this problem. bug 271567 would fix this, however.
Depends on: 271567
Whiteboard: [will be fixed by 300800]
fix for bug 271567 checked into trunk.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.