In order to preview Personas, a website must be on the add-ons whitelist in Firefox. By default, that whitelist is addons.mozilla.org, and for 3.6 getpersonas.com was added to it. As mozilla.com will have firstrun and whatsnew pages that feature Personas to be previewed, mozilla.com would have to be added to the add-ons whitelist or changes would need to be made in product. I see at least 3 possible solutions: 1) add mozilla.com to the whitelist This raises additional issues, because the same whitelist is used for normal add-on installation, and my testing indicates that mozilla.com being on the whitelist means *.mozilla.com is on the whitelist. So, we would need to go through all the sites on *.mozilla.com and make sure no user submitted links to content exist so we don't have another bug 521076. 2. make whitelist checking less greedy, so that mozilla.com means *only* mozilla.com, not *.mozilla.com 3. requires string changes, but add a tiered whitelist such that sites on the whitelist can be for "Personas only" or "All add-ons" Filing in mozilla.com though this bug could probably fit in about 5 components :)
This probably won't work, but can add www.mozilla.com instead? This would remove the problem with mozilla.com counting for *.mozilla.com
Hey justin, Just sent email about this, but I believe the plan has been to host the firstrun/whatsnew pages on mozilla.com, but iframe out to AMO/getpersonas for the personas content. The content in the iframe will have the appropriate permissions, and saves us from having to extend trust to the whole mozilla.com domain. Do you see problems with that approach?
As a side comment, I've already complained about getpersonas.com being in the xpinstall whitelist where it doesn't belong, and I look forward to pushing for its removal during the lightweight themes security review. The xpinstall whitelist and the lightweight themes whitelist should be two separate lists.
Looks like that will work. I didn't see anything about an iframe in the implementation bug 521531 and I don't know if getpersonas.com knew they needed to host this, but that would fix our problem I think.
(In reply to comment #2) > Just sent email about this, but I believe the plan has been to host the > firstrun/whatsnew pages on mozilla.com, but iframe out to AMO/getpersonas for > the personas content. I see a few possible problems. One is this requires a lot more moving parts on both mozilla.com & getpersonas.com. We also may want locale-specific personas, and getpersonas.com doesn't have any content localized (yet). The other is this will point a firehose (or 2 or 3) at getpersonas.com. While we are scaling it up for the increased amount of traffic from 3.6, I'm not sure if it can handle getting hit on every firstrun page load. Matthew would know best if it can handle it. And afaik, I didn't know we were hosting this page.
Could we do a workaround similar to what we do here: http://viewvc.svn.mozilla.org/vc/addons/trunk/site/app/webroot/google/ Would that get us what we need? The JS workaround could be on different hardware and cached like all hell.
Based on our discussion in yesterday's Personas Uplift meeting, it sounds like we are going to go ahead and use the iframe method for now, although Ryan and I are concerned about the scaling and performance of this method. There are already other mozilla.com pages besides firstrun and whatsnew that are planning to have Personas previews and will all have to use iframes and degrade mozilla.com's performance and increase load on getpersonas. Plus, it's just generally hacky. Someone on the mozilla.com/Personas side (i.e., not me) will need to coordinate which pages need to be built on getpersonas for the iframes and their URLs. ----- Firefox developers: I'm wondering how hard it would be to make a tiered whitelist for 3.6 post-beta1. If we change the exceptions dialog's Status column from the static "Allow" text to being a dropdown where the user can choose "Personas" or "All Add-ons", it would require minimal UI and string changes and solve a lot of our problems.
I'm working on the firstrun (bug 521531) and whatsnew (bug 521532) pages. These two pages each have two layout variations (URLs are in the comments on the bugs). Who do I work with to figure out what parts will live in the iframe and who gets it set up? So far, the pages just have static placeholders for the persona previews.
(In reply to comment #9) > Who do I work with to figure out what parts will live in the iframe and > who gets it set up? That would be me ;). Ideally *only* the pieces with persona images will be an iframe. I see a 3x2 grid in the mockups, so that would be 1 iframe containing all of them. Let's get it started by filing a bug under getpersonas.com with the specs (dimensions, personas, etc).
Filed this as Bug 522754 and added a few details there. Tara, can you add the list of which personas will be used? Will this bug be wontfixed, or is there still some hope of fixing this and avoiding the iframe?
(In reply to comment #8) > Based on our discussion in yesterday's Personas Uplift meeting, it sounds like > we are going to go ahead and use the iframe method for now, although Ryan and I > are concerned about the scaling and performance of this method. What are the issues (are they any different than hosting the content elsewhere?)?
The issue we were unsure about is whether getpersonas.com can support all of the traffic it will receive from firstrun and whatsnew pages in 3.6 if there is an iframe on those pages with getpersonas.com in it.
(In reply to comment #13) > The issue we were unsure about is whether getpersonas.com can support all of > the traffic it will receive from firstrun and whatsnew pages in 3.6 if there is > an iframe on those pages with getpersonas.com in it. We're planning for it to and we're planning on fronting getpersonas.com with a CDN.
Ok, then it sounds like the iframe method will be feasible. That's being tracked over in bug 522754 and the tiered whitelist is being blocked in bug 522522, so I think this bug can be closed. Thanks everyone!
Setting the resolution to WONTFIX, as mozilla.com will stay off the whitelist.