1894463 - https://comic.naver.com/index - mouse dragging does not trigger scroll

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P2)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: image.png

1. Open https://comic.naver.com/index
2. Find horizontally scrollable posters, like the attached image
3. Drag on images by mouse

Firefox: It triggers dragging the image
Chrome: The posters are scrolled

Comment 1

[Dennis Schubert [:denschub]]

I can drag the list if I click inbetween the images, so this is something related to the drag-and-drop feature of the image itself.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of a similar issue in Chrome

Are you sure this is firefox-specific?

Personally, I see essentially-the-same issue in Chrome: clicking and dragging the image triggers a drag-and-drop action rather than a scroll action. Here's a screencast. Just as Dennis observed, clicking-and-dragging the space between the images scrolls as-expected.

(The only difference is that the dragged thing seems to be a link-URL with some text in Chrome, whereas it's an image in Firefox.)

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Is that Chrome Canary? My Chrome stable 124 and Chrome dev 126 do not have that behavior, only Chrome Canary does.

Comment 4

[Daniel Holbert [:dholbert]]

I'm using Chrome dev 126.0.6452.3 (Official Build) dev (64-bit) on Linux.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast of Chrome 124 on Win11

It looks like the Chrome drag-and-drop behavior from comment 2 is intermittent on some configurations, FWIW.

It was quite reliably-reproducing for me in comment 2, whereas I can reproduce it sometimes in Chrome release on Windows 11, though there I more-often seem to get the desired drag-to-scroll behavior. (And sometimes a drag changes from the desired to the not-desired behavior, partway through a click-and-drag action.

Here's a screencast where I'm repeatedly clicking and dragging, in Chrome 124 release on Windows 11. Most of the drag actions are "good", but some of them (particularly one near the beginning and one near the end of the screencast) are "bad" and become a link-dragging operation partway through.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Interesting, I can never see the link dragging behavior on the same dev build nor on stable channel on Windows 11 22631.3447, while it always happens on Canary. 🤔

Comment 7

[Daniel Holbert [:dholbert]]

I see the same "bad" dragging behavior in WebKit (gnome-web/epiphany) on Linux, too (in that case, I see a dragged piece-of-paper icon, which seems to be a dragged link).

So I think this is just a site bug on that affects all browsers to varying amounts, depending on some as-yet-not-understood race conditions and/or configuration.

Possibly this should just be closed as INVALID? (Not sure what we do for Site Report bugs that affect all browsers.)

I'm not sure it's worth spending too much more time investigating here given that the badness is reproducible to varying amounts in all browsers (except to find-and-suggest possible fixes to the site to improve behavior in all browsers, if someone wants to do that :) ).

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

This is bug 1674658.

1. Monkeypatch MouseEvent's preventDefault by MouseEvent.prototype.preventDefault = function (...args) { console.trace(); return UIEvent.prototype.preventDefault.call(this, args); }
2. Try the pan-scroll-by-mouse
3. You see preventDefault is called
4. Now try data:text/html,<img src="https://image-comic.pstatic.net/webtoon/822877/thumbnail/thumbnail_IMAG21_40f40cab-4f5e-4c19-bfae-89de05f28b54.jpg" onmousemove="event.preventDefault()"> and see whether the default image dragging behavior is prevented
5. Mystery solved 🙂 No need to mark it as INVALID.

I don't think this affects all browsers, do you see the same intermittent behavior on step 4? Your Chrome behavior is weird enough that worth a Chromium bug 🤔

Comment 9

[Daniel Holbert [:dholbert]]

I see the same behavior in Chrome dev 126, Firefox Nightly 127, and epiphany/gnome-web (WebKit) 42.4

Specifically:

• When viewing https://comic.naver.com/index , after pasting your MouseEvent.prototype.preventDefault snippet into DevTools: when I click and slowly drag an image, I see logging for preventDefault being called for a bit, and then at the moment that the default drag-and-drop action is triggered, the logging stops.

• All browsers behave the same for me on step 4 too; clicking and dragging the image triggers a regular drag-and-drop operation with a preview of the image. (If I paste the MouseEvent.prototype.preventDefault snippet into DevTools, I get a few events logged as my drag starts, and then the logging stops until I release the mouse.)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screencast showing consistent behavior between browsers on data URI from comment 8

Here's a screencast showing what I'm seeing, with the data URI in comment 8 (with consistent behavior between browsers as far as I can tell). This screencast shows me using Firefox Nightly, then Chrome, then Epiphany.

One note for interpretation purposes: unfortunately my screencast doesn't show any visual feedback when I click, so as a hint about when clicks are happening, in most cases I held my mouse frozen in place for a few moments after clicking, as I prepare to start a drag operation.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Kagami Rosylight [:saschanaz] (they/them) (OOO until 2024-05-10) from comment #8)

This is bug 1674658.

FWIW, I'm seeing all browsers behave the same on that bug's testcase (Chrome 124 release does differ, but 125beta & 126dev match Firefox/WebKit). See bug 1674658 comment 16 - 17.

So as far as my testing is showing, it sorta looks like this site's horizontal-draggable-scrolling widget only works with Chrome's "old" behavior (which is in Chrome <=124 based on my testing), though no browser has that behavior anymore, maybe (modulo the differences you're seeing).

Having said that, it's still a bit confusing if you're still seeing "good" behavior in Chrome 126 dev -- maybe there's just some A/B testing going on with feature rollout? :)

Comment 12

[Kagami Rosylight [:saschanaz] (they/them)]

maybe there's just some A/B testing going on with feature rollout? :)

I found this 2023 Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/fyVzOAmQHzU

tl;dr: Google wants to ship our behavior and it's now riding the train: https://source.chromium.org/chromium/chromium/src/+/165b28d3f3e0e6f66fd680e39d751830afb0ed7d

Once it ships and never backs out, I think we can WONTFIX both this and bug 1674658.

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

Now it's all clear to me, big thank you Daniel for continuous investigation! A/B test sometimes really makes things hard to understand 😅

Comment 14

[Daniel Holbert [:dholbert]]

Hooray! Thanks for tracking down the Chromium change. I'm glad everything makes sense. :)

Comment 15

[Jeff Muizelaar [:jrmuizel]]

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #12)

Once it ships and never backs out, I think we can WONTFIX both this and bug 1674658.

Can we close this now?

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

Chrome now behaves same, so closing 🎉👍