828554 - addEventListener treats aWantsUntrusted parameter inconsistently (postMessage and overwriting issues)

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Adam Stankiewicz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17

Steps to reproduce:

add an event listener:

window.addEventListener('message', function(e) {
  alert(e);
});

overwrite addEventListener method this way:

var addEvent = window.addEventListener
window.addEventListener = function(a, b, c, d) { return addEvent(a, b, c, d); };

and send event using following method:

window.postMessage('Hello world!', '*');


Actual results:

No message has been displayed.


Expected results:

Message should have been displayed.

Here is the test: http://jsfiddle.net/VvCMC/2/

If you see no success alert, then test failed. It works on other browsers, but not on Firefox.

In theory providing no parameter, should behave the same way as passing undefined, but in this case Firefox treats undefined as false.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The problem is that per WebIDL providing an explicit undefined is not in fact the same as not providing an argument for optional arguments.  Unless they're marked as [TreatUndefinedAs=Missing], which we don't support yet, so aWantsUntrusted is not marked that way.  Other browsers don't have this problem because they don't have this aWantsUntrusted thing going on.

And of course window.addEventListener is XPConnect, not WebIDL.  Though I wonder if we can fix that now that we have an abstract EventTarget class.

That all said, why are message events sent via postMessage untrusted?

Comment 2

[Boris Zbarsky [:bzbarsky]]

6394   message->SetTrusted(mTrustedCaller);

<sigh>.

Comment 3

[Boris Zbarsky [:bzbarsky]]

One more note.  How did this come up?  Knowing that sort of affects the priority of changes here...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, actually the WebIDL aWantsUntrusted is nullable, with null indicating "do the default thing", so this should actually Just Work if we fix bug 829252 I think.

Comment 5

[Boris Zbarsky [:bzbarsky]]

My patches in bug 829252 fix this, once I get them all squared away.

Comment 6

[Adam Stankiewicz]

It caused our application to fail, because of history.js library that overwrited addEventListener and removeEventListener methods in the way I described. It required a lot of debugging.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Understood; I was mostly trying to figure out whether this is a common issue on the web or something limited to particular cases, and hence whether fixing this in 21 is good enough or whether we need to somehow backport to older branches.

Do you have any idea why this history.js library does anything at all with the fourth argument?  Is it a Gecko-specific library?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Adam, I believe this should be fixed once bug 829252 makes it into a nightly (likely tomorrow or the day after).  Would you mind retesting on your end in a few days?

Comment 9

[Adam Stankiewicz]

I checked it and the test passes on latest Firefox Nightly for Mac.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Great, thanks!