278044 - Selection.deleteFromDocument() should remove selection

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122

When I call deleteFromDocument() method then selected nodes are removed but
selection remains.

Reproducible: Always

Steps to Reproduce:

Comment 1

[alexander :surkov (:asurkov)]

Attachment: test case

Note. Sometimes deleting of selected nodes may come to crach (see
https://bugzilla.mozilla.org/show_bug.cgi?id=278042). Better to see the test
case in previous mozilla builds (in instance firefox 1.7.3).

Comment 2

[Boris Zbarsky [:bzbarsky]]

ccing some people who know something about selection, hopefully...

Comment 3

[alexander :surkov (:asurkov)]

You can see a problem when you call nsIRange::deleteContents()
(nsISelection::deleteFromDocument() called nsIRange::deleteContents()). Actually
selection is removed when range content is removed because
window.selection.rangeCounts is equal 1 and selection.getRangeAt(0) is
collapsed. But selection track is displayed.

Comment 4

[alexander :surkov (:asurkov)]

Attachment: testcase2

It seems the bug is lying in nsRange::CollapseRangeAfterDelete() method.



Such behaviour you can get by using methods nsIRange::setStart() and
nsIRange::setEnd(), in instance, if you set selection after removing charackter
of textnode (see a testcase2). I'm not sure it is the same bug or not. ogub  fi

Comment 5

[alexander :surkov (:asurkov)]

I'm not sure what component ('selection' or 'DOM: Traversal-Range') is right
component for this bug. Please move bug to more appropriate component. ro 

Comment 6

[Martijn Wargers (dead)]

This seems to work for me in current trunk build.

Comment 7

[alexander :surkov (:asurkov)]

I builded one day old seamonkey (SeaMonkey 1.5a
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060405 SeaMonkey/1.5a). Testcases show a problem as before.

Comment 8

[Martijn Wargers (dead)]

Yes, now I can see the bug too.
It seems more like a painting problem to me.
I think the selection is removed all right, but somehow there is still a selection painted. When I move with the caret through the still painted selection (which shouldn't be possible, because when you see a caret, you shouldn't see a selection too), the part where the caret was becomes unpainted.

Comment 9

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.