Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Race Condition with Google Chrome 19.0.1084.52 m on Windows 7 #53

Closed
axkibe opened this Issue May 29, 2012 · 3 comments

Comments

Projects
None yet
2 participants

axkibe commented May 29, 2012

It seems active() is called when the font is not yet ready.

Project site: http//meshcraft.net or http//meshcraft.net/devel.html for a non-compressed version
It is a sole Canvas where everything is drawn in, so its supposed on load to wait for the webfonts to been loaded. WebFont.active() is now calling startup() what used to window.onload directly before.

Every once in a while (1 in 10-20 cases for me) when Ctrl-Refreshing, Chrome will not draw anything, since the font seems to be not really ready yet. Maybe my imagination, but I believe the more tabs I've open the more likely the race condition applies.

Thats the code that handles startup now:

(function(){
'use strict';
if (typeof(window) === 'undefined') { throw new Error('this code needs a browser!'); }

window.onload = function(){
WebFont.load({
        custom: {
                families: [ 'DejaVuSans', 'DejaVuSansBold' ],
                urls: [ '/fonts/dejavu.css' ]
        },

        active: function() {
                console.log('active');
                startup();
        },

        fontactive: function(ff, fd) {
                console.log('fontactive ' + ff + ' ' + fd);
        }
});
}

})();

axkibe commented May 29, 2012

The strange thing is btw. I added 'sans-serif' as backup font to the canvas fonts, which is normaly respected if the favored font is not there, but in case of fontLoader and the webfont, it does not even fall to backup, but seems to be in some kind of intermediary state, where I suppose Chrome things "DejaFuSans" is there, but actually it isn't.

BTW: It works flawless as far I can see on Firefox. (And IE9 breaks, but thats my fault somewhere else)

Contributor

seanami commented May 29, 2012

This is a known issue. See #33 #35 #43. It's an issue where Webkit changed its behavior to fall back to a system default font once a font-face rule has started loading the font file. Because webfontloader watches for changes in width, it triggers active early.

There's no easy way around this issue for now because we don't know what width we should be watching for. We need to rethink our strategy for monitoring font loading.

@axkibe axkibe closed this May 30, 2012

axkibe commented May 30, 2012

Ok, since you got it 3 times already I'm closing my duplicate of a duplicate of a duplicate.

IMHO the W3C should do something about it and properly add an event.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment