Opened 11 years ago

Closed 5 years ago

Last modified 3 years ago

#6236 closed defect (fixed)

Tree: focus not updated correctly in various cases

Reported by: bill Owned by: bill
Priority: high Milestone: 1.10
Component: Accessibility Version: 1.0
Keywords: Cc: Mike Wilcox
Blocked By: Blocking:

Description (last modified by bill)

ISTM focus on the tree isn't updated correctly in the following cases (or at least some of the following cases):

  • focused node is deleted (by, for example, another user... and Tree receives delete notification)
  • focused node's ancestor is deleted
  • focused node is dragged and dropped into collapsed node, thus becoming hidden

Does focus go to "the right place" in these cases (whatever that means)? Or does it just disappear (or is that the "right thing")? Or does it move to another widget entirely, outside of tree?

Closing the ancestor of focused node seems to do the right thing:

if(this.lastFocused){
	// are we collapsing a descendant with focus?
	if(dojo.isDescendant(this.lastFocused.domNode, node.domNode)){
		this.focusNode(node);
	}else{
		// clicking the expando node might have erased focus from
		// the current item; restore it
		this.focusNode(this.lastFocused);
	}
}

Change History (13)

comment:1 Changed 11 years ago by bill

Description: modified (diff)
Milestone: 1.2future

comment:2 Changed 10 years ago by bill

Cc: Mike Wilcox added
Milestone: future1.4
Owner: changed from Becky Gibson to bill
Status: newassigned

Mike asked me for a fix to (1) and (2), I'm working on it now. Actually he just asked to avoid the exception when the user clicks on another TreeNode after the selected one was deleted out from under them. But I want to fix the tabbing problem too.

Oh, turns out the third bullet point is impossible:

focused node is dragged and dropped into collapsed node, thus becoming hidden

because when you drop onto a collapsed node it automatically expands, and also because dropping sets the focus to the drop target.

comment:3 Changed 10 years ago by bill

Milestone: 1.41.5

comment:4 Changed 10 years ago by bill

(In [20818]) Prevent exception when a TreeNode is programatically deleted and then the user switches focus to another node (as seen in test case for #10018), refs #6236 !strict.

comment:5 Changed 9 years ago by bill

Milestone: 1.5future

comment:6 Changed 6 years ago by bill

Mostly fixed by [30029].

comment:7 Changed 6 years ago by dylan

Milestone: future1.9

If it's mostly fixed, what remains to be done? Or should be close this out?

comment:8 Changed 6 years ago by bill

Milestone: 1.9future

See #16323. Doug complained about the new behavior in [30029] so I reverted it.

Also, there's a problem when a node is destroyed while it actually has focus. As opposed to destroying the node marked to get focus when the Tree itself gets focus.

comment:9 Changed 5 years ago by bill

Milestone: future1.10

comment:10 Changed 5 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

In 8cc12c35ee8a6d512c65339771396574224f1a40/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:11 Changed 3 years ago by Bill Keese <bill@…>

In fb8e1093/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:12 Changed 3 years ago by Bill Keese <bill@…>

In b87bfbe/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:13 Changed 3 years ago by Bill Keese <bill@…>

In f35a55a/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 
Note: See TracTickets for help on using tickets.