27417 - When tree item deleted, next item should be selected (selection should not be destroyed)

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect, P3)

Description

[Matthew T (active 1999-2002)]

Build: 2000021014

To reproduce:
* Start Mozilla. Browse with cookies enabled, until you have collected two or
  more cookies.
* Open the Cookie Manager window.
* Select the first cookie in the list, and click Remove Cookie.

What should happen:
* The cookie is deleted, and the next cookie in the list becomes
  selected.

What actually happens:
* The cookie is deleted, but the next cookie is not selected. This makes
  deleting multiple cookies rather tedious.

Ben, giving this to you because you'll know if this problem is specific to the 
cookie manager, or to the widget itself; if it's a problem with the widget, you 
can give it to XP Toolkit/Widgets.

Comment 1

[Ben Goodger (use ben at mozilla dot org for email)]

*** Bug 29034 has been marked as a duplicate of this bug. ***

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

need to create some JS extensions to the tree widget API to support nifty little 
things like this everywhere... M16 so I can do this the Right Way. 

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

not a priority, pushing out as far as possible.

Comment 4

[Paul MacQuiddy]

changing qa contact to [e-mail] on some random bugs

Comment 5

[don]

Move to M21 target milestone.

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

setting component to trees and cc'ing hyatt. 

Comment 7

[Jesse Ruderman]

This bug makes selectively deleting cookies O(n^2) for keyboard people, adding 
access keyword and nominating for nsbeta1.

Comment 8

[Paul Chen]

nav triage team:

Reassigning to hyatt. Seems like something we would like to fix.

Comment 9

[David Hyatt]

This is supposed to work.  bryner and I wrote code to auto-select the next item.
 Can someone point me to a specific tree that exhibits this problem?

Comment 10

[Blake Ross]

hyatt: all of them, I think (if not, and it is indeed a base behavior of trees 
now, we should fix some places where we're still manually selecting and 
focusing).  The tree in the cookie manager is one example.

Comment 11

[Stephen P. Morse]

Forget the cookie manager.  Here's a simplified example of a tree that 
demonstrates the problem.  Select an item and press the "remove button".  
Selected item gets deleted.  But no automatic reselection occurs.


<?xml version="1.0"?>
<?xml-stylesheet href="chrome://communicator/skin/" type="text/css"?> 
<?xul-overlay href="chrome://global/content/dialogOverlay.xul"?>
<!DOCTYPE window>

<window id="cookieviewer"
        class="dialog"
        xmlns:html="http://www.w3.org/1999/xhtml"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        orient="vertical">

  <script type="application/x-javascript">
  <![CDATA[
    function remove() {
      var children = document.getElementById("kids");
      var mytree = document.getElementById("mytree");
      var selitems = mytree.selectedItems;
      for(i = 0; i < selitems.length; i++) {
        document.getElementById("kids").removeChild(selitems[i]);
      }
    }
  ]]>
  </script>

  <tree id="mytree" class="inset" multiple="true" flex="1">
    <treecolgroup>
      <treecol flex="1"/>
    </treecolgroup>
    <treechildren id="kids" flex="1">
      <treeitem>
        <treerow>
          <treecell class="propertylist" label="first"/>
        </treerow>          
      </treeitem>
      <treeitem>
        <treerow>
          <treecell class="propertylist" label="second"/>
        </treerow>          
      </treeitem>
      <treeitem>
        <treerow>
          <treecell class="propertylist" label="third"/>
        </treerow>          
      </treeitem>
    </treechildren>
  </tree>
  <button label="remove" onclick="remove()"/>
</window>

Comment 12

[Stephen P. Morse]

Have a specific patch which at least fixes this for cookies manager and password 
manager.  A more general solution will have to await whatever fix hyatt has 
planned.

It's a good thing I did this because I uncovered several minor problems in the 
password-manager code which my patch corrects.

Comment 13

[Stephen P. Morse]

