v.tambovtsev@ Thanks for the issue.

Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.3 using chrome version 49.0.2623.112 and canary 52.0.2707.2 with the below steps

1. go to URL https://app.tacticrealtime.com/data/AdvertPreview/17ca3e775c5cc9e5a7fc48c17473827f/14417
2.Observed some of the image fonts are not rendered.

This is reproducible on ALL OS and it is regression issue broken in M48.
Please find the bisect information as below.

Narrow Bisect::
Good :: 48.0.2537.0  -- (official build 354398)
Bad:: 48.0.2538.0 --   (official build 354651)

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/e9db8061b1f0b6776858f9c4968f8e85cfff1d63..6b1707c86a8b8f9f0e93dbffc849ed6e500ff43b

Blink Change Log::
https://chromium.googlesource.com/skia/+log/80803ff..466c2c4

Possible suspect from the above blink CL
https://codereview.chromium.org/1393283008

senorblanco @ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Actually, I have this but with fonts disappearing not only _inside_ an iframe, but even on the page _containing_ and iframe

That change was a benign refactor that's 6 months old and pretty much impossible to revert now, given the other things which have landed since then.

(Also, given that the HTML alone for this case is 200K, this is also desperately in need of a reduction.)

Is there a WebFonts expert who could take a look?

I think the culprit is japhet@'s change in that bisect range (http://crrev.com/71adea2).

The example page hits this assertion in debug build @ ToT:

ASSERTION FAILED: resource->isLoaded()
../../third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp(539) : void blink::ResourceFetcher::initializeRevalidation(const blink::FetchRequest &, blink::Resource *)
1   0x7f4fca6e1d06 blink::ResourceFetcher::initializeRevalidation(blink::FetchRequest const&, blink::Resource*)
2   0x7f4fca6e0d3f blink::ResourceFetcher::requestResource(blink::FetchRequest&, blink::ResourceFactory const&, blink::SubstituteData const&)
3   0x7f4fca6b1579
4   0x7f4fca402a06
5   0x7f4fca46bd40
6   0x7f4fca46c31f
7   0x7f4fca562abd
8   0x7f4fca562c20
9   0x7f4fca57fd3a blink::StyleResolver::appendCSSStyleSheet(blink::CSSStyleSheet&)
10  0x7f4fca57fdc3 blink::StyleResolver::appendPendingAuthorStyleSheets()
11  0x7f4fcab034b1
12  0x7f4fcac102ec blink::StyleEngine::attributeChangedForElement(blink::QualifiedName const&, blink::Element&)

Received signal 11 SEGV_MAPERR 0000fbadbeef
#0 0x7f4fe10375fe base::debug::StackTrace::StackTrace()
#1 0x7f4fe103713f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f4fd21a3340 <unknown>
#3 0x7f4fca6e1d0d blink::ResourceFetcher::initializeRevalidation()
#4 0x7f4fca6e0d3f blink::ResourceFetcher::requestResource()
#5 0x7f4fca6b1579 blink::FontResource::fetch()
#6 0x7f4fca402a06 blink::CSSFontFaceSrcValue::fetch()
#7 0x7f4fca46bd40 blink::FontFace::initCSSFontFace()
#8 0x7f4fca46c31f blink::FontFace::create()
#9 0x7f4fca562abd blink::ScopedStyleResolver::addFontFaceRules()
#10 0x7f4fca562c20 blink::ScopedStyleResolver::appendCSSStyleSheet()
#11 0x7f4fca57fd3a blink::StyleResolver::appendCSSStyleSheet()
#12 0x7f4fca57fdc3 blink::StyleResolver::appendPendingAuthorStyleSheets()
#13 0x7f4fcab034b1 blink::StyleEngine::ensureResolver()
#14 0x7f4fcac102ec blink::StyleEngine::attributeChangedForElement()

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 640701  has been merged into this issue.

Still possible to reproduce on  Chrome (52.0.2743.116) (also on Linux) and Canary (54.0.2825.0)

Deleted: chrom_bug.PNG 217 KB

	chrom_bug.PNG 217 KB View Download

Yeah, my company is seeing this too on our page. We're using font-awesome and a custom icon font for some of our buttons. It only happens when the font isn't cached. So, if I open up my console and disable the cache, the font icons will render invisible. If I go into the css style editor and toggle the font property, the icons fix themselves. Also, once the user has hit a page once and cached it, it'll be fine until the cache invalidates. 

Note, still seeing this in 53.0.2785.116. For me the repro is:

 - Parent page with iframe child page
 - Parent loads CSS file with custom @font-face
 - Child loads (different) CSS file with same custom @font-face code
 - Now font renders invisible (in parent) under "certain circumstances"

