Closed Bug 1287200 Opened 8 years ago Closed 6 years ago

update mozilla.org to latest version of jQuery

Categories

(www.mozilla.org :: Bedrock, defect)

Production
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jpetto, Assigned: jpetto)

References

Details

(Whiteboard: [q3 sprint 5])

Attachments

(1 file)

To improve the experience served to very old browsers [1], in addition to restricting first-class CSS, we should also restrict first-class JS.

Currently in old browsers, pages like /firefox/channel/ are served full JS but minimal CSS, resulting in a less than ideal frankenpage. (Working buttons, but without the proper CSS to complete the UI.)

To ensure A-grade content is hidden on old browsers, refactoring on quite a few existing pages will be required. Given the variable complexity and comparatively arduous testing/QA, it seems preferable to roll out the changes in stages rather than in one giant PR.

A side effect of this change will be improved page speed on A-grade browsers, as we'll be able to update to the latest (smaller, faster) release of jQuery.

[1] currently IE 8 and below
Assignee: nobody → jon
My assumption is that we'll need to serve at least a little JS in order to:

1) Run analytics
2) Have smart download buttons (platform detection and popup for old IE)

It would be awesome if I'm wrong, and we can actually serve *no* JS at all.

:jbertsch - thoughts?
Flags: needinfo?(jbertsch)
Peter - When you have a moment, please chime in on how important it is to keep all current GA/GTM scripts loading for IE 8 and below.

Thanks!
Flags: needinfo?(peter.german.bugs)
After meeting with pg and jbertsch, the plan is as follows:

1) Analytics

We need to keep the GA/GTM scripts that are currently in production.

2) Download button

Since we need to serve *some* JS, if it's easier to keep the smart/platform detecting button, we'll go that route (for now).

If it's comparable effort to display the no-JS/dumb download links, we will run a short experiment (Optimizely being the traffic cop) to ensure the dumb download links don't significantly hurt downloads.
Flags: needinfo?(peter.german.bugs)
Flags: needinfo?(jbertsch)
James, Jon is going to give you some URLs to validate later this week that the download buttons are working. Please be sure that they will work in IE8 as these changes are targeted at IE8 users.
Hey James - 

Here are a few URLs to test in IE8:

https://bedrock-demo-jpetto.us-west.moz.works/
https://bedrock-demo-jpetto.us-west.moz.works/firefox/channel/
https://bedrock-demo-jpetto.us-west.moz.works/firefox/products/

You should see a series of download links/buttons instead of a single "smart" download button. Each of the "dumb" links has a data-link-type and data-download-os attribute, which will hopefully satisfy GA.

Let me know if the downgraded experience works in terms of analytics.

Thanks!
Flags: needinfo?(james.lorence)
jpetto,

Downloading tracking is working as expected on the downgraded experience on IE8.
Flags: needinfo?(james.lorence)
Adding bug 1282386 for reference here. There's currently an issue in GTM when clicking direct download links in IE7/8 that invokes the security blocker. This problem doesn't currently manifest itself on the main /new download page, since the redirect is handled by the page JS. But could there be a chance it will become more prevalent when we deprecate JS support more widely?

James and Gareth are working with Google to try and resolve the issue.
See Also: → 1282386
Whiteboard: [q3 sprint 2]
Depends on: 1292528
Whiteboard: [q3 sprint 2] → [q3 sprint 3]
Hey jpetto,

Because of the issue with IE7/8 browsers referenced in bug 1282386, I had to alter our tracking solution for downloads in IE7/8. For those buttons that redirect a user to the /firefox/new?scene=2 page, the download event now tracks when landing on the /firefox/new?scene=2 page and not the button click. This solution just went live today.

But while testing I noticed that this new experience where "dumb" download links are served does not redirect to the /firefox/new?scene=2 page. This will works out fine in the long run as one of the issues with IE7/8 download tracking is due to the redirect, but I will need to make some updates in GTM when this new experience goes live becasue of the changes I just made.

Is there an ETA on when it will go live? And can I get a day advance warning when it does official go live?
Flags: needinfo?(jon)
Also, I noticed that when I was getting served the "dumb" links, there were no data attributes on them.

