Clicking a currently active navbar tab removes ui-btn-active class and styling #5707

Closed
lentz opened this Issue Feb 27, 2013 · 8 comments

Projects

None yet

4 participants

@lentz

With the upgrade from 1.2.0 to 1.3.0, I've noticed that upon clicking an already active navbar tab, the active styling is removed from the tab and will not return upon further clicks. In 1.2.0, clicking the currently active navbar tab would do nothing to the styling of that tab (the ui-btn-active class would persist).

Test page using jQuery Mobile 1.3 and jQuery 1.9: http://jsbin.com/onibuc/286/edit

  1. Notice that the "Page 1" tab is already selected via the ui-btn-active and ui-state-persist classes as described in the docs.
  2. Click the "Page 1" tab and note that it turns from blue to gray, and it's ui-btn-active class is removed.
  3. The same behavior can be observed by clicking the "Page 2" tab, which will turn blue and switch to page 2 after the first click, and then turn gray and lose its active state upon subsequent clicks.

I would expect subsequent clicks of the currently active tab to have no visual effect on the page. I've reproduced this behavior on the desktop with Chrome 25, as well as iOS 6 and Android 4.0.

Looking through the code, I believe this issue is related to the fix for issue #1181 which removes the active class from the active nav button when the pagechange event is fired. Clicking an already active page in the navbar seems to fire pagechange, and cause the active tab to lose the active class.

@agcolom
jQuery Foundation member

@lentz is it fixed for you in http://jsbin.com/onibuc/287/edit
(I think you can solved that by making the link to the current page as # instead of #page1)

Please let me know if this is ok for you.

@jaspermdegroot
jQuery Foundation member

@lentz

Thanks for the issue report.

This is a regression from this fix: #4579
The actual problem is that the pagechange event fires when you click on a link to the same page: http://jsbin.com/onibuc/288

@johnbender - Is that something we can avoid?

@lentz

@agcolom Yes - it is fixed when "#" is used as the href of for the current page. I was hoping to not have to do that, since we are using the same code for our navbar on all pages (while only changing which nav option gets the ui-btn-active on a given page).

It can also be seen on the persistant navbar demo page: http://jquerymobile.com/demos/1.3.0/docs/widgets/navbar/footer-persist-a.html

@agcolom
jQuery Foundation member

@lentz yes, hopefully this is something that can be fixed. let's see what @johnbender says.

@jaspermdegroot jaspermdegroot added a commit that closed this issue Apr 1, 2013
@jaspermdegroot jaspermdegroot Navbar: Changed active state logic. Fixes #5707
Removed workaround for #1181. Fixed that issue by addressing the actual cause: event.target returns ui-btn-inner instead of the anchor
70e2aed
@jaspermdegroot jaspermdegroot added a commit that referenced this issue Apr 1, 2013
@jaspermdegroot jaspermdegroot Navbar: Changed active state logic. Fixes #5707
Removed workaround for #1181. Fixed that issue by addressing the actual cause: event.target returns ui-btn-inner instead of the anchor
440f7c0
@pupvogel

@uGoMobi Since yesterdays commit a clicked navbar-tab (which is not a link to another page) doesn't get the active state anymore. 'ui-btn-active' is just removed from all of the tabs.

@jaspermdegroot
jQuery Foundation member

@pupvogel - Thanks. Looking into it now.

@jaspermdegroot jaspermdegroot added a commit that referenced this issue Apr 1, 2013
@jaspermdegroot jaspermdegroot Navbar: make sure nav buttons with href="#" still get active state.
This fixes a regression from the fix for #5707. That issue was a regression from the fix for #1181. I added the workaround for #1181 again but changed the event to avoid the regression.
307ff5e
@jaspermdegroot jaspermdegroot added a commit that referenced this issue Apr 1, 2013
@jaspermdegroot jaspermdegroot Navbar: make sure nav buttons with href="#" still get active state.
This fixes a regression from the fix for #5707. That issue was a regression from the fix for #1181. I added the workaround for #1181 again but changed the event to avoid the regression.
cf54b98
@jaspermdegroot
jQuery Foundation member

@pupvogel - Can you confirm that it is working as expected now? Thanks!

@pupvogel

@uGoMobi yep, works for me, thanks !!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment