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".
Olli, what's up here?
Component: DOM: CSS Object Model → Selection
QA Contact: style-system → selection
Any news on this? (at least to know if it's considered a bug or not)
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
Which? That it be selectable? Or that it not be selectable?
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?
(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. :/
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.
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
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?
(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).
I think we should do it.
I probably won't have time to work on this for now...
I fixed this in bug 1129356.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Depends on: 1129356
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.