713598 - WebSockets' on{open/error/close/message} should be TreatNonCallableAsNull

Status: RESOLVED DUPLICATE of bug 687332

(Core :: Networking: WebSockets, defect)

Description

[Jason Duell]

If anybody (khuey?) knows the bug # of the nsDOMEventTargetHelper bug (see below) that would be great.   Will that bug also fix this one, or is there more work to do?


>> 1) Added [TreatNonCallableAsNull] to some functions
>>     - what does that mean exactly? My DOM-Fu is weak
>>   [TreatNonCallableAsNull] attribute Function onopen
>>   [TreatNonCallableAsNull] attribute Function onerror
>>   [TreatNonCallableAsNull] attribute Function onclose
>>   [TreatNonCallableAsNull] attribute Function onmessage
>
> It means that if you do:
>
> ws = new WebSocket(...);
> ws.onopen = someFunction;
> ws.onopen = 2;
>
> The second line shouldn't throw, rather it should act as "ws.onopen =
> null;". Olli would know how to hook this up as I think we do this on
> elements correctly now.

There is a bug open to implement it correctly for
nsDOMEventTargetHelper objects too. (nsWebSocket extends nsDOMEventTargetHelper)
IIRC, it is assigned to khuey

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Olli is probably referring to Bug 687332.

Comment 2

[Jason Duell]

mmmK.  So my read of bug 687332 is that 1) I should wait until that bug is resolved to know how to handle this, and that 2) we'll need to write a separate patch for this bug to handle the websockets case, since khuey seemed to run into some issue when he tried to do it in bug 687332.

khuey: I'd be happy to work together on figuring out what wasn't working in the WS case, if that appeals.  I don't know DOM stuff well so that might save me (at least) some time.

I'm also assuming this is not super-high priority...

Comment 3

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Fixed by bug 687332