- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 10 Jan 2012 12:40:34 -0800
On Tue, Jan 10, 2012 at 12:15 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 1/10/12 2:49 PM, Adam Barth wrote: >> >> On Mon, Jan 9, 2012 at 10:02 PM, Boris Zbarsky<bzbarsky at mit.edu> ?wrote: >>> >>> On 1/10/12 12:48 AM, Tantek ?elik wrote: >>>> >>>> Should 'beforeload'/'afterload' be explicitly specified and added to >>>> the web platform? >>> >>> >>> Outside of extensions, what are the use cases? ?Can they usefully labor >>> under restrictions like knowing the URI to be loaded but not the context >>> it's being loaded in? ?AdBlock apparently can in at least some cases, >>> yes? >> >> Some web sites use beforeload to monitor for mixed content >> vulnerabilities. ?In some cases, they block the load > > Do they really need to block the load, or block processing of the response? Just block processing the response. > For the mixed-content case, it seems like blocking processing of the > response is enough (and that furthermore only the URI is needed, not the > actual element, to detect mixed-content cases). The actual element turns out to be useful tracking down and fixing these issues, at least in complicated web sites. For example, suppose your web application contains widgets written by separate teams and you want to block mixed content requests in some, but not all, of these widgets. To be clear, I'm not the biggest fan of beforeload because dispatching synchronous events during loading is pretty tricky. It took us a while to get the crashes out of the WebKit implementation. They are reasonably popular, however. Adam
Received on Tuesday, 10 January 2012 12:40:34 UTC