Kumar McMillan [:kumar] Reporter
	Description • 12 years ago

When a developer is creating JWTs to initiate payment they will make mistakes. Their only feedback is an error code sent to their failure() callback. This bug is about adding a unique error code for all the possible validation failures so that a developer knows what he did wrong and can make the correction.

For example, when a developer creates a JWT with an unknown typ they should receive an error code for that. Instead there is only a debug message that is not visible to them: http://mxr.mozilla.org/mozilla-central/source/dom/payment/Payment.jsm#268

See the in-app payment spec: https://wiki.mozilla.org/WebAPI/WebPayment#In-app_payment It does not yet document how error codes are sent to the callback.

+++ This bug was initially created as a clone of Bug #800511 +++

	Jason Smith [:jsmith]
	Comment 2 • 12 years ago

Blocking nom - developers need to understand what happens if an in-app payment fails and why.

	Andrew Overholt [:overholt]
	Comment 3 • 12 years ago

Having some sort of error feedback is a blocker.  Using the error console is fine.

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 4 • 12 years ago

(In reply to Kumar McMillan [:kumar] from comment #0)
> When a developer is creating JWTs to initiate payment they will make
> mistakes. Their only feedback is an error code sent to their failure()
> callback. This bug is about adding a unique error code for all the possible
> validation failures so that a developer knows what he did wrong and can make
> the correction.
> 
> For example, when a developer creates a JWT with an unknown typ they should
> receive an error code for that. Instead there is only a debug message that
> is not visible to them:
> http://mxr.mozilla.org/mozilla-central/source/dom/payment/Payment.jsm#268
> 

Note that currently the validation is done for *all* the JWTs that are passed to nav.mozPay() call. If there is an error validating one of the JWTs, we *don't* fire the error callback, but continue validating the next JWT, trying to find a valid payment request. We only fire the error callback with the "NO_VALID_PAYMENT_REQUEST_FOUND" when *all* the JWT validations fails.

Are you proposing that we fire the error callback with the first JWT validation error, exposing the exact error and discarding the rest of JWTs (if available)?

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 5 • 12 years ago

After discussing this with Kumar via IRC, we agreed to trigger the error callback with every JWT validation error, along with a detailed error code, with the exception of a wrong 'typ' value. That way we would provide enough information about a wrong payment request while we would still be allowing to use a default set of JWTs that might work in different B2G devices (with different allowed payment providers).

	Fernando Jiménez Moreno [:ferjm] Assignee
	Comment 8 • 12 years ago

Even if there have been a decision about removing the client side validation code, I still would like to add some more error information. I'll be doing it as part of bug 800511 patches, so I am closing this one as a dup.