1506637 - Incorrect OS passwords can cause the browser to crash

Status: RESOLVED WORKSFORME

(Core :: DOM: Web Payments, defect, P3)

Description

[Timea Cernea [:tbabos][inactive]]

[Affected versions]:
Nightly 65.0a1

[Affected platforms]:
Windows 10 x 64, Windows 7 x32, MAC OS 10.13

[Prerequisites]:
- set the pref dom.payments.request.enabled to "true"
- set the pref browser.search.region to "US"
- make sure to have at least one Shipping Address and saved CC
- Use an account that has an OS password set

[Steps to reproduce]:
1. Go to "https://rsolomakhin.github.io/pr/single/" and click on "Buy".
2. Select any address and a Payment Method enter the CVV.
3. Click on "Pay".
4. Fill in a wrong password in the OS password prompt and click ok
5. If the payment is processed, repeat step 4 until the browser becomes unresponsive and crashes - filling in the correct password might also work sometimes


[Expected Result]:
The incorrect OS password should be handled correctly without causing the browser to crash.

[Actual Result]:
The browser crashes with 2 signatures after using wrong OS passwords several times.

Comment 1

[Matthew N. [:MattN]]

J.C., can you help triage this?

Comment 2

[J.C. Jones [:jcj] (he/they)]

I cannot reproduce with today's Nightly on Windows 10 Pro rev 1809, or OSX 10.13.6

On Windows 10 I've a Microsoft account also set up, which incorrect passwords enough times locked me out of without crashing the browser.

On the Mac, I did nearly 100 repetitions without the bug surfacing.

The stack traces attached point to graphics/compositor issues, not anything that I see to do with WebPayments.

I'm guessing this isn't even a Web Payments issue at all; at most it might be related t o the pop-over field or whatever is causing it to lay-out the UI weirdly. [1] But again, I haven't seen the crash.

[1] https://imgur.com/a/tpMjMU8

Comment 3

[Matthew N. [:MattN]]

Thank J.C. The weird layout is a front-end regression (bug 1506531) also from outside of Web Payments.

Timea, can we separate this bug into separate reports per OS and then we can move them to other components? Thanks

Comment 4

[Timea Cernea [:tbabos][inactive]]

Reproduced the issue on latest Nightly 65.0a1 (2018-11-14) (64-bit) on Windows 10 x64.

The Browser Console shows a specific error every time the incorrect password is used, check video
About:crashes page displays a lot of crash reports for one bug (all of them are the above attached 2 signatures): 

Please note that it is a bit intermittent and steps might slightly be different but so far this is how I crashed the browser over 10 times:

[1] Type in the wrong password several times - see if browser crashes, if not go to step [2]
[2] Type in the good password several times in needed and the browser should crash
[3] Start over step 1 if needed

Here is the recording of how the issue was reproduced: https://streamable.com/s9u67

This is the most I can do to help in reproducing the issue. Reproduced on my workstation and on a Surface Pro with Win10. 
Didn't manage to reproduce it on Mac on the latest Nightly since it will warn the user about the wrong password and does not advance further from there compared to Win10. 
So I suppose that the MAC OS can be skipped, but on Windows, it is reproducible with a bit of effort as it can be seen in the video.

Comment 5

[Marcia Knous [:marcia]]

This continues to happen on nightly, but isn't really seen on release. Some correlation to Sophos on nightly:

(63.16% in signature vs 00.22% overall) Module "sophos_detoured_x64.dll" = true [100.0% vs 00.74% if platform_version = 10.0.17134]

Comment 6

[Marcia Knous [:marcia]]

Currently #8 overall top crash signature on 70 nightly.

Comment 7

[Matthew N. [:MattN]]

The increase in the signature from June is likely unrelated to this bug and should be split to its own since the Web Payments feature that used this feature is disabled by default on Nightly since December.

Comment 8

[Marcia Knous [:marcia]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #7)

The increase in the signature from June is likely unrelated to this bug and should be split to its own since the Web Payments feature that used this feature is disabled by default on Nightly since December.

I created Bug 1573569 to track the spike in mozilla::layers::ContainerLayerMLGPU::ComputeIntermediateSurfaceBounds.

Comment 9

[Wayne Mery (:wsmwk)]

Timea, can you reproduce, and if so update crash signatures?

no crashes newer than 78 beta for https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Alayers%3A%3AContainerLayerMLGPU%3A%3AComputeIntermediateSurfaceBounds&date=%3E%3D2020-06-05T14%3A33%3A00.000Z&date=%3C2020-12-05T14%3A33%3A00.000Z

rare, but not quite so true for https://crash-stats.mozilla.org/signature/?signature=TppRaiseHandleStatus&date=%3E%3D2020-11-05T14%3A37%3A00.000Z&date=%3C2020-12-05T14%3A37%3A00.000Z/?signature=TppRaiseHandleStatus

Comment 10

[Matthew N. [:MattN]]

The feature is only on Nightly now: https://searchfox.org/mozilla-central/rev/c14733e74e540b71856cc1d963bc424b38aa4bef/browser/app/profile/firefox.js#1915,1917,1920-1921

Comment 11

[Timea Cernea [:tbabos][inactive]]

Could not reproduce the crashes anymore on the latest Nightly 86.0a1 (2020-12-29) (64-bit) using WebPayments enabled via the prefs. Closing this as resolved:worksforme. Please note that WebPayments was preffed off a long time ago so bumping into the same crash reports reproduced via WebPayment is unlikely.