WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
66789
MessageEvent.ports shouldn't ever be null.
https://bugs.webkit.org/show_bug.cgi?id=66789
Summary
MessageEvent.ports shouldn't ever be null.
David Levin
Reported
2011-08-23 11:13:41 PDT
Currently we set it to null in various circumstances and this doesn't follow the spec. Also, see
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13675
Attachments
Patch
(18.64 KB, patch)
2011-08-23 11:54 PDT
,
David Levin
no flags
Details
Formatted Diff
Diff
Patch
(18.64 KB, patch)
2011-08-23 15:57 PDT
,
David Levin
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
David Levin
Comment 1
2011-08-23 11:54:03 PDT
Created
attachment 104877
[details]
Patch
Darin Adler
Comment 2
2011-08-23 13:21:56 PDT
Comment on
attachment 104877
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=104877&action=review
> LayoutTests/fast/workers/resources/worker-thread-multi-port.js:4 > + testPassed("event.ports is non-null and zero- ength when no port sent");
I think this is an editing mistake where you turned the "l" into a space instead of turning the"-" into a space.
David Levin
Comment 3
2011-08-23 15:57:49 PDT
Created
attachment 104921
[details]
Patch
Darin Adler
Comment 4
2011-08-23 15:58:08 PDT
Comment on
attachment 104877
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=104877&action=review
> Source/WebCore/bindings/js/JSMessageEventCustom.cpp:49 > MessagePortArray* ports = static_cast<MessageEvent*>(impl())->ports(); > if (!ports || ports->isEmpty()) > - return jsNull(); > + return constructEmptyArray(exec, globalObject());
It seems there is no need to check ports->isEmpty() any more here, since empty is no longer a special case. Unless we want a performance optimization for the empty case. It also seems to me we could change things so a MessageEvent always has a MessagePortArray in it, and then we might not need a custom binding at all!
Darin Adler
Comment 5
2011-08-23 15:59:10 PDT
Comment on
attachment 104921
[details]
Patch I made a comment on the old patch that still applies. Seems to me that the “ports is an empty array instead of null” rule could be in the DOM instead of in the binding.
David Levin
Comment 6
2011-08-23 17:49:15 PDT
(In reply to
comment #4
)
> (From update of
attachment 104877
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=104877&action=review
> > > Source/WebCore/bindings/js/JSMessageEventCustom.cpp:49 > > MessagePortArray* ports = static_cast<MessageEvent*>(impl())->ports(); > > if (!ports || ports->isEmpty()) > > - return jsNull(); > > + return constructEmptyArray(exec, globalObject()); > > It seems there is no need to check ports->isEmpty() any more here, since empty is no longer a special case. Unless we want a performance optimization for the empty case.
Good point. I'll clean that up before check-in.
> > It also seems to me we could change things so a MessageEvent always has a MessagePortArray in it, and then we might not need a custom binding at all!
I tried this and failed -- probably something simple. (Along with a few other changes) I tried to express the array as follows - readonly attribute [CustomGetter] Array ports; + readonly attribute MessagePort[] ports; but that didn't work and I couldn't quickly figure out how to do the array, so I filed 66829 to do this later.
David Levin
Comment 7
2011-08-23 17:51:12 PDT
(In reply to
comment #6
)
> I tried this and failed -- probably something simple. (Along with a few other changes) I tried to express the array as follows > - readonly attribute [CustomGetter] Array ports; > + readonly attribute MessagePort[] ports; > but that didn't work and I couldn't quickly figure out how to do the array, so I filed 66829 to do this later.
I also tried readonly attribute Array ports; and had problems.
David Levin
Comment 8
2011-08-24 10:42:48 PDT
Committed as
http://trac.webkit.org/changeset/93709
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug