-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Events whose composed flag should be true #513
Comments
@sorvell, I would like to hear opinions from Polymer folks too. Does the decision affect Polymer's implementation? |
TouchEvents and PointerEvents are also candidates. Given that, instead of enumerating every candidates, Is that okay? |
We really have to update the relevant specifications that dispatch UI events. And if you really want to create a monkey patch first, I think it's better to be exhaustive than to hope implementations will do the right thing. |
We should explicitly enumerate every event. |
I agree that we should explicitly enumerate every event. Let me try to enumerate every event here before updating the relevant specifications. |
Here is the exhaustive list. This should be a good starting point, hopefully. I think it is important that we can know the rationale how we can make the list.
|
Yeah, I think per interface basis might work well here because I could not find any exceptional case. However, I do not agree the rationale you mentioned :)
|
It's worth checking to see if https://html.spec.whatwg.org/multipage/indices.html#events-2 has any events you'll want to include. My guess is that most of them that could be considered "UI events" are already in those other specs but some might be missing. E.g. I think |
Drag-and-drop too probably. Drag-and-drop and cut/copy could be tricky with the user leaking nodes from shadow trees. Maybe that's okay... |
I agree in the case author specified a value but we should just change the default value for |
Can we do that? I am afraid that it is confusing if EventInit's default value depends on Event's interface.
I prefer not changing the default value, per Event interface.
Thus, I would like users to specify it explicitly as UA does. |
It looks that DragEvent inherits MouseEvent. Thus, this can be automatic if we use per-interface basis. |
cut/copy/paste are defined in https://w3c.github.io/clipboard-apis/ Its interface is
I have taken a look at the spec, however, I do not have any preference whether to add ClipBoardEvent or not. I guess there are different opinions on ClipboardEvent. It might be good to exclude it as a starting point. If web developers find that it is inconvenient, we can add it without a significant risk, I think. |
In summary, so far: Inheritance hierarchy:
If we use per-interface basss, |
The thing is, If we're not going to the route of initializing based on the interface, then we absolutely need to enumerate every single event for which |
If possible, I would like to adopt per-interface basis for synthetic events too, but my conern is its feasibility. Suppose the following cases:
If we adopt "default changes per-interface" for synthetic events too, I think user's expectations are:
However, since |
I don't understand how that works. You're invoking a different constructor. Surely you ought be able to distinguish that |
I have found that Blink's Web IDL binding generates the following for EventInit: https://cs.chromium.org/chromium/src/out/Debug/gen/blink/core/events/EventInit.h
It is not However, does WebIDL guarantee this third state? Do every user agents can tell whether the value is missing, false or true, strictly? |
I don't have a very strong opinion here but I wanted to say that the direction this discussion is going seems rather strange to me. My mental model is that the composedness of an event is similar to whether it bubbles or is cancelable. That is, it is a property of an individual firing of the event. Saying that there should be a per-interface default for composedness seems very strange to me given that there is no similar concept for bubbles or cancelable. As far as I can tell every I can see some value in providing non-normative guidance that in general events which use the Yes, it will be a lot of work to update all the places that fire events to correctly set composed. But it is doable, and would be consistent with how the platform already works for other flags on events. I don't think we should try to take a shortcut here. |
Yeah, regarding UA events, I think "per-interface basis" is just a syntax sugar which is only valid in this discussion. Enumerating interfaces here should be just a guide which tells us where we should update. |
@domenic : That's a fair point. Let's go with explicitly enumerating every single that UA fires as |
Thank you, folks. I think the conclusion is:
In terms of implementation, I think this conclusion is implementor-friendly because we do not have to update many places in our engine. |
I have filed an issue for UIEvents specification: w3c/uievents#89 |
I think we have to reflect our conclusions to the following specifications. I have filed issues:
|
All pointer events should propagate across Shadow DOM bounaries. See WICG/webcomponents#513 for details.
Thank you for the feedback. |
Sure, you could listen for something like "click", but I'm not sure how you'd accurately know when the animation/transition is done. Plus, the last thing you'd want is user code (potentially) running during your animation. A couple of more useful examples from the Google I/O 2016 PWA (we waited for several components to fire a
|
It seems really bad to be reusing animation events for those kind of domain specific "done sliding" things. I would expect you would fire control-specific events like "toggle" or "open" or "close". Otherwise you are tying your consumers to the implementation detail of your component, which is that it currently animates. What happens when in v2 you implement a "low power mode" that stops doing animations when the battery level is low? Or in v13 when the industry has moved away from animations as a method of signifying transitions (like Apple has largely done from OS X 10.0 to the current macOS versions)? Transition/animation events definitely feel like the kind of internal-to-a-control, implementation-choice-specific, presentation-related events that should not go outside the shadow tree by default. |
@ebidel Thanks. Could components authors catch these animation events in their shadow tree, and fire a component specific custom event for component consumers? As the example does it, "on-countdown-complete", in https://github.com/GoogleChrome/ioweb2016/blob/41bdeb6ad3a41fe675f2b49dfa343121f720c135/app/elements/io-live.html#L270 Does it make an interface between component authors and component users more stable one? |
This was my earlier point:
IMO, that's all more complicated than it needs to be.
Events are part of a component's public API. I'd expect well authored components to clearly document changes. Real example: https://elements.polymer-project.org/elements/paper-button#events |
Right. I think the concern is exactly about making it easy to accidentally expose implementation details as part of a component's public API. Doing so should be intentional. |
Thank you for the feedback. For compatibility issues, a naive way of not breaking public API might be "catch an animation event in the shadow tree, and fire a new synthetic (the same kind of) animation event for the host". I am aware that this is all more complicated that it needs to be. :( Could it be an acceptable work around??? I am not sure what is the best solution to address this issue. I would like to hear opinions from other browser vendors. |
I could imagine adding some sort of a hook in v2 to make this easier. That is, add some API to specify whether a given event should propagate out of the current shadow tree. But in general, the same argument could be used to make almost every event composed, and we don't want to do that at least for v1. |
I agree with @rniwa. A v2 API where you can override some of this on the shadow root sounds interesting and might be worthwhile. |
The |
@jsilvermist you're looking for #614. |
@annevk Yes... Yes I was... Thanks! |
https://bugs.webkit.org/show_bug.cgi?id=158415 Reviewed by Chris Dumez. Source/WebCore: Replace `scoped` flag with `composed` flag and negate its meaning per the latest spec: https://dom.spec.whatwg.org/#dom-event-composed WICG/webcomponents#513 In the old spec, every event was assumed to be "composed" (crosses shadow boundaries) by default and there was `scoped` flag which prevented the event from crossing bondaries, and there was a handful of events for which `scoped` was set true when dispatched by UA. In the new spec, every event is assumed to be "scoped" and a handful of user-initiated events set `composed` flag to true, which is also exposed in EventInit dictionary. `relatedTargetScoped` flag has been removed. New behavior is identical to when this flag was set to true. No new tests since existing tests are updated to test the new flag and behavior. * dom/CompositionEvent.cpp: (WebCore::CompositionEvent::isCompositionEvent): Added. * dom/CompositionEvent.h: * dom/Event.cpp: (WebCore::Event::Event): Initialize m_composed. Also re-ordered m_type and m_isInitialized for better packing. (WebCore::Event::composed): Renamed from Event::composed. We return true whenever composed is set to true in EventInit, or the engine is dispatching an user-initiated event listed in: WICG/webcomponents#513 (comment) as well as keypress, cut, paste, and, copy as discussed in: WICG/webcomponents#513 (comment) (WebCore::Event::isCompositionEvent): Added. * dom/Event.h: (WebCore::Event::composed): Added. (WebCore::Event::scoped): Deleted. (WebCore::Event::relatedTargetScoped): Deleted. (WebCore::Event): Reordered m_type and m_isInitialized for better packing. Added m_composed and removed m_scoped and m_relatedTargetScoped. * dom/Event.idl: * dom/EventPath.cpp: (WebCore::shouldEventCrossShadowBoundary): Returns true if the event did not originate from a shadow tree (this event entered the current shadow tree via a slot so we need to proceed with the normal bubble path outside the shadow tree) or composed flag is set true. (WebCore::EventPath::EventPath): m_event no longer exists, which was only used to get the value of relatedTargetScoped which has been removed. (WebCore::EventPath::setRelatedTarget): Behave as if relatedTargetScoped is always set true since the flag has been removed. * dom/EventPath.h: * dom/FocusEvent.cpp: (WebCore::FocusEvent::relatedTargetScoped): Deleted. * dom/FocusEvent.h: * dom/MouseEvent.cpp: (WebCore::MouseEvent::relatedTargetScoped): Deleted. * dom/MouseEvent.h: LayoutTests: Updated the tests to reflect the rename of scoped to composed and the negation of its semantics. Now every Event is assumed to be scoped / non-composed by default, and we need to explicitly set composed to true in order for events to cross shadow boundaries. Also, every Event behaves as if related target is assumed to be scoped in the old terminology althoug the flag no longer exists. * fast/shadow-dom/Extensions-to-Event-Interface-expected.txt: * fast/shadow-dom/Extensions-to-Event-Interface.html: Removed a test case that was testing relatedTargetScoped to false since this flag no longer exists. * fast/shadow-dom/MouseEvent-prototype-offsetX-offsetY.html: * fast/shadow-dom/event-inside-shadow-tree.html: * fast/shadow-dom/event-inside-slotted-node.html: * fast/shadow-dom/event-with-related-target.html: * fast/shadow-dom/trusted-event-scoped-flags-expected.txt: * fast/shadow-dom/trusted-event-scoped-flags.html: * fast/xmlhttprequest/xmlhttprequest-get-expected.txt: * http/tests/workers/worker-importScriptsOnError-expected.txt: * inspector/model/remote-object-get-properties-expected.txt: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@202953 268f45cc-cd09-0410-ab3c-d52691b4dbfc
… picker https://bugs.webkit.org/show_bug.cgi?id=159686 Source/WebCore: Reviewed by Chris Dumez. The bug was caused by DOMActivate event not propagating out of the user-agent shadow tree of a file input, and FileInputType not receiving the event to open the file picker. Made DOMActivate "composed" event which cross shadow boundaries to fix the bug. The feedback was given back to W3C on WICG/webcomponents#513 (comment) Test: fast/forms/file/open-file-panel.html * dom/Event.cpp: (WebCore::Event::composed): Tools: Reviewed by Chris Dumez. Added a code to print "OPEN FILE PANEL" in the text when runOpenPanel is called in the UI delegate. * WebKitTestRunner/TestController.cpp: (WTR::runOpenPanel): (WTR::TestController::createOtherPage): (WTR::TestController::createWebViewWithOptions): LayoutTests: <rdar://problem/27263589> Reviewed by Chris Dumez. Added a regression test for opening a file picker on a type=file input element. The test currently only works on WebKit2 since the support for logging "OPEN FILE PANEL" was only added to WebKitTestRunner. Also added WebKit2 specific expected results for some tests that tries to open file panel. * fast/forms/file/open-file-panel-expected.txt: Added. * fast/forms/file/open-file-panel.html: Added. * platform/ios-simulator-wk1/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/win/TestExpectations: * platform/wk2/accessibility: Added. * platform/wk2/accessibility/axpress-on-aria-button-expected.txt: Copied from LayoutTests/accessibility/axpress-on-aria-button-expected.txt. * platform/wk2/accessibility/file-upload-button-with-axpress-expected.txt: Copied from LayoutTests/accessibility/file-upload-button-with-axpress-expected.txt. * platform/wk2/fast: Added. * platform/wk2/fast/events: Added. * platform/wk2/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt: Copied from LayoutTests/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@203187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=158415 Reviewed by Chris Dumez. Source/WebCore: Replace `scoped` flag with `composed` flag and negate its meaning per the latest spec: https://dom.spec.whatwg.org/#dom-event-composed WICG/webcomponents#513 In the old spec, every event was assumed to be "composed" (crosses shadow boundaries) by default and there was `scoped` flag which prevented the event from crossing bondaries, and there was a handful of events for which `scoped` was set true when dispatched by UA. In the new spec, every event is assumed to be "scoped" and a handful of user-initiated events set `composed` flag to true, which is also exposed in EventInit dictionary. `relatedTargetScoped` flag has been removed. New behavior is identical to when this flag was set to true. No new tests since existing tests are updated to test the new flag and behavior. * dom/CompositionEvent.cpp: (WebCore::CompositionEvent::isCompositionEvent): Added. * dom/CompositionEvent.h: * dom/Event.cpp: (WebCore::Event::Event): Initialize m_composed. Also re-ordered m_type and m_isInitialized for better packing. (WebCore::Event::composed): Renamed from Event::composed. We return true whenever composed is set to true in EventInit, or the engine is dispatching an user-initiated event listed in: WICG/webcomponents#513 (comment) as well as keypress, cut, paste, and, copy as discussed in: WICG/webcomponents#513 (comment) (WebCore::Event::isCompositionEvent): Added. * dom/Event.h: (WebCore::Event::composed): Added. (WebCore::Event::scoped): Deleted. (WebCore::Event::relatedTargetScoped): Deleted. (WebCore::Event): Reordered m_type and m_isInitialized for better packing. Added m_composed and removed m_scoped and m_relatedTargetScoped. * dom/Event.idl: * dom/EventPath.cpp: (WebCore::shouldEventCrossShadowBoundary): Returns true if the event did not originate from a shadow tree (this event entered the current shadow tree via a slot so we need to proceed with the normal bubble path outside the shadow tree) or composed flag is set true. (WebCore::EventPath::EventPath): m_event no longer exists, which was only used to get the value of relatedTargetScoped which has been removed. (WebCore::EventPath::setRelatedTarget): Behave as if relatedTargetScoped is always set true since the flag has been removed. * dom/EventPath.h: * dom/FocusEvent.cpp: (WebCore::FocusEvent::relatedTargetScoped): Deleted. * dom/FocusEvent.h: * dom/MouseEvent.cpp: (WebCore::MouseEvent::relatedTargetScoped): Deleted. * dom/MouseEvent.h: LayoutTests: Updated the tests to reflect the rename of scoped to composed and the negation of its semantics. Now every Event is assumed to be scoped / non-composed by default, and we need to explicitly set composed to true in order for events to cross shadow boundaries. Also, every Event behaves as if related target is assumed to be scoped in the old terminology althoug the flag no longer exists. * fast/shadow-dom/Extensions-to-Event-Interface-expected.txt: * fast/shadow-dom/Extensions-to-Event-Interface.html: Removed a test case that was testing relatedTargetScoped to false since this flag no longer exists. * fast/shadow-dom/MouseEvent-prototype-offsetX-offsetY.html: * fast/shadow-dom/event-inside-shadow-tree.html: * fast/shadow-dom/event-inside-slotted-node.html: * fast/shadow-dom/event-with-related-target.html: * fast/shadow-dom/trusted-event-scoped-flags-expected.txt: * fast/shadow-dom/trusted-event-scoped-flags.html: * fast/xmlhttprequest/xmlhttprequest-get-expected.txt: * http/tests/workers/worker-importScriptsOnError-expected.txt: * inspector/model/remote-object-get-properties-expected.txt: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@202953 268f45cc-cd09-0410-ab3c-d52691b4dbfc
… picker https://bugs.webkit.org/show_bug.cgi?id=159686 Source/WebCore: Reviewed by Chris Dumez. The bug was caused by DOMActivate event not propagating out of the user-agent shadow tree of a file input, and FileInputType not receiving the event to open the file picker. Made DOMActivate "composed" event which cross shadow boundaries to fix the bug. The feedback was given back to W3C on WICG/webcomponents#513 (comment) Test: fast/forms/file/open-file-panel.html * dom/Event.cpp: (WebCore::Event::composed): Tools: Reviewed by Chris Dumez. Added a code to print "OPEN FILE PANEL" in the text when runOpenPanel is called in the UI delegate. * WebKitTestRunner/TestController.cpp: (WTR::runOpenPanel): (WTR::TestController::createOtherPage): (WTR::TestController::createWebViewWithOptions): LayoutTests: <rdar://problem/27263589> Reviewed by Chris Dumez. Added a regression test for opening a file picker on a type=file input element. The test currently only works on WebKit2 since the support for logging "OPEN FILE PANEL" was only added to WebKitTestRunner. Also added WebKit2 specific expected results for some tests that tries to open file panel. * fast/forms/file/open-file-panel-expected.txt: Added. * fast/forms/file/open-file-panel.html: Added. * platform/ios-simulator-wk1/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/win/TestExpectations: * platform/wk2/accessibility: Added. * platform/wk2/accessibility/axpress-on-aria-button-expected.txt: Copied from LayoutTests/accessibility/axpress-on-aria-button-expected.txt. * platform/wk2/accessibility/file-upload-button-with-axpress-expected.txt: Copied from LayoutTests/accessibility/file-upload-button-with-axpress-expected.txt. * platform/wk2/fast: Added. * platform/wk2/fast/events: Added. * platform/wk2/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt: Copied from LayoutTests/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@203187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=158415 Reviewed by Chris Dumez. Source/WebCore: Replace `scoped` flag with `composed` flag and negate its meaning per the latest spec: https://dom.spec.whatwg.org/#dom-event-composed WICG/webcomponents#513 In the old spec, every event was assumed to be "composed" (crosses shadow boundaries) by default and there was `scoped` flag which prevented the event from crossing bondaries, and there was a handful of events for which `scoped` was set true when dispatched by UA. In the new spec, every event is assumed to be "scoped" and a handful of user-initiated events set `composed` flag to true, which is also exposed in EventInit dictionary. `relatedTargetScoped` flag has been removed. New behavior is identical to when this flag was set to true. No new tests since existing tests are updated to test the new flag and behavior. * dom/CompositionEvent.cpp: (WebCore::CompositionEvent::isCompositionEvent): Added. * dom/CompositionEvent.h: * dom/Event.cpp: (WebCore::Event::Event): Initialize m_composed. Also re-ordered m_type and m_isInitialized for better packing. (WebCore::Event::composed): Renamed from Event::composed. We return true whenever composed is set to true in EventInit, or the engine is dispatching an user-initiated event listed in: WICG/webcomponents#513 (comment) as well as keypress, cut, paste, and, copy as discussed in: WICG/webcomponents#513 (comment) (WebCore::Event::isCompositionEvent): Added. * dom/Event.h: (WebCore::Event::composed): Added. (WebCore::Event::scoped): Deleted. (WebCore::Event::relatedTargetScoped): Deleted. (WebCore::Event): Reordered m_type and m_isInitialized for better packing. Added m_composed and removed m_scoped and m_relatedTargetScoped. * dom/Event.idl: * dom/EventPath.cpp: (WebCore::shouldEventCrossShadowBoundary): Returns true if the event did not originate from a shadow tree (this event entered the current shadow tree via a slot so we need to proceed with the normal bubble path outside the shadow tree) or composed flag is set true. (WebCore::EventPath::EventPath): m_event no longer exists, which was only used to get the value of relatedTargetScoped which has been removed. (WebCore::EventPath::setRelatedTarget): Behave as if relatedTargetScoped is always set true since the flag has been removed. * dom/EventPath.h: * dom/FocusEvent.cpp: (WebCore::FocusEvent::relatedTargetScoped): Deleted. * dom/FocusEvent.h: * dom/MouseEvent.cpp: (WebCore::MouseEvent::relatedTargetScoped): Deleted. * dom/MouseEvent.h: LayoutTests: Updated the tests to reflect the rename of scoped to composed and the negation of its semantics. Now every Event is assumed to be scoped / non-composed by default, and we need to explicitly set composed to true in order for events to cross shadow boundaries. Also, every Event behaves as if related target is assumed to be scoped in the old terminology althoug the flag no longer exists. * fast/shadow-dom/Extensions-to-Event-Interface-expected.txt: * fast/shadow-dom/Extensions-to-Event-Interface.html: Removed a test case that was testing relatedTargetScoped to false since this flag no longer exists. * fast/shadow-dom/MouseEvent-prototype-offsetX-offsetY.html: * fast/shadow-dom/event-inside-shadow-tree.html: * fast/shadow-dom/event-inside-slotted-node.html: * fast/shadow-dom/event-with-related-target.html: * fast/shadow-dom/trusted-event-scoped-flags-expected.txt: * fast/shadow-dom/trusted-event-scoped-flags.html: * fast/xmlhttprequest/xmlhttprequest-get-expected.txt: * http/tests/workers/worker-importScriptsOnError-expected.txt: * inspector/model/remote-object-get-properties-expected.txt: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@202953 268f45cc-cd09-0410-ab3c-d52691b4dbfc
… picker https://bugs.webkit.org/show_bug.cgi?id=159686 Source/WebCore: Reviewed by Chris Dumez. The bug was caused by DOMActivate event not propagating out of the user-agent shadow tree of a file input, and FileInputType not receiving the event to open the file picker. Made DOMActivate "composed" event which cross shadow boundaries to fix the bug. The feedback was given back to W3C on WICG/webcomponents#513 (comment) Test: fast/forms/file/open-file-panel.html * dom/Event.cpp: (WebCore::Event::composed): Tools: Reviewed by Chris Dumez. Added a code to print "OPEN FILE PANEL" in the text when runOpenPanel is called in the UI delegate. * WebKitTestRunner/TestController.cpp: (WTR::runOpenPanel): (WTR::TestController::createOtherPage): (WTR::TestController::createWebViewWithOptions): LayoutTests: <rdar://problem/27263589> Reviewed by Chris Dumez. Added a regression test for opening a file picker on a type=file input element. The test currently only works on WebKit2 since the support for logging "OPEN FILE PANEL" was only added to WebKitTestRunner. Also added WebKit2 specific expected results for some tests that tries to open file panel. * fast/forms/file/open-file-panel-expected.txt: Added. * fast/forms/file/open-file-panel.html: Added. * platform/ios-simulator-wk1/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/win/TestExpectations: * platform/wk2/accessibility: Added. * platform/wk2/accessibility/axpress-on-aria-button-expected.txt: Copied from LayoutTests/accessibility/axpress-on-aria-button-expected.txt. * platform/wk2/accessibility/file-upload-button-with-axpress-expected.txt: Copied from LayoutTests/accessibility/file-upload-button-with-axpress-expected.txt. * platform/wk2/fast: Added. * platform/wk2/fast/events: Added. * platform/wk2/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt: Copied from LayoutTests/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@203187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Reflect the conclusion of WICG/webcomponents#513.
https://bugs.webkit.org/show_bug.cgi?id=158415 Reviewed by Chris Dumez. Source/WebCore: Replace `scoped` flag with `composed` flag and negate its meaning per the latest spec: https://dom.spec.whatwg.org/#dom-event-composed WICG/webcomponents#513 In the old spec, every event was assumed to be "composed" (crosses shadow boundaries) by default and there was `scoped` flag which prevented the event from crossing bondaries, and there was a handful of events for which `scoped` was set true when dispatched by UA. In the new spec, every event is assumed to be "scoped" and a handful of user-initiated events set `composed` flag to true, which is also exposed in EventInit dictionary. `relatedTargetScoped` flag has been removed. New behavior is identical to when this flag was set to true. No new tests since existing tests are updated to test the new flag and behavior. * dom/CompositionEvent.cpp: (WebCore::CompositionEvent::isCompositionEvent): Added. * dom/CompositionEvent.h: * dom/Event.cpp: (WebCore::Event::Event): Initialize m_composed. Also re-ordered m_type and m_isInitialized for better packing. (WebCore::Event::composed): Renamed from Event::composed. We return true whenever composed is set to true in EventInit, or the engine is dispatching an user-initiated event listed in: WICG/webcomponents#513 (comment) as well as keypress, cut, paste, and, copy as discussed in: WICG/webcomponents#513 (comment) (WebCore::Event::isCompositionEvent): Added. * dom/Event.h: (WebCore::Event::composed): Added. (WebCore::Event::scoped): Deleted. (WebCore::Event::relatedTargetScoped): Deleted. (WebCore::Event): Reordered m_type and m_isInitialized for better packing. Added m_composed and removed m_scoped and m_relatedTargetScoped. * dom/Event.idl: * dom/EventPath.cpp: (WebCore::shouldEventCrossShadowBoundary): Returns true if the event did not originate from a shadow tree (this event entered the current shadow tree via a slot so we need to proceed with the normal bubble path outside the shadow tree) or composed flag is set true. (WebCore::EventPath::EventPath): m_event no longer exists, which was only used to get the value of relatedTargetScoped which has been removed. (WebCore::EventPath::setRelatedTarget): Behave as if relatedTargetScoped is always set true since the flag has been removed. * dom/EventPath.h: * dom/FocusEvent.cpp: (WebCore::FocusEvent::relatedTargetScoped): Deleted. * dom/FocusEvent.h: * dom/MouseEvent.cpp: (WebCore::MouseEvent::relatedTargetScoped): Deleted. * dom/MouseEvent.h: LayoutTests: Updated the tests to reflect the rename of scoped to composed and the negation of its semantics. Now every Event is assumed to be scoped / non-composed by default, and we need to explicitly set composed to true in order for events to cross shadow boundaries. Also, every Event behaves as if related target is assumed to be scoped in the old terminology althoug the flag no longer exists. * fast/shadow-dom/Extensions-to-Event-Interface-expected.txt: * fast/shadow-dom/Extensions-to-Event-Interface.html: Removed a test case that was testing relatedTargetScoped to false since this flag no longer exists. * fast/shadow-dom/MouseEvent-prototype-offsetX-offsetY.html: * fast/shadow-dom/event-inside-shadow-tree.html: * fast/shadow-dom/event-inside-slotted-node.html: * fast/shadow-dom/event-with-related-target.html: * fast/shadow-dom/trusted-event-scoped-flags-expected.txt: * fast/shadow-dom/trusted-event-scoped-flags.html: * fast/xmlhttprequest/xmlhttprequest-get-expected.txt: * http/tests/workers/worker-importScriptsOnError-expected.txt: * inspector/model/remote-object-get-properties-expected.txt: Canonical link: https://commits.webkit.org/177677@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@202953 268f45cc-cd09-0410-ab3c-d52691b4dbfc
… picker https://bugs.webkit.org/show_bug.cgi?id=159686 Source/WebCore: Reviewed by Chris Dumez. The bug was caused by DOMActivate event not propagating out of the user-agent shadow tree of a file input, and FileInputType not receiving the event to open the file picker. Made DOMActivate "composed" event which cross shadow boundaries to fix the bug. The feedback was given back to W3C on WICG/webcomponents#513 (comment) Test: fast/forms/file/open-file-panel.html * dom/Event.cpp: (WebCore::Event::composed): Tools: Reviewed by Chris Dumez. Added a code to print "OPEN FILE PANEL" in the text when runOpenPanel is called in the UI delegate. * WebKitTestRunner/TestController.cpp: (WTR::runOpenPanel): (WTR::TestController::createOtherPage): (WTR::TestController::createWebViewWithOptions): LayoutTests: <rdar://problem/27263589> Reviewed by Chris Dumez. Added a regression test for opening a file picker on a type=file input element. The test currently only works on WebKit2 since the support for logging "OPEN FILE PANEL" was only added to WebKitTestRunner. Also added WebKit2 specific expected results for some tests that tries to open file panel. * fast/forms/file/open-file-panel-expected.txt: Added. * fast/forms/file/open-file-panel.html: Added. * platform/ios-simulator-wk1/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/win/TestExpectations: * platform/wk2/accessibility: Added. * platform/wk2/accessibility/axpress-on-aria-button-expected.txt: Copied from LayoutTests/accessibility/axpress-on-aria-button-expected.txt. * platform/wk2/accessibility/file-upload-button-with-axpress-expected.txt: Copied from LayoutTests/accessibility/file-upload-button-with-axpress-expected.txt. * platform/wk2/fast: Added. * platform/wk2/fast/events: Added. * platform/wk2/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt: Copied from LayoutTests/fast/events/domactivate-sets-underlying-click-event-as-handled-expected.txt. Canonical link: https://commits.webkit.org/177879@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
We have decided to use
Event.composed
flag (false by default), instead ofEvent.scoped
, negating its meaning. See the context: whatwg/html#1160.That means we should have a list of exceptional events whose composed flag should be true,
instead of the current list.
Eventually, instead of having a list in one place, each event's definition should mention its composed flag should be true in each place, but I would like to have a rough consensus here.
I have made a list of events whose composed flag should be true by default, I think. The list is basically made from UIEvent spec: https://w3c.github.io/uievents/.
I am going to update Blink's implementation, however, what do you think about Composition Events? I am not 100% sure what should I do for Composiition Events. Should we exclude Composition Events from here?
The text was updated successfully, but these errors were encountered: