<div dir="ltr">On Thu, Jan 29, 2015 at 10:53 PM, Matthew N. <span dir="ltr"><<a href="mailto:MattN@mozilla.com" target="_blank">MattN@mozilla.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div 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. I think the left-most context menu is supposed to be the page one while the others are supposed to be for a field e.g. <input> but the existing entries shown are the ones from the document menu, not the ones that are currently shown on a field (e.g. Undo, Cut, Copy, etc.).<br><br></div><div 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?<br></div><div style="font-family:arial,helvetica,sans-serif"><br></div></div></blockquote><div><br></div><div>Ryan and discussed this case a bit in person. If we're auto-filling, then the user is probably invoking the context menu because they’re unhappy with something. If we’re getting a user signal that something isn’t working well, then I argue we go IBM, i.e., “It’s Better Manually”. If our magic didn’t work on page load, it’s not clear it’ll work any better on a second try. IBM in this case means we offer to fill saved usernames in non-password fields and saved passwords in password fields. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div 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. I would guess that it's much less likely that users would expect that entry there compared to the fields. It also doesn't tell us any more information to help the user whereas the field context menu actions also indicate which field(s) we are to act on. I would at least make it a lower priority.<br></div></div></blockquote><div><br></div><div>I agree a context menu isn’t a blocker. Longer term we should acknowledge that different users have different ways of doing things (e.g., menu items vs context menus vs keyboard shortcuts), and we should be at the ready when it makes sense to. I think that right clicking on a password field is one of those cases we should make ourselves available to help users.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"></div><div 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).<span class=""><font color="#888888"><br><br></font></span></div></div></blockquote><div><br></div><div>Yeah, that’s something to think about. In my experience, “fill everywhere” rarely blows up, but it occasionally does.</div><div><br></div><div>-chris</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><span class=""><font color="#888888"></font></span></div><span class=""><font color="#888888"><div style="font-family:arial,helvetica,sans-serif">Matthew<br></div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 3:29 PM, Ryan Feeley <span dir="ltr"><<a href="mailto:rfeeley@mozilla.com" target="_blank">rfeeley@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As an alternative means to accessing saved logins in different contexts, we’re recommending<br>
a set of Contextual Menu Items.<br>
<br>
One page PNG ready for the slings and arrows of criticism:<br>
<a href="https://www.lucidchart.com/publicSegments/view/54cabcd9-b4f8-403c-a432-21fe0a0051da/image.png" target="_blank">https://www.lucidchart.com/publicSegments/view/54cabcd9-b4f8-403c-a432-21fe0a0051da/image.png</a><br>
<br>
Ryan Feeley<br>
UX, Cloud Services<br>
Mozilla UX<br>
IRC: rfeeley<br>
<br>
_______________________________________________<br>
Passwords-dev mailing list<br>
<a href="mailto:Passwords-dev@mozilla.org" target="_blank">Passwords-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/passwords-dev" target="_blank">https://mail.mozilla.org/listinfo/passwords-dev</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Passwords-dev mailing list<br>
<a href="mailto:Passwords-dev@mozilla.org">Passwords-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/passwords-dev" target="_blank">https://mail.mozilla.org/listinfo/passwords-dev</a><br>
<br></blockquote></div><br></div></div>