New issue
Advanced search Search tips

Issue 782731 link

Starred by 1 user
Status: WontFix
Owner:
bokan@chromium.org
Closed: Nov 2017
Cc:
flackr@chromium.org
xidac...@chromium.org
dtapu...@chromium.org
mustaq@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Can CC have a concept of WebInputEvent::FrameScale

Project Member Reported by xidac...@chromium.org, Nov 8 2017 
When CC tries to compute a white-listed touch action in InputHandlerProxy::HitTestTouchEvent, it uses touch_event.touches[i].PositionInWidget(). This coordinate has no transform considered. Instead it should use touch_event.TouchPointInRootFrame. However, that function requires frame_scale_ which seems to be set purely from Blink side. Is there a way to let CC know the frame_scale for a particular WebTouchEvent?

Comment 1 by mustaq@chromium.org, Nov 8 2017 

For the touch-action hit-test case xidachen@ and I discussed today, it seems that Blink correctly gets the page scales through WebInputEventConversion from this FrameView method:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrameView.cpp?rcl=6c6888565ff1fde9ef21ef17c27ad4c8304643d2&l=2703

I now see that this scale factor comes to Blink through WebViewImpl from RenderWidget::ApplyViewportDeltas().
https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?rcl=55dad31360f0a651c34f8cf6d3c2f1575c75da4a&l=930
There could be other ways to set the factor in Blink.

So an alternate question is: is it possible to cache this value in cc without affecting other possible setters in Blink (if any)?

Comment 2 by mustaq@chromium.org, Nov 8 2017

Components: Blink>Input

Comment 3 by xidac...@chromium.org, Nov 8 2017 

Actually, I looked a bit further, and it appears that LayerTreeImpl has a page_scale_factor_ that does match the frame_scale_ from Blink. The problem is that when there is a page zoom, CC won't know...

Comment 4 by xidac...@chromium.org, Nov 9 2017

Status: WontFix (was: Assigned)
Apologies, it looks like LayerTreeImpl::FindLayerThatIsHitByPointInTouchHandlerRegion does calculate things correctly, so this would be a won't fix.
►

Sign in to add a comment