Should we remove or standardize the beforeload event?

109 views
Skip to first unread message

Philip Jägenstedt

unread,
Oct 16, 2013, 10:42:38 AM10/16/13
to blink-dev
Hi all,

While fixing <http://code.google.com/p/chromium/issues/detail?id=308047>
I noticed that there's a beforeload event in HTMLMediaElement, which
isn't in the spec. It turns out it's fired for a lot of elements, and
has special handling sprinkled about.

The event isn't mentioned at all in the HTML spec, so what should we do?

There's a bug to implement it in Gecko
<https://bugzilla.mozilla.org/show_bug.cgi?id=715695> but that doesn't
seem to be going anywhere.

I would be happy to purge it from the source tree if it isn't required
for compat.

Philip

Adam Barth

unread,
Oct 16, 2013, 11:06:01 AM10/16/13
to Philip Jägenstedt, blink-dev
The beforeload event was added to the codebase by Apple to support
Safari's extension system without any standardization effort. The
event had led to numerous security vulnerabilities because it lets
JavaScript execute synchronously in the middle of networking code. I
would like to remove the event if compatibility allows. Perhaps we
should add a UseCounter? My guess is that most of the usage is from
extensions.

Adam

Dimitri Glazkov

unread,
Oct 16, 2013, 12:37:13 PM10/16/13
to Philip Jägenstedt, blink-dev
I, too would love to see this removed. For more background, it was added in http://trac.webkit.org/changeset/49113 to support Safari extension scenarios.

From what I understand, chrome.webRequest API (http://developer.chrome.com/extensions/webRequest.html) now completely satisfies all (and more!) use cases for which beforeload was necessary.

:DG<


On Wed, Oct 16, 2013 at 7:42 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Ojan Vafai

unread,
Oct 16, 2013, 1:32:30 PM10/16/13
to Dimitri Glazkov, Philip Jägenstedt, blink-dev

Philip Jägenstedt

unread,
Oct 16, 2013, 1:44:28 PM10/16/13
to Ojan Vafai, Dimitri Glazkov, blink-dev
That's excellent! Given that the UseCounter was added only two weeks
ago, when are where can one expect to see the results?

Ojan Vafai

unread,
Oct 16, 2013, 1:52:08 PM10/16/13
to Philip Jägenstedt, Dimitri Glazkov, blink-dev
We don't get good data until a stable release. But looking at dev channel on Windows (32.0.1664.3), it looks like 1% of pages register a beforeload listener. That's not very promising for removal. I suspect most of that is from extension content scripts. Someone could change the UseCounter for this to measure a different enum if we're in a content script. It's possible that there's just one or two popular extensions that account for most of that and we could get them to change.

Philip Jägenstedt

unread,
Oct 16, 2013, 2:58:03 PM10/16/13
to Ojan Vafai, Dimitri Glazkov, blink-dev
Is there another UseCounter with split accounting for extensions and
Web content that I could have a look at? I'm willing to provide the
patch if pointed in the right direction :)

Philip

Adam Barth

unread,
Oct 16, 2013, 3:07:28 PM10/16/13
to Philip Jägenstedt, Ojan Vafai, Dimitri Glazkov, blink-dev
The easiest thing to do is to call
ScriptController::shouldBypassMainWorldContentSecurityPolicy when the
event listener is registered. That will return true when we're doing
work on behalf of an extension's content script. We're careful about
how we use that value, but using it in a use counter should be fine.

Adam

Philip Jägenstedt

unread,
Oct 16, 2013, 4:10:36 PM10/16/13
to Adam Barth, Ojan Vafai, Dimitri Glazkov, blink-dev
Thanks Adam,

I've uploaded <https://codereview.chromium.org/26828003/> for review.
If it turns out that usage in Web content is really low but there's
work to do for extensions, maybe it could be hidden from Web content
sooner...

Philip

Adam Barth

unread,
Oct 16, 2013, 4:25:16 PM10/16/13
to Philip Jägenstedt, Ojan Vafai, Dimitri Glazkov, blink-dev
We've had a bad experience in the past when we've removed features
from the web but retained them for extensions. If it turns to be
mostly used by extensions, we have a couple of options:

1) We can search the extensions store for developers using the
features and reach out to them proactively and evangelize the
webRequest API.
2) We can remove the API the next time we increase the manifest_version number.

In the past I've had a good experience evangelizing extension
developers. In a couple cases, I've sent them patches for their
extensions, which they were kind enough to apply.

Thank you for raising this issue. Let's see what we learn from the use counter.

Adam
Reply all
Reply to author
Forward
0 new messages