Not sure if it's still true, but not long after the FF WMP plug-in <http://port25.technet.com/pages/windows-media-player-firefox-plugin-download.aspx> came out, I noticed that Firefox supported <script for="" event=""> just like IE does with the WMP activex plug-in.

In other words, Firefox was/is passing <http://shadow2531.com/opera/testcases/plugins/ffwmp/000.html>.

That caused/causes a problem because other browsers besides IE don't support that. For other browsers, you need to define a global function: 
function OnDSPlayStateChangeEvt(newState) {
    alert(newState);
}
instead. (The plug-in supports both the 6.4 api and the 7+ api).

There was even a site that assumed all browsers did like FF and it broke in Opera. Unfortunately, I can't find the site atm.

With that said, we really shouldn't touch that IEism with a 10ft pole. However, 'we just refuse to execute any script where the script element has a
for="" attribute.' makes the best sense *if* we want to handle that. Scripts like that should still be invalid of course.

(IE also supports attachEvent on that WMP plug-in to handle things, which also doesn't work in other browsers.)

Whatever is done, for="" should be strongly discouaraged.

Made for="" block script execution.

Checked in as WHATWG revision r4203.
Check-in comment: Make <script for> block script execution.
http://html5.org/tools/web-apps-tracker?from=4202&to=4203

I recently learned that Mozilla has a fancier rule than just blocking execution of all scripts with a for attribute, and at least some aspects of their rule are required for Web compatibility. 

Here are their rules (now also implemented in WebKit trunk):
          -If there's only a 'for' attribute, execute it.
          -If there's only an 'event' attribute, execute it.
          -If there's a 'for=window' and 'event=onload', execute it.
          -If there's a 'for=window' and 'event=onload()', execute it.
	  -If there's any other combination of both 'for' and 'event', don't execute it.

The WebKit bug that led us to change this was:

https://bugs.webkit.org/show_bug.cgi?id=35556

(Note that executing all scripts with a for attribute is not Web-compatible either, here is an example of the type of bug it may cause:

https://bugs.webkit.org/show_bug.cgi?id=21193
)

(In reply to comment #4)
>           -If there's a 'for=window' and 'event=onload', execute it.
>           -If there's a 'for=window' and 'event=onload()', execute it.

Gecko trims ' ', '\r', '\n' and '\t' characters from the start and end of the values of both attributes.

The string "window" is compared Unicode-case-insensitively after the trimming. That is, "wİndow" matches "window". The value of event is considered to match if (case-insensitively) it after the above-mentioned trimming
 a) is "onload"
OR
 b) starts with "onload("
OR
 c) starts with "onload "

It's unclear to me if Gecko actually registers event handlers in non-onload cases or if the code looks like that is dead code.

(In reply to comment #5)
> (In reply to comment #4)
> >           -If there's a 'for=window' and 'event=onload', execute it.
> >           -If there's a 'for=window' and 'event=onload()', execute it.
> 
> Gecko trims ' ', '\r', '\n' and '\t' characters from the start and end of the
> values of both attributes.

For comparison purposes, that is. Not from the DOM.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: In an attempt to mitigate the damage here, I went with just doing ASCII case-insensitive compares, stripped all "space character"s, and only did full compares to "window", "onload", and "onload()", not substring matches. Please let me know if changing to match that is not an option.

Checked in as WHATWG revision r4938.
Check-in comment: Expand the hacks around <script for event> for extra compatibility.
http://html5.org/tools/web-apps-tracker?from=4937&to=4938

Why bother taking the risk of changing from checking startsWith("onload ") || startsWith("onload(") to equals("onload()")?

sicking, does the change look safe to you?

I don't really see a compelling argument for changing geckos behavior according to what the spec now says. The benefit in terms of code simplification is extremely small.

If anything we should could say that for-value that starts with "onload" (including the string "onload" itself) should be executed when event is "window".

But really, it'd rock if someone did actual research here to see what's on the web. I would tentatively be prepared to say that this whole 'onload' business could go away and we could always ignore scripts with 'for' and 'event' set. Though I'd prefer to see data before making such a change.

(In reply to comment #10)
> But really, it'd rock if someone did actual research here to see what's on the
> web. I would tentatively be prepared to say that this whole 'onload' business
> could go away and we could always ignore scripts with 'for' and 'event' set.
> Though I'd prefer to see data before making such a change.

I should add, yes, I'm sure this would break a few pages, as indicated in
comment 4, but I'd imagine the number of pages is small enough that we can evangelize it.

(In reply to comment #1)
> There was even a site that assumed all browsers did like FF and it broke in
> Opera. Unfortunately, I can't find the site atm.

I'm pretty sure it was <http://www.therossman.org/experiments/wmp_play.html>, fyi. It use to work in Firefox. But, it doesn't seem to now, which is good.