Closed Bug 675884 Opened 13 years ago Closed 13 years ago

Implement Event constructors

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: annevk, Assigned: smaug)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files, 1 obsolete file)

DOM Core introduces a constructor syntax for Events.

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event

Please implement it so init*Event() can die in a fire.
OS: Mac OS X → All
Hardware: x86 → All
Assignee: nobody → bugs
Patch coming soon for Event and CustomEvent.
I don't know specs defining other event ctors.
Ah, there are other specs for other event ctors.

But I'll start from Event and CustomEvent.
Attached patch patch (obsolete) — Splinter Review
This adds the basic stuff (Event and CustomEvent and ctors are defined in DOM4).
After this adding support for new event ctors is easy:
- Create FooEventInit interface
- Add NS_DEFINE_EVENT_CTOR(Foo) and NS_DEFINE_EVENT_CONSTRUCTOR_FUNC_DATA(Foo)
  to nsDOMClassInfo.cpp
- virtual const nsIID& EventInitIID() { return NS_GET_IID(nsIFooEventInit); } 
  to the nsDOMFooEvent.h
- Implement
  virtual nsresult InitFromCtor(const nsAString& aType, nsISupports* aDict);
Attachment #580075 - Flags: review?(jst)
Can you check the expected behaviour for { bubbles: get () { throw foo } } and add a test?

Also, \o/
Attached patch patchSplinter Review
Handle exceptions per WebIDL
Attachment #580075 - Attachment is obsolete: true
Attachment #580075 - Flags: review?(jst)
Attachment #580086 - Flags: review?(jst)
Blocks: 708701
Comment on attachment 580086 [details] [diff] [review]
patch

>--- a/content/events/src/nsDOMEvent.cpp
>+++ b/content/events/src/nsDOMEvent.cpp
>+nsDOMEvent::Initialize(nsISupports* aOwner, JSContext* aCx, JSObject* aObj,
>+                       PRUint32 aArgc, jsval* aArgv)
>+{
>+  JSAutoRequest ar(aCx);
>+  JSString* jsstr = JS_ValueToString(aCx, aArgv[0]);
>+  if (!jsstr) {
>+    return NS_ERROR_DOM_SYNTAX_ERR;
>+  }
>+
>+  JS::Anchor<JSString*> deleteProtector(jsstr);
>+  size_t length;
>+  const jschar* chars = JS_GetStringCharsAndLength(aCx, jsstr, &length);
>+  if (!chars) {
>+    return NS_ERROR_OUT_OF_MEMORY;
>+  }
>+
>+  nsAutoString type;
>+  type.Assign(chars, length);
>+  deleteProtector.clear();

Can this use nsDependentJSString?
I don't know why nsDependentJSString is ever safe to use.
I'm trying to write a code generator for event ctors.

But feel free to review the current patches.
I filed Bug 709569 to get a tool for generic dictionary handling.
I'll file a followup bug to get better nsDependentJSString <-> JS::Anchor 
handling. nsDependentJSString could just do the right thing with JSString, or at 
least  enforce that JS::Anchor is used.
Attachment #580086 - Attachment is obsolete: true
Attachment #580086 - Flags: review?(jst)
Attachment #580731 - Flags: review?(jst)
Comment on attachment 580086 [details] [diff] [review]
patch

er, the previous patch is on top of this.
Attachment #580086 - Attachment is obsolete: false
Attachment #580086 - Flags: review?(jst)
Attachment #580086 - Flags: review?(jst) → review+
Attachment #580731 - Flags: review?(jst) → review+
We really need serious documentation for this...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: