Issue metadata
Sign in to add a comment
|
Select dropdowns do not work within an iframe within extensions
Reported by
lukestan...@gmail.com,
May 26 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Clone this repo: https://github.com/LukeStanbery89/iframe-extension 2. Load it up in Chrome as an extension in developer mode. 3. Try to use the select dropdown. What is the expected behavior? The select should dropdown to expose the possible selection values. What went wrong? The select fails to dropdown. You can still click on it to give it focus and use the alphanumeric keys to make a selection, but you cannot make a selection using only the cursor. Did this work before? N/A Chrome version: 58.0.3029.110 Channel: stable OS Version: OS X 10.12.5 Flash Version:
,
May 30 2017
,
May 31 2017
Tested on Windows and Linux as well. Same problem occurs.
,
May 31 2017
Tested the issue on mac os 10.12.5 using chrome M58 #58.0.3029.110 and followed below steps : 1. Loaded the given zip extension in chrome 2. Clicked on the extension icon and found a popup with dropdown volvo and tried to clicked on t and no dropdown opened. Attached screencast for reference. @lukestanbery89-- Could you please check attached screencast and confirm us if we had missed any steps in reproducing the issue or please provide us a video explaining the issue , that would help us in triaging the issue better. Thanks!
,
May 31 2017
@hdodda No missed steps. You replicated the issue perfectly. As you can see, the dropdown does not open. Thanks.
,
May 31 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2017
Tested the issue on windows 7 , mac os 10.12.4 a using chrome M58 #58.0.3029.110 and M60 #60.0.3117.0 and issue is reproduced. This is a regression issue broken in M55. Using the per-revision bisect providing the bisect results, Good build: 54.0.2840.0 (Revision: 414607). Bad build: 55.0.2842.0 (Revision: 414942). You are probably looking for a change made after 414878 (known good), but no later than 414879 (first known bad). CHANGELOG URL: The script might not always return single CL as suspectas some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/5d6411a1a10652b1a3d9ced8d744f7e427918805..d8f0aefde00132b06bd97cb17555f2ec89a0c203 From the CL above, assigning the issue to the concern owner @nasko- 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. Review-Url: https://codereview.chromium.org/2285883002 Thanks!
,
Jun 1 2017
#c8, it definitely can be the change you pointed, but it merely enables isolation of extensions, so not the root cause. kenrb@, can you take a stab at investigating this one?
,
Jun 1 2017
Looking.
,
Jun 1 2017
I have a tentative patch uploaded for review.
,
Jun 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e4f9108cb1e95e813387cf0b7eca98992530fdb1 commit e4f9108cb1e95e813387cf0b7eca98992530fdb1 Author: kenrb <kenrb@chromium.org> Date: Fri Jun 02 20:32:08 2017 Propagate auto-resize viewport values to OOPIF processes RenderWidgetHostViewChildFrame currently gets its visible viewport size from the top-level RenderWidgetHostView, which typically comes from the platform window. However, when the top-level frame has auto-resize enabled, internally it sets its own visible viewport, and this information not available to OOPIF children. This causes issues in particular for extension popups which have window sizes of (0, 0) and rely on auto-resize to modify the viewport in Blink. This patch causes the WebContents to store the auto-resize value reported by the top-level frame and make it available to OOPIF RenderWidgetHostViews. They, in turn, allow an auto-resize size to override the windows size when determining their visible viewport. BUG= 726743 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2914013004 Cr-Commit-Position: refs/heads/master@{#476772} [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/frame_host/render_widget_host_view_child_frame_browsertest.cc [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/renderer_host/render_view_host_impl.cc [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/renderer_host/render_widget_host_delegate.cc [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/renderer_host/render_widget_host_delegate.h [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/web_contents/web_contents_impl.cc [modify] https://crrev.com/e4f9108cb1e95e813387cf0b7eca98992530fdb1/content/browser/web_contents/web_contents_impl.h
,
Jun 5 2017
,
Jun 6 2017
,
Jun 6 2017
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 6 2017
Thanks for the fix. Please confirm whether the fix is verified in canary. If yes, merge to 3112 branch ASAP.
,
Jun 6 2017
I can no longer reproduce the issue on Windows Canary, will merge shortly.
,
Jun 6 2017
Tested it myself in Canary v61.0.3122.0 for Mac and can confirm that the issue is resolved. Eagerly awaiting the stable release. Thanks, folks!
,
Jun 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/aac33a6085f198ec79b3ea1c293392a3c0d2098f commit aac33a6085f198ec79b3ea1c293392a3c0d2098f Author: Ken Buchanan <kenrb@chromium.org> Date: Tue Jun 06 20:10:38 2017 Propagate auto-resize viewport values to OOPIF processes RenderWidgetHostViewChildFrame currently gets its visible viewport size from the top-level RenderWidgetHostView, which typically comes from the platform window. However, when the top-level frame has auto-resize enabled, internally it sets its own visible viewport, and this information not available to OOPIF children. This causes issues in particular for extension popups which have window sizes of (0, 0) and rely on auto-resize to modify the viewport in Blink. This patch causes the WebContents to store the auto-resize value reported by the top-level frame and make it available to OOPIF RenderWidgetHostViews. They, in turn, allow an auto-resize size to override the windows size when determining their visible viewport. BUG= 726743 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2914013004 Cr-Original-Commit-Position: refs/heads/master@{#476772} Review-Url: https://codereview.chromium.org/2928643003 . Cr-Commit-Position: refs/branch-heads/3112@{#202} Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897} [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/frame_host/render_widget_host_view_child_frame_browsertest.cc [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/renderer_host/render_view_host_impl.cc [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/renderer_host/render_widget_host_delegate.cc [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/renderer_host/render_widget_host_delegate.h [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/web_contents/web_contents_impl.cc [modify] https://crrev.com/aac33a6085f198ec79b3ea1c293392a3c0d2098f/content/browser/web_contents/web_contents_impl.h
,
Jun 8 2017
Verified the issue on windows 10, Mac 10.12.4 and Ubuntu 14.04 using chrome beta version #60.0.3112.24 as per comment #0 Observed that select dropdown worked to expose the possible selection values. Hence, the fix is working as expected. Attaching screen cast for reference. Hence, adding the verified labels. Thanks...!! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by lgrey@chromium.org
, May 26 2017