Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Web Fonts may not render correctly in Chrome #6275

Closed
iwehrman opened this issue Dec 19, 2013 · 32 comments
Closed

Web Fonts may not render correctly in Chrome #6275

iwehrman opened this issue Dec 19, 2013 · 32 comments
Assignees
@njx
Labels
fixed but not closed
Milestone
Release 0.44

Comments

@iwehrman
Copy link
Contributor

Update:

Originally, the bug was that the web fonts on the Getting Started page would often render as blank when using live development in Chrome 32 (which was in beta at the time).

Chrome 32 is now in the stable channel, and we removed the web fonts from Getting Started as a workaround so people wouldn't experience the issue with the Getting Started page. However, this could still occur with other pages that use web fonts in live preview.

It's not clear whether this only happens with Edge Web Fonts (which we were using on the Getting Started page) or whether it would happen with other web fonts as well. It's possible that there's something specific about the EWF loading script that was triggering some new bug in Chrome.

Original screenshot:

"fonts"

This may be a Chrome beta issue; I'm using 32.0.1700.55.
@iwehrman
Copy link
Contributor Author

It still reproduces with Chrome 32.0.1700.68.

@larz0
Copy link
Member

larz0 commented Dec 19, 2013

I can't reproduce it on Chrome Version 32.0.1700.68 beta (OS X Mavericks).

Running the HTML file within the source code.
screen shot 2013-12-19 at 11 29 42 am

@iwehrman
Copy link
Contributor Author

Sometimes it takes a few tries. It also might be sensitive to the width of the window? I've seen it on both 10.9.0 and 10.9.1.

CC @peterflynn

@redmunds
Copy link
Contributor

I just hit this on Mac 10.8.5 with Chrome 32.0.1700.68 beta.

@peterflynn
Copy link
Member

Tagging Sprint 36 -- we should make sure a Chromium bug exists for this issue so it doesn't get into stable builds without warning.

@iwehrman Should we remove "with Live Development" from the title? I'm pretty sure we reproduced it on your machine from a plain old file:// URL too...

@iwehrman
Copy link
Contributor Author

Ohhh right. Yes, good call.

@ghost ghost assigned njx Dec 20, 2013
@njx
Copy link
Contributor

njx commented Dec 20, 2013

To me for now, medium priority.

@njx
Copy link
Contributor

njx commented Dec 20, 2013

I did some searching in the Chromium bugbase. There have been a number of issues filed regarding webfonts, but they seem to involve them falling back to a non-webfont rather than failing to render entirely. All of the recent webfont bugs have been duped to https://code.google.com/p/chromium/issues/detail?id=236298, which was filed in April, whereas our bug only started happening with the latest beta, so I don't think it's the same issue.

I'm trying to create a reproducible case that we can file against Chromium, but am having difficulty. I can easily reproduce this from Live Preview in Brackets, but have been unable to reproduce it by just launching Chrome from the command line. Even if I hit the built-in Brackets server, and launch using:

open -g -n -a "Google Chrome" --args 
    --no-first-run
    --no-default-browser-check 
    --remote-debugging-port=9222 
    --user-data-dir=/Users/nj/Library/Application\ Support/Brackets/live-dev-profile/ 
    http://127.0.0.1:50331/index.html

which I think simulates exactly what brackets-shell does in OpenLiveBrowser(), I can't get the problem to happen.

@njx
Copy link
Contributor

njx commented Dec 20, 2013

One possible theory: it requires the interstitial page to be loaded first in order for the problem to occur. That wouldn't explain why @iwehrman saw it with an ordinary file URL, but perhaps it's more likely to happen if another page was in the middle of loading in the same tab, or some such.

@njx
Copy link
Contributor

njx commented Dec 20, 2013

Or, slightly differently, perhaps it has to do with the fact that the target page is loaded via remote debugging instead of from the command line.

@njx
Copy link
Contributor

njx commented Dec 21, 2013

I did an experiment where I made it so instead of Live Development agents initializing on the page load event, they initialize on the "frameStoppedLoading" event. This seemed to get rid of the problem, probably because it avoids touching anything until the web font loading script has completed. Not sure this really gets us closer to figuring out the underlying problem (and it doesn't at all affect the point that we were at one time able to reproduce it by manually navigating to a file URL), but it's a data point.

@njx
Copy link
Contributor

njx commented Jan 10, 2014

Another data point: moving the font script to the bottom of <body> fixes the problem, again presumably because it changes the timing of font loading so it doesn't interfere with whatever connection we're making in Live Development.

njx added a commit that referenced this issue Jan 10, 2014
@njx
Remove webfonts from Getting Started to avoid #6275 when Chrome bug h…
7240492 
…its the stable channel. Redo screenshots to reflect updated html/css.
@njx njx mentioned this issue Jan 10, 2014
Merged
@njx
Copy link
Contributor

njx commented Jan 11, 2014

Moving to sprint 37. We have a workaround for the Getting Started material in case the bug hits Chrome stable soon.

@marcelgerber
Copy link
Contributor

FYI: Chrome Stable was updated today.
http://googlechromereleases.blogspot.de/2014/01/stable-channel-update.html

@njx
Copy link
Contributor

njx commented Jan 14, 2014

Good thing we added the workaround :) I confirmed that, without the workaround, the problem occurs in the new stable build.

