third_party/WebKit/LayoutTests/vibration/vibration-durations-expected.txt - Issue 2778693004: Remove navigator.vibrate without user gesture.

Side by Side Diff: third_party/WebKit/LayoutTests/vibration/vibration-durations-expected.txt

Issue 2778693004: Remove navigator.vibrate without user gesture. (Closed)

Patch Set: Add entries in histograms.xml to fix the broken about_flags_unittest. Created 3 years, 8 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

« no previous file with comments | « third_party/WebKit/LayoutTests/vibration/cancel-vibration-during-pattern-vibrating-expected.txt ('k') | third_party/WebKit/LayoutTests/vibration/vibration-exceptions-expected.txt » ('j') | third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
	1 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.
	Rick Byers 2017/03/29 18:01:40 I think you want to change the test to simulate a I think you want to change the test to simulate a user gesture, since that's really the codepath the tests intend to validate. Then we can avoid adding all these warnings to the expected output. Ideally you'd have at least one test which intentionally doesn't have a gesture to test the error message and eventual failure. Note that often we'll de-dupe warnings to prevent a frequently called API from generating an infinite number. The risk here seems low with vibrate so it's probably better as-is, but thought it was worth mentioning. binlu 2017/04/11 21:54:25 Done: (1) Made changes to the tests to simulate us Done: (1) Made changes to the tests to simulate user click via adding a user-gesture-utils.js file in third_party/WebKit/LayoutTests/resources. (2) Added another test to test the cases of before/during/after user click on the top page: http/tests/security/vibration/vibrate-on-top-page-before-during-after-user-gesture.html Any pointer on how to de-dupe warnings (even if we don't need it for this change)? On 2017/03/29 18:01:40, Rick Byers wrote: Show quoted text > I think you want to change the test to simulate a user gesture, since that's > really the codepath the tests intend to validate. Then we can avoid adding all > these warnings to the expected output. > > Ideally you'd have at least one test which intentionally doesn't have a gesture > to test the error message and eventual failure. > > Note that often we'll de-dupe warnings to prevent a frequently called API from > generating an infinite number. The risk here seems low with vibrate so it's > probably better as-is, but thought it was worth mentioning. > Rick Byers 2017/04/14 01:09:13 You could use the machinery in Deprecation.cpp (wh Show quoted text On 2017/04/11 21:54:25, binlu wrote: > > Done: > (1) Made changes to the tests to simulate user click via adding a > user-gesture-utils.js file in third_party/WebKit/LayoutTests/resources. > (2) Added another test to test the cases of before/during/after user click on > the top page: > http/tests/security/vibration/vibrate-on-top-page-before-during-after-user-gesture.html > > Any pointer on how to de-dupe warnings (even if we don't need it for this > change)? You could use the machinery in Deprecation.cpp (which relies on UseCounter.cpp to keep track of the usage seen per Page since the last page load). Show quoted text > > > On 2017/03/29 18:01:40, Rick Byers wrote: > > I think you want to change the test to simulate a user gesture, since that's > > really the codepath the tests intend to validate. Then we can avoid adding > all > > these warnings to the expected output. > > > > Ideally you'd have at least one test which intentionally doesn't have a > gesture > > to test the error message and eventual failure. > > > > Note that often we'll de-dupe warnings to prevent a frequently called API from > > generating an infinite number. The risk here seems low with vibrate so it's > > probably better as-is, but thought it was worth mentioning. > > >
	2 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.
	Rick Byers 2017/03/29 18:01:40 Why are we getting this version of the warning whe Why are we getting this version of the warning when status=experimental features are enabled by default for LayoutTests (outside virtual/stable)? Shouldn't we be getting the "has been blocked" warning? binlu 2017/04/11 21:54:25 Is my understanding right that it says "content_sh Is my understanding right that it says "content_shell will not enable experimental/test features by default ..." according to https://www.chromium.org/blink/runtime-enabled-features. Anyway, I changed the experiment feature to FEATURE_ENABLED_BY_DEFAULT (from XXX_DISABLED_BY_DEFAULT), and so we see the "has been blocked" warning. Please let me know if I'm doing it wrong. Thanks. On 2017/03/29 18:01:40, Rick Byers wrote: Show quoted text > Why are we getting this version of the warning when status=experimental features > are enabled by default for LayoutTests (outside virtual/stable)? Shouldn't we > be getting the "has been blocked" warning? Rick Byers 2017/04/14 01:09:13 That page is confusing, sorry. Running layout tes Show quoted text On 2017/04/11 21:54:25, binlu wrote: > Is my understanding right that it says "content_shell will not enable > experimental/test features by default ..." according to > https://www.chromium.org/blink/runtime-enabled-features. That page is confusing, sorry. Running layout tests DOES run with the --dump-render-tree flag (although it's actually called --run-layout-test now). So LayoutTests have status=test (and experimental) enabled by default except inside the virtual/stable virtual test suite. Show quoted text > Anyway, I changed the experiment feature to FEATURE_ENABLED_BY_DEFAULT (from > XXX_DISABLED_BY_DEFAULT), and so we see the "has been blocked" warning. > Please let me know if I'm doing it wrong. Thanks. Have you verified that running your Chrome build manually you don't now get the experimental behavior enabled? You don't want to accidentally ship this just yet ;-). The tests should be testing what we expect to ship in M60 and you should manually verify that (other than warnings) things behave as before in M59. If necessary we can add tests to the 'stable' testsuite to also test the M59 behavior but I don't think it's worth worrying about. Show quoted text > On 2017/03/29 18:01:40, Rick Byers wrote: > > Why are we getting this version of the warning when status=experimental > features > > are enabled by default for LayoutTests (outside virtual/stable)? Shouldn't we > > be getting the "has been blocked" warning? >
	3 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	4 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

	5 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	6 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

	7 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	8 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

	9 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	10 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

	11 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	12 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

	13 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	14 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

	15 CONSOLE WARNING: line 1: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/56442738 61001216.

	16 CONSOLE WARNING: line 17: A call to navigator.vibrate will soon require user tap on the frame or any embedded frame:https://www.chromestatus.com/feature/5644273 861001216.

1 Tests for how durations are handled in the Vibration API.	17 Tests for how durations are handled in the Vibration API.

2	18

3 On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE ".	19 On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE ".

4	20

5	21

6 PASS navigator.vibrate([]) is true	22 PASS navigator.vibrate([]) is true

7 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), []) is true	23 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), []) is true

8 PASS internals.isVibrating(navigator) is false	24 PASS internals.isVibrating(navigator) is false

9 PASS navigator.vibrate(0) is true	25 PASS navigator.vibrate(0) is true

10 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), []) is true	26 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), []) is true

(...skipping 13 matching lines...) Expand all Loading...
24 PASS navigator.vibrate(-1) is true	40 PASS navigator.vibrate(-1) is true

25 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), []) is true	41 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), []) is true

26 PASS internals.isVibrating(navigator) is false	42 PASS internals.isVibrating(navigator) is false

27 PASS navigator.vibrate([-1, -1, -1]) is true	43 PASS navigator.vibrate([-1, -1, -1]) is true

28 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), [10000, 10000, 10000]) is true	44 PASS areArraysEqual(internals.pendingVibrationPattern(navigator), [10000, 10000, 10000]) is true

29 PASS internals.isVibrating(navigator) is true	45 PASS internals.isVibrating(navigator) is true

30 PASS successfullyParsed is true	46 PASS successfullyParsed is true

31	47

32 TEST COMPLETE	48 TEST COMPLETE

33	49

OLD	NEW