Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#17287 closed defect (fixed)

TabContainer.selectChild(someChild) doesn't seem to set focus style on the tab button

Reported by: dylan Owned by: bill
Priority: undecided Milestone: 1.10
Component: Dijit Version: 1.9.1
Keywords: Cc:
Blocked By: Blocking:

Description

tabs.selectChild(someChild) selects the correct tab, but keeps the original tab in focus, e.g. the outline around the text of the tab button seems to stick on the previous tab. This seems to be an issue with Chrome and Firefox.

It's not a major issue, but stylistically feels wrong to see an outline around the tab that is not actually selected.

Attachments (1)

screenshot 2013-06-27 at 4.42.52 .png (14.5 KB) - added by dylan 6 years ago.
Screenshot showing the style issue on Chrome latest

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by dylan

Screenshot showing the style issue on Chrome latest

comment:1 Changed 6 years ago by dylan

Owner: set to bill
Status: newassigned

comment:2 Changed 6 years ago by bill

Owner: changed from bill to dylan
Status: assignedpending

I agree the screenshot looks weird, since that never happens via navigating with the keyboard or the mouse. But OTOH if the focus is completely outside the TabContainer?, for example if the user pressed a button outside the TabContainer? that changed the selected tab, focus should not be changed; it should stay on the button. That seems like the typical case.

How is it in your app that focus was on tab #2 and the user didn't do anything, but suddenly there was a call to tabs.selectChild(someOtherChild)?

comment:3 Changed 6 years ago by dylan

Owner: changed from dylan to bill
Status: pendingassigned

Scenario is as follows:

  • User loads app
  • Clicks on tab 2
  • Clicks browser back button
  • dojo/router calls tabs.selectChild() based on the change in the route

e.g.:

router.register("/pane/:id", function(event){
	tabs.selectChild(event.params.id);
});

Given that scenario, this may indeed be as designed, but what should happen?

comment:4 Changed 6 years ago by bill

Hmm, I guess in the scenario you described, either dijit or the application should focus the event.params.id tab before selecting it. As you said, that would be look nicer, and also it would avoid problems when the focused node is hidden (problems for anyone that needs to navigate via the keyboard because they can't use the mouse, and also some additional problems on older versions of IE).

Two related scenarios would be if the user changed the focus before and/or after clicking on tab 2, for example:

  • User loads app
  • Clicks an <input> inside tab 1
  • Clicks on tab 2
  • Clicks an <input> inside tab 2
  • Clicks browser back button
  • dojo/router calls tabs.selectChild() based on the change in the route

In this case it seems like ideally the focus should go to the input in tab 1, but perhaps that's not worth the code bloat, or at least not worth coding inside of dijit.

Anyway, I can't just add code to selectChild() to unconditionally change the focus. I could add code to focus the new tab if focus is currently on or inside another tab. But like I said in the previous paragraph, perhaps that's better done in the application?

comment:5 Changed 6 years ago by bill

PS: Another scenario not involving dojo/router would be a TabContainer? where the initial tab is called something like "Introduction" or "Summary" or "Contents", and has links or buttons to move to the other tabs. In that case, clicking the links or buttons should move focus somewhere sensible, either the label of the selected tab or more ideally, the first focusable field inside the selected tab. Like what happens when you open a dialog.

comment:6 Changed 6 years ago by dylan

Ok, that's reasonable. Feel free to close this out, as setting focus works, by doing something like the following for the above example:

focus.focus(registry.byId("tabs_tablist_"+event.params.id));

comment:7 Changed 6 years ago by bill

OK. I'm still on the fence about it though, it might make sense to add to dijit since it covers a few cases. It's probably just adding a few lines of code to selectChild(), conceptually like:

if(this._focused){
    // Focus must be inside the currently selected tab,
    // or on the currently selected tab label. 
    registry.byId("tabs_tablist_"+event.params.id).focus();
}

comment:8 Changed 6 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

In df83f09c02ffdb0aa7ee77ae4da20e04e2f949d8/dijit:

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

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

In 2f9852284d80534033dcc510b2c984c4f254f042/dijit:

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

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

In c263d8c4a7021171a7f9649898637073d1cabe07/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.