User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Search for text in webpages with masked password component

Actual results:

I can found each letter of apassword by try caracter by caracter

Expected results:

masked passwords should not be highlighted

There's no realistic risk of people leaving their machine unattended for an attacker to snoop at, all with a login page open with the password typed in, and the protonmail page you're using as a test page (like many pages) has a little icon you can click to switch between occluded and plain display of the password, so find in page is not revealing anything the page (or devtools) wouldn't be able to tell you anyway. So not a security bug.

Maybe still a bug? Up to the find-in-page folks...

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cc95daffbdfa661aaaf7bd2eec801d9ea550cc7d&tochange=1299909504c95261d946df29a97e57ec8df4e36e

Maybe if / when we have a native way to allow showing the password we
can lift this if the password is visible or what not. Until then this is
just confusing.

Other than this, there hasn't been any other major regression since we
introduced that switch. I don't think there's a point in keeping it
around.

https://hg.mozilla.org/mozilla-central/rev/785137734d14
https://hg.mozilla.org/mozilla-central/rev/75396f51f724

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9161474 [details]
Bug 1650444 - Explicitly disallow finding in <input type=password>. r=jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: Users can find-in-page password fields.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple fix + test for a recent-ish regression.
• String changes made/needed: none

Comment on attachment 9161474 [details]
Bug 1650444 - Explicitly disallow finding in <input type=password>. r=jfkthame

Approved for 79.0b6.

https://hg.mozilla.org/releases/mozilla-beta/rev/b07c76f8aae8
https://hg.mozilla.org/releases/mozilla-beta/rev/b905c33c0052

Reproduced the initial issue using release version 78.0.1 on Windows 10.
Verified - Fixed in Beta 79.0b6 (build id: 20200709230528) and latest Nightly 80.0a1 (build id: 20200710033027) on Windows 10 and Ubuntu 18.04. The masked password is not highlighted anymore using the "find in page" bar.

Should we take this on ESR78 also?

Comment on attachment 9161474 [details]
Bug 1650444 - Explicitly disallow finding in <input type=password>. r=jfkthame

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Find in page regression from 78.
• User impact if declined: see comment 0
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): pretty simple patch
• String or UUID changes made by this patch: none

Comment on attachment 9161474 [details]
Bug 1650444 - Explicitly disallow finding in <input type=password>. r=jfkthame

Approved for 78.1esr also.

https://hg.mozilla.org/releases/mozilla-esr78/rev/56922d42adad
https://hg.mozilla.org/releases/mozilla-esr78/rev/ea2af90997c0

Verified - Fixed in 78.1.0ESR (build id: 20200716223031) using Windows 10 and Ubuntu 18.04.