User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 I try to download an extension and receive a message saying Firefox prevented it. I click on "Edit Options", and add the site to my "Allow" list. I try to download the extension again and Firefox still blocks it. I closed Firefox and restarted it to see if this helped, but it still doesn't allow me to download an extension from the website even though I have manually added it to my allow list. Reproducible: Always Steps to Reproduce: 1. Click "Download" (for any of the extensions). 2. Click "Edit Options" -> "Allow" -> "Close" 3. Click "Download" again Actual Results: I keep receiving a message that Firefox blocked the download. Expected Results: After I add the site to my allow list, Firefox shouldn't block downloads from it anymore. Theme: default Extensions: Adblock Plus 0.7.2.2 Forecastfox 0.9.3.1 Tabbrowser Preferences 126.96.36.199
Where is it you're trying to download the extension from?
http://www.graysonmixon.com/extension I was unable to find the addon I wanted from the usual extensions page, so I went to it's homepage to download it. I'm able to download it on my older version of Firefox (188.8.131.52) just not the new version I installed on my main computer.
Confirming this. The site links to extensions on the host 184.108.40.206:8080 yet when you attempt to install the warning bar and subsequent add to whitelist all refer to the original host (www.graysonmixon.com) so unless you add "220.127.116.11:8080" manually to the whitelist you cannot install the extensions.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: unable to download extension after adding to safe list → Wrong host added to whitelist when xpi hosted on a different server
Sounds like this is xpinstall since it is the code at work at this stage
Assignee: nobody → xpi-engine
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: extension.manager
Version: unspecified → 1.8 Branch
Slightly different to what I first thought actually. The webpage is actually a frameset with the main frame being on the server 18.104.22.168:8080, the same server as the xpi is held on. But the whitelist check and add all work from the host of the top level webpage.
Summary: Wrong host added to whitelist when xpi hosted on a different server → Wrong host added to whitelist when xpi linked to in a frame on a different server
This is a regression in 2.0, 1.5x worked fine. Google toolbar is facing a similar problem if people remove the default whitelisted host. In both cases the extension is launched from a subframe on a different host, graysonmixon.com frames http://22.214.171.124:8080/extension/ and the Google toolbar install launches the install by opening a frame on addons.mozilla.org http://tools.google.com/firefox/toolbar/install.html In 1.5 the install whitelist infobar offers to add the correct host (126.96.36.199 or addons.mozilla.org), and in 2.0 the infobar wants to add the topmost host. The xpinstall code did not change in the whitelisting area. It looks like it's checking the source (frame) against the whitelist correctly, it's the notification and/or front-end event handling that's gone wrong. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpinstall/src/nsInstallTrigger.cpp&rev=FIREFOX_2_0_RELEASE#249 Note the above code hasn't changed since the aviary landing, FF1.0 Possible xpinstall broken assumptions: - did nsIScriptGlobalObjectOwner::GetScriptGlobalObject() change behavior? - is the wrong aWindowContext being passed in? - is GetDocShell() returning a different shell? (there are similar notifications from scripted installs in nsJSInstallTriggerGlobal.cpp -- don't know if those are similarly broken or if it's just the link click ones that are. Looks like the infobar widget was reworked in FF2.0, and now instead of using the shell (aSubject) passed by the notification it's using the shell from the current browser -- that'd match the symptoms we're seeing, too. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&mark=670,709&rev=FIREFOX_2_0_RELEASE#663 Is the fix as simple as passing shell to xpinstallEditPermissions() on line 709 instead of browser.docShell ? I'm on vacation and can't drive this any further, I'm assigning to Neil based on cvs blame. Would like this fixed in 2.0.0.x which shouldn't be a problem if it's as simple as I'm guessing. But I don't know the new infobar widget
Assignee: xpi-engine → enndeakin
Component: Installer: XPInstall Engine → General
Product: Core → Firefox
Version: 1.8 Branch → 2.0 Branch
Created attachment 246183 [details] [diff] [review] Change shell reference Yes, the fix is that simple.
Attachment #246183 - Flags: review?(mano)
Comment on attachment 246183 [details] [diff] [review] Change shell reference r=mano
Attachment #246183 - Flags: review?(mano) → review+
Not blocking, but wanted, patch should be approved (Neil, can you nominate for approval188.8.131.52?)
Flags: blocking184.108.40.206? → blocking220.127.116.11-
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 246183 [details] [diff] [review] Change shell reference approved for the 1.8 branch, a=dveditz for drivers
Attachment #246183 - Flags: approval18.104.22.168+
Neil, do you remember you have a 22.214.171.124 checkin pending here?
Verified fixed for trunk and 126.96.36.199. Verified with: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a2pre) Gecko/20070206 Minefield/3.0a2pre ID:2007020604 [cairo] for trunk Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:188.8.131.52pre) Gecko/20070206 BonEcho/184.108.40.206pre ID:2007020604 for 220.127.116.11
Status: RESOLVED → VERIFIED
Keywords: fixed18.104.22.168 → verified22.214.171.124
12 years ago
Depends on: 372819
You need to log in before you can comment on or make changes to this bug.