Environment: Device: LG G4 (Android 5.1); Build: Nightly 50.0a1 (2016-06-12); Steps to reproduce: 1. Go to facebook.com; 2. Sign in with valid credentials. Expected result: A doorhanger asking to remember or not the password is displayed. Actual result: The Password Doorhanger is not displayed. Regression window: Last good build 2016-01-20 First bad build 2016-01-21 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2e50b83954e62d52d2ef294e850c4380d457d96a&tochange=977d78a8dd78afbc0153d37fd9887c3a200dce6a

ahunt or sebastian, if you're running out of Fennec bugs to work on, and you could get to this before liuche is back next week, one of you could take a look at this.

I started digging into this - but on further testing, I'm no longer getting the doorhanger, across today's nightly, nightly from 19th June, and release. I did get the doorhanger the first time I tested (with a non-updated nightly from 20th June), however it's possible that this was with a cached version of facebook.com. This makes me suspect something has changed on facebook, as opposed to a bug on our side - when testing with the version that did show a doorhanger, the page reloaded after submitting bogus credentials, the page now no longer reloads (no progress bar shown) when entering bogus credentials.

Same behaviour (i.e. no prompt) with a clean install of the 20th June nightly. Another issue is that the keyboard enter/next/go button no longer activates the login: the keyboard disappears, but you're still on the login page, and you need to press the blue login button to continue.

Digging into our JS password prompting code, it looks like Facebook has changed the login behavior on mobile, possibly to handle ServiceWorkers. Going through the login, onFormSubmit is no longer called [1], and therefore no doorhanger is shown. (onFormSubmit is still called on other login pages, such as Google accounts login). Looking at the HTML (see attachment), the login button is now just a button, no longer an input type (with the callback to handle logins in code). I added a bunch of breakpoints in places that seem to be relevant where the button id "login" was checked, but none of them were called (but it's possible I just didn't find the right places in the minified code). Fwiw, Chrome still shows the password dialog for Facebook. The next steps for this would probably be to actually find the pathway that is triggered (via breakpoints, etc) and then it should be straightforward to figure out what isn't being triggered. If Facebook is indeed going through a ServiceWorker path, and does not send an onFormSubmit event, we'd need to call our doorhanger-showing code on that pathway too. [1] https://dxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/LoginManagerParent.jsm#289

Maybe MattN can help investigate this, if it's as issue in the toolkit code.

I wonder if bug 1166947 will fix this as that bug is about not requiring a form submit event.

That sounds exactly like this case, though I'll check again when that lands. Thanks for the heads up, Matt!

I just tested this and they are using a <form> so bug 1287202 is the fix.