810758 - implement new onmatch callback

Status: RESOLVED INVALID

(Core Graveyard :: Identity, defect)

Description

[Ben Adida [:benadida]]

A new callback, onmatch(), has been specified to simplify the situation with onready():

  https://github.com/mozilla/id-specs/commit/0ad12419034273e888992305f37effbd2b4e4044

We should implement it natively.

Comment 1

[Jason Smith [:jsmith]]

This needs more information before we put this in scope for basecamp. We also need to be very careful about scope here - things should only be added if there's a developer workflow we didn't think of that doesn't have a workaround.

Questions:

1. Does the developer have a work-around? comment 0 implies there is a work-around, and this just simplifies the developer workflow.
2. Why does this need to be scope for basecamp? It's late to be adding enhancements, so we need to be careful about scope here.

Comment 2

[Ben Adida [:benadida]]

(In reply to Jason Smith [:jsmith] from comment #1)
> This needs more information before we put this in scope for basecamp. We
> also need to be very careful about scope here - things should only be added
> if there's a developer workflow we didn't think of that doesn't have a
> workaround.

Hi Jason,

I hear your caution about scope, but I want to point out that there is another driver here, for which my team is willing to take full responsibility: making identity work across *all* of our platforms. You won't find a B2G-specific user story that makes sense here, but if you care about apps working across all FX instances properly, then this matters.

Again, Identity Team is happy to take this on. If you'd rather this not be marked blocking-basecamp, that's ok, I guess, but I want to make sure that doesn't prevent us from landing this.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Ben Adida [:benadida] from comment #2)
> (In reply to Jason Smith [:jsmith] from comment #1)
> > This needs more information before we put this in scope for basecamp. We
> > also need to be very careful about scope here - things should only be added
> > if there's a developer workflow we didn't think of that doesn't have a
> > workaround.
> 
> Hi Jason,
> 
> I hear your caution about scope, but I want to point out that there is
> another driver here, for which my team is willing to take full
> responsibility: making identity work across *all* of our platforms. You
> won't find a B2G-specific user story that makes sense here, but if you care
> about apps working across all FX instances properly, then this matters.
> 
> Again, Identity Team is happy to take this on. If you'd rather this not be
> marked blocking-basecamp, that's ok, I guess, but I want to make sure that
> doesn't prevent us from landing this.

Okay. I'm inclined to say this shouldn't be tracked for basecamp then. For landing this, if you get aurora approval, then you should be able to land this with no issues.

Comment 4

[Jason Smith [:jsmith]]

Also note - the other bugs need to happen first in terms of priority, as the PMs are really cracking down in the fact that we're not feature complete per the b2g work week discussion for identity.

Bug list for reference - https://wiki.mozilla.org/Apps/ID_and_Payments#Identity_DOM

Comment 5

[Ben Adida [:benadida]]

(In reply to Jason Smith [:jsmith] from comment #4)
> Also note - the other bugs need to happen first in terms of priority, as the
> PMs are really cracking down in the fact that we're not feature complete per
> the b2g work week discussion for identity.

Hmmm, for the on-client stuff for identity, we were absolutely feature complete end of October. However, a big patch broke our code (and lots of other code). So we're working on it, but I hope the PM team understands that this was a curve ball completely out of our control.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Ben Adida [:benadida] from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #4)
> > Also note - the other bugs need to happen first in terms of priority, as the
> > PMs are really cracking down in the fact that we're not feature complete per
> > the b2g work week discussion for identity.
> 
> Hmmm, for the on-client stuff for identity, we were absolutely feature
> complete end of October. However, a big patch broke our code (and lots of
> other code). So we're working on it, but I hope the PM team understands that
> this was a curve ball completely out of our control.

Per the b2g work week, we realized that identity was not feature complete because there's open features right now for b2g v1 that are linked to actionable user stories in the v1 app status doc:

- bug 769865 (PAYANDID-028)
- bug 790141 (PAYANDID-029)

However, they were not initially called out in the scope document when we initially drafted it because it was missing feature scope we didn't clearly call out. When we did a final review during the work week for v1 user stories and signed off on the list, these two bugs were included as features needed to be completed to be able to declare the identity pieces as feature complete. So at this point of time after finalizing the definition for v1 features for payments and identity, we currently show the following in the doc under PAYANID:

OPEN					https://bugzilla.mozilla.org/show_bug.cgi?id=790141	Payments & Identity	Marketplace		PayAndID-028	As a user, I should be able to use the identity I have set up for Marketplace on a persona-powered site or app that uses the older persona get() API
OPEN					https://bugzilla.mozilla.org/show_bug.cgi?id=769865	Payments & Identity	Marketplace		PayAndID-029	As a user, I need to be notified when logging into persona that I do not network connection, so that I know I need to connect to the network to login into persona.

Every other user story on that list is either marked as OOS (out of scope), since it was marketplace-specific or CC (feature complete in their language). Thus, identity right now is not feature complete per that analysis.

Reference doc: https://docs.google.com/spreadsheet/ccc?key=0Ajt_meMlK3MOdHphdnV2a2RvcU9MZmd3cDlIQnZBMVE#gid=1

Comment 7

[Ben Adida [:benadida]]

Hi Jason,

> - bug 769865 (PAYANDID-028)

As I've mentioned before, this is, at most, a bug, not a feature. Offline logging in is an edge-case situation. Considering Identity "not feature complete" because of this issue is misleading.

> - bug 790141 (PAYANDID-029)

So, this is the bug that *I* want us to get done, but it doesn't block any marketplace/payment user stories. In particular, if you think this bug matters, then so does the onmatch() bug described in this thread. Marketplace is not impacted in any way by either one.

We need to have a useful definition of feature-complete. In my opinion, if we're not feature-complete, we've got a serious issue that needs highlighting at the executive level.

Do either of the above two bugs qualify for this all-hands-on-deck situation? I don't think so.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Ben Adida [:benadida] from comment #7)
> Hi Jason,
> 
> > - bug 769865 (PAYANDID-028)
> 
> As I've mentioned before, this is, at most, a bug, not a feature. Offline
> logging in is an edge-case situation. Considering Identity "not feature
> complete" because of this issue is misleading.


I don't understand. The discussion in bug 769865 implies that it was a feature (read the entire bug discussion for clarity) - https://bugzilla.mozilla.org/show_bug.cgi?id=769865#c8 specifies the user story called out. 

I wouldn't call offline mode a huge edge case (given the target markets) and necessarily not a feature - other major feature sets for b2g have called b2g offline cases part of the user stories for v1. In fact, it's quite common - I also test the calendar, which additionally calls out a user story similar to this bug:

As a user setting up a new Calendar account, I want to be alerted when the application cannot connect to the server using the information i entered during setup.

That's why I'd call this a feature, not a bug. See more examples in that ff os v1 app status doc.
 
> 
> > - bug 790141 (PAYANDID-029)
> 
> So, this is the bug that *I* want us to get done, but it doesn't block any
> marketplace/payment user stories. In particular, if you think this bug
> matters, then so does the onmatch() bug described in this thread.
> Marketplace is not impacted in any way by either one.

Marketplace isn't, but remember that persona isn't just used by marketplace, it's used across the web, including certain top apps. We discovered that this was a core piece we didn't think of initially when scoping testing for identity during the b2g identity testing brainstorming session I had with John M. and Jed. Top app/site compatibility is critical to success of this product, so this should be treated as high importance, especially cause we likely can't turn on the pref to turn identity with trusted UI on by default without this bug. Unless I'm misinterpreting something that we could safely turn the pref on and not break top sites using the legacy API.

onmatch() I'm not sure about because the first comment above implies that this simplifies the developer workflow from onready(). Traditionally if a work-around exists in a developer's workflow, then I'd be inclined to argue that this is "polishing" the developer workflow to improve the developer experience, but since a work-around exists, I'd argue it wouldn't block v1. If we had to ship, what we would likely have to do then if this wasn't implemented was ensure that developer docs were updated to indicate that a developer would have to do feature detection to know if they can or cannot use onready. If I'm misinterpreting something, then please clarify.

> 
> We need to have a useful definition of feature-complete. In my opinion, if
> we're not feature-complete, we've got a serious issue that needs
> highlighting at the executive level.

Agreed. Let's talk more tomorrow.

> 
> Do either of the above two bugs qualify for this all-hands-on-deck
> situation? I don't think so.

If both are called out as features, then it needs to be done asap (that would be why the target milestone says "B2G C1 (to 19nov)," also known as "It really needs to be done by November 19th, 2012). If both are not features, then that's a different story resulting in reprioritizing the bug to priority that makes sense. Priorities actively used for blockers are the following:

- P1 - missing feature work, smoketest bustage, etc
- P2 - major regressions, security bugs, etc
- P3 - Usability issues, perf issues, etc

The priority set reflects when the work has to be done (the milestones in other words).

I'll hold my further discussion points on the debate until tomorrow. Tomorrow let's talk about the three bugs then as well (this one, the id.get one, and the offline one).

Comment 10

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

This has been removed from the Persona RP spec:

https://github.com/mozilla/id-specs/blob/greenfield/browserid/api-rp.md

Closing this as invalid.