Count CSS/form images (fixes #20).

[adoxa]

<img> tags are still counted as usual (although now src-less ones are ignored), with a new function to count CSS images, as well as type=image forms; link icons are not counted. Since apparently there's no way to know if these images are complete or not, I've just added a third value if necessary - complete/total/all where complete & total represent the number of unique (according to src) <img> tags and all is the number of all images. For example, this page shows as 3/3/4. If there are no <img> tags, I've just reduced it to 0, rather than having 0/0.

[adoxa]

Just re-reading the "commit closes" topic again and I see that "fixes #20" needs to go in the body (I forgot to put it in the commit).

[sipertruk]

Have you considered this ? (In observeActivity in the httpObserver under ACTIVITY_SUBTYPE_RESPONSE_COMPLETE) aHttpChannel = aHttpChannel.QueryInterface(Components.interfaces.nsIHttpChannel); console.log(aHttpChannel.getRequestHeader("Accept"));

So far the count is good for sites I tested.

[adoxa]

To count completed images? Wouldn't work during offline use, so /^image/.test(request.contentType) in onEndRequest in the stream listener would be better. It seems stopping short causes the request to come after stop, but going offline and reloading has a normal order, just with the data available being less than contentLength (and I guess that still won't work with images lacking contentLength). Probably not worth the effort.

[sipertruk]

I found this for knowing if a css image is loaded. http://jsfiddle.net/tovic/gmzSG/light/

[adoxa]

Interesting, but it still doesn't work in offline mode - the event still fires and complete is true, even though the log says the image is corrupted. So I still don't think it's worth the effort. Thus, if we just assume completeness, the extra count could be removed (e.g. 6/6/10 could just be 10, and 5/6/10 would be 9/10).

[sipertruk]

I'm concerned that 3 values would be too cryptic for most users, and beside ESB is about showing progress, so just stating facts about the page or assuming loaded state would miss the point.

If offline mode is a problem why not skip that count if it is the case. Then make countOtherImage independant from countImages and implement in it the onload method, which require only one count, maybe at STOP or on the first progress event.

[adoxa]

If it's about progress, doing it on STOP is rather silly :smile: and doing it on first progress may not be sufficient. I ran another test - set up the load event on a normal img tag (since it just works by creating a new element, I expect this to be similar to other images), load a page and stop it before the image is finished. At the point of STOP, the event hasn't been fired, but it does fire later and shows as completed. So I guess the procedure would be something along the lines of: create the element if we haven't already done so; if the load event fires during progress, increase completed count; then either remove all the remaining load events at STOP, regarding the images as incomplete, or just ignore them afterwards, assuming they don't get loaded after STOP.

[sipertruk]

Sure one count is not enough in case of a css file loaded afterwards. Then yes let's create a img load event at every new css detected, and ignore event fired after STOP if the loading failed, that 'd be aStatus != Components.results.NS_OK if I'm correct.

[adoxa]

Tried a few more tests and it looks like the load event always fires, image completed or not. What's more, the onStopRequest status is NS_OK the first time, it's only after refreshing that it changes to NS_BIND_ABORTED (for an offline case). Even so, stopping might still continue to load the image in the background. So I give up.

[adoxa]

Okay, I've stopped worrying about it. All images are regarded as loaded when the new onload event fires, whenever that may be and whatever actual state the image is in.

[adoxa]

Getting the computed style is sometimes quite expensive, so without that the existing code is sufficient.