swiper icon indicating copy to clipboard operation
swiper copied to clipboard

`navigation-hide-on-click="true"` hides navigation when clicking nextEl/prevEl

Open techfg opened this issue 1 year ago • 2 comments

Check that this is really a bug

  • [X] I confirm

Reproduction link

https://codesandbox.io/p/sandbox/swiper-element-navigation-hide-on-click-repro-3x4w6c

Bug description

With navigation-hide-on-click="true", clicking on navigation elements results in the navigation elements toggling hidden/visible.

In reviewing the target of the event passed to the listener, it is always the swiper-container and not the navigation element (when nav element was clicked) resulting in the internal checks failing to detect that the navigation element itself was clicked.

I am unable to reproduce this issue with Swiper Core - see identical configuration repro. When using Core, the "swiper" click event never fires when clicking a navigation element, whereas in Element, swiperclick fires.

One other note is that I noticed that each event fires twice (in both Element and Core). For example, when clicking a slide, click event fires twice and navigationHide/Show fires twice. This does seem odd but possibly expected behavior? As mentioned, this occurs in both Element & Core. The double event does not happen every time but it happens nearly every time.

Steps to reproduce:

  1. Open Element Repro
  2. Open dev tools console for preview window
  3. Click prev/next element
  4. Open Core Repro
  5. Open dev tools console for preview window
  6. Click prev/next element

Expected Behavior

  1. When clicking the navigation element itself, the navigation visibility should not change and the click event should not fire.
  2. Unclear if this is expected behavior or not but it does seem odd that events fire twice so mentioning it here just in case it is not expected behavior.

Actual Behavior

When clicking the navigation element directly, the navigation toggles visibility and each event fires twice.

Element Repro Console Log (event name / target id / event)

swiperclick swiper-repro CustomEvent {isTrusted: false}
swiperclick swiper-repro CustomEvent {isTrusted: false}
swipernavigationhide swiper-repro CustomEvent {isTrusted: false}
swipernavigationhide swiper-repro CustomEvent {isTrusted: false}

Core Repro Console Log (event name / swiper instance)

swipernavigationnext {__swiper__: true, support: Object, device: Object, browser: Object, eventsListeners: Object, …}
swipernavigationnext {__swiper__: true, support: Object, device: Object, browser: Object, eventsListeners: Object, …}

Swiper version

11.1.3

Platform/Target and Browser Versions

Windows Edge Version 125.0.2535.51, Windows Chrome Version 125.0.6422.112, Firefox 126.0

Validations

  • [X] Follow our Code of Conduct
  • [X] Read the docs.
  • [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
  • [X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

  • [ ] I'm willing to open a PR

techfg avatar May 27 '24 11:05 techfg

t0ggles-create swiper

nolimits4web avatar May 27 '24 11:05 nolimits4web

Task nolimits4web/SWIPER-137 was created

t0ggles task SWIPER-137

t0ggles[bot] avatar May 27 '24 11:05 t0ggles[bot]

Task nolimits4web/SWIPER-137 status changed to Done

t0ggles[bot] avatar May 30 '24 09:05 t0ggles[bot]

Hello @nolimits4web -

Thanks for the quick turn on applying a fix for the navigation buttons, I've verified that the navigation buttons no longer toggle visibility when clicked when hideOnClick=true with v11.1.4.

Unfortunately, I'm still seeing what I believe are other issues as mentioned in the OP:

  1. The swiperclick event fires when the navigation button is clicked. This is different behavior than the Core version as the Core version does not fire the click event when a navigation button is clicked.
  2. Events (e.g., swiperclick, swipernavigationhide, etc.) are all firing twice - this happens in Core & Element

Let me know if you feel if these items are expected behavior and if not, happy to open a new issue to cover those.

Thank you!

techfg avatar May 30 '24 11:05 techfg