Right now link rel=prefetch doesn't dispatch onload events. However, it probably would be really good if it did. Tests would be less flaky, for one. I emailed hixie to see what he thought, and here's the pasted correspondence: Ian Hickson to Gavin, Adam show details 5 Nov - Hide quoted text - On Fri, 5 Nov 2010, Gavin Peters (�~S~K�~V~G彼德�~V�) wrote: > > WebKit currently supports link rel=prefetch, but doesn't have onload or > onerror events for this. There was some discussion when this feature > was first added about if this was appropriate: > https://bugs.webkit.org/show_bug.cgi?id=3652 > > We've since landed it, and I've had web developers ask me if we can > generate these events: especially since WebKit supports mutating the DOM > to include link rel=prefetch (mozilla doesn't), developers who are > adding these programatically want a way to know how many are in flight. > This mechanism would do it for them. > > What do you think? Is this within spec and reasonable, or do you have > any other comments about it? Sounds good to me. Technically the HTML spec requires load and error events to be fired on all <link> elements whenever they load anything: http://www.whatwg.org/specs/web-apps/current-work/complete.html#concept-link-obtain ...so it's definitely per-spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Created attachment 75089 [details] Patch
Comment on attachment 75089 [details] Patch This is my first pass. I've reworked a lot of tests, and I'm very interested to hear back what people think.
Attachment 75089 [details] did not build on qt: Build output: http://queues.webkit.org/results/6354099
Attachment 75089 [details] did not build on win: Build output: http://queues.webkit.org/results/6304125
Attachment 75089 [details] did not build on gtk: Build output: http://queues.webkit.org/results/6344091
Comment on attachment 75089 [details] Patch Don't commit my patch: besides the bad builds, I have realised it takes totally the wrong approach to delaying onload events. I have a new idea I'll submit in a forthcoming patch.
Created attachment 75598 [details] Patch
I left my approach to onload events in. It somewhat closely mirrors what's done in the ImageLoader; the use of a SetTimer(0) forces us to wait until more of the document exists in the case of a load from cache. Adam, I'm interested to see what you think of what I have here. I'd like to clean this up before I start adding the onerror element. Let me know if you think it's best to land this with onerror or in two CLs.
Comment on attachment 75598 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=75598&action=review This is looks to be correct and a nice approach. I have a couple questions before, mostly for my education. > LayoutTests/ChangeLog:8 > + Implement onload events for WebKit > + > + implement onload events for <link rel=prefetch> > + https://bugs.webkit.org/show_bug.cgi?id=50187 One of these lines seems redundant. :) > LayoutTests/fast/dom/HTMLLinkElement/link-and-subresource-test.html:16 > + ++nick_load_count missing ; > LayoutTests/fast/dom/HTMLLinkElement/prefetch-onload.html:15 > + if (window.layoutTestController) { > + layoutTestController.notifyDone(); > + } No braces needed. > LayoutTests/fast/dom/HTMLLinkElement/prefetch-onload.html:22 > + </script> bad indent > LayoutTests/fast/dom/HTMLLinkElement/prefetch.html:-7 > - setTimeout("layoutTestController.notifyDone()",50); Yay! > LayoutTests/http/tests/misc/prefetch-purpose.html:-17 > -<body onload="setTimeout('finishUp()', 50);"> yay! > WebCore/html/HTMLLinkElement.cpp:376 > +#if ENABLE(LINK_PREFETCH) > +void HTMLLinkElement::onloadTimerFired(Timer<HTMLLinkElement>*) > +{ We usually have an ASSERT_UNUSED that we're being called back with the right timer. > WebCore/html/HTMLLinkElement.cpp:377 > + m_loading = false; This line surprises me. I'm not quite sure I understand it. > WebCore/html/HTMLLinkElement.cpp:382 > +void HTMLLinkElement::notifyFinished(CachedResource*) > +{ Again, an ASSERT here would be nice. > WebCore/html/HTMLLinkElement.cpp:383 > + m_onloadTimer.startOneShot(0); Should we remove ourselves as a client of the prefetch at this point? > WebCore/loader/cache/CachedResource.cpp:118 > + setLoading(false); I'm not sure I quite understand this line either. Would you be willing to explain what it does?
Comment on attachment 75598 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=75598&action=review >> LayoutTests/ChangeLog:8 >> + https://bugs.webkit.org/show_bug.cgi?id=50187 > > One of these lines seems redundant. :) Done. >> LayoutTests/fast/dom/HTMLLinkElement/link-and-subresource-test.html:16 >> + ++nick_load_count > > missing ; Now it's not. >> LayoutTests/fast/dom/HTMLLinkElement/prefetch-onload.html:15 >> + } > > No braces needed. Gone. >> LayoutTests/fast/dom/HTMLLinkElement/prefetch-onload.html:22 >> + </script> > > bad indent Fixed. >> WebCore/html/HTMLLinkElement.cpp:376 >> +{ > > We usually have an ASSERT_UNUSED that we're being called back with the right timer. Good plan. Done. >> WebCore/html/HTMLLinkElement.cpp:377 >> + m_loading = false; > > This line surprises me. I'm not quite sure I understand it. Neither did I. It's gone. The original patch in 3652 manipulated m_loading quite a bit; this was the last vestige of that. In the case of HTMLLinkElement through, isLoading() is really about CSS, and not any other kind of resource, so I'm not touching it any more. >> WebCore/html/HTMLLinkElement.cpp:382 >> +{ > > Again, an ASSERT here would be nice. Done. >> WebCore/html/HTMLLinkElement.cpp:383 >> + m_onloadTimer.startOneShot(0); > > Should we remove ourselves as a client of the prefetch at this point? I think it's a good idea. When the HTMLLinkElement is deleted, it'll remove itself. And of course the CachedResource has a life at least as long as this element, since it should survive in the MemoryCache for the length of the page. Done. >> WebCore/loader/cache/CachedResource.cpp:118 >> + setLoading(false); > > I'm not sure I quite understand this line either. Would you be willing to explain what it does? As it happens, CachedResource::data is used only in the LinkPrefetch case. This method is overriden specifically in all the other subclasses. The omission of this line was a bug, but invisible since nothing cared about completion of prefetch loads. In other CachedResources, loading is normally set to false after completion, or after discovering it will fail. Grep through ImageLoader.cpp say looking for setLoading(false) and you'll see a very similar call in ::data() (around like 299). The most important use probably comes in CachedResource::didAddClient(), if isLoading() returns false, we immediately send our new client a notifyFinished. It's actually that immediate event-pass-through that required I put the timer in HTMLLinkElement; when the memory cache contained the target of the prefetch, onload on prefetch events was launching before we even had a fully baked DOM.
Created attachment 75610 [details] Patch
Adam, Thanks for your review. I've remediated to your concerns, and answered your questions. I will go ahead and get working on onerror events, so we can either wait for that patch, or just land this and have the onerror events add to it.
Comment on attachment 75610 [details] Patch The removeClient is causing trouble on mac. Wait for more.
Created attachment 75611 [details] Patch
Comment on attachment 75611 [details] Patch This patch solves the crash I was seeing on Mac (and I'm surprised I didn't see in gtk). However, I'd like to add one more test; so I'm putting it here more to have stashed it than anything else.
Ixnay adding that test; I wanted to confirm if this patch was introducing onload to rel="stylesheet" elements, and it is not. Perhaps that's a good followup CL to this.
Comment on attachment 75611 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=75611&action=review Thanks! > WebCore/html/HTMLLinkElement.cpp:384 > + if (m_cachedLinkPrefetch.get() == resource) { Can this be false? Or are we just planning ahead?
Comment on attachment 75611 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=75611&action=review >> WebCore/html/HTMLLinkElement.cpp:384 >> + if (m_cachedLinkPrefetch.get() == resource) { > > Can this be false? Or are we just planning ahead? I don't believe it can be false, since I don't believe CachedCSSStyleSheet sends notifyFinished() events. But, yeah, planning ahead since one day it might, and I adding onload for link rel=stylesheet should be a careful conscious choice in the future.
Maybe we should use an ASSERT with a comment to document that fact?
Comment on attachment 75611 [details] Patch Clearing flags on attachment: 75611 Committed r73335: <http://trac.webkit.org/changeset/73335>
All reviewed patches have been landed. Closing bug.
The commit-queue encountered the following flaky tests while processing attachment 75611 [details]: animations/combo-transform-translate+scale.html fast/preloader/script.html Please file bugs against the tests. These tests were authored by abarth@webkit.org, cmarrin@apple.com, darin@apple.com, ojan@chromium.org, and pol@apple.com. The commit-queue is continuing to process your patch.