getSelection returns too much.
John J Barton
right click. If you pick copy or Add Watch, the line numbers are copied
as well as the source text.
Firebug is just using:
var selection = this.document.defaultView.getSelection().toString();
which I can understand would lead to the result above, since the line
number node would be between the anchor and focus points of any multiple
line selection.
But in the UI, the line numbers do not appear to be selected. Why?
If the line numbers did appear to be selected, users would probably not
be surprised when they appear in the result.
I would like to just get the source. I can figure out how to do it, but
if someone has a clever way, please speak up.
jjb
Boris Zbarsky
> But in the UI, the line numbers do not appear to be selected. Why?
Insufficient information to answer the question. What's the markup for
the line numbers?
> If the line numbers did appear to be selected, users would probably not
> be surprised when they appear in the result.
>
> I would like to just get the source. I can figure out how to do it, but
> if someone has a clever way, please speak up.
That really depends on the markup question above.
-Boris
John J. Barton
> John J Barton wrote:
>> But in the UI, the line numbers do not appear to be selected. Why?
>
> Insufficient information to answer the question. What's the markup for
> the line numbers?
>
<div class="sourceRow">
<a class="sourceLine"> 5</a>
<span class="sourceRowText">if(!Array.prototype.shift)</span>
</div>
The selection includes sourceRowText but not sourceLine.
>> If the line numbers did appear to be selected, users would probably
>> not be surprised when they appear in the result.
>>
>> I would like to just get the source. I can figure out how to do it,
>> but if someone has a clever way, please speak up.
>
> That really depends on the markup question above.
I solved this part by the iterating the nodes, thanks. So now the right
thing happens but the selection is only accidentally correct.
jjb
Boris Zbarsky
>> Insufficient information to answer the question. What's the markup
>> for the line numbers?
>>
>
> <div class="sourceRow">
> <a class="sourceLine"> 5</a>
> <span class="sourceRowText">if(!Array.prototype.shift)</span>
> </div>
>
> The selection includes sourceRowText but not sourceLine.
That's quite odd; I can't reproduce that in the following html snippet:
<!DOCTYPE html>
<body>
<div>
<a>1</a>
<span>First line</span>
</div>
<div>
<a>2</a>
<span>Second line</span>
</div>
</body>
If I select both "First line" and "Second line", then the "2" is
selected and drawn so. What's different about your case? What's the
CSS applied to your markup, for example?
-Boris
John J. Barton
Oh:
.sourceLine {
-moz-user-select: none;
margin-right: 10px;
border-bottom: 1px solid #EEEEEE;
border-right: 1px solid #CCCCCC;
padding: 0px 4px 0 20px;
background: #EEEEEE no-repeat 2px 0px;
color: #A0A0A0;
white-space: pre;
}
So "-moz-user-select: none" causes the UI not to show the select. But
what about Selection? Maybe that is what the "range" stuff is about? I
couldn't make out what that part was for.
https://developer.mozilla.org/En/DOM/Selection
jjb
Boris Zbarsky
> So "-moz-user-select: none" causes the UI not to show the select.
Yep. And also makes it impossible to select that text directly.
> But what about Selection? Maybe that is what the "range" stuff is about?
Yes. In this case, the selection is set by clicking somewhere and
dragging somewhere else. Everything between "somewhere" and "somewhere
else" in the DOM ends up in the selection, including things that can't
be selected on their own (display:none content, your line numbers, etc).
It does lead to some pretty counterintuitive behavior in some cases, of
course.
-Boris
John J. Barton
Ok, thanks. So then there must be a bug in Firefox's cmd_copy? Does it
correctly deal with the range stuff? Firebug uses cmd_copy in its Copy
operation (at least I think), which incorrectly selects the line
numbers. I tried to find the source in mxr but got lost.
jjb
Boris Zbarsky
> Ok, thanks. So then there must be a bug in Firefox's cmd_copy?
How does that follow from what I said?
> Does it correctly deal with the range stuff?
It takes the selection's current ranges and serializes them. That's
certainly what it's doing in your case...
> Firebug uses cmd_copy in its Copy
> operation (at least I think), which incorrectly selects the line
> numbers. I tried to find the source in mxr but got lost.
Please do read what I said: the line numbers are in the range than
nsSelection creates. The just don't _draw_ selected due to the styling.
But they're in the range.
-Boris
John J. Barton
...
> Please do read what I said: the line numbers are in the range than
> nsSelection creates. The just don't _draw_ selected due to the styling.
> But they're in the range.
Ok let me try again. Consider this case:
<div class="sourceRow">
<a class="sourceLine"> 5</a>
<span class="sourceRowText">if(!Array.prototype.shift)</span>
</div>
<div class="sourceRow">
<a class="sourceLine"> 6</a>
<span class="sourceRowText">return;</span>
</div>
with
.sourceLine {
-moz-user-select: none;
}
If the user selects from "if( ... return;" then what is the correct
result of Copy?
The user sees the source code selected. The user does not see the line
number '6' selected. This is correct because of -moz-user-select: none.
However the clipboard entry includes the line number 6. This is a bug:
the user cannot select the 6 and should not see it in the buffer,
whether or not the selection runs over elements that have the line number.
I can work around this in Firebug, but it seems like a bug in Firefox.
jjb
Boris Zbarsky
> If the user selects from "if( ... return;" then what is the correct
> result of Copy?
That's a philosophical question, depending on the precise definition of
"-moz-user-select: none". At the moment, the only definition in
existence is "what Gecko does with it".
> The user sees the source code selected. The user does not see the line
> number '6' selected. This is correct because of -moz-user-select: none.
Sure.
> However the clipboard entry includes the line number 6. This is a bug:
No, it's the expected behavior of "-moz-user-select:none" in this case.
Sorry, but that's how things are.
Now if the proposal is to change the way "-moz-user-select: none" should
work that's a separate issue, but that has compat issues, of course.
> the user cannot select the 6 and should not see it in the buffer,
> whether or not the selection runs over elements that have the line number.
Note that you'd get the same issue if you just use "display: none". The
fact is, selection in Gecko works on the DOM. What the user sees is
only very loosely related to the DOM (CSS can affect the order things
appear in, as can BiDi, CSS generated content is visible but not present
in the DOM, XBL anonymous content is visible but not present in the DOM,
background images look just like normal images but can't be copied
because not present in the DOM, etc, etc).
One could argue that this is just a broken-by-design selection setup.
I'd tend to agree; if someone wants to rewrite selection from scratch
please do that.
-Boris
John J Barton
>
> One could argue that this is just a broken-by-design selection setup.
> I'd tend to agree; if someone wants to rewrite selection from scratch
> please do that.
In the meantime, -moz-user-select: none; should not be used in my
opinion. It causes the user interface to 'lie' to users about the result
of copy/cut operations.
jjb
John J Barton
Well, I take it partly back: now that Firebug is analyzing the selection
to get the part that the user wants, the style setting is what I want.
I updated the MDC page https://developer.mozilla.org/En/CSS/-moz-user-select
jjb
Boris Zbarsky
> In the meantime, -moz-user-select: none; should not be used in my
> opinion.
I can only support not using any of the -moz-user-* styles, for what
it's worth. They all have pretty weird behavior.
-Boris