Status of "immediate unblocking" feature · 2007-03-07 03:28 by Wladimir Palant
My post about finding a way to unblock items immediately when the filters change was probably too optimistic. I am finished coding the basics but I hit some problems in Gecko.
Stylesheets seem to be the only elements where the simple “remove and re-add” approach actually worked. If you re-add a stylesheet to its document, the check whether it should be loaded will be triggered again. Perfect. Less so with images — here the check will only be triggered if previously the image was blocked, for successfully loaded images the check is not repeated. But I managed to reset the image’s state using nsIImageLoadingContent so everything is fine again.
Objects are identical to images with the exception that Firefox trunk nightlies currently have some bug — calling nsIImageLoadingContent.loadImageWithChannel makes the objects disappear. Not nice but it should be possible to fix this, after all these are nightlies and not a released Firefox version. And regression fixes are always easier to justify.
But the real problem are frames. Generally re-adding them does what it should do. However, if there is more than one frame in the document Gecko might confuse them. When you unblock a frame it will show the contents of the other frame for a second. And when you reload the page after that the contents of both frames will be identical. This is a Gecko bug of course but not a new one — both Firefox 2.0 and trunk nightlies show the same behavior. And I suspect that this bug has been there since the “beginning of time”, having its roots in the DOM0 frames collection that simply doesn’t handle insertions well.
I still need to check the situation with the types “other” (usually XBL bindings though with some luck XMLHttpRequests should appear here as well soon) and “link”. Unblocking scripts and background images however certainly won’t be possible without reloading the page.
Commenting is closed for this article.