Issue metadata
Sign in to add a comment
|
Longpress on a link within a PDF is broken
Reported by
jshan...@etouch.net,
Jun 17 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version: 53.0.2770.0 (Official Build) 318e6f543c58eeeac93b122030041139da7e1e6a-refs/heads/master@{#400326}-32/64 bit OS: Windows 10 (Touch device) URL: http://www.orimi.com/pdf-test.pdf Steps: 1. Launch Chrome and navigate to above URL. 2. Long tap/touch on the link seen on pdf page and observe Actual: Context menu does not open for link via long tap/touch on it. Expected: Context menu should open for link via long tap/touch on it. This is a regression issue broken in M-51, below is bisect info. Good build: 51.0.2701.0 Bad build: 51.0.2702.0 Narrow bisect: https://chromium.googlesource.com/chromium/src/+log/5a73176ca2aabb80616c95d25f01fc3c95cb5d26..54ad52b6a815e0aaca6391f7baac2e1064d4acec?pretty=fuller&n=100 Suspecting: r385360 ? Please help to re-assign if your change is not the cause for this issue. Note: This is touch device specific issue, same works fine via mouse click.
,
Jun 17 2016
Never mind, I think the real explanation is less convoluted, amaralp@ pointed out the culprit is probably the canStartSelection check originally introduced in https://codereview.chromium.org/309553007, causing longpress to be absorbed by the selection code more often and not propagated to the plugin.
,
Jun 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3 commit a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3 Author: aelias <aelias@chromium.org> Date: Wed Jun 22 18:27:41 2016 Make plugin elements return false from canStartSelection. The canStartSelection property of Node is to indicate that text selection can start there, i.e. it's some variety of text or editable. Image and media elements, for example, are excluded. After I switched long-press selection to consider this property in r385360, context menu events stopped being forwarded correctly to plugins because the events were absorbed by text selection instead. The root cause was this incorrectly assigned Node property. For completeness: - I made the long-press layout tests run on all platforms. After r385360, they were no longer Android-specific, and I only just learned of their existence now. BUG= 621063 Review-Url: https://codereview.chromium.org/2078143002 Cr-Commit-Position: refs/heads/master@{#401359} [modify] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/LayoutTests/NeverFixTests [modify] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/LayoutTests/editing/selection/readonly-disabled-text-selection.html [modify] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp [modify] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/Source/core/html/HTMLPlugInElement.h [modify] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/Source/web/tests/WebViewTest.cpp [add] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/Source/web/tests/data/long_press_object.html [add] https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3/third_party/WebKit/Source/web/tests/data/long_press_object_fallback.html
,
Jun 29 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by aelias@chromium.org
, Jun 17 2016Components: -UI>Browser>Options Internals>Plugins>PDF
Summary: Longpress on a link within a PDF is broken (was: Regression: Context menu does not open for link via long tap/touch on it at 'orimi.com')