Easy (but stupid) workaround:

 - Create duplicates of the custom font files
 - Child CSS loads the duplicated custom font files instead of loading the same ones as the parent.

(Found this workaround mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=582198 which I assume was actually the same issue as this one)

Btw, there is still bug in Chrome, however we found workaround, so it works now in first post:
https://app.tacticrealtime.com/data/AdvertPreview/17ca3e775c5cc9e5a7fc48c17473827f/14417

Workaround:
For each font we add format to url (.woff2?format), so for browser it looks like it loads new font.

Can you, please, supply a stable URL with as less code as possible? It is very hard to work on a bug that its reproduction URL no longer reproduces the issue at hand.

Problem is still reproduced (55.0.2883.87 on Windows).

I can vouch for the above, it is very easy to reproduce this problem when sharing font files between a parent window and iframe. Only workaround I have found is to load separate font files for the iframed window as mentioned above

I prepare a page that can reproduce this issue.
http://yuri.twintail.org/chrome/font/602968/

I can see this issue only with the font that the first referenced site use.
But I believe it is just because of timing. What I notice here are:

- when the second font in an iframe is created, FontResource is already in memory cache, and notifyFinished() is synchronously called when addClients is called.
- but isLoaded() returns false because revalidation is running.
- it will not be notified after the revalidation is finished.

https://codereview.chromium.org/2550663002/diff/20001/third_party/WebKit/Source/core/css/RemoteFontFaceSource.cpp

This is ksakamoto's old patch. I think this is a right patch to fix this issue.
If we are counting revalidation cases in, we should check m_font->hasCustomFontData() rather than isLoaded().

Update 'Blocking' to point issues that should happen due to the same root cause.

Please see:
https://bugs.chromium.org/p/chromium/issues/detail?id=582198#c20

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a

commit 99cc846f07ae952c27c026f7a4ddc0dbfba0a83a
Author: ksakamoto <ksakamoto@chromium.org>
Date: Fri Mar 03 07:24:10 2017

RemoteFontFaceSource should keep FontCustomPlatformData over FontResource revalidation

RemoteFontFaceSource assumed that FontResource::isLoaded() never returns
false after notifyFinished(), but FontResource can go back to "loading"
state by resource revalidation. This caused a bug where webfonts are not
displayed when loaded in one frame and immediately revalidated in
another frame.

To fix this bug, this CL does the following:
- Make FontCustomPlatformData RefCounted.
- Make RemoteFontFaceSource to get RefPtr<FontCustomPlatformData> and
  use it in RemoteFontFaceSource::createFontData().
- RemoteFontFaceSource never accesses FontResource after notifyFinished().

BUG= 602968 ,  652974 ,  692574 

Review-Url: https://codereview.chromium.org/2717123003
Cr-Commit-Position: refs/heads/master@{#454537}

[add] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/LayoutTests/http/tests/webfont/font-face-revalidation-expected.html
[add] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/LayoutTests/http/tests/webfont/font-face-revalidation.html
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/core/css/BinaryDataFontFaceSource.h
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/core/css/RemoteFontFaceSource.cpp
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/core/css/RemoteFontFaceSource.h
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/core/loader/resource/FontResource.cpp
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/core/loader/resource/FontResource.h
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/platform/fonts/FontCustomPlatformData.cpp
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/platform/fonts/FontCustomPlatformData.h
[modify] https://crrev.com/99cc846f07ae952c27c026f7a4ddc0dbfba0a83a/third_party/WebKit/Source/platform/testing/FontTestHelpers.cpp

for those describing workarounds, is the key to solving this involve actually creating a new css sheet that's a clone of the existing one, then loading that into the iframe?

or does the copy also need to re-declare the font-faces with different font-family names?

ie:
main.css
font-face { font-family: "my custom font" src: "foo" };

iframe.css
font-face { font-family: "my custom font 2" src: "foo" };

@dan.a.qu...@gmail.com

Simply creating a CSS file that was a clone of the existing one that is used exclusively for the iframe worked for me. Didn't have to rename the font family. (Also note that I did this with the font-faces set up in an isolated CSS from my main styles, so I didn't need to do duplicate the rest of my page styles for it to work)

This should be fixed in latest canary (59.0.3032.0). If not, please let us know.

 Issue 585239  has been merged into this issue.

Hi all, it's probably unlikely, but does anyone have a suggested fix in code that can be done for chromium 49? For reasons beyond my control, I cannot upgrade to the latest version of chromium to get the recent fix, and the codebase has diverged drastically since then, such that it's too complex to backport the fix in this bug. I'm hoping there's a simple one or two line change that can be done in chromium 49.