Tab Widget list item active tab does not maintain highlight when other buttons are pressed

[adammatthewsmith]

Using tabs in a navbar as in http://view.jquerymobile.com/master/demos/tabs/, if you select other buttons in the page (not the navbar) the navbar button anchors lose the 'ui-btn-active' class and therefore lose the blue highlight.

To test:

1. Go to the tabs demo page. (Tab Widget does not set class "ui-btn-active" for the initially opened tab #7407 already captures the issue where the first tab is not highlighted by default even though its content is shown).
2. Select any tab. It should become highlighted.
3. Select the 'View Source' button.
4. Close the source window.
   Expected: the selected tab should still be highlighted.
   Actual: no tabs are highlighted.

[gabrielschulhof]

The button that brings up the "View Source" popup gets the ui-btn-active class when it brings up the popup. We don't have a way of tracking back to the previous button that used to have ui-btn-active. I'm not sure we want to implement this kind of active-state chaining. @arschmitz?

[adammatthewsmith]

I would suggest that rather than tracking previous active buttons so that ui-btn-active could be restored, the more robust solution would be to let the navbar button highlight operate via a different css class. The current navbar button should always be highlighted regardless of other page interactions.

[arschmitz]

The problem here is actually much simpler then all this. The only reason this is happening is because those are links not buttons to launch the popup. When links are clicked we remove the active class from all other links because we are navigating ( popup from a link is a nav event ). If you use anything else ( like an actual button checkbox open the popup from a button etc http://jsbin.com/qupasewova/1 ) this does not happen.

My inclination is to close this as expected behavior ( not a bug ).

@adammatthewsmith @gabrielschulhof thoughts?

[Ruffio]

Perhaps writting a few lines on demo/doc would be a good idea then? Just to
make sure it is expected behavior...

[adammatthewsmith]

'Expected behavior' is a strong phrase here without 'unfortunate' as a qualifier. It is expected in the context of links in a web page, especially by experienced web developers, but when links in a web page are actually buttons in an application and navigation to other pages may actually just be exposing popups the subtleties of the implementation are likely lost on the average jqm user (myself included).

Updating the demo site and documentation is sufficient for helping people at least realize why this behavior is observed, and ultimately if you change the demo code to use a button instead of an anchor then most cases of this confusion will be avoided. It was easy enough to write handlers that manage my custom class as a workaround, but I'm not aware of the other design effects of changing the widget in the core code. It's likely that the doc/demo change will be the most time effective solution here.

[arschmitz]

@adammatthewsmith its about using elements for their intended purpose. Links are meant to do exactly that link. So if your not using it for that your kinda misusing the element. If your really going for interaction within a page you should use a button.

I do agree we should update the demos and docs on this.

Also just as a note we are reviewing our link handling soon and will keep this in mind.

[agcolom]

@arschmitz I'll fix the api docs. Should I also fix in jquery-mobile AND in demos if we're not going to have a 1.4.6?

[slavap]

It's better to look at this problem from the other side, i.e. from tabs widget. Active page header must always be highlighted. Period. Doesn't matter what else is going on on the page and what kind of other widgets are in use. It's just unnatural behavior, and fixing docs is not a solution. It should be highlighted when page starts as well, how user can tell which tab is active now? There is a clear difference between active tab and focused widget. May be not highlighted, but clearly marked/shaped.

[apsdehal]

@agcolom Are you still willing to fix the api docs? If not, I will take the charge.

[apsdehal]

I am closing this for now, but I will add this to TODO for docs. Also in 1.5-dev, this issue no longer occurs.