964791 - (fx-update-banners) Ensure existing Firefox Update Banners still work

Status: VERIFIED FIXED

(Firefox Affiliates Graveyard :: affiliates.mozilla.org, defect)

Description

[Osmose [:osmose, :mkelly]]

There is a special banner that shows a different image based on whether the viewer's browser, if it's Firefox, is up-to-date or not, that was added in bug 719522. The implementation currently uses an .htaccess file generated during the push process based on some settings.

The implementation of these banners will probably be updated, but we should still make sure that existing banners in the wild still function correctly.

Comment 1

[Osmose [:osmose, :mkelly]]

So I looked into this some more and talked with Chelsea about it. We've decided to move forward with using JavaScript to control the image-switching functionality of these banners, instead of depending on the existing Apache-config-based system (see bug 976804 for implementation of that).

Essentially, the switching behavior won't happen on the server when the user accesses the image, but instead it will happen via the JavaScript included with the banner code. The side effect here is that, by removing the server-side switching, we're breaking all the existing banners. However, we feel the tradeoff of not supporting the old banners is worth it given that:

- Only 20 or so of these banners have >100 clicks.
- Only 4 of them have >1000 clicks.
- Only 1 has >3000 clicks, and that particular banner doesn't use the image-switching function anyway.

Thus the impact of this change will be pretty low. For existing banners, what will happen is that, instead of showing a different image depending on what version of Firefox the user is on, they'll revert to showing one image to all users (which image hasn't been decided; Do we want the "Upgrade" message or the "Different by Design" message?).

Scope of this bug is now to make sure existing banners show the right image rather than preserve the switching behavior.

Comment 2

[Chelsea Novak [:chelsea]]

Thanks for this Mike. I think we want to show the "different by design" message. 

I will write a blog post explaining this change. I assume it will happen at re-launch? Also, I can e-mail those 25 people directly and let them know about the pending change. 

Sound good?

Comment 3

[Osmose [:osmose, :mkelly]]

(In reply to Chelsea Novak [:chelsea] from comment #2)
> Thanks for this Mike. I think we want to show the "different by design"
> message.

Luckily, this appears to be the default behavior if we just remove the code, so yay!
 
> I will write a blog post explaining this change. I assume it will happen at
> re-launch?

Yes.

Comment 4

[Justin Crawford [:hoosteeno] [:jcrawford]]

This bug is incorporated in the Affiliates 2.0 release currently live in dev: https://affiliates-dev.allizom.org/

Comment 5

[Osmose [:osmose, :mkelly]]

I'm removing [qa-] from this because the original purpose of this bug - to make sure that existing update banners still worked with the new site - is still relevant. After input on Chelsea's blog, we decided to not move away from an apache-based upgrade banner system, and were able to support older upgrade banners.

This is tricky to test, though, because affiliates-dev has already been migrated. What we'll have to do is have mbrandt or someone create a upgrade banner on affiliates-stage, and keep it around so that when we migrate stage prior to going to prod, he can test to ensure that his old banner code still works (as in, the image still displays correctly based on the user's Firefox version, and clicking the banner still increments the banner click count).

Does that sound like a good plan?

Comment 6

[Matt Brandt [:mbrandt]]

QA verified on stage (pre-launch) and production (post-launch) -- banners created prior to the redesign persist as well as continue to aggregate click counts.