Add an "input field type" entry to WebContextMenuData.

Source/web/ContextMenuClientImpl.cpp

 /*
  * Copyright (C) 2009, 2012 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 377 matching lines @@
         HTMLAnchorElement* anchor = toHTMLAnchorElement(r.URLElement());
 
         // Extract suggested filename for saving file.
         data.suggestedFilename = anchor->fastGetAttribute(HTMLNames::downloadAttr);
 
         // If the anchor wants to suppress the referrer, update the referrerPolicy accordingly.
         if (anchor->hasRel(RelationNoReferrer))
             data.referrerPolicy = WebReferrerPolicyNever;
     }
 
+    // Find the input field type.
+    if (isHTMLInputElement(r.innerNode())) {
+        HTMLInputElement* element = toHTMLInputElement(r.innerNode());
+        if (element->type() == InputTypeNames::password)

[Mike West, 2015/05/19 12:58:35]

Should we also take the `autocomplete` attribute into consideration here? If so,
we could pick up "username", for instance.

[msramek, 2015/05/19 15:42:44]

I thought about it a bit, and I would say that not just yet. I'll keep it in
mind for future iterations :)

We could define InputFieldTypeUsername and show some special context menu item
on fields with autocomplete="username". However, then we'll also want the same
behavior for forms that do not use autocomplete. We could say that if no field
in the form has autocomplete="username", then all of them will be treated as
InputFieldTypeUsername.

This might be useful, but it seems like inconsistently rewriting the password
manager heuristics in blink, and I would avoid it until we have clear idea what
exactly we want to offer for the username field. The current design expects no
action on the username field; the username value will be found using the usual
heuristics.

About autocomplete="current-password" and "new-password", I had a quick chat
with Václav and we arrived to the conclusion that we don't want to discriminate;
the user using the force-save feature knows what they're doing, and they should
decide which password field is correct themselves.

+            data.inputFieldType = WebContextMenuData::InputFieldTypePassword;
+        else if (element->isTextField())
+            data.inputFieldType = WebContextMenuData::InputFieldTypePlainText;
+        else
+            data.inputFieldType = WebContextMenuData::InputFieldTypeOther;
+    } else {
+        data.inputFieldType = WebContextMenuData::InputFieldTypeNone;
+    }
+
     data.node = r.innerNodeOrImageMapImage();
 
     WebLocalFrameImpl* selectedWebFrame = WebLocalFrameImpl::fromFrame(selectedFrame);
     if (selectedWebFrame->client())
         selectedWebFrame->client()->showContextMenu(data);
 }
 
 void ContextMenuClientImpl::clearContextMenu()
 {
     HitTestResult r = m_webView->page()->contextMenuController().hitTestResult();
@@ skipping 43 matching lines @@
         outputItems[i] = subItems[i];
     subMenuItems.swap(outputItems);
 }
 
 void ContextMenuClientImpl::populateCustomMenuItems(const ContextMenu* defaultMenu, WebContextMenuData* data)
 {
     populateSubMenuItems(defaultMenu->items(), data->customItems);
 }
 
 } // namespace blink