Wrong host added to whitelist when xpi linked to in a frame on a different server




12 years ago
12 years ago


(Reporter: priestessmiaka, Assigned: enndeakin)


({regression, verified1.8.1.2})

2.0 Branch
Windows XP
regression, verified1.8.1.2
Bug Flags:
blocking1.8.1.1 -
blocking1.8.1.2 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)




(1 attachment)



12 years ago
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
Adblock Plus
Tabbrowser Preferences
Where is it you're trying to download the extension from?

Comment 2

12 years ago
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 ( just not the new version I installed on my main computer.
Confirming this. The site links to extensions on the host 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 "" manually to the whitelist you cannot install the extensions.

Severity: major → normal
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, 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 and the Google toolbar install launches the install by opening a frame on addons.mozilla.org


In 1.5 the install whitelist infobar offers to add the correct host ( 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.


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.


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
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.1?
Keywords: regression
Product: Core → Firefox
Version: 1.8 Branch → 2.0 Branch

Comment 7

12 years ago
Created attachment 246183 [details] [diff] [review]
Change shell reference

Yes, the fix is that simple.
Attachment #246183 - Flags: review?(mano)
QA Contact: general
Comment on attachment 246183 [details] [diff] [review]
Change shell reference

Attachment #246183 - Flags: review?(mano) → review+
Not blocking, but wanted, patch should be approved (Neil, can you nominate for approval1.8.1.1?)
Flags: blocking1.8.1.1? → blocking1.8.1.1-


12 years ago
Last Resolved: 12 years ago
Resolution: --- → FIXED
Flags: blocking1.8.1.2+
Comment on attachment 246183 [details] [diff] [review]
Change shell reference

approved for the 1.8 branch, a=dveditz for drivers
Attachment #246183 - Flags: approval1.8.1.2+
Duplicate of this bug: 366639
Neil, do you remember you have a checkin pending here?


12 years ago
Keywords: fixed1.8.1.2
Verified fixed for trunk and

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: Gecko/20070206 BonEcho/ ID:2007020604 for
Keywords: fixed1.8.1.2 → verified1.8.1.2
You need to log in before you can comment on or make changes to this bug.