Internal PDF viewer form filling breaks characters
Reported by
lazartam...@gmail.com,
Feb 20 2017
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Open a PDF file with forms 2. Edit the form with "ő" "ű" characters (or type new text which contains these chars) test pdf: https://drive.google.com/file/d/0B8b7BM62G4pANHU3cjE5blNtaE0/view?usp=sharing What is the expected behavior? Every character should remain still What went wrong? When i edit a form with these characters (ő,ű) the other characters change to something else, this problem is only occuring in chrome, seems like the forms don't use the embedd fonts (in other pdf-s i used dejavu sans, still the same problem occurs) (in the second picture i just removed the last "g" character from the text) Did this work before? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0
,
Feb 21 2017
,
Feb 23 2017
Able to reproduce the issue on Windows 10, Mac 10.12.2 and Ubuntu 14.04 using chrome reported version #56.0.2924.87 and latest canary #58.0.3020.0. Bisect Information: ===================== Good build: 53.0.2759.0 Revision(397936) Bad Build : 53.0.2761.0 Revision(398174) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/8f82c72fbf4be9c5e4bd08999c17bc13d54c8749..11456cf3138b836726da2975e75f44005de2a266 From the above change log suspecting below change Review url: https://codereview.chromium.org/2046623002 ochang@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Feb 23 2017
Dan, Tom, mind taking a look at this? The bisect is to a roll.
,
Feb 24 2017
I also bisected to https://pdfium.googlesource.com/pdfium.git/+log/c324646..f7e108b but it might be a bit of a pain to bisect further. Eyeballing the changelog isn't coming up with anything obvious.
,
Feb 24 2017
Well, rebuilding code from 9 months ago turned out to be not bad. I will bisect further. My repro steps: 1) Focus on the left text field. 2) Type ΦΦ 3) Unfocus 4) Focus again, press home, press Del twice, type ΦΦ again. 5) Unfocus Expected: See ΦΦ Actual: See two vertical lines
,
Feb 24 2017
Bisected to https://codereview.chromium.org/2027273002 - oh shadow variables! :...( I'll see if I can isolate which file in that CL is causing this.
,
Feb 24 2017
Tracked it down to PDF_EncodeText(). Sounds like we need more unit tests.
,
Feb 24 2017
,
Feb 24 2017
The following revision refers to this bug: https://pdfium.googlesource.com/pdfium/+/37e2bd1acf843db4eef891d994390520b8fcf3fa commit 37e2bd1acf843db4eef891d994390520b8fcf3fa Author: Lei Zhang <thestig@chromium.org> Date: Fri Feb 24 18:52:40 2017 Fix a wrong variable usage in PDF_EncodeText(). BUG= chromium:694147 Change-Id: I388cb1d117318edb0339f5c7ee1d2b072f0fb741 Reviewed-on: https://pdfium-review.googlesource.com/2832 Reviewed-by: Tom Sepez <tsepez@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> [modify] https://crrev.com/37e2bd1acf843db4eef891d994390520b8fcf3fa/core/fpdfapi/parser/fpdf_parser_decode.cpp [modify] https://crrev.com/37e2bd1acf843db4eef891d994390520b8fcf3fa/core/fpdfapi/parser/fpdf_parser_decode_unittest.cpp
,
Feb 24 2017
This should be fixed in Chrome Canary 58.x in a day or so. I will try to merge this to Chrome 57 next week.
,
Feb 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/152ea3512884a13e3d61a380b66ebb7616377e0a commit 152ea3512884a13e3d61a380b66ebb7616377e0a Author: pdfium-deps-roller <pdfium-deps-roller@chromium.org> Date: Fri Feb 24 22:02:03 2017 Roll src/third_party/pdfium/ 40e0a8191..37e2bd1ac (1 commit). https://pdfium.googlesource.com/pdfium.git/+log/40e0a819100b..37e2bd1acf84 $ git log 40e0a8191..37e2bd1ac --date=short --no-merges --format='%ad %ae %s' 2017-02-23 thestig Fix a wrong variable usage in PDF_EncodeText(). Created with: roll-dep src/third_party/pdfium BUG= 694147 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, see: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls TBR=dsinclair@chromium.org Review-Url: https://codereview.chromium.org/2708353011 Cr-Commit-Position: refs/heads/master@{#452942} [modify] https://crrev.com/152ea3512884a13e3d61a380b66ebb7616377e0a/DEPS
,
Feb 27 2017
This should be fixed on Canary channel with 58.0.3023.0 or newer.
,
Feb 28 2017
Bug reporter: Can you verify this is fixed on Chrome Canary? I tried on Windows but annoyingly I can't reproduce the issue with Chrome 56. Though I don't know which keyboard layout to use so maybe I typed it wrong.
,
Feb 28 2017
I can confirm this is fixed on Canary, thank you very much. I use hungarian keyboard layout. Is there a chance that this will be in 57? on a side note: i use pdftk to fill the forms and then i open it with iframe. At first these chars not appearing, when i click on the form they reappear, but when unfocus they disappear. If i download the pdf, and reopen (only if i 'pull' the file into chrome) it works perfectly. After that it works until i reboot the computer. I know this is a little specific problem, but is it possible that these problems have some connection?
,
Feb 28 2017
Yes, we will try for a M57 merge. If the problem in the side note occurs on Canary, please file a new bug report for that separately and we'll be happy to take a look.
,
Feb 28 2017
This bug requires manual review: We are only 13 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 28 2017
Tested the issue on windows 7, Mac 10.12.2, Linux Ubuntu 14.04 using chrome version#58.0.3025.5 with the steps mentioned in comment #0.Observed that the other characters are not changing When we edit a form with these characters (ő,ű) . Hence adding TE-Verified labels. Please find the attached screen cast for the same. Thanks!!
,
Feb 28 2017
The fix for this is a 1 line change that only affects the PDF Viewer. The code that shipped in M56 is obviously wrong and we should merge this to M57 to fix it for users ASAP in the next stable channel promotion.
,
Feb 28 2017
Approving merge to M57 branch 2987 based on comment #21. Please merge ASAP. Thank you.
,
Feb 28 2017
,
Feb 28 2017
Could you please merge your changes into M57 branch 2987 latest before 5:00 PM PT today so we can take it in for tomorrow's Beta release. Thank you.
,
Feb 28 2017
The following revision refers to this bug: https://pdfium.googlesource.com/pdfium/+/66935d5be45783f34d94c7a8ac15daa6db411271 commit 66935d5be45783f34d94c7a8ac15daa6db411271 Author: Lei Zhang <thestig@chromium.org> Date: Tue Feb 28 20:49:57 2017 M57: Fix a wrong variable usage in PDF_EncodeText(). BUG= chromium:694147 Change-Id: I388cb1d117318edb0339f5c7ee1d2b072f0fb741 Reviewed-on: https://pdfium-review.googlesource.com/2832 Reviewed-by: Tom Sepez <tsepez@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> (cherry picked from commit 37e2bd1acf843db4eef891d994390520b8fcf3fa) Change-Id: I295812cd4af287d0855a3d4626da49807ade6b50 Reviewed-on: https://pdfium-review.googlesource.com/2886 Reviewed-by: Lei Zhang <thestig@chromium.org> [modify] https://crrev.com/66935d5be45783f34d94c7a8ac15daa6db411271/core/fpdfapi/parser/fpdf_parser_decode.cpp [modify] https://crrev.com/66935d5be45783f34d94c7a8ac15daa6db411271/core/fpdfapi/parser/fpdf_parser_decode_unittest.cpp
,
Feb 28 2017
|
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 Deleted