Touch adjustment can cause touch and click events on a tap to have different targets |
|||||||||||||
Issue description"Touch adjustment" is a feature where, on a tap (or long press) we attempt to select the best target for the event considering ALL nodes underneath the finger. For some details of how this works in chromium see: https://docs.google.com/presentation/d/1-n1qyzewpagREbzW2zm0wOalq33UhbtbSkWf9mEdly8/edit#slide=id.gba38d212_099 https://youtu.be/DujfpXOKUp8?t=16m45s http://rbyers.net/touchAdjustment.html This feature is necessary to make websites designed for desktop usable on a small touch screen. We've long debated whether it's really worth it on sites designed for mobile (issue 417534), but for now it's still enabled there. The main source of complaints we hear about touch adjustment is that it's confusing when the target of the touchstart and click events don't match (and the DOM / scroll position has not changed between these events). In particular, imagine one web component UI widget designed for touch (activates on touchend but cannot cancel the touchend event) next to another that is not designed for touch (activates on click). Each component has reasonable logic, but you could get both activating from a single tap. Our guidance for avoiding issues like this is typically: - Always use 'click' events for activation behavior (there's no longer any good reason to do your own click detection on touchend - see https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away?hl=en). - If you must activate something on touchend, call preventDefault to indicate you handled the event. - Ensure the browser knows what elements are intended to be clickable, either with dedicated 'click' event handlers (not relying exclusively on event delegation) or with a :active CSS style. But these are not always convenient and regardless there's (rightfully) a lot of confusion here. Perhaps we can do better? First I think we should survey how exactly Safari and Edge appear to behave here (they both have some sort of similar feature). Can we just match them? We've avoided "faking" the co-ordinates inside touch events because touch (and pointer) events are designed to be a low-level API that exposes the underlying OS/hardware directly. We could make things a lot worse by trying to be "smart" (eg. would be bad if you couldn't precisely draw near clickable elements in a painting app). But maybe we could change the target of the touch events (without faking the co-ordinates)? I.e. do the rect-based-hit-test at touchstart time instead of during a GestureTap? Note that we'll still have to re-do hit tests for the various events that occur during a tap in case the DOM has changed (otherwise we break websites). chongz@ is starting to look into this.
,
Jul 1 2016
,
Jul 1 2016
,
Aug 1 2016
The more I think about this, the more it seems like the most rational model is to consider touch adjustment a modification of hit-testing that applies equally to all touch-driven hit-tests (i.e. touchstart, pointerdown, mouse events). Perhaps we can just modify the target without changing any co-ordinates. If that's what Edge and/or Safari seems to do, then it's probably worth trying. See also https://github.com/w3c/pointerevents/issues/126
,
Aug 1 2016
I wonder if this will be a problem for pointer events. It's potentially surprising for click to go to the common ancestor of pointerdown/pointerup for mouse but not for touch. I believe Edge does touch adjustment on the pointer events and so will not have this confusion. Note that this is orthogonal from the arguments around what model the mouse compatibility events should follow (here we're talking just about pointer events - including "click" which is to be upgraded to be a pointer event).
,
Feb 11 2017
I would like to stress out that the current behavior, i.e. pointer and touch events having different targets than subsequent click events, is extremely confusing. Especially considering the fact that this happens only on certain devices and only when pointer hits specific area. It took me a whole day until I finally stumbled upon this bug. Lets say I wanted a custom button element to be focusable with keyboard, but not with pointing device (e.g. mouse, trackpad, touchscreen). The obvious solution is to call event.preventDefault() in pointerdown listener. However, when touch adjustments are enabled and the pointer is down slightly below the button, the pointerdown listener is not fired at all and therefore the button becomes focused even though the pointer didn't hit it. Or lets say I wanted to implement a button with ripple effect from Material Design. When the pointer is down I begin animating the ripple and when the pointer is up I'm finishing the ripple animation. Now when I have two such buttons directly next to each other and I click the space between them, the button that receives the "click" event might be different than the button that shows the ripple effect (that is suppoused to indicate click). In my opinion all events triggered by pointing devices (i.e. click, mouse*, pointer*, touch* events) should use the same hit testing algorithm to determine their target.
,
Feb 11 2017
Could you please at least make touch adjustments optional when using Chrome Dev Tools mobile emulation?
,
Feb 13 2017
Issue 399761 has been merged into this issue.
,
Feb 13 2017
I agree this is really confusing - thanks for the examples! Many apps probably avoided this issue in the past by using touchend instead of click (i.e. to avoid the click delay). This issue is probably the only last legitimate reason to avoid using 'click' events on touchscreen devices. The main (only?) reason I can think of right now for having touch adjustment apply only to click (other than implementation convenience) is to match behavior with Mobile Safari. We've been very hesitant to have touch events behave differently than in Mobile Safari, but we don't try to copy other crazy things they do (like require "clickable targets" to be identified explicitly), so perhaps we never should have copied this either. I have a hard some imagining how a site that works correctly in Safari might be broken by us changing to adjust touchstart also. Note that Edge already follows a model where touch hit-testing is consistent. So we have good reason to believe such a change is relatively web compatible. dtapuska@ WDYT? > Could you please at least make touch adjustments optional when using Chrome Dev Tools mobile emulation? DevTools aims to be a faithful representation of a mobile environment. Would it not just lead to more confusion if touch adjustment didn't always apply there? But perhaps we should add some devtools visualization to help developers see what's going on easier.
,
Feb 13 2017
> The main (only?) reason I can think of right now for having touch adjustment apply only to click (other than implementation convenience) is to match behavior with Mobile Safari. Great, that means making "pointer*" events hit testing consistent should be safe as Safari does not support them all. > DevTools aims to be a faithful representation of a mobile environment. Would it not just lead to more confusion if touch adjustment didn't always apply there? From my testing some mobile devices (at least Nexus 7) don't use touch adjustments by default while others do. Dev tools emulation seems to be always using touch adjustments even when you choose a custom "Desktop" or "Mobile (no touch)" preset which means you can't test against all possible edge cases.
,
Feb 13 2017
I don't think making only pointerevent hit testing consistent is a reasonable solution, it could cause issues with pointerdown/up vs touchstart/end handlers on nearby elements. I agree with Rick's suggestion here: we should try touch adjustment on hit-testing and check if this can really trigger a compat issue.
,
Jun 9 2017
,
Aug 30 2017
I'm concerned the proposal on the intent is moving us quite far into automagic and the original touch point becomes totally concealed from developers AFAICT. Is there some other property (existing or planned) on the touch event that would provide the true coordinate? Secondly, Safari's explicit click target mechanism sounds like it provides more developer control over the magic. What is bad about it?
,
Aug 30 2017
,
Aug 30 2017
Re #13: > I'm concerned the proposal on the intent is moving us quite far into automagic and the original touch point becomes totally concealed from developers AFAICT. Is there some other property (existing or planned) on the touch event that would provide the true coordinate? Yes I was thinking we could have some kind of <meta> or JS API to disable adjustment completely, but I don't have data to prove that such API is demanded. Would you suggest we add such API now or only after we have seen broken websites? > Secondly, Safari's explicit click target mechanism sounds like it provides more developer control over the magic. What is bad about it? I took rbyers@'s words that we don't want such mechanisms. However according to my tests Safari do have touch adjustment on link, superscript, tabindex and mousedown handler, which is the issue we want to fix.
,
Aug 30 2017
I have two separate concerns. One is that it perhaps should be possible to disable touch adjustment. The second is that when touch adjustment activates, it should still be possible to know the true touch event coordinate. The change in the intent actually is a regression on my second concern. I had one new idea: how about if we made touch adjustment change *only* the hit element but not alter the x,y coordinate at all? I.e. we would accurately report to the developer that our hit testing is no longer strict, instead of trying to pretend that it still is via fake coordinates.
,
Aug 30 2017
> I have two separate concerns. One is that it perhaps should be possible to disable touch adjustment. The second is that when touch adjustment activates, it should still be possible to know the true touch event coordinate. The change in the intent actually is a regression on my second concern. I can see your second concern, but I'm not sure how hard it would be to get buy-in from other venders for the extra coordinates on TouchEvent, GestureEvent, and probably PointerEvent as well. My assumption is that apps require precise touch support should already be mobile-optimized, and thus don't need touch adjustment. In other words: 1. Mobile-optimized sites should disable touch adjustment completely to handle precise touch. 2. Other sites most likely don't care about precise touch, and could leave touch adjustment activated. > I had one new idea: how about if we made touch adjustment change *only* the hit element but not alter the x,y coordinate at all? I.e. we would accurately report to the developer that our hit testing is no longer strict, instead of trying to pretend that it still is via fake coordinates. Yes this might work as well (similar to #4?). My only concern is we are introducing something new that doesn't match anyone else, which could lead to some new problems.
,
Aug 31 2017
Right, it's the same as #4, which I had skipped over. Anyway, it seems like the most elegant long-term direction so I wonder if it would be worth the effort of pioneering it and figuring out exactly how many compatibility problems we find. My intuition is that use cases either care about hit element or about coordinate but rarely both in combination, so there might be very few problems.
,
Aug 31 2017
Touch is implicitly captured so one should expect co-ordinates outside of your border box anyways (at least for touchmove/pointermove/touchend). The situations to think about are 1) touchstart - might be odd 2) click - mouse coordinates outside of a image submit might be a little odd for a server to handle.
,
Sep 6 2017
So Edge modifies the co-ordinate in even the pointerdown events? That's surprising to me (though may reflect an OS implementation detail). I really like the "modifies only hit-testing" model - it would be super-convenient if there was some browser that was doing something like that already ;-) In terms of disabling, I wonder if it might be trivial to add a feature policy knob for this? I still suspect adjustment should be off by default for "modern" applications, but feature policy is the knob we're trying to use to let us continually phase in new definitions of "modern".
,
Sep 7 2017
Rick, what do you envision as the 'feature' here? Is is 'touch-adjustment', enabled by default, but disableable by any content, anywhere in the frame tree? Or were you thinking something else? (And does it make sense for this to be frame-scoped, so it might be on at the top-level, but then disabled in specific frames? -- I don't know that would interact with gestures that crossed frame boundaries)
,
Oct 13 2017
Re-assign to nzolghadr@ as I no longer work on this issue. Please re-assign if someone else will takeover. Thanks!
,
Oct 13 2017
Chong's prototype was here: https://chromium-review.googlesource.com/c/chromium/src/+/655947
,
Oct 30 2017
,
Oct 30 2017
I think Ella is the right owner here?
,
Dec 20 2017
,
Jan 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b3b1612a3591e4f8309af0aeaeb95f98112bddce commit b3b1612a3591e4f8309af0aeaeb95f98112bddce Author: Ella Ge <eirage@chromium.org> Date: Tue Jan 16 17:03:19 2018 remove unused BestZoomableAreaForTouchPoint EventHandler::BestZoomableAreaForTouchPoint isn't been used ouside tests anymore. Remove related function and tests. Bug: 625198 Change-Id: I0012eefa1306810fce5a3d7ec5ade41165de585b Reviewed-on: https://chromium-review.googlesource.com/860530 Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#529448} [delete] https://crrev.com/8b44f53c3173fca3d2e66bde791b97de5b7826f6/third_party/WebKit/LayoutTests/touchadjustment/zoom-basic.html [delete] https://crrev.com/8b44f53c3173fca3d2e66bde791b97de5b7826f6/third_party/WebKit/LayoutTests/touchadjustment/zoom-fatfinger.html [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/input/EventHandler.h [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/page/TouchAdjustment.cpp [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/page/TouchAdjustment.h [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/testing/Internals.cpp [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/testing/Internals.h [modify] https://crrev.com/b3b1612a3591e4f8309af0aeaeb95f98112bddce/third_party/WebKit/Source/core/testing/Internals.idl
,
Jan 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a commit 89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a Author: Ella Ge <eirage@chromium.org> Date: Tue Jan 23 00:23:50 2018 Do touchAdjustment on TouchStart This CL implement Unified touch adjustment behind a flag. This adds TouchAdjustment logic when targeting TouchStart, and following touch events will also be captured by the same target. We only change the touch event target but keep the original coordinates. Adjusted coordinates are stored to be used in gesture events. If a gesture event has corresponding touch event adjust result, use the adjusted coordinates to do a point-base hit test instead of a rect-base hit test This cl also add a uma metric to measure distance between tap point and adjusted point (0 if not adjusted). Intent to implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/VjFBlOBwkmY Bug: 625198 Change-Id: I1463f29415c46c1cd0f98be5eeac57654c5ff833 Reviewed-on: https://chromium-review.googlesource.com/771540 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Jeremy Roman <jbroman@chromium.org> Reviewed-by: Ilya Sherman <isherman@chromium.org> Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Mustaq Ahmed <mustaq@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#531079} [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/content/browser/renderer_host/input/input_router_impl_unittest.cc [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/content/browser/renderer_host/input/legacy_input_router_impl_unittest.cc [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/content/browser/renderer_host/input/passthrough_touch_event_queue_unittest.cc [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/content/common/input/synthetic_web_input_event_builders.cc [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/TestExpectations [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/fast/events/hit-test-counts-expected.txt [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/fast/events/hit-test-counts.html [add] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/fast/events/pointerevents/pointerevent_touch-adjustment_click_target.html [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/touchadjustment/touch-links-active.html [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/touchadjustment/touch-links-longpress.html [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/LayoutTests/touchadjustment/touch-links-two-finger-tap.html [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/events/PointerEventFactory.cpp [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/events/PointerEventFactory.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/input/EventHandler.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/input/PointerEventManager.cpp [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/input/PointerEventManager.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/core/page/TouchAdjustment.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/Source/platform/runtime_enabled_features.json5 [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/public/platform/WebMouseEvent.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/public/platform/WebPointerProperties.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/third_party/WebKit/public/platform/WebTouchPoint.h [modify] https://crrev.com/89324f19f9d7ac0e36ad56791a3b9bdb9d4acf2a/tools/metrics/histograms/histograms.xml
,
Jan 24 2018
,
Jan 30 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6 commit d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6 Author: Ella Ge <eirage@chromium.org> Date: Tue Jan 30 21:30:34 2018 UMA metric to measure unified touch adjustment result This CL adds a boolean UMA metric to proof that with unified touch adjustment enabled, GestureTap will hit in the same node as before. This CL makes gesture events go through both old touch adjustment code and also the "unified touch adjustment" which do adjustment on touchstart. It adds extra hit tests. This CL also adds feature flag for finch support. This this CL should be revert after finch trial. Bug: 625198 , 805650 Change-Id: Ie82fcafef4a895eceb3ad3e2fe40fe4c05c7447d Reviewed-on: https://chromium-review.googlesource.com/852479 Reviewed-by: Rick Byers <rbyers@chromium.org> Reviewed-by: Robert Kaplow <rkaplow@chromium.org> Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#533026} [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/content/child/runtime_features.cc [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/content/public/common/content_features.cc [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/content/public/common/content_features.h [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/third_party/WebKit/LayoutTests/fast/events/hit-test-counts-expected.txt [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/third_party/WebKit/Source/platform/exported/WebRuntimeFeatures.cpp [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/third_party/WebKit/public/platform/WebRuntimeFeatures.h [modify] https://crrev.com/d76ed3e7c6cc58f8ce0a19bcc60c51bac345b0f6/tools/metrics/histograms/histograms.xml
,
Feb 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/57b9fb55cab5e7687799483b469253d00e98f611 commit 57b9fb55cab5e7687799483b469253d00e98f611 Author: Ella Ge <eirage@chromium.org> Date: Thu Feb 22 00:41:14 2018 Apply same adjustment distance limit to GE and TE From UMA histogram Event.Touch.TouchAdjustment.AdjustDistance metric, In Windows, 90% of gesture adjust distance(DiagonalLength) are under 16 pixel, 95% are 22 pixel, 99% are under 32 pixel. (Peak is around 15~16 pixel) In Android, There are an upper bound of GestureEvent radius 16pixel. The histogram data are: 90% under 7, 95% under 9, and 99% under 15. Generally, laptop's pixel density is lower than mobile device, (e.g. SurfaceBook2 is 3200*2000 267 PPI, GooglePixel is 1920*1080 441 PPI) Using MaxAdjustmentRadius = 16 should be fine. In this CL, apply a upper bound = 16 to GE and TE adjustment padding under UnifiedTouchAdjustment flag to experiment the adjustment distance. Bug: 625198 Change-Id: I6079c6aa99f19e1b89e89cc2c8e8bd44449cfcbf Reviewed-on: https://chromium-review.googlesource.com/911899 Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#538282} [modify] https://crrev.com/57b9fb55cab5e7687799483b469253d00e98f611/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/57b9fb55cab5e7687799483b469253d00e98f611/third_party/WebKit/Source/core/input/PointerEventManager.cpp [modify] https://crrev.com/57b9fb55cab5e7687799483b469253d00e98f611/third_party/WebKit/Source/core/page/TouchAdjustment.cpp [modify] https://crrev.com/57b9fb55cab5e7687799483b469253d00e98f611/third_party/WebKit/Source/core/page/TouchAdjustment.h
,
Feb 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/31cc41b9e1264fae799bc8c1a4a74522a8d802fc commit 31cc41b9e1264fae799bc8c1a4a74522a8d802fc Author: Ella Ge <eirage@chromium.org> Date: Thu Feb 22 02:09:16 2018 Add more value to TouchAdjustment UMA enum In crrev.com/c/852479, we added a UMA metric to see if tap node will be same as before with UnifiedTouchAdjustment. But the result is not as expected. In this CL, change the UMA metric to record the relation of the two hit test node. Bug: 625198 , 805650 Change-Id: Iffd45cb6ea8ac475abd011f920986c2228f51ab7 Reviewed-on: https://chromium-review.googlesource.com/911610 Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Robert Kaplow <rkaplow@chromium.org> Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#538312} [modify] https://crrev.com/31cc41b9e1264fae799bc8c1a4a74522a8d802fc/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/31cc41b9e1264fae799bc8c1a4a74522a8d802fc/tools/metrics/histograms/enums.xml [modify] https://crrev.com/31cc41b9e1264fae799bc8c1a4a74522a8d802fc/tools/metrics/histograms/histograms.xml
,
May 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/05e79827419819e81b88f4c2c11edde6ac16fdbe commit 05e79827419819e81b88f4c2c11edde6ac16fdbe Author: Ella Ge <eirage@chromium.org> Date: Fri May 11 19:59:46 2018 Enable UnifiedTouchAdjustment feature by default Turn blink runtime_enable_feature flags to stable; Removes content_feature flags used for finch trial; Makes related histogram as obselete. intent to ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/l5PCVakcOCE Bug: 805650, 625198 Change-Id: I873a77f98670f5f293b20a1b3a4373ace93027db Reviewed-on: https://chromium-review.googlesource.com/978626 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Robert Kaplow <rkaplow@chromium.org> Reviewed-by: Rick Byers <rbyers@chromium.org> Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org> Commit-Queue: Ella Ge <eirage@chromium.org> Cr-Commit-Position: refs/heads/master@{#557989} [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/content/child/runtime_features.cc [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/content/public/common/content_features.cc [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/content/public/common/content_features.h [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/WebKit/LayoutTests/fast/events/hit-test-counts-expected.txt [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/public/platform/web_runtime_features.h [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/core/input/event_handler.cc [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/core/input/pointer_event_manager.cc [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/core/page/touch_adjustment.cc [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/core/page/touch_adjustment.h [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/platform/exported/web_runtime_features.cc [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/platform/geometry/layout_size.h [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/third_party/blink/renderer/platform/runtime_enabled_features.json5 [modify] https://crrev.com/05e79827419819e81b88f4c2c11edde6ac16fdbe/tools/metrics/histograms/histograms.xml
,
May 12 2018
,
Oct 12
|
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by rbyers@chromium.org
, Jul 1 2016