Thanks for the report!  I can repro on ChromeOS.  James, can you take a look to see if this repros on Canary, and what might be going wrong?

No problem, and thank you very much for the quick reply and looking into this!

Some extra observations:

1. I can repro on 68.0.3410.0 (Official Build) canary (64-bit) with Strict Site Isolation

2. I took the URL of the iframe containing the iframe (*) and
2.a. Tried navigating a new tab's main frame to the iframe's URL - no repro
2.b. Tried navigating a new tab to https://csreis.github.io/tests/cross-site-iframe.html and then calling navFrame(iframeURL) - no repro.

3. I notice that in https://duo.com/about/careers/job/1100333/apply the dropdowns don't work when trying to click them with a mouse, but they also don't work when trying to use the keyboard (hitting the tab key a few times to focus the dropdown element and then pressing the space key to activate the dropdown).  This seems to indicate that this might be something other than a hit-testing issue.

(*) in my case this was: https://boards.greenhouse.io/embed/job_app?for=duosecurity&t=duo.com&token=1100333&b=https%3A%2F%2Fduo.com%2Fabout%2Fcareers%2Fjob%2F1100333%2Fapply

I've also tested on 68.0.3410.0 where I opted out of Site Isolation by setting 1) "Strict site isolation" to "disabled" and 2) "Site isolation trial opt-out" to "Opt-out (not recommended)".  The issue didn't repro with Site Isolation disabled.

In my local repro HTMLSelectElement::ShowPopup() seems to exit early because it sees VisibleBoundsInVisualViewport().IsEmpty()

I've butchered Element::VisibleBoundsInVisualViewport to look as follows:

  IntSize viewport_size = GetDocument().GetPage()->GetVisualViewport().Size();
  IntRect rect(0, 0, viewport_size.Width(), viewport_size.Height());
  // We don't use absoluteBoundingBoxRect() because it can return an IntRect
  // larger the actual size by 1px.  crbug.com/470503 
  auto absolute_bounding_box = RoundedIntRect(GetLayoutObject()->AbsoluteBoundingBoxFloatRect());
  auto viewport_box = GetDocument().View()->ContentsToViewport(absolute_bounding_box);
  LOG(ERROR) << "VisibleBoundsInVisualViewport"
             << "; rect = " << rect.ToString().Utf8().data()
             << "; viewport_size = " << viewport_size.ToString().Utf8().data()
             << "; absolute_bounding_box = " << absolute_bounding_box.ToString().Utf8().data()
             << "; viewport_box = " << viewport_box.ToString().Utf8().data();
  rect.Intersect(viewport_box);
  LOG(ERROR) << "VisibleBoundsInVisualViewport"
             << "; new rect = " << rect.ToString().Utf8().data();
  return rect;

and got back:

    VisibleBoundsInVisualViewport; rect = 0,0 935x1040; viewport_size = 935x1040;
        absolute_bounding_box = 273,1484 309x50; viewport_box = 273,1484 309x50
    VisibleBoundsInVisualViewport; new rect = 0,0 0x0

Updating the status based off of the discussion.

Quick update: this repros on http://csreis.github.io/tests/cross-site-iframe.html, via the following steps.

1. In the main frame, execute
navFrame("https://boards.greenhouse.io/embed/job_app?for=duosecurity&t=duo.com&token=1100333&b=https%3A%2F%2Fduo.com%2Fabout%2Fcareers%2Fjob%2F1100333%2Fapply")

2. Inspect the iframe element in DevTools and modify the height attribute to 4000.

I tried this because I noticed that the iframe height on https://duo.com/about/careers/job/1100333/apply is also large - maybe it's resized to fit the content after the frame loads?  Perhaps if the <select> isn't visible prior to the resize, something doesn't make it visible after the resize?

Also worth noting that this still repros on today's canary (68.0.3410.0), so Ken's r554097 didn't help.

Thanks!  Glad we're narrowing this down.  Adding Paint and Layout components, since it seems like the <select> just isn't visible in this "resize large OOPIF" case.

James and I noticed that the <select>s are still semi-functional-- you can click on them to give them focus, and then the arrow keys will let you select values.  That means it's primarily just an issue that they aren't painting.

Sounds like James and/or Ken might be able to look more deeply at this on Monday.

