STR - build a hosted/packaged webapp that calls navigator.mozPay() - install it on desktop Firefox (webappRT) I did not expect navigator.mozPay() to be defined but it is. However, it is not defined in the Firefox browser. When you call mozPay(), it loads the payment provider within the app's main window. This means the purchase will never complete because the app is not running in the background. It would also be tricky for developers to adjust their payment prefs to work with pre-production payment systems. I don't think mozPay should be defined on the desktop web because there are already enough utilities to perform web payments on desktop. This also interferes with our payment library (https://github.com/mozilla/fxpay) since it looks for the existence of mozPay to decide whether or not to perform a web payment flow or a native one. As a side note, debugging a desktop app is as simple as running it from the command line like: /Applications/SomeApp.app/Contents/MacOS/webapprt -debug 6000 and connecting with WebIDE: https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Debugging_Firefox_Desktop

Fernando, was it intentional to expose mozPay in the webappRT?

To be more specific, I was able to load the purchase window from webappRT using mozPay() but when calling paymentSuccess(), I got: Error: Exposing privileged or cross-origin callable is prohibited

(In reply to Kumar McMillan [:kumar] (needinfo for quickness) from comment #1) > Fernando, was it intentional to expose mozPay in the webappRT? Yes, we exposed it on bug 898499 (In reply to Kumar McMillan [:kumar] (needinfo for quickness) from comment #2) > To be more specific, I was able to load the purchase window from webappRT > using mozPay() but when calling paymentSuccess(), I got: > > Error: Exposing privileged or cross-origin callable is prohibited This is because we didn't modify the webappRT implementation to support the new WebIDL based payment implementation done in bug 1097928. We can either fix that or remove payment support from webappRT.

> This is because we didn't modify the webappRT implementation to support the new WebIDL based payment implementation done in bug 1097928. Yes, this is also the cause for this regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1080088 > We can either fix that or remove payment support from webappRT. I'm not sure what we want to do. Bill is probably the best person to ask.

oops, didn't mean to reset needinfo. not sure what to do yet, hopefully Myk or Nick will have an idea.

(In reply to Kumar McMillan [:kumar] (needinfo for quickness) from comment #0) > I don't think mozPay should be defined on the desktop web because there are > already enough utilities to perform web payments on desktop. I don't quite understand this reasoning, since there are libraries for in-app payments on other platforms as well, and the status of alternatives is orthogonal to our goals for WebAPIs. > This also > interferes with our payment library (https://github.com/mozilla/fxpay) since > it looks for the existence of mozPay to decide whether or not to perform a > web payment flow or a native one. Hmm, that's not quite interference, provided that the "native" flow works as expected. The problem is that it doesn't. (In reply to Bill Walker [:bwalker] [@wfwalker] from comment #5) > oops, didn't mean to reset needinfo. not sure what to do yet, hopefully Myk > or Nick will have an idea. In the short term, fxpay should switch to the "web payment" flow on desktop, even if mozPay is present. In the medium term, we should fix mozPay on desktop. And in the long term, we should revisit our platform strategy for mozPay to make sure it actually makes sense to support it on desktop (and other non-B2G platforms).

(In reply to Myk Melez [:myk] [@mykmelez] from comment #6) > (In reply to Kumar McMillan [:kumar] (needinfo for quickness) from comment > #0) > > I don't think mozPay should be defined on the desktop web because there are > > already enough utilities to perform web payments on desktop. > > I don't quite understand this reasoning, since there are libraries for > in-app payments on other platforms as well, and the status of alternatives > is orthogonal to our goals for WebAPIs. That statement was the result of asking myself this question: why do we need navigator.mozPay() on desktop? I couldn't come up with a good answer because we already can open a new window (to do the payment) and can use window.postMessage() to communicate the payment result back to the app. It requires the app to install a payments library but apps use libraries to enhance their functionality all the time. > In the short term, fxpay should switch to the "web payment" flow on desktop, > even if mozPay is present. In the medium term, we should fix mozPay on > desktop. And in the long term, we should revisit our platform strategy for > mozPay to make sure it actually makes sense to support it on desktop (and > other non-B2G platforms). There is currently a window bug blocking us from doing a web flow: bug 1135261. But, yes, ultimately we'd like to prioritize the web flow because it allows us to support other platforms that do not implement mozPay().

Over in bug 1080088 I'm disabling the existing, broken implementation while we figure out what we want to do here.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #8) > Over in bug 1080088 I'm disabling the existing, broken implementation while > we figure out what we want to do here. Which means that bug 1080088 effectively "fixes" this bug (as originally described). The future of mozPay isn't clear, but presumably it depends on the standardization of Web Payments <https://www.w3.org/community/webpayments/>, so let's revisit the issue of desktop support for that API once those standardization efforts progress (or some other reason arises). In the meantime, I'm making this bug depend on bug 1080088 and will resolve this one once that one is resolved.