666618 - Drag selection(word by word selection) is broken if textarea is there.

Status: RESOLVED FIXED

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

Description

[Alice0775 White]

Attachment: sample html

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/48e72227c2fa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110623 Firefox/7.0a1 ID:20110623030811

Drag selection(by word selection) is broken if textarea is there.
No copy context menu appears.
When I click elsewhere of page, selection is not collapsed.

11111 22222<br>
33333 44444<br>
<textarea rows="10" cols="80"></textarea><br>
77777 88888<br>
99999 00000<br>

Reproducible: Always

Steps to Reproduce:
1. quickly perform mousedown-mouseup-mousedown on 11111 to select a word
2. keep holding mousedown and drag to the downward to 00000 slowly
OR
1. quickly perform mousedown-mouseup-mousedown on 00000 to select a word
2. keep holding mousedown and drag to the upward to 11111 slowly

Actual Results: 
Selection will not expand.
Selection will be broken. (Context menu of Copy does not appear).
Click elsewhere of page, the selection is not collapsed.

Expected Results:
11111 to 00000 should be selected. (Context menu of Copy should appear).
Click elsewhere of page, the selection should be collapsed.

Comment 1

[Alice0775 White]

This also happen on ubuntu10.04.
http://hg.mozilla.org/mozilla-central/rev/48e72227c2fa
Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110623 Firefox/7.0a1 ID:20110623030811

Comment 2

[Alice0775 White]

Regression window:
Works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a3pre) Gecko/20070228 Minefield/3.0a3pre
Fails:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a3pre) Gecko/20070301 Minefield/3.0a3pre
Reference:
http://forums.mozillazine.org/viewtopic.php?f=23&t=525704
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-28+00%3A00%3A00&maxdate=2007-03-01+06%3A00%3A00&cvsroot=%2Fcvsroot

Comment 3

[Alice0775 White]

In local build,
It works when I backed out relevant code of patch Bug 372086 .

So, this is regressed by Bug 372086.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Are we ending up with one selection endpoint inside the textarea and the other outside?

Comment 5

[(no longer active)]

Yes, the window selection object seems to get replaced with the textarea selection object, which means that the anonymous DIV is exposed to the content js.  Is that safe?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Generally that's something we avoid. Though wrappers might prevent it from actually getting exposed?

Comment 7

[(no longer active)]

(In reply to comment #6)
> Generally that's something we avoid. Though wrappers might prevent it from
> actually getting exposed?

I noted that accessing anything on the object throws...

Comment 8

[Alice0775 White]

Progression window(m-c)
Bad:
http://hg.mozilla.org/mozilla-central/rev/c3190d715044
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 ID:20120620015514
Fixed:
http://hg.mozilla.org/mozilla-central/rev/e240d6e43c9a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 ID:20120620075815
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c3190d715044&tochange=e240d6e43c9a


Progression window(m-i)
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/4a44ebe3e8ff
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 ID:20120619222316
Fixed:
http://hg.mozilla.org/integration/mozilla-inbound/rev/96303b557d55
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 ID:20120619234016
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4a44ebe3e8ff&tochange=96303b557d55

This was fixed by Bug 762764 in Firefox16