For context, there's only a small trial of Site Isolation in Chrome 66, so most users are unaffected.  We don't have a great workaround yet, but so far the short-term options seem to include:
* Disable Site Isolation trials via chrome://flags/#site-isolation-trial-opt-out
* Click to give focus, then use the keyboard to select a value.
* Change the page to use a smaller iframe in the main frame?

Marking this as a launch blocker, and we'll try to get the fix into at least M67 and higher.

Adding M67 "ReleaseBlock-Stable" for tracking.

I dug a bit more, and I think this is a coordinate transformation issue in this function:

IntRect LocalFrameView::ConvertToRootFrame(const IntRect& local_rect) const {
  if (LocalFrameView* parent = ParentFrameView()) {
    IntRect parent_rect = ConvertToContainingEmbeddedContentView(local_rect);
    return parent->ConvertToRootFrame(parent_rect);
  }
  return local_rect;
}

Without --site-per-process, the parent FrameView is local, and we convert a rect like "23,1717 439x51" to "33,370 439x51" (note the smaller the height) in the repro.

With --site-per-process, ParentFrameView() is a RemoteFrameView, so this is skipped and we leave "23,1717 439x51" as-is.  Later, when it's intersected with the visual viewport size (0,0 935x1040), we think the intersection is empty.

For reference, here's how we get to this function:
#1 0x7fde7f637935 blink::LocalFrameView::ConvertToRootFrame()
#2 0x7fde7f63cecb blink::LocalFrameView::ContentsToViewport()
#3 0x7fde7f333ddb blink::Element::VisibleBoundsInVisualViewport()
#4 0x7fde7f750aa7 blink::InternalPopupMenu::WriteDocument()
#5 0x7fde7f55aa06 blink::WebPagePopupImpl::InitializePage()
#6 0x7fde7f55a3a8 blink::WebPagePopupImpl::Initialize()
#7 0x7fde7f577c6c blink::WebViewImpl::OpenPagePopup()
#8 0x7fde7f752f26 blink::InternalPopupMenu::Show()
#9 0x7fde7f74233f blink::HTMLSelectElement::ShowPopup()
#10 0x7fde7f742af0 blink::HTMLSelectElement::MenuListDefaultEventHandler()
#11 0x7fde7f743bfd blink::HTMLSelectElement::DefaultEventHandler()
#12 0x7fde7f35afaa blink::EventDispatcher::DispatchEventPostProcess()
#13 0x7fde7f35a73a blink::EventDispatcher::Dispatch()
#14 0x7fde7f51e18e blink::MouseEvent::DispatchEvent()
#15 0x7fde7f3597b3 blink::EventDispatcher::DispatchEvent()
#16 0x7fde7f853024 blink::MouseEventManager::DispatchMouseEvent()
#17 0x7fde7f859839 blink::PointerEventManager::SendMousePointerEvent()
#18 0x7fde7f8468c5 blink::EventHandler::HandleMousePressEvent()

I think changing the height attribute in #8 doesn't really matter; what seems to be important is that the (replicated) Page's visual viewport size is less than the OOPIF's size, and the <select> in the OOPIF is at a position beyond the visual viewport size. Here's a simpler repro with my own test page:

1. Go to http://csreis.github.io/tests/cross-site-iframe.html
2. From main frame: navFrame("https://alexmos17.github.io/tests/select.html")
3. Resize the browser window so its height is smaller than iframe's height (300).
4. Scroll main frame and iframe to the bottom <select> for colors in the iframe and click on it.  It doesn't work.

I don't really know how to fix this, and whether we have enough information on RemoteFrameView already to do this.  Ken or James are probably best folks to continue looking at this.

alexmos@'s observations in C#12 seem to have correctly identified the issue: when the ParentFrameView is remote, we just totally drop the ball on doing to rect conversion.

Another demonstration about the irrelevance of the height attribute is to load one of the sample pages from C#0 just change the page's scale factor to about 50%, then the drop-down selectors work (although as you go further down the page you may eventually hit drop-downs that fail).

It seems that information, perhaps in the form of a transform matrix, needs to flow down from the remote parent frame view (via the browser process) to the RemoteFrameView, and then we could implement the equivalent version of ConvertToRootFrame.

Thanks for all the investigative work while I was OOO. I have a couple of ideas on how to fix this.

I have a CL up for review, but I don't know for certain this is the best way to address the problem. https://chromium-review.googlesource.com/c/chromium/src/+/1036232

