Womp womp. Can repro on Mac as well. This also happens with just fill-on-account-select enabled.

Taking a look. I suspect we might need to pass the bounds through TransformBoundingBoxToViewportCoordinates() like the normal autofill popup does: https://cs.chromium.org/chromium/src/components/autofill/core/browser/autofill_manager.cc?sq=package:chromium&rcl=1483575682&l=539

There are other popups and bubbles that can go over the viewport (except on Linux). Is the problem here that the dropdown might go off-screen, or is it that we want to keep it inside the viewport so that it's "part" of the page?

Re #4: I think the dropdown shouldn't show up at all if it doesn't overlap the viewport at all (as in the screenshot).

Oh, I see, the bug is specifically about the behaviour after refresh.

It disappears after any action for me, since the relevant field isn't even selected. I agree that it shouldn't show up.

A few things:

- I've double-checked that the warning can also got off the top  (see attached screenshot).
- I don't think TransformBoundingBoxToViewportCoordinates() is the solution. That seems to be to handle coordinate transformations for OOPIF, not clipping/reigning things into the viewport. (Also, I haven't yet found a way to get access to the autofill driver from the password autofill code, but maybe I just haven't looked in the right spot.)
- ChromeAutofillClient::ShowAutofillPopup can use element_bounds and web_contents()->GetContainerBounds() to figure out of the popup would be out of bounds, so I have at least one place for a (hacky) solution.

Deleted: Screen Shot 2017-01-13 at 18.36.19.png 147 KB

	Screen Shot 2017-01-13 at 18.36.19.png 147 KB View Download

Thanks for investigating, Lucas! There's an example of pulling out the AutofillDriver at [1], but sounds like that's not necessary anyway (since TransformBoundingBoxToViewportCoordinates isn't the right thing).

The solution you suggested (checking element_bounds against web_contents()->GetContainerBounds in ChromeAutofillClient) sounds reasonable to me. Adding +mathp in case he has any thoughts.

[1] https://codereview.chromium.org/2617813002/diff/40001/components/password_manager/content/browser/content_password_manager_driver.cc

+rogerm has been looking at this code this week!

Screenshots for https://codereview.chromium.org/2641643002

Deleted: just-inside-viewport-bottom.png 445 KB

	just-inside-viewport-bottom.png 445 KB View Download

Deleted: just-outside-viewport-bottom.png 434 KB

	just-outside-viewport-bottom.png 434 KB View Download

Deleted: just-outside-viewport-top.png 424 KB

	just-outside-viewport-top.png 424 KB View Download

Deleted: just-inside-viewport-top.png 431 KB

	just-inside-viewport-top.png 431 KB View Download

Per https://codereview.chromium.org/2641643002, I've checked what happens when you hide the form:

`visibility: hidden` works like I would expect, just like `opacity: 0` or `opacity: 0.01`: The dropdown appears where the field is, even if the field is not visible.
(Also, autofill works.)

`display: none` was unexpected: the "Login not secure" popup appears at the top left of the viewport. I guess we're getting the default viewport-anchored coordinates for that.
Autofill does *not* work in this case.

estark@ found form_util::IsWebNodeVisible, whose description sounds like it would allow us to detect `display: none`.
I'll try to find out what is preventing autofill in the latter, to see if we can piggyback.

As for `visibility: hidden`, I think general consensus is that it's not easy to prevent autofill for inputs that the developer wants to prevent the user from noticing. I think it's definitely out of scope for this.

[1] https://cs.chromium.org/chromium/src/components/autofill/content/renderer/form_autofill_util.h?q=form_util::IsWebNodeVisible&sq=package:chromium&l=136&dr=Ss

Deleted: visibility-hidden.png 102 KB

	visibility-hidden.png 102 KB View Download

Correction: `display: none;` *does* still autofill.
I made a mistake while testing it initially, but estark@ disproved me. :-)

I think we should either:
1. Hide the popup for the (0, 0) / `display: none;` case.
2. Show the popup at (0, 0) for forms off the screen, too.

1. is a lot less confusing, so I will try that. Sound okay?

Deleted: display-none.png 74.4 KB

	display-none.png 74.4 KB View Download

Just an FYI, I'm discussing with hwi and emilyschechter that there might be quite a few edge cases we haven't thought of with showing the warning on page load before the form field is focused. Maybe we want to rethink that part of the spec.

In the meantime, I think hiding the popup for the display:none case is reasonable.

We decided not to show the warning on page load for Form-Not-Secure due to bugginess. See  issue 685213 . (Note this bug will still apply to Fill-on-Account-Select though.)

I haven't marked the accompanying CL as closed yet.

> (Note this bug will still apply to Fill-on-Account-Select though.)

Do we care about this, or can I just close the CL?

While I have no good estimates on when yet, I would like my team to make Fill-on-Account-Select happen. If you have good ideas for solving this bug in your CL, lgarron@ please share. Is https://codereview.chromium.org/2641643002 the CL you are talking about (because it does look closed).

> Is https://codereview.chromium.org/2641643002 the CL you are talking about (because it does look closed).

Yep. It mainly involved finding out the right way to hide the popup if it is outside the viewport at all. Feel free to copy or reappropriate it.