Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
lentz opened this Issue · 8 comments

4 participants

Jesse Lentz Anne-Gaelle Colom Jasper de Groot pupvogel
Jesse 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.

Anne-Gaelle Colom
Collaborator

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

Jasper de Groot

@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?

Jesse 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

Anne-Gaelle Colom
Collaborator

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

Jasper de Groot jaspermdegroot closed this issue from a commit
Jasper de Groot 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
Jasper de Groot jaspermdegroot referenced this issue from a commit
Jasper de Groot 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.

Jasper de Groot

@pupvogel - Thanks. Looking into it now.

Jasper de Groot jaspermdegroot referenced this issue from a commit
Jasper de Groot 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
Jasper de Groot jaspermdegroot referenced this issue from a commit
Jasper de Groot 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
Jasper de Groot

@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
Something went wrong with that request. Please try again.