Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#7287 closed enhancement (fixed)

Dialog: Disable autofocus on first dialog element

Reported by: aeon Owned by: bill
Priority: high Milestone: 1.2
Component: Dijit Version: 1.1.1
Keywords: Dialog Focus Cc:
Blocked By: Blocking:

Description

There should be a way to disable autofocus on first dialog element - sometimes one wants to display the dialog without big widgets popping up in front of it.

Patch attached that lets you specify 'autofocus: false' in the Dialog creation params.

Attachments (1)

Dialog.patch (990 bytes) - added by aeon 11 years ago.

Download all attachments as: .zip

Change History (15)

Changed 11 years ago by aeon

Attachment: Dialog.patch added

comment:1 Changed 11 years ago by bill

Not sure what "without big widgets popping up in front of it" means? Is it about DateTextBox?

comment:2 Changed 11 years ago by bill

Summary: Disable autofocus on first dialog elementDialog: Disable autofocus on first dialog element

comment:3 Changed 11 years ago by Aeon

Yeah, DateTextBox? or TimeTextBox? would be examples of a widget that pops up in front of the dialog and confuses the user since they can't see the instructions for the input field.

comment:4 Changed 11 years ago by bill

Milestone: 1.21.3
Resolution: duplicate
Status: newclosed

OK, in that case will probably just fix #5151 instead, I'll add a comment there.

comment:5 Changed 11 years ago by aeon

Why not allow both options, to disable autofocus on first element of dialog, or to disable widget expansion on autofocus?

comment:6 Changed 11 years ago by bill

What would be the advantage of doing that?

comment:7 Changed 11 years ago by aeon

Well, first of all, this is not a duplicate of the other bug. It deals with completely different code.

Second of all, a use case that cannot be duplicated without this would be being able to have the picker NOT popup as soon as dialog opens, but still popup as soon as user focuses on it. If this patch is not accepted, the only option is to either a) have the picker popup as soon as dialog opens, or b) have to click on the icon to bring up the picker. With this patch, it would be possible to do any of the three possibilities (focus and popup, focus and no popup, no focus).

I would think that anything that gives the developer more flexibility in what they can do would be a good thing. What would be the advantage of not doing that?

comment:8 Changed 11 years ago by bill

this is not a duplicate of the other bug. It deals with completely different code.

Perhaps "wontfix" would have been better than "duplicate", although what I meant was that the other ticket addresses the same issue.

I would think that anything that gives the developer more flexibility in what they can do would be a good thing.

The disadvantage of adding any option to the widgets is that it adds bulk to our code base and creates possible bugs and more code paths to test. Plus which, I don't want to encourage developers to make a bad UX, which I think this might do, as I suspect most users assume that as soon as a Dialog shows up they are focused on the first element and can start typing.

Anyway, I'll keep this in mind if more people complain about it.

comment:9 Changed 11 years ago by taras

Resolution: duplicate
Status: closedreopened

Hi

May be this is not a bug, and may be is not an enhancement, but for sure is an usability issue. Please read my 'tale' how the current behavior affect .

I have some dialogs with only grids and dates.The grids are created dynamically in parallel to the display (show) of the dialog.

The behavior is such that at the first time I display the dialog , the calendar is displayed above the inputtext box, but then, the grids are started to be automatically displayed and modify the dimensions of the dialog.

So after all widgets finished rendering inside the dialog, I have a calendar displayed more or less in the middle of the dialog and above one of the grids, you move the dialog and the calendar remain alone elsewhere unconnected geographically from the original inputdate box.

I don't need to tell you the "beautiful" of this, you can imagine.

Any user that will receive an application like that will not feel so "comfortable", isn't it?

For the test I put a simple input box before the calendar, and I see that the problem is bypassed, so for sure, the focus issue is the problem.

Any applicable temporary workaround will also be very welcomed.

Can you rise priority of this problem ?

I reopen this issue.

thanks !

Eduardo

comment:10 Changed 11 years ago by bill

Owner: set to bill
Status: reopenednew

OK, I give in :-) I'll apply the patch.

comment:11 Changed 11 years ago by bill

Milestone: 1.31.2
Status: newassigned

comment:12 Changed 11 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [14640]) Parameter to control whether or not dialog/tooltip dialog focuses on first item. Recommended not to change from default values except in special circumstances. Fixes #7287 !strict.

comment:13 in reply to:  12 Changed 11 years ago by taras

Replying to bill:

(In [14640]) Parameter to control whether or not dialog/tooltip dialog focuses on first item. Recommended not to change from default values except in special circumstances. Fixes #7287 !strict.

Hi Bill

Thanks very much, you are great !

Eduardo

comment:14 in reply to:  12 Changed 11 years ago by taras

Replying to bill:

(In [14640]) Parameter to control whether or not dialog/tooltip dialog focuses on first item. Recommended not to change from default values except in special circumstances. Fixes #7287 !strict.

OK, I changed from default only when strictly needed, according to my test it is working ok as expected, and seems to havn't any negative side effect even on complex dialogs, at least in my tests.

ps: thanks also for the borderContainer correction, the additive solution is a very good one !

thanks again !

Note: See TracTickets for help on using tickets.