Mac: PDF password input is not focusable inside OOPIF
Reported by
ch...@lendeavor.com,
Jul 16
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: 1. Create an iframe that is 538x800 2. Point the iframe src to a pdf that is password protected 3. The password input can't be clicked on to focus until the browser is resized. What is the expected behavior? What went wrong? I am consistently unable to click and focus into the password input for a password-protected pdf that is embedded into an iframe of a specific size. Resizing the window seems to fix the issue, but as seen in the attached screenshot, it doesn't look like the password field should be prevented from being focused via click. Did this work before? Yes Chrome version: 67.0.3396.99 Channel: stable OS Version: OS X 10.13.5 Flash Version:
,
Jul 17
,
Jul 17
Thanks for filing the issue! Tried checking the issue on reported chrome version 67.0.3396.99 using Mac 10.13.1 with the below mentioned steps. 1. Launched Chrome 2. Opened a password protected PDF document Observed the PDF password input field is focusable without having to resize it. @Reporter: As per the steps(1 & 2) mentioned in comment#0, Could you please share a sample test file with the pre-conditions mentioned, which helps us to triage the issue further in a better way.
,
Jul 20
Thanks for the report! I believe this might be a site isolation issue. I can repro the problem with --site-per-process, but not without it. My repro steps, tried on Mac canary 69.0.3497.0: 1. Go to http://csreis.github.io/tests/cross-site-iframe.html 2. Open devtools and execute navFrame("http://alexmos17.github.io/tests/pdf-with-password.pdf") I can't focus on the password input, but if I resize the window I can. chris@lendeavor.com: can you please check if going to chrome://flags/#site-isolation-trial-opt-out and setting it to "Opt out" fixes this issue for you? (It does for me.) Ehsan, would you be able to triage this further?
,
Jul 20
,
Jul 20
Thanks Alex, I can confirm, changing the flag you linked to "Opt out" fixes the issue for me as well.
,
Jul 23
Sounds like this is a Mac-specific focus issue for out-of-process iframes (OOPIFs), somehow involving PDFs. That could be BrowserPlugin related. Adding wjmaclean@ for input and BrowserPlugin, and avi@ for Mac. Ehsan or James, would you be able to help take a closer look or help find an owner? I'm hoping we can get a fix merged to M69. (Probably too late for M68, which goes to the stable channel tomorrow.)
,
Jul 23
I will investigate a bit more for the right owner. So far I realized that changing any style (that affects the OOPIF side) such as transforms or size or page visibility seem to fix the bug. I also noticed selecting the text makes it work but selecting the text on a debug build leads to a DCHECK. I am wondering if the bug is due to FocusController::SetActive not being called for the extension page.
,
Jul 23
also +avallee who's worked on OOPIF webview focus.
,
Jul 23
We fixed a PDF password focus bug a year or two ago ... there's a PDF extension test for it (that test will help in identifying the CL). It may or may not be relevant to this bug, but possibly worth looking at to see how that issue was resolved. But ultimately I'm assuming this is a focus issue based on the interaction of BrowserPlugin and an OOPIF, as suggested earlier.
,
Jul 24
I can see this happening on Windows 10 as well. Further debugging reveals that BrowserPluginGuest::SetFocused does not get called for a focused == true value. This bug does not seem to repro on Linux. I have not tried ChromeOS.
,
Jul 24
That's interesting. I wasn't able to repro on Windows yesterday using the steps in comment 4. What version were you testing on, and did you use those repro steps?
,
Jul 24
Charlie: I can repro this on both Windows and Mac Chrome 67. 0- Disable site isolation and opt-out as well. 1- Navigate to data:text/html <iframe src="pdf_file_with_password"></iframe> 2- Click inside <input> and see no focus. 3- Click on the word "Password" and then inside <input>. This time the <input> is focused. I am still unclear on what is causing this bug but there could be more than one reason and perhaps easier to reproduce with --site-isolation. I cant repro using the same steps on 69. Currently I am investigating page focus and the MaybeSendSyntheticTapGesture which is called when a mouse event (click) is routed to RWHVG. I also attached the repro on Mac.
,
Jul 25
Adding some updates here. First off, when "www.a.com" adds an <iframe sec="www.X.com/pdf.pdf"> the <iframe> will end up having a PluginDocument. A plugin document is <html><body><embed src="pdf-url"></body></html>. When |X == 'a'| the <iframe> is same-process and of course cross-origin when otherwise. The PdfExtension draws the password form. The PDF extension is inside a main-frame of a nested WebContents whose RWHV is a RenderWidgetHostViewGuest. When we click inside the form: 1- The click is directly routed to RWHVG. 2- Before sending the click we call MaybeSendSyntheticGestureTap() - this is intended to focus the plugin inside the <frame> (BrowserPlugin). For some reason I can't yet explain, the hittesting goes wrong inside the OOPIF. Instead of eventually selecting <embed id="plugin"> which is the BrowserPlugin, we return the document (HTML). I think this is the root cause behind the bug. If plugin does not get focused then BrowserPluginGuest won't get focused and I double any text input should work without it.
,
Jul 25
Comment 13: Interesting-- I can indeed repro it on Windows using data:text/html,<iframe src="http://alexmos17.github.io/tests/pdf-with-password.pdf"></iframe> on 67.0.3396.99 and 68.0.3440.68, but not on 69.0.3493.3 or 70.0.3501.2. Actually, it doesn't seem to repro on Mac Canary 70.0.3502.0 either. Did something resolve the bug recently, or am I doing something wrong?
,
Jul 25
Charlie, I can reproduce on newest Mac canary using the data URL you provided (70.0.3502.0). But it reproduces randomly. Also, when it repros, clicking on the text and then the <input> fixes the issue.
,
Jul 25
Re C#14, when we switched to having touch events directly targeting the guest, which is similar to what I think you're describing, we added special logic in (I think) RenderWidgetHostViewGuest to force the embedder to receive focus as well ... I wonder if something like that is needed here? I'll try and look up where that logic lives.
,
Jul 25
ekaramad@ - Since you can repro this on Windows, does it repro with touch (as opposed to mouse-click)?
,
Jul 26
wjmaclean@: I tried this on Chrome 67 Windows. As mentioned before it reproduces flaky-ly and the same behavior seems to be true for touch. Sometimes I have to tap several times until the <input> is focused. I still suspect hit testing in blink to be a problem. Maybe BrowserPlugin's LayoutObject is of size 0 or something (comment #14).
,
Jul 27
I was wondering about a possible layout issue when the resize was mentioned above. We should loop in someone on the Blink layout team for that!
,
Aug 9
Assigning to wjmaclean@ for further investigation. Thanks!
,
Aug 9
Talking with James offline it appears that since MimeHandlerViewGuest is the only guest that currently *can* be embedded inside an OOPIF getting the right owner RenderFrame/WidgetHost could be a potential source of error for input-related bugs. For MHVG for instance, the OwnerRWH is the OOPIF's RWH: https://cs.chromium.org/chromium/src/extensions/browser/guest_view/mime_handler_view/mime_handler_view_guest.cc?dr&g=0&l=108
,
Sep 26
What is the current status of this issue?
,
Oct 2
Still bad in 69.0.3497.100
,
Oct 4
In 70.0.3538.45 is this problem too.
,
Jan 4
So ekaramad@'s previous assessment seems to still hold: The problem is that EventHandler::HitTestResultForGestureEvent() seems to fail when it's invoked at: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/input/event_handler.cc?rcl=cc70104cf3c6427394f4c4f31b367e7a794b7410&l=1738 In the PDF's login "dialog", clicking on any text in the dialog will return a hit-test InnerNode of EMBED, which correctly routes the GestureTap to the BrowserPlugin, which in turns focuses it. But if you click anywhere else in the dialog, the InnerNode() from hit-testing is HTML, and the GestureTap does not get routed to the BrowserPlugin. Re-assigning to eirage@ for further triage regarding the hit testing. Simplified repro instructions for Linux (and probably Windows): 1) Go to http://csreis.github.io/tests/cross-site-iframe.html 2) Open devtools for the main-frame, and in the console run navFrame("http://alexmos17.github.io/tests/pdf-with-password.pdf") 3) Left-click with the mouse in the grey box for the password. Note: I *don't* think this is related to the input field being a custom element, since replacing it with a simple <input> field yields the same behaviour.
,
Jan 7
One quick follow-on comment: on the off-chance that the targeting issue was due to a badly-formed GestureTapDown coming from RenderWidgetHostViewGuest, I tried this on a touch-screen so that it would be a real (i.e. system-generated) GestureTapDown, and it seems to have the same targeting problem.
,
Jan 7
I took a quick look and it seems the GestureTapDown coordinates are incorrect. Click on the text fixed the problem may just because the text are upper and it's incorrect coordinates still failed in the range of the embedded.
,
Jan 7
s/failed/fell
,
Jan 7
I'm not sure why we have the offset here[1], but removing it seems fix the issue. [1] https://cs.chromium.org/chromium/src/content/browser/frame_host/render_widget_host_view_guest.cc?sq=package:chromium&g=0&l=610 route back to wjmaclean@ as this seems a RenderWidgetHostViewGuest problem.
,
Jan 7
,
Jan 7
Thanks eirage@ ... I guess I must have thought that clicking on the text was somehow picking up on the text itself, and I didn't notice the difference in height between the text and the box about matched the offset.
,
Jan 16
(6 days ago)
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dc15ae989c1056e9a44ad6a44dc65d466d8d291b commit dc15ae989c1056e9a44ad6a44dc65d466d8d291b Author: W. James MacLean <wjmaclean@chromium.org> Date: Wed Jan 16 20:58:48 2019 Correct transformation of SyntheticTap for RenderWidgetHostViewGuest. RWHVG uses a synthetic GestureTap sent to the guest's embedder (owner) in order to make sure the BrowserPlugin in the owner is properly focused. Prior to this CL, the gesture location was converted using an offset-only technique that referenced the top-level root view, which is incorrect for guests embedded in iframes. This CL performs a more principled conversion, with only reference to the owner view. Bug: 863943 Change-Id: I72c93c6bec2fe8cca3e1932c98e870333eb5a4c6 Reviewed-on: https://chromium-review.googlesource.com/c/1400949 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Commit-Queue: James MacLean <wjmaclean@chromium.org> Cr-Commit-Position: refs/heads/master@{#623352} [modify] https://crrev.com/dc15ae989c1056e9a44ad6a44dc65d466d8d291b/chrome/browser/pdf/pdf_extension_test.cc [add] https://crrev.com/dc15ae989c1056e9a44ad6a44dc65d466d8d291b/chrome/test/data/pdf/test-offset-cross-site-iframe.html [modify] https://crrev.com/dc15ae989c1056e9a44ad6a44dc65d466d8d291b/content/browser/frame_host/render_widget_host_view_guest.cc [modify] https://crrev.com/dc15ae989c1056e9a44ad6a44dc65d466d8d291b/content/browser/frame_host/render_widget_host_view_guest.h
,
Jan 16
(6 days ago)
This should be fixed now in tip-of-tree ... please re-open if needed. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by vamshi.kommuri@chromium.org
, Jul 17