@njx
Copy link
Contributor

njx commented Jan 25, 2014

This has been moved to Ready. Removing milestone.

@njx
Copy link
Contributor

njx commented Jan 30, 2014

Updated title and description to reflect the current state of things.

@njx
Copy link
Contributor

njx commented Jan 30, 2014

BTW, I just verified that it happens with Typekit's loading script as well.

I'm thinking it has something to do with the fact that the scripts deliberately block rendering in order to avoid the FOUT. The timing of when they allow rendering to continue is probably tickling some new bug/behavior in Chrome.

I'm going to try to see if someone on the EWF/Typekit team can help figure this out.

@njx njx mentioned this issue Feb 4, 2014
Closed
@njx
Copy link
Contributor

njx commented Feb 4, 2014

@rogervila ran into this in #6701 as well. He ran into it with the Google Fonts loader, so it isn't something specific to the EWF/Typekit loader (although it might be similar or the same).

@njx
Copy link
Contributor

njx commented Feb 19, 2014

The MissionBit students were running into this with (I think) Google Fonts as well.

@njx njx mentioned this issue Feb 24, 2014
Closed
@jasonsanjose jasonsanjose mentioned this issue Feb 25, 2014
Merged
@redmunds
Copy link
Contributor

Looks like this was fixed in Chrome 33: http://blog.typekit.com/2014/02/04/chrome-bug-affecting-web-fonts/

@jasonsanjose
Copy link
Member

I saw it today with PR #6997 and Chrome 33 on windows. 😢

@njx
Copy link
Contributor

njx commented Feb 25, 2014

Interesting. I've been suspecting that the bug they fixed was different from ours - the bug they fixed was one where web fonts fall back to a system font. The last comment on that Typekit post sounds more like the problem that we're seeing (where the web font disappears completely). It's good to know that it's reproducible outside of our live development case, although it doesn't really help us figure out how to reproduce it...

@njx njx mentioned this issue Mar 3, 2014
Open
@njx njx added this to the Brackets 1.0 milestone Mar 14, 2014
@njx
Copy link
Contributor

njx commented Mar 14, 2014

This is already in Ready but I'm nominating it for 1.0 since we definitely want it fixed by then.

@JeffryBooher
Copy link
Contributor

Seems pretty stable with Chrome 34.0.1847.76 beta on Mac.

@njx
Copy link
Contributor

njx commented Mar 25, 2014

@JeffryBooher What files were you testing with? Did you sync back to an earlier version of Getting Started that used webfonts?

@JeffryBooher
Copy link
Contributor

@njx I was testing my own code from scratch which helped me uncover some other problems but I had a conversation with @peterflynn who suggested a few other test scenarios to look at. I should have amended my comments to reflect that. I will have a look at the old getting started page before we ripped out EWF and see how it does later tonight.

@JeffryBooher JeffryBooher assigned JeffryBooher and unassigned njx Mar 25, 2014
@JeffryBooher
Copy link
Contributor

Verified that all scenarios are fixed in Chrome 34. Moving to Tracking.

@njx
Copy link
Contributor

njx commented Mar 25, 2014

Does it work in Chrome 33 as well? (That's what I would expect if the changes we made to Live Preview startup timing were what fixed it.) If so, maybe we should just close it as fixed.

@bchintx bchintx assigned njx and unassigned JeffryBooher Mar 31, 2014
@JeffryBooher
Copy link
Contributor

Verified that it does work with Chrome 33. FBNC @njx

@njx
Copy link
Contributor

njx commented Apr 1, 2014

Seems to be working fine to me now in Chrome 33 as well. Closing.

@njx njx closed this as completed Apr 1, 2014
@njx
Copy link
Contributor

njx commented Apr 1, 2014

FYI (since it wasn't mentioned in this bug), our hypothesis is that this was fixed by some of the changes that were made to Live Development connection startup last sprint.

@core-ai-bot core-ai-bot mentioned this issue Aug 30, 2021
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@njx njx

Labels
fixed but not closed
Projects
None yet
Milestone
Release 0.44
Development

No branches or pull requests
9 participants
@njx @iwehrman @jasonsanjose @redmunds @peterflynn @larz0 @JeffryBooher @marcelgerber @bchintx