steps to reproduce: 1. Load https://marketplace.allizom.org on the latest nightly on your android device 2. Sign in 3. Search for :paid 4. Start the purchase flow 5. Click on Forgot PIN? link 6. Confirm Reset expected behavior: Fxa screen loads where user is prompted to reenter their password actual behavior: 500! logcat shows: 02-18 16:17:12.545 I/GeckoConsole( 7646): [lib][auth] Begin webpay user reset at /mozpay/auth/reset_user 02-18 16:17:12.555 I/GeckoConsole( 7646): [views][reset-start] starting logout timer. 02-18 16:17:12.635 W/GeckoConsole( 7646): [JavaScript Warning: "This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1." {file: "https://marketplace.allizom.org/mozpay/auth/reset_user" line: 0}] 02-18 16:17:12.635 I/GeckoConsole( 7646): [lib][auth] reset webpay user 02-18 16:17:12.655 I/GeckoConsole( 7646): [lib][auth] Setting needs-provider-logout in localStorage to true 02-18 16:17:12.655 I/GeckoConsole( 7646): [views][reset-start] Clearing logout reset timer. 02-18 16:17:12.655 I/GeckoConsole( 7646): [views][reset-start] Forgot-pin logout done 02-18 16:17:12.665 I/GeckoConsole( 7646): [models][transaction] Saving JWT to sessionStorage 02-18 16:17:12.675 I/GeckoConsole( 7646): [views][reset-start] redirecting to https://oauth.accounts.firefox.com/v1/authorization?scope=profile&state=8ee80490ee424495a9e7788d12fff28d&client_id=e39e5fe5d3ed5529&email=kraj%40mozilla.com&action=force_auth 02-18 16:17:12.675 W/GeckoConsole( 7646): [JavaScript Warning: "This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1." {file: "https://www.google-analytics.com/collect?v=1&_v=j33&a=1942604612&t=event&_s=4&dl=https%3A%2F%2Fmarketplace.allizom.org%2Fmozpay%2Fspa%2Fsuper-simulate&ul=en-us&de=UTF-8&dt=Connecting%20to%20Firefox%20Accounts%20%7C%20Firefox%20Marketplace&sd=24-bit&sr=360x592&vp=360x519&je=0&ec=Consumer%20Payment%20Flow&ea=webpay%20user%20reset&el=Reset%20User%20Success&_utma=42843833.823365031.1406834330.1406839831.1406922484.4&_utmht=1424305032652&_u=SIACAAQB~&cid=i05qimin.xqp&tid=UA-36116321-6&z=1510976035" line: 0}] 02-18 16:17:12.995 I/Gecko ( 7646): console.error: priceblink: 02-18 16:17:12.995 W/GeckoConsole( 7646): [JavaScript Error: "TypeError: can't access dead object"] 02-18 16:17:12.995 I/Gecko ( 7646): Message: TypeError: can't access dead object 02-18 16:17:12.995 I/Gecko ( 7646): Stack: 02-18 16:17:12.995 I/Gecko ( 7646): getInnerId@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/window/utils.js:78:3 02-18 16:17:12.995 I/Gecko ( 7646): initialize/model.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:62:27 02-18 16:17:12.995 I/Gecko ( 7646): Observer<.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/system/events.js:72:7

I got a subtley different error message: I/GeckoConsole( 9034): [views][reset-start] redirecting to https://oauth-stable.dev.lcip.org/v1/authorization?scope=profile&state=[redacted]&client_id=[redacted]&email=scolville[redacted]&action=force_auth W/GeckoConsole( 9034): [JavaScript Warning: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.google-analytics.com/collect. (Reason: CORS request failed)."] W/GeckoConsole( 9034): [JavaScript Warning: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.google-analytics.com/collect. (Reason: CORS request failed)."] W/GeckoConsole( 9034): [JavaScript Error: "Critical error:"] W/GeckoConsole( 9034): [JavaScript Error: "Error: Permission denied to access property 'postMessage'"] Looks like we'd redir'd to https://oauth.accounts.firefox.com at this point.

Screenshot of 500 error attached.

Are we trying to call the native FxA flow on Android?

