1123067 - "addEventLister" and "user-select: none"

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[abolfazl]

User Agent: Mozilla/5.0 (Windows NT 6.2; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

keys ← ↑ ↓ → not be work when using "user-select: none".
http://jsfiddle.net/b6Lb96h1/



Actual results:

in new version 35.0
my project after update(to 35.0) moz not be work

Comment 1

[Mats Palmgren (inactive)]

Regression from bug 739396 maybe?

Comment 2

[:Gijs (he/him)]

(In reply to Mats Palmgren (:mats) from comment #1)
> Regression from bug 739396 maybe?

Looks like it broke earlier. Still narrowing this down further...

Comment 3

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #2)
> (In reply to Mats Palmgren (:mats) from comment #1)
> > Regression from bug 739396 maybe?
> 
> Looks like it broke earlier. Still narrowing this down further...

I get to eat my words - sorry, I seem to have made a mistake in my testing. Re-testing, and yes, it might be this bug.

Comment 4

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=152ef25e89ae&tochange=98ea98c8191a

So yeah, bug 739396 seems plausible.

Note that even before bug 739396, in the testcase the reporter linked to, I don't seem able to navigate to the part of the div past the <br>. I'm not sure why.

Comment 5

[abolfazl]

ooops ! this is a bug or not ?

Comment 6

[abolfazl]

(In reply to Mats Palmgren (:mats) from comment #1)
> Regression from bug 739396 maybe?

thanks.

because in last version of moz this be work correctly. but in new version of moz my project does not work! I'm wrong? or this is a bug ?

Comment 7

[Mats Palmgren (inactive)]

Yes, I think this is a bug and I'm working on a fix.  Meanwhile, can you tell us a little bit
about your project and what you are using "user-select: none" for?  (It's good for us to know
how features are used so we can make sure we don't break those use cases.)

Comment 8

[abolfazl]

i am a php programmer and me have not enough about client programmer(js,css,html and etc ...) 
But I know a little bit of everything(js,css,html and etc ...).
i using "user-select" for private console program in my project and this is like cmd in windows (only like).
for example user(or admin) cannot be selected or drag of text.

Comment 9

[Mats Palmgren (inactive)]

Attachment: part 1, fix

This allows us to have a caret inside a user-select:none editable node.

Comment 10

[Mats Palmgren (inactive)]

Attachment: part 2, tests

https://treeherder.mozilla.org/#/jobs?repo=try&revision=34b429184ac9

Comment 11

[abolfazl]

thanks you Mats :)

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8556715 [details] [diff] [review]
part 1, fix

I'm probably missing something here...
Why always append aItem. Don't we want to check if aItem is collapsed and only then add it?

Comment 13

[Mats Palmgren (inactive)]

Comment on attachment 8556715 [details] [diff] [review]
part 1, fix

(In reply to Olli Pettay [:smaug] from comment #12)
> Why always append aItem. Don't we want to check if aItem is collapsed and
> only then add it?

If we requiring aItem to be collapsed the bug would still occur for
Shift+Arrow etc.  While that seems like an extreme edge case, I don't
see any reason to not fix it in the same way.  In general, the caret
is at the end of the range whether it is collapsed or not.  That's
why I think collapsing and adding the range is the right behavior
in an editable, but non-selectable, context.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

well shift+arrow shouldn't work, right? shift+arrow should extent the current selection and if it doesn't do that, why should selection move?

Comment 15

[Mats Palmgren (inactive)]

> well shift+arrow shouldn't work, right?

Fair enough.  It seems like a separate bug though, and in the meanwhile I think
this behavior is reasonable.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8556715 [details] [diff] [review]
part 1, fix

This is weird but fine.

Comment 17

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ea4ea5299409
https://hg.mozilla.org/integration/mozilla-inbound/rev/d35d83e9c9f2

Comment 18

[Mats Palmgren (inactive)]

(Filed bug 1128730 to follow-up on comment 14 / 15)

Comment 19

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/74c73eb6ee73 for mochitest-5 bustage:

https://treeherder.mozilla.org/logviewer.html#?job_id=6188634&repo=mozilla-inbound

It also broke the test on B2G Linux Desktop: https://treeherder.mozilla.org/logviewer.html#?job_id=6186621&repo=mozilla-inbound

Comment 20

[Mats Palmgren (inactive)]

I disabled the bug1123067-1.html part of the test (not super-important anyway) and re-landed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b9692dccd0e7
https://hg.mozilla.org/integration/mozilla-inbound/rev/b3630a0f5b0d

Filed bug 1129205 on re-enabling that test.

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b9692dccd0e7
https://hg.mozilla.org/mozilla-central/rev/b3630a0f5b0d