Noticing, as when Netscape topped around 80%, and then IE passed 80 on way to 95%, and now with Chrome: when a browser gets 80% market power, esp. with leading devtools so web devs live in it, content interop suffers. Not rationalizing or excusing; it is bad _per se_. Real, too.
-
Show this thread
-
Cc:
@bz_moz@davidbaron who probably know at a glance what's up.1 reply 0 retweets 1 like -
Replying to @BrendanEich @bz_moz
var f = document.createElement('iframe') var loaded = false; var t = ""; f.addEventListener('load', () => { loaded = true; }) t += `${loaded},`; document.body.appendChild(f) t += `${loaded},`; setTimeout(() => { t += `${loaded}`; console.log(t); }, 100);
1 reply 0 retweets 1 like -
I think the above code shows the difference more clearly: * logs "false,false,true" in Firefox * logs "false,true,true" in Chrome My guess is this has to do with synchronous vs asynchronous loading of contents of empty iframes? That's a question for
@hsivonen.2 replies 0 retweets 1 like -
Nesting an event handler call (mutating var loaded & of course the DOM) without nesting an event loop (_verboten_, could vary all invariants) seems irregular. Security vulns have exploited similar unexpected nesting. Cc:
@natashenka1 reply 2 retweets 3 likes
This is just a bug wrt spec in Chrome, pure and simply. Spec says to fire the event async. Chrome is firing it sync. No spec ambiguity here.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.