Summary: | dispatchEvent should raise an exception if the event object is already being dispatched | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dominic Cooney <dominicc> | ||||||||||
Component: | UI Events | Assignee: | Dominic Cooney <dominicc> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | darin, dglazkov, webkit.review.bot | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Bug Depends on: | |||||||||||||
Bug Blocks: | 63934 | ||||||||||||
Attachments: |
|
Description
Dominic Cooney
2011-07-07 23:53:14 PDT
Created attachment 100086 [details]
WIP patch
Created attachment 100090 [details]
Patch
Comment on attachment 100090 [details] Patch Attachment 100090 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9000461 New failing tests: http/tests/misc/slow-loading-mask.html http/tests/navigation/javascriptlink-frames.html fast/blockflow/japanese-rl-selection.html svg/transforms/text-with-mask-with-svg-transform.svg fast/backgrounds/background-leakage.html fast/box-shadow/scaled-box-shadow.html fast/backgrounds/repeat/negative-offset-repeat.html svg/W3C-SVG-1.1/struct-use-01-t.svg transforms/2d/hindi-rotated.html http/tests/websocket/tests/hixie76/websocket-event-target.html svg/repaint/filter-repaint.svg fast/blockflow/japanese-lr-selection.html Created attachment 100094 [details]
Archive of layout-test-results from ec2-cr-linux-01
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
http/tests/websocket/tests/hixie76/websocket-event-target.html failures look relevant; I will investigate. Comment on attachment 100090 [details]
Patch
Clearing review: ? to investigate WebSocket test failures.
Created attachment 100475 [details]
Patch
Comment on attachment 100475 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=100475&action=review > Source/WebCore/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=64150 It would be really good if you included here a link to the part of the spec you're implementing. Comment on attachment 100475 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=100475&action=review > Source/WebCore/dom/Event.h:174 > + bool isBeingDispatched() const { return eventPhase(); } Even though the implementation is different, this seems redundant with the dispatched() function. Do we really need both? (In reply to comment #9) > (From update of attachment 100475 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=100475&action=review > > > Source/WebCore/dom/Event.h:174 > > + bool isBeingDispatched() const { return eventPhase(); } > > Even though the implementation is different, this seems redundant with the dispatched() function. Do we really need both? The meanings *should* be different, so I think we need both: dispatched()—has event dispatch started for this event at any point in the past, ie can you no longer call init*Event. isBeingDispatched()—is event dispatch processing this event right now. So the state transitions are different: !dispatched() → dispatched() [terminal state] !isBeingDispatched() → isBeingDispatched() → !isBeingDispatched() → … However since bug 63934 is about the event target being reset to 0, which dispatched() depends on, I expect dispatched() is broken. If it is OK I will work on that in the context of bug 63934. Adding Darin in reply to comment 9: <https://bugs.webkit.org/show_bug.cgi?id=64150#c10> Committed r90972: <http://trac.webkit.org/changeset/90972> |