[TIMOB-1773] Kitchensink opens on wrong tab

changed erroneous title

This is an order of operations problem. Here's the issue:

   var tab4 = Titanium.UI.createTab({
   ...
       active:true
   });
   ...
   tabGroup.addTab(tab4);
   ...
   tabGroup.setActiveTab(1);
   ...
   tabGroup.open(...)
   

tab4 is explicitly set as 'active', but then before opening the tab group itself, we set the actual active tab. So which takes precedence? What if there's more than one tab marked as 'active' when it's added to the tab group before opening? Currently, the first tab in the bar with 'active:true' is focused.

We need some clarification on the issue. The reason order started changing is probably because of an iOS change, where one property was being set before the other - wasn't this around when a new 4.1b/4.1 was released?

I'm not sure I can answer these question (I'm not 100% sure about the timing relative to 4.1), assigning to Ralf. If the current behavior is correct, should android change its to reflect this for parity?

I don't know much but my expectation would be that the active tab is set to 1, and that should be the active tab, which seems to be the old behavior on IOS and the current behavior on Android.

To keep compatibility and just my instinct tells me we should honor the "last" setActiveTab execution, if more than one exists.

Here's the problem. I do the following, instead of what's described above:

   tabGroup.setActiveTab(0);
   tabGroup.add(Ti.UI.createTab({
     active:true
   })
   tabGroup.open()
   

Which one gets respected? We have no way to tell which was set first upon opening. We should simply say that the order is undefined.

Sorry, changing back to needs-more-info.

Steve, it is always the last.

Fundamentally whether by setActiveTab or via tab.group.add(... active:true), the last one wins before the tabGroup.open()

At the point of tabGroup.open() it should be the tab that was created and added in your latest example.

My point is that we don't KNOW which change was last when the tab is opened. It's obvious in the user's JS, but that's not how Titanium works internally - all properties are, for all intents and purposes, set in a specific order all the time always (there are in fact a lot of features which depend on this) upon certain operations (in this case, opening the tab group causes all of them to be set "for real").

So we can't determine that information from property settings on either the tab or the tab group. The order is thus indeterminate and we should document it as such.

(from [aa66687741d962455f0d191e06e872b628f85ff9]) [#1773 state:fixed-in-qa] Documentation updated to reflect ambiguous ordering of tab activation. http://github.com/appcelerator/titanium_mobile/commit/aa66687741d962455f0d191e06e872b628f85ff9"> http://github.com/appcelerator/titanium_mobile/commit/aa66687741d96...

Question:

    tabGroup = Ti.UI.createTabGroup({
        activeTab:1,
        tabs:[
            tabGroup.add(Ti.UI.createTab({active:true}),
            tabGroup.add(Ti.UI.createTab({})
            ]
        })
    tabGroup.open()
    

Entries in a dict/object are unordered. Who wins?

OK, let's take a deep breath everyone. :)

Let's all think the rationale for having an "active: boolean" property on Tab.

Why do we need it?

I think the undefined issue (above) would go away if it was either "deprecated" or "read-only".

Why don't we think about this, and "do the right thing" if we can.

Steve, I'll take it back and change the state.

When we understand the rationale and arguments, we'll have to make a call make it part of the "spec" that doesn't exist now but will exist sometime soon. :)

That sounds good. For now, I'm leaving the documentation change in.

That's a good question. Tabs should have 'active' as a read-only property to determine whether or not they're the currently displayed tab.

What did we choose on this, again?

The comments above are relevant. I will have some interesting observations in our upcoming API scrub.

If we see this as an "ordering issue", please make sure that our KS code is "fixed" to launch to the first tab on both platforms.

Assigning to Steve to fix KS ASAP!

(from [e3c8d2a13c626d84582035d4217bd4ec7ab8508f]) [#1773] Updated KS to always start on 1st (Base UI) tab, unambiguously. https://github.com/appcelerator/titanium_mobile/commit/e3c8d2a13c626d84582035d4217bd4ec7ab8508f"> https://github.com/appcelerator/titanium_mobile/commit/e3c8d2a13c62...

Setting to TBS because the requested KS change was made.

Hey Stephen - I believe we need to keep line 90. If we comment out both 90 and 57 we get default tab set, which gets rid of the test in KS. I ran this by Blain and he agrees. Ralfs at lunch right now, wanted to send this back.

tabGroup.setActiveTab(1);

(from [cf498dde5a379ec9b361ff20bc8e694c1e83177e]) [#1773] Provided requested fix. NOT marking this bug fixed because the underlying issue is not resolved. https://github.com/appcelerator/titanium_mobile/commit/cf498dde5a379ec9b361ff20bc8e694c1e83177e"> https://github.com/appcelerator/titanium_mobile/commit/cf498dde5a37...

The observations are correct that the order cannot be determined esp when using the activetab property.

In a future API scrub, we will discuss this property. If it should exist at all maybe it should be read-only.

The only remaining question is setActiveTab().

My opinion is that if multiple calls exist, the last call to this function should be the tab that is active. Again, fodder for our API scrub.

Our KitchenSink example is fixed and works the same on both platforms as it should right now.

My action is to place it in the TBS release, with needs-more-info state and another tag stating it is due for API scrub.