We should explore creating an add-on API to allow an add-on to create a footer at the bottom of a home panel. One concern here is that this would conflict with the snippets footer if the user makes this panel the default. I'm not sure if we would want the add-on footer to take precedence, or if we should show the snippets footer instead (or have them work together somehow?).

Does the snippets footer show up on all home panels? I was thinking it only displayed for Top Sites.

(In reply to Mark Finkle (:mfinkle) from comment #1) > Does the snippets footer show up on all home panels? I was thinking it only > displayed for Top Sites. No, it shows up on whatever panel is the default. So for the majority of users this is probably Top Sites, but it can show up elsewhere. We could also change the logic to make it only show up on our Top Sites panel, but then we can't assume that users will all see this banner. However, it's not super noticeable right now, either, so maybe people don't see it much anyway. And even desktop snippets only appear on about:home, which not all users see either.

Anthony, do you have some updated mock-ups you could attach here?

This should follow the same snippet specs from bug 1064461. But I did find that in most cases, we will need to make the "x" more visible so I placed a 30dp x 30dp, white, circle centered to and behind the "x" icon. So, maybe we can add that in for this bug.

(In reply to Anthony Lam (:antlam) from comment #4) > This should follow the same snippet specs from bug 1064461. I guess the most important question for me is: Do we want this footer to be something that is attached to the add-on panel and behaves somehow like snippets. Or do we want to extend the snippet API to support something like big images / banners? Biggest difference will be: Snippets show up on whatever is the default panel of the user. And they'll show content from different sources. Extending the home panel API will attach this footer only to this panel but we'll have to take care of footer and snippet being visible at the same time.

(In reply to :Sebastian Kaspari from comment #5) > (In reply to Anthony Lam (:antlam) from comment #4) > > This should follow the same snippet specs from bug 1064461. > > I guess the most important question for me is: Do we want this footer to be > something that is attached to the add-on panel and behaves somehow like > snippets. Or do we want to extend the snippet API to support something like > big images / banners? > > Biggest difference will be: Snippets show up on whatever is the default > panel of the user. And they'll show content from different sources. > Extending the home panel API will attach this footer only to this panel but > we'll have to take care of footer and snippet being visible at the same time. Personally, I'm in favor of extending our current home banner API (the thing we use to show snippets). Having different banners on multiple panels seems pretty obtrusive, and I'm also worried about some of the implementation/UX details of swiping from one panel to the next when they have different banners. So yes, this means that the banner wouldn't be tied to a given panel, and it also means that we'd have to figure out how to make add-ons play nicely with our snippet system (or let them override it entirely), but that still seems simpler than allowing multiple banners.

I talked to Sebastian about this a bit earlier. I'm all for less-snippets in our panels. So keeping them to just the home panel works for me.

If we keep control of the snippet to just the home panel API, can that pull content from different sources or would that all be managed through a single course (for displaying content)? I think it makes sense to simply extend as well for consistency of implementation.

This is a WIP version of a patch adding big images to the banner API.

And that's a screenshot showing the current version. It'll be impossible to create a banner image that will work across form factors so we'll need to think about how we want to handle that. I've also a patch flying around where I implemented this footer as static view attached to the panel. In that patch I used the same approach that Google uses when serving AdMob smart banners[1]: The banner height is dynamically chosen based on the height of the device (depending on current orientation). This makes the banners look good on different form factors but there will still be empty space to the left and right in some cases. [1]: https://developers.google.com/admob/android/banner#smart_banners

Not continuing to work on this for now.

Let's not do this.