New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 647457 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Cannot give keyboard input focus back to PDF in <webview> when site-per-process is on.

Project Member Reported by ekaramad@chromium.org, Sep 15 2016

Issue description

Version: 55.0.2861.0 (Official Build) canary (64-bit)
OS: All

What steps will reproduce the problem?
(1) Run chrome and enable the site-per-process flag from chrome://flags.
(2) Open the sample browser app which uses <webview> (link to download: https://chrome.google.com/webstore/detail/browser-sample/edggnmnajhcbhlnpjnogkjpghaikidaa)
(2)* alternatively, inside a chrome app, add <webview>.
(3) Navigate to a PDF form which has input fields.
(4) Focus an input field inside PDF and type "foo".
(5) Focus address bar and type "bar".
(6) Focus the input inside PDF and type "baz".

What is the expected output?
Input field inside PDF should have "foobaz" and address bar should not contain "baz" (assuming the the URL did not contain baz to begin with).

What do you see instead?
PDF input field has only "foo" and browser has "barbaz".

See the attached movie. I could repro this on (Linux|Win)64 as well.
 
pdf_bug.mov
6.8 MB Download
Not quite sure if this is somehow a duplicate of issue 614463; or some other OPPIF-webview-focus bug. If so, since this involves PDF, shouldn't we raise its priority?
I've just tried this on Mac canary 55.0.2880.4, as well as a recently synced Linux ToT build, with --site-per-process, and I couldn't repro this.  ekaramad@: can you see if you can still repro on the latest canary on your end?  Maybe something recent fixed this?

One weirdness that I did notice, both with and without --site-per-process, is that after step (5) there are two blinking carets, one in the <webview> and one in the address bar in the embedder.  That doesn't seem right.  avallee@, do you know if this is caused by page focus issues you've been investigating?
This is narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/64ee320eb5f9adb0281de97c0d4a17317327ad10..4a35aa63801770012471d58b6d400bfd635c83f1

I think kenrb@'s patch fixed it; specifically given that we use mouse focus in repro. I think in almost all versions I tested the double caret issue was present.

Should we mark this as fixed then?

Comment 4 by creis@chromium.org, Oct 7 2016

Owner: kenrb@chromium.org
Status: Fixed (was: Available)
Thanks for the bisect.  Sounds like it's resolved, so I'll close it.

Sign in to add a comment