search

brackets-archive / bracketsIssues

Archive of issues in brackets.
0 stars 0 forks source link

[CLOSED] Web Fonts may not render correctly in Chrome #5716

Open core-ai-bot opened 3 years ago

core-ai-bot commented 3 years ago

Issue by iwehrman Thursday Dec 19, 2013 at 19:13 GMT Originally opened as https://github.com/adobe/brackets/issues/6275

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.

core-ai-bot commented 3 years ago

Comment by iwehrman Thursday Dec 19, 2013 at 19:15 GMT

It still reproduces with Chrome 32.0.1700.68.

core-ai-bot commented 3 years ago

Comment by larz0 Thursday Dec 19, 2013 at 19:30 GMT

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

core-ai-bot commented 3 years ago

Comment by iwehrman Thursday Dec 19, 2013 at 19:34 GMT

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

core-ai-bot commented 3 years ago

Comment by redmunds Friday Dec 20, 2013 at 16:26 GMT

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

core-ai-bot commented 3 years ago

Comment by peterflynn Friday Dec 20, 2013 at 17:49 GMT

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...

core-ai-bot commented 3 years ago

Comment by iwehrman Friday Dec 20, 2013 at 18:07 GMT

Ohhh right. Yes, good call.

core-ai-bot commented 3 years ago

Comment by njx Friday Dec 20, 2013 at 19:52 GMT

To me for now, medium priority.

core-ai-bot commented 3 years ago

Comment by njx Friday Dec 20, 2013 at 22:48 GMT

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.

core-ai-bot commented 3 years ago

Comment by njx Friday Dec 20, 2013 at 22:54 GMT

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.

core-ai-bot commented 3 years ago

Comment by njx Friday Dec 20, 2013 at 22:55 GMT

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.

core-ai-bot commented 3 years ago

Comment by njx Saturday Dec 21, 2013 at 00:08 GMT

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.

core-ai-bot commented 3 years ago

Comment by njx Friday Jan 10, 2014 at 01:16 GMT

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.

core-ai-bot commented 3 years ago

Comment by njx Saturday Jan 11, 2014 at 00:08 GMT

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

core-ai-bot commented 3 years ago

Comment by MarcelGerber Tuesday Jan 14, 2014 at 21:07 GMT

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

core-ai-bot commented 3 years ago

Comment by njx Tuesday Jan 14, 2014 at 23:23 GMT

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

core-ai-bot commented 3 years ago

Comment by njx Saturday Jan 25, 2014 at 00:10 GMT

This has been moved to Ready. Removing milestone.

core-ai-bot commented 3 years ago

Comment by njx Thursday Jan 30, 2014 at 00:13 GMT

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

core-ai-bot commented 3 years ago

Comment by njx Thursday Jan 30, 2014 at 00:42 GMT

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.

core-ai-bot commented 3 years ago

Comment by njx Tuesday Feb 04, 2014 at 01:30 GMT

@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).

core-ai-bot commented 3 years ago

Comment by njx Wednesday Feb 19, 2014 at 19:35 GMT

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

core-ai-bot commented 3 years ago

Comment by redmunds Tuesday Feb 25, 2014 at 18:44 GMT

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

core-ai-bot commented 3 years ago

Comment by jasonsanjose Tuesday Feb 25, 2014 at 18:48 GMT

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

core-ai-bot commented 3 years ago

Comment by njx Tuesday Feb 25, 2014 at 23:29 GMT

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...

core-ai-bot commented 3 years ago

Comment by njx Friday Mar 14, 2014 at 23:28 GMT

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

core-ai-bot commented 3 years ago

Comment by JeffryBooher Tuesday Mar 25, 2014 at 01:25 GMT

Seems pretty stable with Chrome 34.0.1847.76 beta on Mac.

core-ai-bot commented 3 years ago

Comment by njx Tuesday Mar 25, 2014 at 03:25 GMT

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

core-ai-bot commented 3 years ago

Comment by JeffryBooher Tuesday Mar 25, 2014 at 03:56 GMT

@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.

core-ai-bot commented 3 years ago

Comment by JeffryBooher Tuesday Mar 25, 2014 at 20:18 GMT

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

core-ai-bot commented 3 years ago

Comment by njx Tuesday Mar 25, 2014 at 20:49 GMT

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.

core-ai-bot commented 3 years ago

Comment by JeffryBooher Monday Mar 31, 2014 at 17:14 GMT

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