Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame #291

graouts · 2019-06-27T06:51:50Z

The test pointerevent_mouse_pointercapture_inactivate_pointer.html specifically checks that handling a pointerdown event dispatched on a target element in a child frame and calling setPointerCapture() in the parent frame on an element contained in the parent frame should not trigger pointer capture.

However, I'm not finding explicit text in the spec that would specify this behavior. The only step in Setting Pointer Capture that should fails silently is:

If the pointer is not in the active buttons state, then terminate these steps.

But I can't see anything that specifies that, in this scenario, the pointer would not be in the active buttons state.

As it stands on wpt.fyi, I see Chrome and Edge pass this test, but Firefox and Safari do not.

The text was updated successfully, but these errors were encountered:

NavidZ · 2019-07-02T15:10:45Z

@graouts You are right. It is not very clear how the active button state is defined with respect to the iframes. But how do you feel about the current behavior?

A little background on this. We realized if we had cross origin frames we didn't want the embedder or the embedded iframe call the setpointercapture if they didn't receive an active button state pointer before for security reasons. Not only that if they had received a leave event (like when pointer leaves their boundaries) we still didn't want them to be able to capture. So we thought we should not let the element that belongs to a document that doesn't have an active pointerevent in it be able to call capture. If we accept such a logic this test should also fail. As it really doesn't matter who is calling capture on the element in the embedder. Either a timeout or a function call from the inner frame. However, let's first see what you think about the behavior in general. @graouts do you think that is reasonable? @smaug---- in case this was missed before, what do you think?

smaug---- · 2019-07-02T16:35:12Z

Given the current spec, nothing prevents setPointerCapture to occur, so the test is invalid.

How did that happen, invalid test landed to wpt. Hmm, some Google internal thing... web-platform-tests/wpt@9d19b76#diff-a7cee0688ae91de031e5f94fff49e332 linking to some non-open design doc :/

That test should be removed from wpt until we've decided in the spec what the behavior should be.

smaug---- · 2019-07-02T16:47:36Z

I'm not against limiting setPointerCapture to current domain, although that does prevent certain use cases. And a question is that should it be limited to the current document, or current domain.

NavidZ · 2019-07-02T17:20:11Z

That test should be removed from wpt until we've decided in the spec what the behavior should be.

I don't mind either moving the test to the extension folder until we agree on a behavior about this. Also I believe @EiraGe just made that document public.

Regarding the use cases, what did you have in mind @smaug---- ? I'd like to know whether those would encourage any of domain vs document level capturing or not.

EiraGe · 2019-07-02T17:39:12Z

I'll have the test remove from WPT shortly. Sorry for the incorrect test :/

smaug---- · 2019-07-02T17:59:47Z

Just some embedding scenario where some cross-domain widget would do something useful. One could pass pointerid via postMessage.
Same origin iframe case is probably more compelling, since there communication is synchronous.

Does Blink limit setPointerCapture to the document, or same origin iframes or what?

This test initially added to wpt but the behavior is not clearly defined in spec. So move to non-wpt pointerevents test. See discussion in w3c/pointerevents#291 TBR=nzolghadr@chromium.org Change-Id: Ic871c57526681d790d6e68081f5a4bf8316e8494 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1684464 Reviewed-by: Ella Ge <eirage@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#674191}

NavidZ · 2019-07-03T18:35:53Z

Does Blink limit setPointerCapture to the document, or same origin iframes or what?

Our plan was to limit it to the document. There might be some bugs here and there and edge cases that we haven't caught yet but that was our plan and the current state as far as our tests say.

EiraGe · 2019-07-03T19:36:53Z

It may also have security concern for allowing capture in cross-domain widget: a frame may keep trying to capture mouse id or just random pointer ids without any postMessage.

smaug---- · 2019-07-03T22:36:10Z

What does limiting to document mean? If an element with event listener for pointerdown is moved during event dispatch to another document and then handles the event, is it allowed to call setPointerCapture?
(Remember, event path is calculated before handling the event, so capturing event listeners for example can move targets in path to other documents)

NavidZ · 2019-07-11T14:59:50Z

I believe from the Blink implementation we do limit it to the document that belongs to the event path calculation (i.e. the document that the target belonged to at the time of hit-testing). But we certainly are open to other interpretations and changing this behavior if there are use cases for them

