This breaks the password save/update doorhanger if javascript:… action is involved. The issue is that > Services.io.newURI("javascript:").hostPort throws NS_ERROR_FAILURE. [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.hostPort]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/LoginHelper.jsm :: doLoginsMatch :: line 229" data: no] doLoginsMatch resource://gre/modules/LoginHelper.jsm:229:11 onFormSubmit resource://gre/modules/LoginManagerParent.jsm:385:16 receiveMessage resource://gre/modules/LoginManagerParent.jsm:89:9 receiveMessage jar:file:///Applications/FirefoxNightly.app/Contents/Resources/browser/omni.ja!/components/nsBrowserGlue.js:254:15 receiveMessage self-hosted:1027:17

Comment on attachment 8979071 [details] Bug 1462959 - Catch exceptions accessing .hostPort for non-http/ftp schemes in LoginHelper.doLoginsMatch. https://reviewboard.mozilla.org/r/245336/#review251860 I suppose this is strictly an improvement, but shouldn't we go the other way around and only consider URLs that can contain a host and a port? What happens if you plug in about:blank or data:text/html,<div>?

Comment on attachment 8979071 [details] Bug 1462959 - Catch exceptions accessing .hostPort for non-http/ftp schemes in LoginHelper.doLoginsMatch. https://reviewboard.mozilla.org/r/245336/#review252150 That seems better to me, thanks!

Pushed by mozilla@noorenberghe.ca: https://hg.mozilla.org/integration/autoland/rev/366a9f1b95f6 Catch exceptions accessing .hostPort for non-http/ftp schemes in LoginHelper.doLoginsMatch. r=johannh