(In reply to Andy McKay [:andym] from comment #4) > Are we trying to call the native FxA flow on Android? Ah we aren't. We are inside the Trusted UI and redirecting to FxA flow.

We haven't seen this, but working with Krupa we repro'ed Stuart's error in https://bugzilla.mozilla.org/show_bug.cgi?id=1134466#c1 (Krupa's original error was likely due to an extension). "Permission denied to access property 'postMessage'" looks like the likely suspect. I noticed you guys are loading FxA from a chrome URL. Are you using the iframe OAuth flow by loading FxA in an iframe on that page? If so, I wonder if something is blowing up due to loading a Web iframe on a chrome page.

Shane and Zach, I don't think there is much actionable for you yet here, but it's one for you to watch. Also, adding rfkelly, who is now responsible for direct leadership of FxA.

I'm having trouble reproducing this, but Krupa is helping me out. How does this PIN reset flow integrate with FxA? Does it use the iframe flow? If it does, I noticed that the PIN reset flow runs on a chrome:// URL. The iframe flow does some comms with FxA, which invokes "window.parent.postMessage". I wonder if there is some permission error because "window" is a Web iframe and window.parent is privileged.

> I wonder if there is some permission error because "window" is a Web iframe and window.parent is privileged. I'm starting to suspect this is the case. I connected a remote debugger and got the stack trace below. Does this flow work on dev? An alternative to this flow is to use our "WebChannel" flow, which is a way for privileged browser code to communicate with our accounts pages. It works similar to the postMessage/iframe flow, but the framed page just fires an event on its own window, which should skirt this potential permission issue. Error: Permission denied to access property 'postMessage' Stack trace: .dispatchCommand@https://accounts.firefox.com/scripts/0f968594.main.js:15:1563 h.send@https://accounts.firefox.com/scripts/0f968594.main.js:14:26115 R@https://accounts.firefox.com/scripts/0f968594.main.js:7:7278 Q/<@https://accounts.firefox.com/scripts/0f968594.main.js:7:7237 c.send@https://accounts.firefox.com/scripts/0f968594.main.js:14:24959 h@https://accounts.firefox.com/scripts/0f968594.main.js:15:1834 j@https://accounts.firefox.com/scripts/0f968594.main.js:15:2044 k<.selectStartPage@https://accounts.firefox.com/scripts/0f968594.main.js:15:2418 E.prototype._selectStartPage/</<@https://accounts.firefox.com/scripts/0f968594.main.js:15:15071 F@https://accounts.firefox.com/scripts/0f968594.main.js:7:5767 E@https://accounts.firefox.com/scripts/0f968594.main.js:7:5721 l@https://accounts.firefox.com/scripts/0f968594.main.js:7:3777 The "dispatchCommand" line in question is most likely: https://github.com/mozilla/fxa-content-server/blob/c8a8affa7cdb9a5c09b82ed62441760a63be92fb/app/scripts/lib/channels/iframe.js#L47

NOTE: While trying to reproduce this on Android, make sure you have https://addons.mozilla.org/en-US/android/addon/dev-marketplace installed. needinfo'ing stuart to help confirm chris's notes in comment 9.

After further investigation, "using the iframe flow" from our perspective just means that the accounts flow is loaded in an iframe. We assume that if we're loaded in an iframe, then the relier means to use our postMessage based integration. Is this the same code that implements this flow on FxOS? If it is, can you verify if this flow works on FxOS? I'm going to chat with Shane about this tomorrow during our 1:1.

I just verified this flow works on FxOS, so if it is the same code path, then it's at least failing in a different way.

It works on FxOS in 2.1, but we are likely going to be having similar issues on FxOS 2.2 or 3.0. This is most likely related to the platform changes for WebIDL that ferjm recently landed. Thanks so much for the investigation, I would suggest that we what to hear from ferjm first before going to far.

