Able to reproduce on Windows 10, Ubuntu 14.04 and Mac OS 10.11.6 using chrome reported version #53.0.2785.143.

Bisect Information:
=====================
Good build:  47.0.2526.111
Bad Build :  48.0.2560.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/9fe937fb45fd57da5988abde1e0afc9a7c8bb5d5..aadbd2624c5003698624cf2e21fd6ae876e28629

From the above change log suspecting below change

Review url: https://codereview.chromium.org/1419603004

rdevlin.cronin@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

rdevlin.cronin@ Ping! Could you please let us know is there any latest update available for this issue?

Thanks!

Issue is still observed on chrome latest stable-54.0.2840.99 version.

rdevlin.cronin@ Could you please let us know is there any recent update available on this issue?

 Thanks!

> When the extension is re-invoked, all the text is not rendered.  The inspector shows that the text elements are present in the DOM, and if I add a style to one of the .tabmgr-title elements to change the font size, the text for that item will become visible UNLESS I set it to 10px, 12px or 13px ... all other font sizes render properly, those 3 do not render. Strange.

This sounds like a blink bug.

I suspect this is an issue to do with the injected style sheets not properly
getting applied. If I tweak an element on the main page (not the injected overlay) with devtools to specify a no-op style update then the overlay text
gets painted.

I was able to reproduce this easily.
It sounds potentially like an invalidation thing. Rune - do you have any ideas?

Reproducing in Linux Chrome 54.0.2840.100
Cannot reproduce with ToT chrome.

I can repro in 54.0.2840.100 (64-bit) on Linux by installing the extension, and pressing Alt + T 3 times.

I downloaded 57.0.2933.0 where I can reproduce.

Able to reproduce on ToT built locally as well after retrying a couple of times.

Tried FullStyleUpdate instead of AnalyzedUpdate in StyleEngine::injectAuthorSheet() which effectively does a SubtreeStyleChange on Document. Didn't help.

After a day of printf debugging this seems to point in the direction of webfont loading. The 'Roboto Bold' font is an @font-face in the injected stylesheet and changing the font to anything else, or even change the size as mentioned in comment #5, the text is displayed. Not rendering the text is most likely a FOUT-avoidance and we probably don't get the correct invalidation of fonts after the 'Roboto Bold' font finishes loading. I don't know if this is specific to web-fonts embedded in extensions.

That was all I figured out today.

Discussed with fs@opera.com. We think this is related to bitmapped fonts because of the fact that it's not working for certain sizes (see comment #5). Setting back to Untriaged.

Thanks for putting in all that effort Rune! Much appreciated :)

Thanks Rune. Looks like a font invalidation issue, let me take a look.

Created a reduced test case: https://codereview.chromium.org/2550663002
Something is wrong with cache revalidation of font resources.

Go team! 

Font::drawText() returns early because shouldSkipDrawing() returns true even long after the font finishes loading. At the bottom level of that call we end up in CSSCustomFontData::shouldSkipDrawing() which returns true because this is true:

  m_fallbackVisibility == InvisibleFallback && m_isLoading;

In fact, I don't see a single place in the code where m_isLoading can ever be set back to false after being set to true in beginLoadIfNeeded().

Hmm, seems that could be the mode of operandi for that class as it's only instantiated from createLoadingFallbackFontData.

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