
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It seems like the proposal is mixing up the page context menu with a field context menu IIUC.</div></div></div></blockquote><div><br class=""></div><div>Well spotted! You’re right. I added the other contexts without changing the content of the menu. Updated now (same link, I love LucidChart).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regarding the 2nd and 4th menu, I was thinking we would want to fill both the username and password field (if we detect both) when right-clicking on a password field too (at least if the username field is empty). What was the thinking around that?</div></div></div></blockquote><div><br class=""></div><div>Great suggestion. I am assuming that if the username field was present, a user would only click directly on a password field because it wasn’t filling properly. But I’ll add it.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">To be honest, I'm not sure the page context menu entry is worth the added screen real-estate without further user research or data since we'll have the doorhanger anchor already.</div></div></div></blockquote><div><br class=""></div><div>When the anchor is appearing, it’s simply an alternative some users may find to be more expedient. Field-specific fill can be very handy in situations where the username is read-only (like when your username is remembered from last time).</div><div><br class=""></div><div>I’m designing for very defensive cases because the web is wild, and our understanding of what’s on the page is often tenuous. The bits of UI will hopefully act as a reliable toolkit for when we’re wrong (even the best password managers are wrong a lot of time).</div><div><br class=""></div><div>Also having at least the one persistent item for Saved Passwords helps the user bring up their credentials for desktop and mobile apps (or when someone calls asking for the Netflix password).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Related: One thing we may run into with the doorhanger for filling that applies to the whole page is the case where there are multiple password forms on the same page. I know of an open source project that had the registration and login forms on the same page so we may not be sure which field should be filled when a fill action is initiated from the doorhanger alone. This is something we can deal with in the heuristics at some point to avoid any UX changes and it may be rare enough to ignore in the UX designs for now (though the context menu entries on the field will provide workarounds).</div></div></div></blockquote><br class=""></div><div>Exactly!</div></body></html>