Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable ConsumeGestureOnNavigation by default #10200
See blink-dev thread:
A browser test is moved to be a tentative WPT due to this change.
Revert "Enable ConsumeGestureOnNavigation by default"
This reverts commit 2ca250d409adfa73a666daabd3ba19b94d6443a7.
Reason for revert: A leak bot complains navigation-consumes-user-activation.tentative.sub.html is leaking.
Started: 2018-03-27 22:31:40
Browser: "Chrome Dev"
Apr 9, 2018
This has already been reverted in Chromium, but I commented on the original review about the flakiness:
@kereliuk hm I wonder if the timeout is due to races with the test instrumentation and the final top-level navigation this test does?
Does WPT have any slow endpoint that takes a while for a response to come back? Then we might be able to abort the navigation before it commits.
OK. To keep our export pipeline flowing I've manually put the revert commit on this as well and will rebase+merge both. This will be a no-op change which is a bit silly, but we currently don't have a way to mark Chromium commits as not needing export once they've landed, and we'd otherwise keep trying to export the revert which would never apply.
Apr 10, 2018
1 check was pending
Thanks @foolip. Can you clarify what you mean by " it's possible the Travis VMs are unload load"? I was thinking of making the test navigate to some endpoint that would delay for arbitrary lengths of time (e.g. a minute), but then immediately abort the navigation (via window.stop).
I think the issue comes from the fact that navigating away from the document under test is confusing to the wpt test harness (and potentially also to the leak detector).
I mean that if the test assumes that some operation will be fast, or the network snappy, then that might not be true in testing infrastructure like Travis.
@csharrison, can the test be written to do the navigation in a new window, opened with
@foolip I don't think it would work, the feature only governs navigations in the current main frame. Additionally, any API that ends up creating a new window should consume a user gesture / user activation anyway in Chrome, so we wouldn't really be testing the feature.