…n-wpt pointerevent tests., a=testonly Automatic update from web-platform-tests Move a pointercapture pointer test to non-wpt pointerevent tests. This test initially added to wpt but the behavior is not clearly defined in spec. So move to non-wpt pointerevents test. See discussion in w3c/pointerevents#291 TBR=nzolghadr@chromium.org Change-Id: Ic871c57526681d790d6e68081f5a4bf8316e8494 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1684464 Reviewed-by: Ella Ge <eirage@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#674191} -- wpt-commits: 060265cb71f8cbe6e9a042e245232a0fabb07048 wpt-pr: 17614

NavidZ · 2019-08-07T15:48:59Z

This issue was discussed in today's PEWG call and we decided to add the restriction of the activeness to the target's associated document (@NavidZ to send a pull request and we can discuss further on that). Although this seems to be restricted we decided to go with that for now to make sure abusive behaviours are not possible. But we keep an eye on this in case any valid use case rises in future. @graouts do you also agree with this approach? Although we can discuss better on a concrete proposal in the PR. So I'll send one soon.

graouts · 2019-08-19T08:42:44Z

@NavidZ That seems reasonable. Has a PR materialized yet? Feel free to Cc me.

This test initially added to wpt but the behavior is not clearly defined in spec. So move to non-wpt pointerevents test. See discussion in w3c/pointerevents#291 TBR=nzolghadr@chromium.org Change-Id: Ic871c57526681d790d6e68081f5a4bf8316e8494 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1684464 Reviewed-by: Ella Ge <eirage@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#674191}

…n-wpt pointerevent tests., a=testonly Automatic update from web-platform-tests Move a pointercapture pointer test to non-wpt pointerevent tests. This test initially added to wpt but the behavior is not clearly defined in spec. So move to non-wpt pointerevents test. See discussion in w3c/pointerevents#291 TBR=nzolghadrchromium.org Change-Id: Ic871c57526681d790d6e68081f5a4bf8316e8494 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1684464 Reviewed-by: Ella Ge <eiragechromium.org> Commit-Queue: Ella Ge <eiragechromium.org> Cr-Commit-Position: refs/heads/master{#674191} -- wpt-commits: 060265cb71f8cbe6e9a042e245232a0fabb07048 wpt-pr: 17614 UltraBlame original commit: 05b8c92a2d89f41a9f2c54a401a5c16269e81017

chromium-wpt-export-bot mentioned this issue Jul 2, 2019

Move a pointercapture pointer test to non-wpt pointerevent tests. web-platform-tests/wpt#17614

Merged

NavidZ self-assigned this Aug 7, 2019

NavidZ mentioned this issue Aug 23, 2019

Define active document for the active pointers #300

Merged

NavidZ closed this as completed in #300 Nov 4, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame #291

Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame #291

graouts commented Jun 27, 2019

NavidZ commented Jul 2, 2019

smaug---- commented Jul 2, 2019 •

edited

smaug---- commented Jul 2, 2019

NavidZ commented Jul 2, 2019 •

edited

EiraGe commented Jul 2, 2019

smaug---- commented Jul 2, 2019

NavidZ commented Jul 3, 2019

EiraGe commented Jul 3, 2019

smaug---- commented Jul 3, 2019

NavidZ commented Jul 11, 2019

NavidZ commented Aug 7, 2019

graouts commented Aug 19, 2019

Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame #291

Setting pointer capture on an element in a parent frame when the pointer was made active in a child frame #291

Comments

graouts commented Jun 27, 2019

NavidZ commented Jul 2, 2019

smaug---- commented Jul 2, 2019 • edited

smaug---- commented Jul 2, 2019

NavidZ commented Jul 2, 2019 • edited

EiraGe commented Jul 2, 2019

smaug---- commented Jul 2, 2019

NavidZ commented Jul 3, 2019

EiraGe commented Jul 3, 2019

smaug---- commented Jul 3, 2019

NavidZ commented Jul 11, 2019

NavidZ commented Aug 7, 2019

graouts commented Aug 19, 2019

smaug---- commented Jul 2, 2019 •

edited

NavidZ commented Jul 2, 2019 •

edited