Were they just not added for the experiment? Without those we really will lose downloads so just making sure it's a known issue.
(In reply to James Lorence from comment #8)
> But while testing I noticed that this new experience where "dumb" download
> links are served does not redirect to the /firefox/new?scene=2 page. This
> will works out fine in the long run as one of the issues with IE7/8 download
> tracking is due to the redirect, but I will need to make some updates in GTM
> when this new experience goes live becasue of the changes I just made.

Yep, the "dumb" links don't do a redirect - they have no smarts. ;) These links just point directly to a build of Firefox.

> Is there an ETA on when it will go live? And can I get a day advance warning
> when it does official go live?

We are planning to test the "dumb" links for IE 8 on /firefox/new/ (en-US only) as soon as the pop-up issues are resolved. After the pop-up issues are resolved, we'll wait on the green light from you before starting the test.

> Also, I noticed that when I was getting served the "dumb" links, there were
> no data attributes on them.

I just updated my demo server [1] with data-* attributes on the "dumb" links. Can you give it another test in IE 8? I noticed the pop-up issues are still present, though based on your previous comment, I think this is expected.

[1] https://bedrock-demo-jpetto.us-west.moz.works/en-US/firefox/new/?v=2
Flags: needinfo?(jon) → needinfo?(james.lorence)
(In reply to Jon Petto [:jpetto] from comment #10)
> I just updated my demo server [1] with data-* attributes on the "dumb"
> links. Can you give it another test in IE 8? I noticed the pop-up issues are
> still present, though based on your previous comment, I think this is
> expected.
> 
> [1] https://bedrock-demo-jpetto.us-west.moz.works/en-US/firefox/new/?v=2

I am seeing the data attributes now.

Are you saying that you're still triggering the security blocker pop-up when clicking the links? I implemented a solution in GTM yesterday afternoon and am looking for someone on the Moz team to validate that the solution worked, but Alex Gibson is out. Can you confirm whether the issue is resolved or not?
Flags: needinfo?(james.lorence)
Yep, on my demo [1] (which does have GTM configured, as far as I can tell), I am getting a pop-up blocker in IE 8 when clicking one of the "dumb" download links. If I disable JS on IE 8 and test again, I do not get the pop-up blocker, which points to GTM still being the culprit.

It does not appear the issue is resolved.

[1] https://bedrock-demo-jpetto.us-west.moz.works/en-US/firefox/new/?v=2
Jon,

I've noticed that the data attributes needed to track download clicks are still not on the "dumb" links that are live right now. IE downloads have dipped over the past few days which is somewhat due to recent GTM changes that I've addressed, but we'll continue to be missing a lot of downloads until those data attributes get added.
Flags: needinfo?(jon)
Hey James - 

Hm, IE users currently don't get the "dumb" links in production unless they have explicitly turned off JavaScript. I didn't realize we had so many users getting served the "dumb" version of the download button. Can you offer a little insight as to what platforms/browsers are seeing the "dumb" links?

I've filed bug 1296114 to add the data attributes. Please give the PR [1] a look to make sure they are as expected.

Thanks!

[1] https://github.com/mozilla/bedrock/pull/4287
Flags: needinfo?(jon)
Jon,

I was using a Chrome plugin for testing different user agent values for IE6/7/8 becasue of a GTM change I was making and I was getting the "dumb" links, but not consistently. I thought I had read something about a experiment being run for these and was concerned I was getting bucketed into an experiment when I saw those and so just wanted to make sure we were still getting downloads.

I don't know what the impact of not having the data attributes there have been as we had switched tracking from button clicks on download buttons to tracking when landing on the /firefox/new/?scene=2 page. Something broke with that solution though and that's why the IE downloads dropped the last few days. I updated GTM to go back to tracking on button clicks though and so wanted to flag this as I knew the missing data attributes would mean no tracking.
(In reply to James Lorence from comment #15)
> Jon,
> 
> I was using a Chrome plugin for testing different user agent values for
> IE6/7/8 becasue of a GTM change I was making and I was getting the "dumb"
> links, but not consistently. I thought I had read something about a
> experiment being run for these and was concerned I was getting bucketed into
> an experiment when I saw those and so just wanted to make sure we were still
> getting downloads.

Hm, not sure why you were intermittently getting the dumb links. Something with the plugin? We are waiting for this GTM popup blocker issue to be resolved before starting the experiment.

> 
> I don't know what the impact of not having the data attributes there have
> been as we had switched tracking from button clicks on download buttons to
> tracking when landing on the /firefox/new/?scene=2 page. Something broke
> with that solution though and that's why the IE downloads dropped the last
> few days. I updated GTM to go back to tracking on button clicks though and
> so wanted to flag this as I knew the missing data attributes would mean no
> tracking.

Yeah, for old IE, we do some JS gymnastics to get around the popup blocker - basically opening our own popup that triggers the download while the original page redirects to ?scene=2.
Whiteboard: [q3 sprint 3] → [PBL]
Whiteboard: [PBL] → [q3 sprint 5]
Summary: Do not serve page JS to old IE → update mozilla.org to latest version of jQuery
The work for this bug will now:

- Update mozilla.org to the latest version of jQuery for IE 9+ and all modern browsers.

- Serve a minimal JS bundle (including jQuery 1.11.3) to IE 8 and below. The primary purpose of this bundle is to enable pop-ups on the download buttons.

- Serve only the bare minimum JS to IE 8 and below, meaning no site_js or stub_attribution bundles.
pg - No rush at the moment, but can you check in to how important GA/GTM is for visitors using IE 8 and below? It would be easier/more future-proof if we can only focus GA/GTM on IE 9+, but it's not a *huge* deal either way (yet).

Thanks!
Flags: needinfo?(pgerman)
cmore - How important is stub attribution for visitors using IE 8 and below? (pg's answer to comment 19 may inform us here.)

Similar to above, this isn't something that's difficult at the moment, but will likely cost us more the longer it stays around (as we'll likely end up with an IE <= 8 fork of the JS).
Flags: needinfo?(chrismore.bugzilla)
I just checked out downloads from non-Firefox browsers for the past 30 days using this IE <=8 segment:

Browser = Internet Explorer
Browser version matching regex ^[0-8]\..+$

That IE <=8 segment is 10% of our global downloads, which is still significant. That is larger that I would have guessed. Thus, we need to ensure attribution is still working for these users as that is a decent size of our visible funnel and I wouldn't want to accidentally count them toward the dark funnel.

Gareth: any feedback or comments?
Flags: needinfo?(pgerman)
Flags: needinfo?(chrismore.bugzilla)
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/09fd36ef1cdb520f2a9efe393b74af6ed8b22905
[fix bug 1287200] Update jQuery to latest release.

- Serves minimal bundle (w/jQuery 1.11) to <= IE 8
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: