648624 - -moz-user-select doesn't propagate to child nodes with a position absolute/fixed

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Michael Putters]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 Gecko/20100101 Firefox/4.0

When a DOM element has a style -moz-user-select : none;, its text cannot be selected. If nodes contained in that DOM element have a "normal" positioning (eg relative), they inherit the style. If they have an absolute or fixed positioning, they don't.

Reproducible: Always

Steps to Reproduce:
cf URL with test-case (body with -moz-user-select : none and various divs with different position style).
Actual Results:  
The first div (with position : relative) cannot be selected
The second div (with position : absolute) can be selected
The third div (with position : fixed) can be selected

Expected Results:  
No text should be selected

Behavior of -webkit-user-select is similar to what I describe in "expected results".

Comment 1

[Boris Zbarsky [:bzbarsky]]

Olli, what's up here?

Comment 2

[Michael Putters]

Any news on this? (at least to know if it's considered a bug or not)

Comment 3

[Boris Zbarsky [:bzbarsky]]

That's what the question in comment 1 is about, yes.  -moz-user-select is not an inherited CSS property, so it's not actually directly applied to any of the divs above.  I'm guessing that we check up the box tree for the property; perhaps we should be checking up the content tree instead...

And in particular, nsFrame::IsSelectable indeed walks the frame parent chain.  Should it walk back through placeholders instead?

In particular, should something like this:

  <span style="-moz-user-select: none;">
    <span style="float:left">Is this selectable?</span>
  </span>

be selectable?

Comment 4

[(no longer active)]

(In reply to comment #3)
> In particular, should something like this:
> 
>   <span style="-moz-user-select: none;">
>     <span style="float:left">Is this selectable?</span>
>   </span>
> 
> be selectable?

That would certainly be the intention of the author, I assume.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Which?  That it be selectable?  Or that it not be selectable?

Comment 6

[Boris Zbarsky [:bzbarsky]]

If you mean the latter, what about a run-in that runs into a -moz-user-select:none block?  Should we just be walking the content tree instead of the frame tree?

Comment 7

[(no longer active)]

(In reply to comment #6)
> If you mean the latter, what about a run-in that runs into a
> -moz-user-select:none block?  Should we just be walking the content tree
> instead of the frame tree?

I meant the latter...  But you just made the question a lot harder!

When you're writing HTML code, you generally don't have an idea what the frame tree is going to look like.  So I think basing this type of behavior on the frame tree is wrong.

But then again, only walking the content tree also seems to produce the wrong result when the user is interacting with the page (where effectively only the frame tree matters).

I'm kind of lost between these two worlds, and can't think of an option which keeps them both sane.  :/

Comment 8

[Michael Putters]

How about this (ok, it's user-select, not -moz-user-select, but still):

http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select (4th paragraph):

This property is not inherited, but it does affect children in the same way that display: none does, it limits it. That is if an element is user-select: none, it doesn't matter what the user-select value is of its children, the element's contents or it's childrens contents cannot be selected.

Comment 9

[Michael Putters]

Also, since there is none and -moz-none (to overcome the description above, I suppose), it'd kinda make sense if the child nodes were not selectable...
https://developer.mozilla.org/en/CSS/-moz-user-select

Comment 10

[Boris Zbarsky [:bzbarsky]]

The link in comment 8 doesn't necessarily help since back then (well, and now too, thanks to certain WG members) CSS did not really distinguish between ancestry along the element tree and ancestry along the box tree, even though they can be pretty different.

In any case, the simple change here would be to go through the placeholder's parent for out-of-flows, I think.  Ehsan, does that sound ok?

Comment 11

[(no longer active)]

(In reply to comment #10)
> The link in comment 8 doesn't necessarily help since back then (well, and now
> too, thanks to certain WG members) CSS did not really distinguish between
> ancestry along the element tree and ancestry along the box tree, even though
> they can be pretty different.
> 
> In any case, the simple change here would be to go through the placeholder's
> parent for out-of-flows, I think.  Ehsan, does that sound ok?

Probably.  But I still don't think that's the ideal solution (not saying that I have a better suggestion).

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we should do it.

Comment 13

[(no longer active)]

I probably won't have time to work on this for now...

Comment 14

[Mats Palmgren (inactive)]

I fixed this in bug 1129356.