Attachment: patch for cookie-manager and password-manager

Comment 14

[Stephen P. Morse]

It should be noted that most of the changes in this patch are either cleanup or 
outright bug fixes.  Only the few lines that are of the form "x.selectedIndex=" 
are relevant to auto-selecting after a deletion.  So even if the general 
solution is ever checked in, most of this patch will still be worthwhile.

Comment 15

[Stephen P. Morse]

cc'ing alecf for super-review

Comment 16

[dbragg]

r=dbragg

Comment 17

[Stephen P. Morse]

now I'm really cc'ing alecf for super-review (I thought I did it yesterday but 
apparently I didn't).

Comment 18

[Alec Flett]

sr=alecf

Comment 19

[Stephen P. Morse]

My patch is now checked in.  Leaving this open for hyatt to implement the 
general solution (my patch fixed it for cookies and passwords only).

Comment 20

[Aaron Leventhal]

Not an access bug, the delete key works for deleting several items at once.

Comment 21

[Jesse Ruderman]

I marked this bug with the access keyword because it made it difficult to 
delete *every other* cookie (or otherwise selectively delete cookies).

Comment 22

[Stephen P. Morse]

I don't understand Ruderman's comment.  This bug has been fixed for the cookie 
manager (as well as the password manager).  See my pathch of 4/15 which has been 
checked in.

Comment 23

[Jesse Ruderman]

>This bug has been fixed for the cookie manager (as well as the password manager).

That's why I used the past tense in my last comment :)

Comment 24

[Matthew T (active 1999-2002)]

*** Bug 89789 has been marked as a duplicate of this bug. ***

Comment 25

[Tuukka Tolvanen (sp3000)]

*** Bug 105639 has been marked as a duplicate of this bug. ***

Comment 26

[Joe Hewitt (gone)]

tree is no more, wontfix

Comment 27

[Matthew T (active 1999-2002)]

Outliner is now called tree. Reopening.

Comment 28

[Matthew T (active 1999-2002)]

*** Bug 135104 has been marked as a duplicate of this bug. ***

Comment 29

[Matthew T (active 1999-2002)]

*** Bug 117267 has been marked as a duplicate of this bug. ***

Comment 30

[Matthew T (active 1999-2002)]

*** Bug 58713 has been marked as a duplicate of this bug. ***

Comment 31

[Peter Trudelle]

->component owner

Comment 32

[jglick]

Would really like to see this fixed for Buffy since its a big usability issue
for Mail. Double click a mail message to open it, click delete on the open msg
toolbar. The next msg appears, but if you look at the main mail window, the msg
being displayed in the open window isn't selected. Click delete on open msg
toolbar. It doesn't work. 

Comment 33

[Peter Trudelle]

Bumping severity to major, since that's major loss of function in the message
window.

Comment 34

[jglick]

Problem described in comment #32 is filed as bug 171711 (Delete in standalone 
window only works once). It may or may not be connected to this bug.

Comment 35

[jglick]

Bug 171711 was responsible for not being able to delete more than one mail msg.
This bug still a top usability issue for mail thought. Open a mail msg in
standalone. Delete msg. Close standalone window. Nothing in thread pane is
selected. Disorienting for user. Not clear to user where they left off reading
msgs in thread pane.

Comment 36

[Samir Gehani]

Nav triage team: deleting in Bookmarks Manager selects the next bookmarks.  Is
the problem in comment 35 specific to mail?  If so, has this bug morphed and the
original problem been fixed?

hewitt, could you investigate?

Comment 37

[jglick]

I filed Bug 172392 detailing the specific problems i see in mail. My hunch is
that its a different bug causing the mail related problems.

Comment 38

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 39

[Timea Cernea [:tbabos][inactive]]

Closing this as resolved:incomplete given it is an old issue with no activity in the last 19 years. Also, deleting one item from a list now passes over the selection highlight to the next one, so most likely this issue is no longer reproducible.