Closed Bug 906511 Opened 11 years ago Closed 10 years ago

Wrong set bubbles and cancelable properties for document.createEvent()

Categories

(Core :: DOM: Events, defect)

26 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: crimsteam, Assigned: ayg)

References

()

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

Method document.createEvent() wrong set default properties for events, like Event.bubbles and Event.cancelable. Its synthetic event and should be false, even if we not initiate them. Other browser works fine.


Actual results:

<script>

	var event = document.createEvent("Event");

	document.write(event.bubbles); // true
	document.write("<br>");
	document.write(event.cancelable); // true

</script>


Expected results:

<script>

	var event = document.createEvent("Event");

	document.write(event.bubbles); // false
	document.write("<br>");
	document.write(event.cancelable); // false

</script>
So trying to change the default in WidgetEvent's constructor is presumably insanity.  How else can this be done, though?  It looks like there's no way to change .bubbles after init, so we can't easily fix it in places higher up the chain like nsIDocument::CreateEvent.  I don't know the right way to do this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Making createEvent to use *EventInit for construction would initialize properties to default values.
https://tbpl.mozilla.org/?tree=Try&rev=ddfeb874e321

Is this the only web-exposed way to create events?  It seems the Event constructor already correctly initializes .bubbles and .cancelable to false somewhere.
I guess we could do that. It is a bit hackish to init in sIDocument::CreateEvent, but
C++ code will anyway then call Init*Event again.

Don't use "", but EmptyString()
It looks like InitEvent() somehow sets the event to initialized, i.e., it has side-effects other than setting bubbles/cancelable.  Specifically, it causes these failures:

1671 INFO TEST-UNEXPECTED-FAIL | /tests/dom/events/test/test_bug641477.html | Should have thrown InvalidStateError!
5062 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/imptests/html/dom/events/test_EventTarget-dispatchEvent.html | If the event's initialized flag is not set, an InvalidStateError must be thrown.: assert_throws: function "function () { document.dispatchEvent(e) }" did not throw

Do you have any suggestions for how else to do this?  How does new Event() set the flags?  I can't find where the code for that lives.
Flags: needinfo?(bugs)
Oh right, initEvent ends up setting mEvent->message, so
NS_ENSURE_TRUE(aEvent->message || !aDOMEvent || aTargets,
                 NS_ERROR_DOM_INVALID_STATE_ERR);
will throw.

Instead of calling InitEvent, you could do something like
WidgetEvent* e = event->GetInternalNSEvent()
e->mFlags.mBubbles = false;
e->mFlags.mCancelable = false;
Flags: needinfo?(bugs)
https://tbpl.mozilla.org/?tree=Try&rev=c85cd3893ced
Status: NEW → ASSIGNED
OS: Windows 7 → All
QA Contact: ayg
Hardware: x86_64 → All
Attached patch patchSplinter Review
Try run is green.
Assignee: nobody → ayg
Attachment #8404748 - Flags: review?(bugs)
Attachment #8404748 - Flags: review?(bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/0db7896686a0
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.