317914 - window.getSelection().toString() not work properly (return empty string)

Status: RESOLVED DUPLICATE of bug 310241

(Core :: DOM: Core & HTML, defect)

Description

[Vladimir Yeryomin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8) Gecko/20051107 Firefox/1.5

On a test page select any test and press "Quote". In Mozilla1.0.7- and other browsers this function is work properly.

Reproducible: Always

Steps to Reproduce:
1. Select any text on testpage.
2. Press "Quote" link
3. See in textarea

Actual Results:  
In 1.5+ text not returned (by window.getSelection().toString())

Expected Results:  
Full quotation (return selected text by window.getSelection().toString())

Comment 1

[Vladimir Yeryomin]

Attachment: Testfile

Comment 2

[Ian Graham]

The testcase WFM on XP in Firefox 1.5 Beta 1 (or at least works the same as on MOzilla suite 1.7.2). Firefox version info:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

So potentially a regression since then??? 

Comment 3

[Sergey Sokoloff]

Ian, if you see [quote][nickname]testuser[/nickname]
and just [/quote] on the next line,
it's still the bug.

Comment 4

[zug_treno]

WFM with Mozilla 1.8a5 but reproducible with Mozilla 1.8a6 (and SeaMonkey 1.0a).

Comment 5

[Vladimir Yeryomin]

Attachment: Testcase update

If you not see selected text in the textarea after selecting text and press "Quote" — it is BUG!

Comment 6

[Vladimir Yeryomin]

Update!
See testcase from bug #38254: https://bugzilla.mozilla.org/attachment.cgi?id=38254#
If you select text with link and press link, window.getSelection().toString() text returned properly!

Comment 7

[Vladimir Yeryomin]

Attachment: Workaround

Comment 8

[Vladimir Yeryomin]

Update! see workaround!

Comment 9

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME

Comment 10

[Daniel Veditz [:dveditz]]

> No specific bug / patch referenced as the fix.
> -> WORKSFORME

There has been no fix, "WFM" comments in the bug refer to old builds in an attempt to narrow down the regression range. I'm glad the poster found a workaround but the original testcase still shows a regression from 1.0.x

Not blocking 1.8.0.1, however.

Comment 11

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060115 Firefox/1.6a1

All three testcases work for me just as expected. Note that the second two just show the selected text, but this is because they're coded that way.

Comment 12

[Raj Bhaskar]

I see this bug on SeaMonkey 1.0 final (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 MultiZilla/1.8.1.0x SeaMonkey/1.0).  Using onmousedown rather than onclick as in the workaround solves it for me.

Comment 13

[JjMeric]

I have a similar problem, badly formulated here 
http://forums.mozillazine.org/viewtopic.php?t=375161

and can provide an html file for testing.

basically same problem in my application: getSelection().toString() now returns an empty string.

This worked in Firefox before 1.5 and still works in Mozilla 1.7.7

---begin test file---
<table>
<th>sample bug page for my bug</th>
<tr>
 <td><b>some dummy text : select any portion with your mouse, then click on "google.fr" (top right of this page)</b>

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
<p>
My app is BROKEN !
<p>
my application worked in Firefox 1.0.4 Fr and still works in Mozilla 1.7.7
it stopped working as soon as I installed the new Firefox 1.5
<p>
if uses the javascript function getSelection() to pass the text selected to a Google search
<p>
I tried to apply the copy/paste user preferences in profiles/user.js as explained
here : http://forums.mozillazine.org/viewtopic.php?t=372322&highlight=selected+text
but this did not solve the problem;
I may have been confused about where the file should be placed, though, the documentation does not compare with my setup at all! + implementing this to a large group of users is not realistically feasible anyway.
<p>
the link the users click on to launch the search on the selected text:
...
 </td>
 <td valign=top>
<a href="javascript:jumpSelection();">[Google.fr]</a>
</td>
</tr>
</table>
<script>
function jumpSelection() {
someurl='http://www.google.fr/search?hl=fr&ie=ISO-8859-1&q=%22'+escape(getSelection().toString())+'%22&btnG=Recherche+Google&meta=lr%3Dlang_fr';
showme=window.open(someurl,"","width=800,height=600,top=50,resizable=yes,scrollbars=yes,toolbar=yes,menubar=yes");
}
</script>

---end test file

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 310241 ***

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

clearing blocking1.8.1 request, as this is a duplicate (the other bug already has that request)