fix(tabs): Initial tab selection

[chrisirhc]

• Avoid re-initializing tab.active
• setActive only when all tab.active are set up (on the next
  digest cycle)

Before I go to explain, there are up to two expressions that indicate
whether a tab is active:

1. active variable in the isolate scope of the tab directive
2. The expression from the active attribute (attrs.active) if it is set, I'll call this getActive, as that's the variable that refers to it (setActive assigns to it).

During initial linking (adding of tabs), the active variable in the tab's isolate scope tracks the active tab. When the first tab is added, it's active is set to true since there's no way to know if subsequent tabs are active since they haven't been added yet. As such, at this point, it is not meaningful to set assign the getActive with the value of active. At least not until all the tabs have been added. Hence, a good time would be to wait until the next $digest cycle.

A watcher is called asynchronously after initialization even if there is no change on the expression's value.

As such, we can leave that to the watcher for the active expression to initialize getActive by calling setActive during its initlization cycle.

However, there is a chance (if the $digest cycles and planets align...) that the active variable gets initialized a second time using the getActive (in the watcher for getActive). Since we're already setting active to getActive, and the active variable should now be carrying the truth. Avoid this re-initialization.

---

This fix is ugly because the logic for the two-way binding of active and the getActive is complex. Consider refactoring the implementation for maintaining the two-way binding. It looks like this sort of binding is exactly what $compile already does in compile.js#L973-L1001 . AngularJS 1.1.4 introduced the feature in angular/angular.js@ac899d0 to allow optional binding of variables in the isolate scope that handles this very cleanly just by declaring scope: {active: '=? active'} for the directive.

I didn't investigate into why the previous test with ng-repeat didn't expose this problem. It's possible it's because it had an additional digest cycle between linking such that the digest cycles didn't go in the order that would expose the problem.

Fixes #747.

[chrisirhc]

During initial linking (adding of tabs), the active variable in the tab's isolate scope tracks the active tab. When the first tab is added, it's active is set to true since there's no way to know if subsequent tabs are active since they haven't been added yet. As such, at this point, it is not meaningful to set assign the getActive with the value of active. At least not until all the tabs have been added. Hence, a good time would be to wait until the next $digest cycle.

This will happen automatically, because the watcher for active should run asynchronously on the later (see comment on line 216) even if the active variable hasn't changed.

[ajoslin]

thanks @chrisirhc - finally merged it! Fortunately we will soon be replacing the binding with '=?' as you said!