All buttons regardless of markup should get active state

[kvedananda]

When I click a button like this

<a data-role="button" href="#page2">Page 2</a>

it works fine.

However this

<button id="test">Test</button>

does not work. It fires the tap event but does not change css to the tapped state and then back to normal.

It appears that only buttons that are either linked to another page or buttons that submit forms will properly relay feedback to the user. I want to have a button on a page that handles a request for me without going anywhere. The tap event does work but the user gets no feedback that something has happened.

[jaspermdegroot]

@kvedananda - This is indeed something we want to improve. See the thread of #4469 for work arounds.

@toddparker - Is applying the active state to all buttons, regardless of markup, something we can add for 1.3?

[toddparker]

Absolutely. We've been adding active state feedback wherever we can to improve perceived responsiveness. We just need to make sure to pull this class after a brief delay to ensure they are cleaned up.

[kvedananda]

Great thanks guys. Setting the href to javascript:void(0) as described in #4469 works for now.

[jaspermdegroot]

@kvedananda

Closing this as feature request and I added a link to this ticket here https://github.com/jquery/jquery-mobile/wiki/Feature-Requests

[jaspermdegroot]

Oops. Since this will be for 1.3 I better leave it open.

[jaspermdegroot]

I changed the topic of this ticket (was: "Unlinked buttons don't display click/tap animation").

Things to look into:

• collapsibles should get active state as well: see request add active-state on clicked collapsibles or fade out ui-focus in collapsible-sets #4864
• list items should only get the active state if they have an anchor, but not only if that anchor has a href attribute
• selects (native and custom): there seems to be some inconsistency in when a select button get the focus style and active state
• issues about the active state not being removed: navbar link stays active when using changePage() #1181 and Popup: Calling LI don't lose ui-btn-active #4611 (see also my comment on PR Fixes: #1181 - navbar link stays active when using changePage() #4579)

Update:

• links with data-ajax="false" should get active state too

[jaspermdegroot]

Related PR: #5145

[gabrielschulhof]

The problem is that we only add the active class to buttons for which we know that clicking on them will not result in the current instance of jQM being scrapped. That is, we only do the logic for buttons that result in navigation that's done internally.

The reason for this is that we cannot remove the active class off buttons that, when clicked, lead to a page accessed over HTTP, because the request causes the whole browser state to be scrapped, including our logic to remove the active class upon the next button click. So, if the user were then to hit "Back", she would be taken back to the page where the button still has the active state applied. Not only that, but, if she were to click on yet another button on that page, which also leads to a HTTP request, that button would also have the active state upon her return. This would basically result in visual artifacts.

[jerone]

@gabrielschulhof can't the buttons state be reset on unload?

[gabrielschulhof]

After a discussion with @uGoMobi we've come up with two possible solutions for adding active states to those buttons (be they links or form elements) that will cause the browser to tear down all of jQM as it shows a page via an HTTP request.

1. The CSS-based approach: We create a new class (ui-btn-active-remove - naming is up for discussion, of course) that is a CSS transition which basically negates the modifications introduced by ui-btn-active, but does so after a while. We apply this class during nav's click handler, when we determine that following the link would result in HTTP navigation. A central sumbit handler similar to the click handler might have to be added so we can also deal with form buttons that have had ui-btn-active added to them. We identified several consequences with this approach:

   1. The source page might become littered with applications of the class ui-btn-active-remove if the user repeatedly navigates over HTTP, then returns to the jQM page containing the HTTP links. The presence of these classes would have no visual effect, but it would be "unsightly". We could clean up during the click handler with a $( ".ui-btn-active-remove" ).removeClass( "ui-btn-active-remove" ) if that turns out not to be expensive. For browsers that do not support CSS transitions, the application of ui-btn-active-remove would have the effect of immediately removing the modifications applied by ui-btn-active, so for those browsers this issue would not be fixed.
   2. There might be bugs similar to the problems that prompted introduction of popup interruptible transitions. For example, there is a (Chrome) browser bug that was not filed whereby, when clicking an AJAX link from a popup that leads to another page and later returning to the page containing the popup, one would see the final stages of the popup's closing transition on the source page, even though the time interval during which the closing transition was supposed to complete is much shorter than the time spent on the page opened from the popup.
   3. The class ui-btn-active-remove might have to be themed, and we'll have to apply one of ui-btn-active-remove-[a-z] at the time of vclick.

   This approach hinges on the fact that we can essentially achieve the effect of removing .ui-btn-active by adding the class .ui-btn-active-remove and, furthermore, defining ui-btn-active-remove in such a way that, where browsers support CSS transitions, the transition is used to achieve the effect of removing ui-btn-active, and where browsers do not support CSS-transitions, the basic properties of the ui-btn-active-remove class will have the effect of removing ui-btn-active. @Wilto should be able to weigh in here.

2. The unload-based approach (as @jerone suggested): During the central click routing in jquery.mobile.navigation.js we make the determination as to whether we should handle a link via AJAX or whether we should let the browser handle it the normal way. At this point, if the decision is to let the browser handle it, we could add a one-shot unload handler that would remove the active state added during the central vclick handler the same way as the hashchange handler would remove such an active state. We might also have to introduce a central submit handler so as to add this one-shot unload handler for submit buttons as well.

   The challenge with this approach is that we must test that the unload event works reliably on all our supported platforms.

[jerone]

Just a small note on the unload-method; there is not much support for it (but this is almost 2 year old information): http://mscerts.programming4.us/programming/coding%20javascript%20for%20mobile%20browsers%20%28part%2010%29%20-%20event%20handling.aspx#title-ID0EH4AK

[gabrielschulhof]

OK, so we decided that #5337 is as far as we'll go. We're not gonna handle the case of links/buttons that result in HTTP requests. Feel free to re-open if you find another instance where internal navigation needs to result in a button that receives the active state right after it gets tapped on.

Otherwise, feel free to drop us a PR for the HTTP navigation case.