Closed Bug 828554 Opened 8 years ago Closed 8 years ago

addEventListener treats aWantsUntrusted parameter inconsistently (postMessage and overwriting issues)


(Core :: XPConnect, defect)

17 Branch
Not set





(Reporter: sheerun, Unassigned)



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) {

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:

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.
Component: Untriaged → XPConnect
Product: Firefox → Core
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?
6394   message->SetTrusted(mTrustedCaller);

One more note.  How did this come up?  Knowing that sort of affects the priority of changes here...
Depends on: 829250
Depends on: 829252
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.
My patches in bug 829252 fix this, once I get them all squared away.
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.
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?
Ever confirmed: true
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?
I checked it and the test passes on latest Firefox Nightly for Mac.
Great, thanks!
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.