1376369 - -moz-user-select:none triggers dragging also when @draggable="false"

Status: NEW

(Core :: DOM: Selection, defect, P3)

Description

[Mats Palmgren (inactive)]

Attachment: Testcase

STR
1. drag the image (which has -moz-user-select:none and draggable="false")

ACTUAL RESULTS
dragging works as if it had draggable="true"

EXPECTED RESULTS
Neither a selection, nor a drag operation, should be initiated
when trying to drag this image.

I suspect the bug is in the Selection code where we normally
initiate the drag-selection operation.  We probably check for
-moz-user-select:none there and fall back to dragging behavior.
We need to check element->Draggable() there first.

Comment 1

[stephane.jacquet]

+1

Comment 2

[Daniel Holbert [:dholbert]]

This seems to be a regression, and I get this regression range:
 6:12.80 INFO: Last good revision: 8f57f60ee58a (2015-04-09)
 6:12.80 INFO: First bad revision: fec90cbfbaad (2015-04-10)
 6:12.80 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f57f60ee58a&tochange=fec90cbfbaad

Comment 3

[Daniel Holbert [:dholbert]]

BTW, I double-checked that regression range with Mats' testcase as well as with my just-a-link jsfiddle (no images), https://jsfiddle.net/pmfLdr8x/

Comment 4

[Daniel Holbert [:dholbert]]

Aha -- so in that range, this would've regressed from bug 936092:
> 1eec2c8789c1	Olli Pettay — Bug 936092, initial DnD support for e10s, r=enndeakin,karlt

("DnD" = Drag n Drop)

Smaug, maybe you could take a look?

Comment 5

[James B]

Is there a workaround while waiting for a fix? I have an element that I'd like to be able to click, but not drag or select. It works fine in any other browser, but in Firefox I have to pick one of those two to prohibit and allow the other one, which is a bad user experience.

Comment 6

[James B]

Also, trackback to bug 1326143, which is probably the same thing?

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

You can currently preventDefault on mousedown event to workaround this, but it's not ideal... Hopefully this bug can be fixed.

Comment 8

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 9

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 10

[chris]

(In reply to Daniel Holbert [:dholbert] from comment #4)

Aha -- so in that range, this would've regressed from bug 936092:

1eec2c8789c1 Olli Pettay — Bug 936092, initial DnD support for e10s, r=enndeakin,karlt

("DnD" = Drag n Drop)

Smaug, maybe you could take a look?

So, this is affecting Google, Netflix, a considerable number of users of our software and no doubt countless thousands of other users in other applications across the world.

Can we please get the priority of this bumped up considerably and ensure it gets the attention it deserves?

Comment 12

[Clara Guerrero ( Need Info Brindusa Tot Please)]

HI,

Thanks for the details. I was able to reproduce on windows 10 pro, on the following versions

Firefox Nightly Nightly 77.0a1 (2020-04-08) (64-bit)
Beta 76.0b1 (64-bit)
Release 75.0 (64-bit)

I will update flags accordingly.

Best,
Clara

Comment 13

[jackj106gamesofficial]

A temporary workaround:

if (window.navigator.userAgent.toLowerCase().includes("firefox")) {
  document.querySelectorAll("img[draggable=false]").forEach((el) => {
    el.addEventListener("mousedown", (event) => event.preventDefault());
  });
}

Comment 14

[davecrawley]

(In reply to chris from comment #10)

I second the motion to get this bumped up in priority - in our case it causes a safety issue (like real human injury could occur - type safety). We have a web based control of a commercially available robot where a button causes the robot to drive forward. Under firefox the button, in effect, gets stuck and the robot drives off in to the distance and can and has crashed, and I don't mean the computer just went down.

(In reply to Daniel Holbert [:dholbert] from comment #4)

Aha -- so in that range, this would've regressed from bug 936092:

1eec2c8789c1 Olli Pettay — Bug 936092, initial DnD support for e10s, r=enndeakin,karlt

("DnD" = Drag n Drop)

Smaug, maybe you could take a look?

So, this is affecting Google, Netflix, a considerable number of users of our software and no doubt countless thousands of other users in other applications across the world.

Can we please get the priority of this bumped up considerably and ensure it gets the attention it deserves?

Comment 15

[Karl Dubost💡 :karlcow]

P3 based on the fact we have a couple of reports for now. But the comment #14 is very unfortunate indeed.
If people in this bug have examples of more cases on real websites, that would be cool to know about them, to better understand the next course of actions.

Comment 16

[faeldihn]

I'm new on bugzilla but, as a firefox addict, I follow the question for a long time now.
My point is: since you allow <img draggable="false" ... /> the guy who really wants to prevent it can.
But in his site where he will have to make it for each img block and each generated img object, webkit solution allows it one-line quite simply where moz doesn't.
It is not a question of making img "impossible to drag by default", like it was repeatedly objected years ago, but simply allowing to prevent it with a simple line where it currently requires typing it in every concerned html object, just for firefox.

As for this very page header-external-menu-button, and other pop-up able images of the header, its image is not draggable while not pop-up ones are (browse, search, ...).
I happen to browse number of images and, as quite a long time interface designer, it feels more like an unexpected side-effect than a really wanted feature, and the result is a feeling of incoherence.
Personally, I force draggable="false" in the body which makes the same, but it breaks my W3C xhtml validation for it's not a body attribute.

Allow KISS principle, please.
Respectfully.

A stupid.

Comment 17

[faeldihn]

(In reply to faeldihn from comment #16)

I'm new on bugzilla but, as a firefox addict, I follow the question for a long time now.
My point is: since you allow <img draggable="false" ... /> the guy who really wants to prevent it can.
But in his site where he will have to make it for each img block and each generated img object, webkit solution allows it one-line quite simply where moz doesn't.
It is not a question of making img "impossible to drag by default", like it was repeatedly objected years ago, but simply allowing to prevent it with a simple line where it currently requires typing it in every concerned html object, just for firefox.

As for this very page header-external-menu-button, and other pop-up able images of the header, its image is not draggable while not pop-up ones are (browse, search, ...).
I happen to browse number of images and, as quite a long time interface designer, it feels more like an unexpected side-effect than a really wanted feature, and the result is a feeling of incoherence.
Personally, I force ondragstart="return false" in the body which makes the same, but it breaks my W3C xhtml validation for it's not a body attribute.

Allow KISS principle, please.
Respectfully.

A stupid.