Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 275191

Summary:	[About] Should installation details dialog put focus inside the selected page
Product:	[Eclipse Project] Platform	Reporter:	Susan McCourt <susan>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	Kevin_McGuire, prakash, susan
Version:	3.5
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Susan McCourt

2009-05-06 13:57:26 EDT

Currently the initial focus of installation details is on the page tab.
Should it instead go to the page?
The answer depends on whether we think the default (last used page in the session) page is likely to be the page the user wants to work with when the dialog opens.

Comment 1 Susan McCourt

2009-05-06 13:59:15 EDT

As part of this bug we should also make sure the pages themselves set the focus to correct widget, so that if we decide to place focus on the page, it goes to the expected place.

Comment 2 Kevin McGuire

2009-05-06 17:30:28 EDT

I think it works fine as is.  The focus is on the tabs so I can keyboard arrow to the next tab, then drop into the tab content via <tab>. Feels like what I'd expect.

Comment 3 Kevin McGuire

2009-05-06 18:05:19 EDT

(In reply to comment #0)
> The answer depends on whether we think the default (last used page in the
> session) page is likely to be the page the user wants to work with when the
> dialog opens.

Hard to say, sometimes it may be, sometimes it could be a month later that I open the dialog.

If we look at the Preference pages, the filter box/tree always has focus. 

So focus on tab, while remembering last tab, is right.

Comment 4 Susan McCourt

2009-05-06 20:16:03 EDT

ok, thx.
Will leave this bug open to look at comment #1 in a future release

Comment 5 Susan McCourt

2009-06-25 14:17:07 EDT

assigning milestone for investigation in 3.6

Comment 6 Susan McCourt

2009-09-23 18:00:48 EDT

> Will leave this bug open to look at comment #1 in a future release

To clarify what I meant in comment #1

> As part of this bug we should also make sure the pages themselves set the focus
> to correct widget, so that if we decide to place focus on the page, it goes to
> the expected place.

We don't want pages to use setFocus anywhere in the creation sequence because this will force focus off the tabs and onto the content.  Instead we need to make it clear where a page should set its initial focus.  Maybe just doc'ing it (that they should use composite.setTabOrder) is good enough...or maybe we want a framework method to specify it?

Comment 7 Susan McCourt

2009-10-06 17:42:05 EDT

moving to M5 to reevaluate priority against other tasks.

Comment 8 Susan McCourt

2011-04-19 16:51:49 EDT

unassigning bugs without milestones

Comment 9 Lars Vogel

2019-11-14 02:24:23 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.