pdfium: double-click word selection selects Left-to-Right marks at beginning of words |
||||
Issue descriptionChrome Version: 60.0.3112.78 (Official Build) beta (64-bit) OS: Linux What steps will reproduce the problem? (1) Open pdf with Left-to-Right marks[1] in it on some words (like the crash IDs listed in https://drive.google.com/open?id=0B7KQn_T09MTNS3VPWmFiQWNyM28 accessible to @google.com accounts) (2) Double click crash ID in above document (3) paste to crash/<paste> using Ctrl+Shift+V and navigate [1] - https://en.wikipedia.org/wiki/Left-to-right_mark What is the expected result? user would visit crash/<ID> What happens instead? user visits crash/%E2%80%8B<ID>%E2%80%8B The built-in PDF viewer on my linux workstation (Evince Document Viewer) grabs only the ID as expected.
,
Aug 25 2017
w00t! I was sure this would never be fixed because of how small it sounds :) btw, I filed a near identical bug against the Drive web viewer. If there is any code shared between the implementations (I honestly have no idea) maybe a fix could be applied there as well: b/65026976
,
Aug 25 2017
What's being copied is actually a zero width space. (0x200B) When triple clicking in Evince to highlight the entire line, the zero width spaces are copied as well, so the CL below emulates that behavior, instead of stripping them out all together in PDFiumEngine::GetSelectedText(). https://chromium-review.googlesource.com/636709
,
Aug 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7c33a9b2e5e182c9730831d2720f0fab80258ee1 commit 7c33a9b2e5e182c9730831d2720f0fab80258ee1 Author: Lei Zhang <thestig@chromium.org> Date: Tue Aug 29 18:29:27 2017 PDF: Check for zero-width spaces when double clicking to select. BUG= 758754 Change-Id: I515f7d7b48f5818a2463dab95e2e3f3c42fb5e24 Reviewed-on: https://chromium-review.googlesource.com/636709 Reviewed-by: dsinclair <dsinclair@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#498177} [modify] https://crrev.com/7c33a9b2e5e182c9730831d2720f0fab80258ee1/pdf/pdfium/pdfium_engine.cc
,
Aug 29 2017
,
Aug 30 2017
Somehow I was unable to reproduce the issue on the build with and without the fix. Tested this on Windows-10, chrome version: 62.0.3200.0 which contains the CL from C#4. Didn't navigated to crash/id upon following the steps mentioned in C#1. Attached is the screenshot of the same. elijahtaylor@: Could you please check this on the latest canary(62.0.3200.0) and confirm if this works fine now. Thankyou!
,
Aug 30 2017
@ajha: The screenshot you included actually exhibits the bug: the location bar doesn't display the LTR marks so it looks like you navigated to crash/<ID>, but the 404 lists the extra characters encoded before and after the ID: %E2%80%8B So if you're in corp, and can access crash/, the bug is that you'll get a 404 with the bad behavior, but a valid crash report if it's fixed. |
||||
►
Sign in to add a comment |
||||
Comment 1 by thestig@chromium.org
, Aug 25 2017Status: Assigned (was: Untriaged)