1. Open the DOM inspector and select a node, say an element node which is a sibling of a whitespace node. 2. Now move the focus rect to the whitespace node (Ctrl-click it twice, or just use Ctrl-up or -down on the keyboard) while maintaining the selection of the element node. 3. Using keyboard shortcuts, invoking the context menu from the keyboard, or using the menuitems in the Edit menu, issue copy and paste commands. Result: The whitespace node is duplicated. Expected result: The element node--the actual selection--is duplicated. This is due to code like the following: For trees which aren't seltype="single", currentIndex is used where ranges from nsITreeSelection should be used instead, because currentIndex determines/gives the index of the tree row caret/focus rect/whathaveyou, not the selection, and it's possible for the row that has the current focus rect to be one which is not part of the selection. grepping for "currentIndex" and inspection reveals this poor choice in the following viewer files: accessibleEvents/accessibleEvents.js accessibleRelations/accessibleRelations.js accessibleTree/accessibleTree.js dom/dom.js domNode/domNode.js jsObject/jsObjectViewer.js stylesheets/stylesheets.js The the style rules viewer was changed from this behavior in bug 192841, the XBL bindings viewer will use single seltype trees after bug 530643 is fixed. The DOM node object viewer is the closest to correct behavior from this list; it may even be doing the right thing altogether. A copy and paste test and a multi-selection delete shows that it does indeed respect selection instead of the focus rect, but the edit command relies on currentIndex. What's the correct behavior for trees? Obviously insert should rely entirely on currentIndex, because it refers to the caret, the insertion point. But what about edit? Selection or caret? Note also that this affects more than just contextual actions. The DOM node document viewer uses currentIndex quite a bit. One use is whenever parameters to inDOMView change, and the tree has to be rebuilt, even just for styling when "show accessible nodes" is toggled, it attempts to maintain the current selection, expanding parent nodes if necessary (improvement on that process could be another bug itself).

Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023

Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023