1470110 - Crash in IPCError-browser | RecvRequestPayment

Status: RESOLVED FIXED

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

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-78bd0a2e-8e54-4a2f-9ced-622fa0180621.
=============================================================

Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForAlertByThreadId 
1 ntdll.dll RtlSleepConditionVariableSRW 
2 kernelbase.dll SleepConditionVariableSRW 
3 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:58
4 xul.dll mozilla::CondVar::Wait xpcom/threads/CondVar.h:66
5 xul.dll mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue<mozilla::LabeledEventQueue> >::GetEvent xpcom/threads/ThreadEventQueue.cpp:156
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:991
7 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:519
8 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:125
9 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run ipc/glue/MessagePump.cpp:301

=============================================================

content crashes with this signature are starting to appear cross-platform in a low volume in 61 & 62 beta builds.

a comment at bp-95e690c8-17a0-4350-a708-2ace00180615 says: "Happened when testing the web payment API in whatwebcando.today"

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Hey Blake, can you take a look at this?

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

I was worried that this was a regression from bug 1442453 and that someone had figured out a way to cause us to reliably crash, but it turns out this is a beta only thing that (I think) has been around for a while. We only build the browser/components/payments stuff on Nightly builds and neither Dev Edition or Beta count as that, so we end up with the pref set to true (which must have been done manually by the user) and no frontend, which ends up crashing us. I think the right thing to do here is to never turn on payments if we're not Nightly builds (for now at least).

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Bug 1470110 - Consistently disable payments off of Nightly.

We only build the frontend parts of Web Payments on Nightly, but users could
futz with the prefs and expose the DOM API on Beta. We should be careful about
not allowing that mismatch.

This also adds some additional logging if we run into a bug like this again.

Review commit: https://reviewboard.mozilla.org/r/252400/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/252400/

Comment 4

[Matthew N. [:MattN]]

Comment on attachment 8987163 [details]
Bug 1470110 - Consistently disable payments off of Nightly.

https://reviewboard.mozilla.org/r/252400/#review258880

Thanks. I had previously suggested to the team in Taipei that we shouldn't even build payments outside of Nightly, like we do with the front-end but this is also better than what we have. The rationale for not building was to reduce memory usage which is even more important for mobile which isn't going to get UI for this anytime soon.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a2e970897bb2
Consistently disable payments off of Nightly. r=MattN

Comment 6

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/a2e970897bb2

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Doesn't sound like this is likely to hurt us on release, but I'd be open to taking this as a dot release ride-along if we see more crashes than expected.