search

mozilla / addons

☂ Umbrella repository for Mozilla Addons ✨
Other
127 stars 41 forks source link

The font style on AMO prod looks different than -dev and stage #12350

Closed AlexandraMoga closed 6 years ago

AlexandraMoga commented 6 years ago

STR:

  1. Load AMO on a clean profile
  2. Observe the font style - see add-on names, Collection titles etc
  3. Compare the page with -dev or stage

Actual result: On -dev and stage the font is bold-ed while on prod is not

Expected result: Prod should have the same font style as -dev and stage

Notes:

[Prod] image

[Dev] image

willdurand commented 6 years ago

I see those messages in the console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://addons-amo.cdn.mozilla.net/979a13914c3398f40c3114ead422ed41.woff2. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://addons-amo.cdn.mozilla.net/668362de763a7132b42ce73dc1eabb74.woff2. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]

It is worth mentioning that one might not see any visual regression, because it depends on which font is loaded/used by the browser and you also might have it installed on your system.

willdurand commented 6 years ago

Fixed by @autrilla

autrilla commented 6 years ago

Mini-postmortem (probably only interesting for @bqbn)

Looking at the Network graph in DevTools you could see that none of the fonts were getting loaded because of missing Access-Control-Allow-Origin headers in the response. CSS and other static assets loaded fine. I verified that S3 was returning the correct response to CloudFront, and indeed S3 was returning the correct headers. Following this, I submitted an invalidation for /* to CloudFront, which fixed this issue.

As to why CloudFront cached responses without the CORS headers in the first place, I don't know for sure. One possibility is that the fonts got accessed by someone who didn't set the Origin header before https://github.com/mozilla-services/cloudops-deployment/pull/2451 was deployed, resulting in the response not containing CORS headers. This seems pretty unlikely, though.

A possible mitigation for this would be to cache based on the Origin header in CloudFront, so if someone provides a different Origin header, we'd issue a new request to S3.

We should also improve detection, because I'm guessing this started happening last Thursday. I think we should run UI tests against -prod and at least email us when they fail.

AlexandraMoga commented 6 years ago

Prod look good to me now too:

image

bqbn commented 6 years ago

Assuming this only happened to Chrome browser, it is weird too why Firefox was able to get the CORS related headers without having to invalidate /* in CloudFront.

My best guess is that it has to do with what's been described in [1], i.e. Chrome loaded the fonts from its local cache without the Origin header.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=409090#c7

autrilla commented 6 years ago

This was reproducible on both Firefox and Chrome, not just in Chrome.

bqbn commented 6 years ago

Oh, that's interesting. I thought it's only for Chrome, since https://github.com/mozilla-services/cloudops-deployment/pull/2451 was meant to fix a Chrome related issue.

I don't know then. And with the issue being fixed, I guess we can't reproduce it in order to find the cause either. :/