i have latest browser of chrome and firefox but anyway text and buttons not showing up for me

[sprom]

- Do you want to request a feature or report a bug?

- What is the current behavior?

- If the current behavior is a bug, please provide the steps to reproduce.

- What is the expected behavior?

- Please mention your operating system version and the version of your browser

[sprom]

im front-end developer and im sure problem not with my device

[indysigner]

Hi @sprom, do you have any screenshots that you could share with us? Ideally with the Console tab in Devtools open. Thank you!

[vitalyfriedman]

Dear @sprom — could you check if you still have the issue in here: https://deploy-preview-1958--smashing-magazine.netlify.com/ ?

Thank you!

[ronyth]

This happened too on my Chrome Version 62.0.3202.94 (Official Build) (64-bit) and Firefox 57.0 (64-bit). https://deploy-preview-1958--smashing-magazine.netlify.com/ look same.

[ronyth]

Here's Console log on Chrome (if that helps) Slow network is detected. Fallback font will be used while loading: https://d33wubrfki0l68.cloudfront.net/9c2752fab289f61c6ed3a1f78ab60fb2034103b7/bf691/fonts/elenawebregular/elenawebregular.woff And I'm pretty sure my internet is not that slow.

[vitalyfriedman]

Dear @ronyth — is it still the case now? We deployed a fix a few days ago! (see https://www.smashingmagazine.com/)

[ronyth]

@vitalyfriedman Yes, it is. I cleared browser history too. On the last Console output it says: ReferenceError: OA_output is not defined at postLoadLater ((index):2998) at (index):3013

[criterion9]

I have the same behavior in Chrome. I do not see any blocked resources and ABP is disabled on the domain.

The font-family line when disabled shows the text. .wf-loaded-stage2 .h2, .wf-loaded-stage2 h2 { / font-family: Mija; / }

[vitalyfriedman]

Interesting, @criterion9, can you check what happens if it says:

.wf-loaded-stage2 .h2, .wf-loaded-stage2 h2 { font-family: Mija, sans-serif; }

Does the text appear then?

[criterion9]

That still doesn't render. It looks like most of the fonts that are put in with html.wf-loaded-stage2 fail to render but also do not fall back. First place I would check since that means the render believes it has an appropriate font is any CDN node issues maybe caching a "bad" font file?

[zachleat]

Can you clear your site’s application storage in the devtools?

“Clear site data” at the bottom. I wonder if something was corrupted in your serviceworker.

[deddythok]

same here. i'm using latest chrome and latest firefox

[criterion9]

Cleared all local files (cache, worker, cookies, etc) tagged for the domain and still no font render. For what it is worth attempting to convert the mija_regular-webfont.woff2 to a ttf using an online converter created a corrupted file.

[criterion9]

Also, the returned headers from CloudFront indicate a cache hit on edge. Probably a corrupted file in the chain somewhere.

[vitalyfriedman]

Humm... @zachleat — is it possible that MijaInitial was corrupted for some reason during subsetting?

[zachleat]

It seems unlikely if we can't reproduce in the same OS and browser combination. Who did the subsetting? Is this something we can diagnose at the CDN level? Does Cloudfront offer tools for this kind of thing?

[criterion9]

It loads fine on my home computer (that hadn't attempted to load it since sometime a couple months ago). I would assume you need to invalidate cache at the edge. CloudFront offers an invalidation tool that can be used to force a refresh of a particular asset (or assets matching a pattern). This would make particular sense if a fix had been pushed recently and may not have reached all edge caches.

[vitalyfriedman]

Will be checking with @biilmann on Netlify if we could address it on the Cloudfront side of things. As for subsetting: it appears that only Mija seems to be problematic although some screenshots have missing Elena as well. I'm wondering about MijaInitial and ElenaInitial — they don't really have any fallback stack, right? Perhaps adding Arial or sans-serif or something would help? @zachleat

[zachleat]

@vitalyfriedman I think adding a fallback to the initial stack is unlikely to help. As you can see on http://output.jsbin.com/guruvel even using a stack that has no valid families still has an implied fallback.

This appears to be a FOIT, which to me suggests it’s a repeat view with a corrupted font file in one of the caches (or hanging request). Remember, repeat views using the sessionStorage trick fallback to the default font loading behavior (it’s assuming those fonts are in cache now, which is a good assumption since they’re in the SW right?).

Well, wait. The fonts aren’t in the service worker, are they? Those urls no longer match, since they’re loading from the CDN: toolbox.router.get('/fonts/*/*.woff2', toolbox.cacheFirst); from sw.js.

[vitalyfriedman]

Uhm, that's something that @pukhalski can answer better!

[zachleat]

@vitalyfriedman I think my recommendation at this point will be to remove the ServiceWorker checks for the web fonts for now, since the URLs aren’t correct in the toolbox setup (as of today it is still using the local paths to your fonts, not the correct CDN urls that are being used in other places on the site).

Change 1

Specifically, this means changing the JavaScript in the header from this:

if (sessionStorage.foutFontsStage1Loaded && sessionStorage.foutFontsStage2Loaded ||
   ('serviceWorker' in navigator && navigator.serviceWorker.controller !== null && navigator.serviceWorker.controller.state === 'activated')
) {
  var docEl = document.documentElement;
  docEl.classList.add('wf-loaded-stage1');
  docEl.classList.add('wf-loaded-stage2');
}

to this:

if (sessionStorage.foutFontsStage1Loaded && sessionStorage.foutFontsStage2Loaded ) {
  var docEl = document.documentElement;
  docEl.classList.add('wf-loaded-stage1');
  docEl.classList.add('wf-loaded-stage2');
}

Change 2

later in the document

if (sessionStorage.foutFontsStage1Loaded && sessionStorage.foutFontsStage2Loaded ||
   ('serviceWorker' in navigator && navigator.serviceWorker.controller !== null && navigator.serviceWorker.controller.state === 'activated')
) {
} else if ('fonts' in document) {
  // …

should be this:

if (sessionStorage.foutFontsStage1Loaded && sessionStorage.foutFontsStage2Loaded) {
} else if ('fonts' in document) {
  // …

Either those serviceworker checks need to be removed from the inlined JS in the head OR the toolbox urls need to be fixed to point to the CDN urls.

[vitalyfriedman]

Thanks @zachleat — @pukhalski can you look into it, please?

[vitalyfriedman]

Just fixed the toolbox URLs, @zachleat — @sprom @ronyth @criterion9, could you double check if it's working for you now? www.smashingmagazine.com

[criterion9]

That is actually worse. Almost no text shows now.

[vitalyfriedman]

Uhm. That's quite strange. It's still Chrome? Windows or Mac? Can you try to use Chrome Canary or an incognito window, please? @criterion9

[criterion9]

Same results using incognito. Windows 7 on Chrome.

[criterion9]

Not sure if this might help but a URL the service worker is attempting is getting stuck in WebSense: aHR0cHM6Ly9zdGF0cy5nLmRvdWJsZWNsaWNrLm5ldC9yL2NvbGxlY3Q_dj0xJmFpcD0xJnQ9ZGMmX3I9MyZ0aWQ9VUEtNjA1MjEyMzctMSZjaWQ9ODQ4NjAyNTI1LjE1MTYzODg2MzcmamlkPTY0Mjk5Mzg2NiZfZ2lkPTEzNzU4NTc2ODYuMTUxNjg4ODA3MSZnamlkPTE3MjkwODA2NjImX3Y9ajY2Jno9MTc4MDM5Mzg

[zachleat]

Interesting! How’d you discover that?

[criterion9]

That request was getting force redirected to a capture portal over http instead of https so it was highlighted in the network tab. So I took a closer look. Not sure if that is helpful or not but figured I would share.

[criterion9]

Got a new build from work and I can see text now. This new build was Windows 8.1.

[vitalyfriedman]

Still quite mysterious, but glad that the issue was (finally) resolved! @criterion9