777876 - Using Google Web Fonts prevents javascript loading/execution.

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[hasrinaxx]

After the upgrade to 14.0.1 we noticed that a so called "infinite scroll" javascript on our CMS was no longer functioning on Windows, Mac OS/X 10.6 and 10.7. An example can be found at http://www.joelix.com . Research showed that the script, which is called by a setInterval function, seemingly does not execute at all. However, opening the Web Console seems to trigger the execution of the script. Research proves that this problem only occurs when using external fonts from CSS (in this case, Google Web Fonts. Other external fonts have not been tested), even when run in safe mode. Setting gfx.downloadable_fonts.enabled to false causes the script to execute and function correctly. This error is reproducable and does not occur on other browser platforms.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see identical behavior with Firefox 13 and Firefox 14 on Mac OS X 10.6 on the page:  I scroll down to the last post (the "You can use Coca Cola" one right now), and that's it.

What are the steps to reproduce the bug?

Comment 2

[hasrinaxx]

You have just reproduced the bug. Notice the setInterval() function in the source. This would trigger normally before 14.0.1, but now no longer does. If you disable external fonts, you will notice the script will execute normally.

Comment 3

[hasrinaxx]

Bringing up the Web Console DOES influence the execution of the script. When the page is "stuck" at the bottom (i.e. new content is not loading because the script is not executing) and the Web Console is opened (either from the menu or by Control-Shift-K) the script will execute normally.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> You have just reproduced the bug

Except I see the same behavior in Firefox 13, which you claim has different behavior....

And I also see the same behavior in Chrome.

What's going on here is that script on the page does this:

<script>var totalHeight = document.body.offsetHeight;var cH = document.documentElement.clientHeight;var cS;var getNext=6;var pgn = 5;setInterval(scroll, 1000);</script>

before onload has fired.  That means that the document.body.offsetHeight might not be its final value yet, because not all subresources (fonts, images, etc) have loaded.

And indeeed, in Firefox 13 I see this:

[17:15:44.011] totalHeight
[17:15:44.013] 13123
--
[17:16:13.916] document.body.offsetHeight
[17:16:13.918] 12873
--
[17:16:04.788] window.pageYOffset + cH
[17:16:04.790] 12873

13123 - 12873 = 250, which is larger than the "200" fudge factor in the script.  So scroll() is being called just fine, but returns without doing anything.

So the point is, the behavior here depends on things like network speed and whether you have the font files cached and so on and so forth.  But fundamentally, it's just a race condition in the script, which is why I see it in Chrome and you don't: the timing just happens to be slightly different.

I suggest just recomputing totalHeight every time scroll() is called.  That will fix the problem.

Comment 5

[hasrinaxx]

Your points taken. One final thing: given that you can reproduce my error (which we now know was present) in FF13 and Chrome as well, it seems something has changed in external font rendering in 14.0.1, because the error would not produce itself with external fonts disabled (causing a timing difference).

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, chances are you just run your script before the fonts are loaded.  Then they load, the font on the page changes, and the height of the body changes....

Comment 7

[hasrinaxx]

I appreciate the original thinking in that Boris, but this does not account for the fact that this was working fine until we received the 14.0.1 upgrade. Obviously something changed in the timing. Funnily, it brought out a flaw in our script, but nonetheless, something has changed.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oh, I thought you were asking why it depended on the fonts at all.

If you're just talking about why you didn't see a problem in 13 but did in 14, sure.  Timing changed somewhere.  This happens all the time: prioritization algorithms get updated, cache behavior changes, etc.