13 Bluetooth wpt tests failing with UserActivation v2 |
||||||||||
Issue descriptionAs of today, enabling UAv2 causes 13 wpt layout test to fail, and all of them use testdriver.js:callWithTrustedClick. external/wpt/bluetooth/requestDevice/cross-origin-iframe.sub.https.html external/wpt/bluetooth/requestDevice/request-from-iframe.https.html external/wpt/bluetooth/requestDevice/request-from-sandboxed-iframe.https.html external/wpt/bluetooth/server/disconnect/detach-gc.https.html external/wpt/bluetooth/server/disconnect/gc-detach.https.html external/wpt/bluetooth/server/getPrimaryService/gen-discovery-complete-no-permission-absent-service.https.html external/wpt/bluetooth/server/getPrimaryService/gen-discovery-complete-service-not-found.https.html external/wpt/bluetooth/server/getPrimaryService/two-iframes-from-same-origin.https.html external/wpt/bluetooth/server/getPrimaryServices/gen-discovery-complete-no-permission-absent-service-with-uuid.https.html external/wpt/bluetooth/server/getPrimaryServices/gen-discovery-complete-service-not-found-with-uuid.https.html external/wpt/bluetooth/service/getCharacteristic/gen-reconnect-during.https.html external/wpt/bluetooth/service/getCharacteristics/gen-reconnect-during-with-uuid.https.html external/wpt/bluetooth/service/getCharacteristics/gen-reconnect-during.https.html The following non-wpt test is also failing because it uses the same function above through wpt/bluetooth/resources/bluetooth-helpers.js: bluetooth/characteristic/notifications/notification-after-disconnection.html
,
Jul 11
I was hoping this is related to Issue 601584 but the CL there doesn't fix this bug. Here the test seems to expect that main frame activation is visible to a subframe (I checked request-from-iframe.https.html), which is not the case with UAv2.
,
Jul 11
An update to the original post: the tests marked "***" also fails in site_per_process_webkit_layout_tests but they are marked [Skip] in FlagExpectations/site-per-process.
,
Jul 11
The blocker here is the test_driver.js API: test_driver.click(element) For UAv2, we have to send the clicks to a subframe for these tests. Unfortunately, |test_driver.click()| only accepts an |element| in the top level document, so there is no way to specify a subframe element (even for same-site iframes). Passing on the container iframe element doesn't work either, because the container's |onclick| is NOT triggered through a click on the container's contentDocument;
,
Sep 26
Without testdriver support, I don't see how we can fix the failing tests. ortuno@: do you see a way forward?
,
Sep 26
Is it possible to call test_driver.click() from an iframe?
,
Sep 27
FYI: my failed attempt [1] hits an assertion [2] which came from LayoutTests/resources/testdriver.js. nzolghadr@: Any clue why testdriver doesn't expect an element outside current dom? [1] crrev.com/c/1249391 [2] https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/resources/testdriver.js?rcl=f37018c402c4af20a6b89d2daf22766033f0d57d&l=103
,
Nov 14
Raising the priority since we are planning to ship UAv2 in M72.
,
Nov 19
,
Nov 19
,
Nov 19
,
Nov 19
Sorry that I missed your comment earlier. I believe it is because of the rest of the functions in that flow. Like finding whether that element is in view and scrolling it into view and whatnot. Feel free to enhance the rest of the implementation if you think that is needed and can be done.
,
Nov 19
Alternatively you can use a pointer action API and use pointermove/pointerdown/pointerup and it should work if your element is in the view already (and you are responsible for scrolling it into view if it is not.
,
Nov 19
Some of these tests are just wrong. They assume that the click in an iframe will activate the iframe doing the activity in another iframe. Or that postMessage propagates the user gesture. I don't think the click is the issue here.
,
Nov 20
,
Nov 20
These tests rely on user activation propagation, and they pass today because a click on any frame activates all (same-site) frames in old (UAv1) system. With UAv2, fixing the click target iframe should pass these test and also make them more realistic, so I wanted to give it a try. Unfortunately, testdriver.js:callWithTrustedClick turned out to be a blocker for that, because this method only performs top-window specific things (e.g. scroll into view). Anyway, I agree with #c14 that these tests are based on wrong assumptions (re user activation) that are clearly unrelated to Bluetooth API. Disabling these tests seems like a reasonable way forward for sake of UAv2 timeline.
,
Nov 20
Please don't disable our tests in order to speed up your launch. Is there a new trusted click mechanism that will work for iframes under UAv2? We can try to help with porting these tests to the new thing if it available. If it is not then I'd consider that a blocker for UAv2 launch because we cannot disable these tests until an indefinite point in the future when such a capability is available.
,
Nov 21
reillyg@ and I had a quick chat today, we agreed on the following plan: 1. Disable the tests now, and make this bug a non-blocker for UAv2 (but keep the bug open). 2. Keep working on these test failures until each has been fixed/migrated/etc.
,
Nov 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/087f2e3078f24fb8d855ca1537d350a975a06bc4 commit 087f2e3078f24fb8d855ca1537d350a975a06bc4 Author: Mustaq Ahmed <mustaq@google.com> Date: Wed Nov 21 20:22:09 2018 Disable bluetooth tests that rely on activation at non-child frames. Bug: 860713 Change-Id: I561cb3042aa1d83bd45ed7ec2678df1994da67f3 Reviewed-on: https://chromium-review.googlesource.com/c/1347058 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/heads/master@{#610195} [modify] https://crrev.com/087f2e3078f24fb8d855ca1537d350a975a06bc4/third_party/WebKit/LayoutTests/TestExpectations
,
Nov 21
,
Nov 22
> Or that postMessage propagates the user gesture. IIUC from Issue 161068, this is in fact how it's supposed to work. User gestures should propagate through postMessages.
,
Nov 23
ortuno@: This is complicated topic but in short, propagating user gesture through postMessages is old expectation that was never implemented because of complications involved (e.g. Issue 161068 is six years old, yet needed a "temporary" hack few months ago). With UAv2, we are replacing API-specific propagation with a activation-specific one, to offer a solid fix for the postMessage problem as well as others. So yes, the expectations are different now.
,
Nov 27
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by mustaq@chromium.org
, Jul 11