(In reply to Chris Karlof [:ckarlof] from comment #9) > > I wonder if there is some permission error because "window" is a Web iframe and window.parent is privileged. > > I'm starting to suspect this is the case. I connected a remote debugger and > got the stack trace below. Does this flow work on dev? An alternative to > this flow is to use our "WebChannel" flow, which is a way for privileged > browser code to communicate with our accounts pages. It works similar to the > postMessage/iframe flow, but the framed page just fires an event on its own > window, which should skirt this potential permission issue. > > Error: Permission denied to access property 'postMessage' > Stack trace: > .dispatchCommand@https://accounts.firefox.com/scripts/0f968594.main.js:15: > 1563 > h.send@https://accounts.firefox.com/scripts/0f968594.main.js:14:26115 > R@https://accounts.firefox.com/scripts/0f968594.main.js:7:7278 > Q/<@https://accounts.firefox.com/scripts/0f968594.main.js:7:7237 > c.send@https://accounts.firefox.com/scripts/0f968594.main.js:14:24959 > h@https://accounts.firefox.com/scripts/0f968594.main.js:15:1834 > j@https://accounts.firefox.com/scripts/0f968594.main.js:15:2044 > k<.selectStartPage@https://accounts.firefox.com/scripts/0f968594.main.js:15: > 2418 > E.prototype._selectStartPage/</<@https://accounts.firefox.com/scripts/ > 0f968594.main.js:15:15071 > F@https://accounts.firefox.com/scripts/0f968594.main.js:7:5767 > E@https://accounts.firefox.com/scripts/0f968594.main.js:7:5721 > l@https://accounts.firefox.com/scripts/0f968594.main.js:7:3777 > > The "dispatchCommand" line in question is most likely: > https://github.com/mozilla/fxa-content-server/blob/ > c8a8affa7cdb9a5c09b82ed62441760a63be92fb/app/scripts/lib/channels/iframe. > js#L47 From the payments side we're changing location in the trusted ui to the oauth flow. There's certain restrictions in this environment but it should work the same as the trusted-ui on pre-native FFOS devices. Here's the relevant line that ties in with the logs in comment 1 https://github.com/mozilla/spartacus/blob/913ca4047cc3ff22c5afee5a0c8936f3b5c80572/public/js/views/reset-start.js#L86

(In reply to Andy McKay [:andym] from comment #13) > It works on FxOS in 2.1, but we are likely going to be having similar issues > on FxOS 2.2 or 3.0. FxOS is quite a different scenario than Android. On FxOS we load the payment flow within the trusted UI which is an iframe created by the System app. The System app, while it's "privileged" in the sense of Firefox *apps*, lives on a content (unprivileged) window. So there shouldn't be chrome <-> content window message passing at that level. Also, on FxOS we should not be using the FxA OAuth flow and instead use the native FxA flow which is not available on Android, but I guess that's another discussion. On Android we load the payment flow in an iframe created within a chrome (privileged) window (loaded with a chrome:// url) [1]. During the payment flow we redirect to the FxA OAuth flow (this is where I am starting to get lost) and it seems that we are creating a child iframe (unprivileged content) and we are trying to communicate to its parent (privileged window) via window.parent.postMessage(). (In reply to Chris Karlof [:ckarlof] from comment #9) > > I wonder if there is some permission error because "window" is a Web iframe and window.parent is privileged. > > I'm starting to suspect this is the case. I connected a remote debugger and > got the stack trace below. Does this flow work on dev? An alternative to > this flow is to use our "WebChannel" flow, which is a way for privileged > browser code to communicate with our accounts pages. It works similar to the > postMessage/iframe flow, but the framed page just fires an event on its own > window, which should skirt this potential permission issue. I also believe the issue is the attempt to communicate between the unprivileged and privileged content. Could you try to use the "WebChannel" flow as Chris suggested? [1] https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/payment.xhtml#27

I tested Shanes patch and this worked. When this lands in prod I'll close so we can test this on stage.

The fix is going out on train-32, which should be in production by the end of this week.

> The fix is going out on train-32, which should be in production by the end of this week. PR 2171 [1] was merged yesterday into the current master, so this is going to make train-33. jrgm informed me train 33 ships the week of the 23rd. The patch is currently on the latest stack [2] and can be tested there. --------------------- [1] - https://github.com/mozilla/fxa-content-server/pull/2171 [2] - https://developer.mozilla.org/en-US/Firefox_Accounts#Latest_development_%28updated_continuously_from_master%29

Ah whoops, indeed I got my wires crossed on the trains there, and this will be on train-33. Thanks Shane.

Tested pointing local dev env at oauth-latest and it's looking good.

I can still reproduce this issue in mp-dev and mp-stage on Android 4.2.1 The 500 error is displayed: http://screencast.com/t/kpkkbokSqun Reopeneing.

(In reply to Madalin Cotetiu from comment #21) > I can still reproduce this issue in mp-dev and mp-stage on Android 4.2.1 > The 500 error is displayed: http://screencast.com/t/kpkkbokSqun > Reopeneing. The fix isn't live yet. I've bumped the milestone.

The FxA-side fix should be in production by the end of this week.

Verified as fixed in FF39(Android 4.2.1) Pin can now be successfully reseted on Android. Closing bug.