So far all I can tell is that we end up trying to init the map _twice_ in the working build (both times under the same each() call, just in two different callback invocations) but only once in the non-working build.....

More precisely, Ya.WM.App.init is reached exactly once in the working build and not at all in the non-working one. But it's reached via an afterCurrentEvent() callback and it seems that the _second_ afterCurrentEvent call is the one that ends up reaching it.
That second call happens when doing an each() when the name of the current prop is "b-page". The first one happens when the name is "b-wm-app".
Debugging this would be a lot simpler with unminified code for the Yandex stuff. :(

So we reach this code:
BEM.DOM.decl("b-page", {
onSetMod: {
js: function () {
Ya.WM.App.init(this.findBlockOn("b-wm-app"), this.params)
}
}
});
in the wikimaps script in both cases. But the above onSetMod.js doesn't seem to be called in the non-working build.
I did some digging, and that also ends up called from afterCurrentEvent. So I really need to figure out where in the mess of minified foreach spaghetti things are going wrong there. :(
Azat, I could really use some help from your end here...

OK, looks like D is just a jquery wrapper for the <body>.
And it has getAttribute("onclick") returning the string that ends up in 'A' in a working build.
So the key part here is that attr() in jQuery 1.5.2 looks like this (trimming out the irrelevant bits):
if ( (name in elem || elem[ name ] !== undefined) && notxml && !special ) {
return elem[name];
}
// Fall through to getAttribute
while jQuery 1.6 has a blacklist of things that shouldn't get the getAttribute treatment and does getAttribute by default.

I see what's going on here... The problem is that the onclick attribute leads to an event handler being added to the _window_. We do that for all attributes on <body>. This does not actually match the HTML5 spec, sadly.
But the forwarding to window only happens for the on* getters and setters for particular event names, per spec.
So we do compile that attribute into a function, and stick it on the window. But body.onclick returns null, not that function.
We need to either change the attribute forwarding to forward only that whitelist of attributes (not that hard, actually) or change body and frameset to forward all on* gets/sets to the window (also not that hard). Or back out the event changes on aurora, of course.... This last would entail a noticeable DOM performance regression at this point, with type inference enabled.
Jonas, Olli, preferences for which approach to take here?

Oh, and my general take on the risks of those approaches....
Implementing what the spec says right now is a no-go in my opinion. For example, it lists "pageshow" as an event that does not work as an onpageshow attribute on <body>, which is not what either we or WebKit do. We certainly have tests depending on it (though not many); I would assume there is web content depending on it too.
So my gut feeling is that if forward _fewer_ content attributes to the window we should still forward everything that's in FORWARDED_EVENT and WINDOW_EVENT in the event list. These are all the _idl_ attributes that get forwarded to the window so the two lists will be consistent. I suspect we want to actually spec it that way, except for the view events that are WINDOW_EVENT but not a supported on* content attribute at all (in this case, only "message"). There is some risk in this approach, since it will attach fewer listeners to the window than we do now, of course.
The other option is to forward all on* sets on the body and frameset to the window, as well as all the relevant attributes. This would, I believe, effectively keep our old behavior, but I do think we want to change that behavior eventually (e.g. other UAs don't have it). So it would just be putting things off. But it's probably a safer change.
Perhaps the right thing to do is to forward fewer attributes on m-c and to forward more on* property on aurora.... I'm not sure what I think of landing a change on aurora without it really baking on m-c, though.

One other note: in the old code we do NOT forward any on* DOM properties from body to window (but we do register the on* attribute handlers on window). The only reason the yandex code worked is that attr() tested false for |"onclick" in body| and fell through to getAttribute. This is also why they have the silly new Function dance.
Given that, and given that I had misunderstood what the spec was saying, smaug and I think that it would probably be safest to align to the spec here. I'll post a patch for that (passing try and all) in a few minutes.

The change that was made is that HTML that looks like this:
<body onfoo="something">
only sets up an event listener on the window for some values of foo (the ones listed in the spec), not all values of foo. The relevant spec section is http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects and in particular the table following the "The following are the event handlers (and their corresponding event handler event types) that must be supported by Window objects, as IDL attributes on the Window object, and with corresponding content attributes and IDL attributes exposed on the body and frameset elements" text.

The second table is for all elements except body (and frameset; that needs to be added to the spec) and for Document.
The third table is for Window, body, and frameset.
The behaviors are slightly different; an onload property on a <script> registers an event handler for that <script>, while an onload property on a <body> registers an event handler on the Window.

OK, I think the docs are updated. There are some fine points that need to be clarified on the docs for specific events, but documenting those events in detail is outside the scope of this particular bug.
https://developer.mozilla.org/en/DOM/DOM_event_reference
I've also mentioned this on Firefox 9 for developers.

Note

You need to
log in
before you can comment on or make changes to this bug.