*** Bulk Edit ***
M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

Comment 16: Thanks Ken!  Does it look like the fix might be landable before the weekend?  It would be great to let it bake over the weekend and request merge on Monday if possible, before the next M67 beta build is cut.

It should be possible. Blink reviewers are pretty overloaded these days, but I just sent a ping to try to get things moving along.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/af20a60ef63b8a650700c321e763bd1bfd4557af

commit af20a60ef63b8a650700c321e763bd1bfd4557af
Author: Ken Buchanan <kenrb@chromium.org>
Date: Sun May 06 17:20:30 2018

Allow select popups to check viewport position within OOPIFs

Select menu dropdowns use LocalFrameView::ContentsToViewport to
determine what part of the menu intersects with the window viewport.
This doesn't work in OOPIFs because LFV::ContentsToRootFrame only
converts coordinates into the local frame root's coordinates, not the
main frame. The consequence is that menus in large iframes that have
been scrolled into view will falsely report to be out of view.

This patch changes the intersection calculation to use
LayoutView::MapToVisualRectInAncestorSpace(), which determines the
viewport intersection while accounting for OOPIF containers.

Bug:  837639 
Change-Id: If265e24ad4cbee967fdb97ae85002a81e75033a7
Reviewed-on: https://chromium-review.googlesource.com/1036232
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556355}
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/content/test/content_browser_test_utils_internal.cc
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/content/test/content_browser_test_utils_internal.h
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/third_party/blink/renderer/core/dom/element.cc
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/third_party/blink/renderer/core/dom/element.h
[modify] https://crrev.com/af20a60ef63b8a650700c321e763bd1bfd4557af/third_party/blink/renderer/core/frame/visual_viewport_test.cc

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

Seems to be fixed by r556355, as tested on the 68.0.3423.0 Windows Canary.  Thanks Ken!

I'll close this.  Ken, can you double check there's no crashes or bugs as a result and request merge to M67 today if it looks good?  The cut is 4 pm Pacific.

(I'll note that today's Canary does show one major regression in font anti-aliasing in  issue 840392 , but I would guess that's pretty unrelated to this CL.)

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-67 label, otherwise remove Merge-TBD label. Thanks.

So far I haven't seen any regressions. This is fairly low risk, the existing non-OOPIF behavior has good test coverage, and where OOPIFs are concerned it should be strictly an improvement.

I've been keeping an eye out for any crashes that might be attributable to this but so far haven't seen anything.

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge for r556355, to M67 branch 3396 based on comment #24. Thank you.

Ken and I are happy with the current state (no crashers or other regressions seem to be due to this), so we'll proceed with the merge.  I've compiled and tested the merge locally on my M67 checkout and verifies that it fixes the bug.

Ok, sounds good. Thanks to you and Ken!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1

commit 12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1
Author: Charlie Reis <creis@chromium.org>
Date: Tue May 08 00:01:07 2018

Merge to M67: Allow select popups to check viewport position within OOPIFs

Select menu dropdowns use LocalFrameView::ContentsToViewport to
determine what part of the menu intersects with the window viewport.
This doesn't work in OOPIFs because LFV::ContentsToRootFrame only
converts coordinates into the local frame root's coordinates, not the
main frame. The consequence is that menus in large iframes that have
been scrolled into view will falsely report to be out of view.

This patch changes the intersection calculation to use
LayoutView::MapToVisualRectInAncestorSpace(), which determines the
viewport intersection while accounting for OOPIF containers.

Bug:  837639 
Change-Id: If265e24ad4cbee967fdb97ae85002a81e75033a7
Reviewed-on: https://chromium-review.googlesource.com/1036232
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#556355}
Reviewed-on: https://chromium-review.googlesource.com/1048869
Cr-Commit-Position: refs/branch-heads/3396@{#509}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/content/test/content_browser_test_utils_internal.cc
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/content/test/content_browser_test_utils_internal.h
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/third_party/blink/renderer/core/dom/element.cc
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/third_party/blink/renderer/core/dom/element.h
[modify] https://crrev.com/12b3fc2b7edd66bb9c6c17ed1f8678acb6d98ad1/third_party/blink/renderer/core/frame/visual_viewport_test.cc

The NextAction date has arrived: 2018-05-08

 Issue 846349  has been merged into this issue.