starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Bug: ShortClick not recognized in chrome when scrolled down far enough #1450

New issue

Closed

opened 2026-02-20 00:12:49 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 00:12:49 -05:00

Owner

Originally created by @heikomat on GitHub (May 28, 2022).

What does not work as described in the documentation?

ShortClicking the slection-dot in the mosaic-view doesn't always work when having scrolled far enough.

How can we reproduce it?

Go to the mosaic view
Scroll far enough down (~1500 pictures)
Click on the selection-dot fast enough to be e short-click, but not too fast

I'm observing this behaviour in chrome, on a macbook pro, using the trackpad
This happens on a local version, but also on the current release-version of photoprism.
The Issue seems to be, that the event-timestamp of the click-event is smaller than the event-timestamp of the corresponding mousedown-event.

This does NOT happen on firefox.

Strangely enough, the clicks that don't result in toggling the selection are ALSO not recognized as click by the video-capture. This can be seen by the fact that a log appears without a circle appearing around the mouse. (On closer inspection, the circle can be seen on the buggy click before the last one)

This made me think that this is a macos issue, but that can't be, because firefox on the same machine does not show this behaviour.

This in turn made me think that this is an issue with chrome. But even if it is, fixing it photoprism is probably a lot easier.

What behavior do you expect?

if the item was selected, it should get unselected and vice versa

What could be the cause of your problem?

Maybe it has to do with the fact that i'm using a trackpad.
It could also be that chrome might be waiting to see if i make a double click?
Or it has to do with the reduced precision of event.timeStamp

Can you provide us with example files for testing, error logs, or screenshots?

Here's a video:

https://user-images.githubusercontent.com/20770029/170840368-3f9c5feb-61d1-45ab-9268-f5c1e39bcfb9.mp4

Note that the clicks that don't result in toggling the selection are ALSO not recognized as click by the video-capture. This can be seen by the fact that a log appears without a circle appearing around the mouse.

Which software versions do you use?

PhotoPrism Build 220527-005770ca and a local dev build
macOS 12.3.1
Chrome 101.0.4951.64
No Addons (icognito mode)

Originally created by @heikomat on GitHub (May 28, 2022). **What does not work as described in the documentation?** ShortClicking the slection-dot in the mosaic-view doesn't always work when having scrolled far enough. **How can we reproduce it?** 1. Go to the mosaic view 2. Scroll far enough down (~1500 pictures) 3. Click on the selection-dot fast enough to be e short-click, but not too fast I'm observing this behaviour in chrome, on a macbook pro, using the trackpad This happens on a local version, but also on the current release-version of photoprism. The Issue seems to be, that the event-timestamp of the click-event is smaller than the event-timestamp of the corresponding mousedown-event. This does NOT happen on firefox. ~~Strangely enough, the clicks that don't result in toggling the selection are ALSO not recognized as click by the video-capture. This can be seen by the fact that a log appears without a circle appearing around the mouse.~~ (On closer inspection, the circle can be seen on the buggy click before the last one) This made me think that this is a macos issue, but that can't be, because firefox on the same machine does not show this behaviour. This in turn made me think that this is an issue with chrome. But even if it is, fixing it photoprism is probably a lot easier. **What behavior do you expect?** if the item was selected, it should get unselected and vice versa **What could be the cause of your problem?** Maybe it has to do with the fact that i'm using a trackpad. It could also be that chrome might be waiting to see if i make a double click? Or it has to do with the [reduced precision](https://developer.mozilla.org/en-US/docs/Web/API/Event/timeStamp#reduced_time_precision) of event.timeStamp **Can you provide us with example files for testing, error logs, or screenshots?** Here's a video: https://user-images.githubusercontent.com/20770029/170840368-3f9c5feb-61d1-45ab-9268-f5c1e39bcfb9.mp4 Note that the clicks that don't result in toggling the selection are ALSO not recognized as click by the video-capture. This can be seen by the fact that a log appears without a circle appearing around the mouse. **Which software versions do you use?** - PhotoPrism Build 220527-005770ca and a local dev build - macOS 12.3.1 - Chrome 101.0.4951.64 - No Addons (icognito mode)

deekerman

2026-02-20 00:12:49 -05:00

closed this issue
added the
frontend

ux
labels

deekerman commented

2026-02-20 00:12:50 -05:00

Author

Owner

@lastzero commented on GitHub (May 28, 2022):

Probably because we manually handle the timing of click events so that a long/short click can be distinguished in mobile Safari. I'm in a hurry right now, but you should be able to find the related/closed GitHub issue with these keywords. It's a bit of a hack, but I haven't found a better solution that works on all browsers.

I won't have time to experiment further in the near future. So if anyone has a solution that works on all browsers AND devices while avoiding the problem reported in this ticket, let us know! 😉

@lastzero commented on GitHub (May 28, 2022): Probably because we manually handle the timing of click events so that a long/short click can be distinguished in mobile Safari. I'm in a hurry right now, but you should be able to find the related/closed GitHub issue with these keywords. It's a bit of a hack, but I haven't found a better solution that works on all browsers. I won't have time to experiment further in the near future. So if anyone has a solution that works on all browsers AND devices while avoiding the problem reported in this ticket, let us know! 😉

deekerman commented

2026-02-20 00:12:50 -05:00

Author

Owner

@lastzero commented on GitHub (Jul 7, 2022):

Is this still an issue (that should remain open)?

@lastzero commented on GitHub (Jul 7, 2022): Is this still an issue (that should remain open)?

deekerman commented

2026-02-20 00:12:50 -05:00

Author

Owner

@heikomat commented on GitHub (Aug 11, 2022):

Haven't rechecked, but assuming that it's because of the weird event timestamps, this is probably still an issue (as I haven't seen anything related to that getting changed).

Luckily this should be super easy to test. will check that when I'm back home in about an hour

@heikomat commented on GitHub (Aug 11, 2022): Haven't rechecked, but assuming that it's because of the weird event timestamps, this is probably still an issue (as I haven't seen anything related to that getting changed). Luckily this should be super easy to test. will check that when I'm back home in about an hour

deekerman commented

2026-02-20 00:12:50 -05:00

Author

Owner

@heikomat commented on GitHub (Aug 11, 2022):

Nope, can no longer reproduce the issue. Maybe chrome has fixed something regarding event timestemaps?

Closed -> no longer reproducible

@heikomat commented on GitHub (Aug 11, 2022): Nope, can no longer reproduce the issue. Maybe chrome has fixed something regarding event timestemaps? Closed -> no longer reproducible

deekerman commented

2026-02-20 00:12:50 -05:00

Author

Owner

@graciousgrey commented on GitHub (Aug 11, 2022):

Thanks for testing and all the other work you do ❤️

@graciousgrey commented on GitHub (Aug 11, 2022): Thanks for testing and all the other work you do ❤️

deekerman referenced this issue

2026-02-20 01:01:40 -05:00

Plugin System: REST API and Webhook based Plugin System #1874