W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] should we add beforeload/afterload events to the web platform?

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 10 Jan 2012 12:40:34 -0800
Message-ID: <CAJE5ia_rLB1WJaqKpfSEvbT8FFBAqJBsV40wF91u+6StP9WprQ@mail.gmail.com>
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.

Received on Tuesday, 10 January 2012 12:40:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC