Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1773] Kitchensink opens on wrong tab

GitHub Issuen/a
TypeBug
PriorityLow
StatusClosed
ResolutionNeeds more info
Resolution Date2011-04-15T03:01:54.000+0000
Affected Version/sn/a
Fix Version/sBacklog
ComponentsiOS
Labelsapi, ios, regression, scrub, setactivetab
ReporterThomas Huelbert
AssigneeBlain Hamon
Created2011-04-15T03:01:49.000+0000
Updated2017-03-03T07:01:01.000+0000

Description

1.using todays pull, build and install KS on device or simulator
2.launch and note which tab is opened

results: opens to PLatform tab (tab3), when the script indicates it should open controls (tab 1)

tabGroup.setActiveTab(1);

this just broke

Comments

  1. Thomas Huelbert 2011-04-15

    changed erroneous title

  2. Stephen Tramer 2011-04-15

    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?

  3. Thomas Huelbert 2011-04-15

    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?

  4. Ralf Pfeiffer 2011-04-15

    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.

  5. Stephen Tramer 2011-04-15

    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.

  6. Stephen Tramer 2011-04-15

    Sorry, changing back to needs-more-info.

  7. Ralf Pfeiffer 2011-04-15

    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.

  8. Stephen Tramer 2011-04-15

    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.

  9. Jeff Haynie 2011-04-15

    (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...

  10. Blain Hamon 2011-04-15

    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?

  11. Ralf Pfeiffer 2011-04-15

    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. :)

  12. Stephen Tramer 2011-04-15

    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.

  13. Blain Hamon 2011-04-15

    What did we choose on this, again?

  14. Ralf Pfeiffer 2011-04-15

    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!

  15. Jeff Haynie 2011-04-15

    (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...

  16. Stephen Tramer 2011-04-15

    Setting to TBS because the requested KS change was made.

  17. Thomas Huelbert 2011-04-15

    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);

  18. Jeff Haynie 2011-04-15

    (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...

  19. Ralf Pfeiffer 2011-04-15

    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.

  20. Lee Morris 2017-03-03

    Closing ticket due to time passed and irrelevance.

JSON Source