Closed Bug 35087 Opened 24 years ago Closed 23 years ago

dialog with one text field should set focus

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: akkzilla, Assigned: saari)

References

(Blocks 1 open bug)

Details

(Keywords: access, helpwanted, Whiteboard: [nsbeta2-] [nsbeta3-]) 

I'd been assuming that there was a bug on this already, but I can't find it.

Whenever I start mail, I have to click in the text field in the password dialog
in order to type in my password.  I shouldn't have to do this; the dialog should
come up with focus already in the text field.

Note that I use pointer focus, not click-to-type, in kde.  This may be working
in the click-to-type focus model, but it's not working if the dialog doesn't
initially have focus when it comes up.  The text field should get focus as soon
as the mouse is moved into the window (i.e. when the dialog has focus, so does
the text field).

Seems like this should happen in general (provided by the toolkit, since most
other toolkits I'm familiar with provide that service), so I'm guessing it's a
general focus problem, rather than a specific failure of the imap password
dialog to call focus().
Similar to bug 11494.
Yeah, focus happens on load of the dialog in most cases. If the dialog itself 
doesn't have focus at load time, then the focus memory tracker probably doesn't 
get informed where the focus should be set on activation, as it is listening to 
the focus messages also. 

SooOOoo, this is probably a change that needs to happen with focus memory. Hyatt, 
thoughts on how to do this, since we're not actually going to get the focus event 
in the command dispatcher listener?
Status: NEW → ASSIGNED
Target Milestone: --- → M16
*** Bug 37586 has been marked as a duplicate of this bug. ***
*** Bug 37586 has been marked as a duplicate of this bug. ***
If there are multiple text fields in a dialog box, common practice is to start
with focus in an appropriate field, usually, but not always, the first.  I think
this would be better titled "Dialogs with text fields should set focus".
*** Bug 38782 has been marked as a duplicate of this bug. ***
nominating for nsbeta2
Keywords: nsbeta2
[nsbeta2-]
Whiteboard: [nsbeta2-]
*** Bug 40126 has been marked as a duplicate of this bug. ***
Mass-moving nsbeta2- bugs to M20
Target Milestone: M16 → M20
*** Bug 11494 has been marked as a duplicate of this bug. ***
Nominating for nsbeta3.
Keywords: nsbeta3
nsbeta3-, you'll have to set it in the onload handler for now.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M20 → Future
I suppose it's none of my business, but ... Removing nsbeta3- for further 
consideration.

If you require that each single-field dialog set focus itself, then all the 
bugs which have been marked as a duplicate of this one (several of which would 
probably get nsbeta3+ if nominated) are going to have to be un-dupped so that 
they can be fixed individually. Just fixing this bug, instead, would surely 
save a *lot* of development time overall.
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-]
    I don't know if anybody else noticed, but with the latest builds it works
for me, at least with the Alt-F (find in page) and Alt-L (open location)
dialogs.  After pressing Alt-F or Alt-L I can type directly into the dialog now,
without any mouse action. But I haven't checked other dialogs.
I agree, it would save time overall, but there are more serious bugs that I need 
to look at before we ship. If you want to implement this feature, I can tell you 
how to do it... you need to insert code to grovel the UI upon load completion and 
jam the focus into the first textfield/textarea. You must do this *before* the 
onload handler fires so that it can be overridden.

Sorry, but considering our current bug load and severe time/resource
constraints, we can't commit to fixing this for nsbeta3.  nsbeta3-
Whiteboard: [nsbeta2-] → [nsbeta2-] [nsbeta3-]
Doesn't work on Mac build 2000082608, Mac OS 9.0 (both Find and Open Location 
dialogs). The focus ring is shown, but focus isn't actually set (which is highly 
misleading). Back to All/All.
OS: Linux → All
Hardware: PC → All
Interestingly, it works okay in the mail password dialog
Some dialogs set focus explicitly, since they needed to to get around this bug.

There are several bugs asking for workarounds for certain dialogs: bug 47507, 
bug 51549.  If this bug is not getting fixed soon, should there be a metabug to 
track the workaround bugs so the workarounds can be reveresed when this bug is 
fixed?
I'm surprised this has been futured; this is almost a dogfood issue for me. I'm 
very reluctant to use any mail app that is not controllable just from the 
keyboard.

This will just be a convenience feature for XP app developers, windows with
multiple text fields will still need to set focus where they want it.
I disagree. I think the toolkit should set the focus to the first focussable 
widget in the window automatically. This would also fix the problem with typing 
into the url bar on new browser windows.

That would have been an interesting suggestion when we were soliciting
requirements long ago, but I don't think it is something we should consider in
the last week before Zarro Boogs.  There are certain to be many exceptions, such
as the message compose window, where we probably want the focus in the first
address field, yet probably also want to be able to focus in the From and To
popups that precede it.  Perhaps you meant the first focussable widget in an
explicit tab ordering, or the first focussable text widget?  In any case, this
bug has much more limited scope.
Keywords: access
You mean like Randolph Fritz' suggestion to do that on 2000-04-28 21:10?

Every toolkit I've used has provided this automatically (if you bring up a
dialog, focus is *somewhere* in the dialog, normally the first text field if not
expliticly set elsewhere) -- how else would mouseless users be able to use
dialogs?  Are there really toolkits (besides ours) that don't work this way?

If there's no time, there's no time -- but it's not by any means a new or
last-minute request, and we should certainly address it when we have time.
Well, I don't know where that came from (I know Randolph from way back, and read
his posts, yet don't see it now on XPFE or UI NGs), and I was thinking of more
than a year earlier when we were soliciting requirements from XPFE developers,
but you have a good point. This may be a deficiency we should have addressed by
now, and we'll probably have to resolve it before we claim the platform is 1.0.
I'm just surprised to be hearing it escalated only a week before we're supposed
to be done fixing bugs.  My point is mainly that I don't think that is the kind
of thing we should be changing right now.  If anyone feels strongly otherwise,
please nominate a bug for it. 
Sorry, should have been more specific: Randolph's comment was earlier in this
bug.
Someone come up with a good algorithm for choosing what widget to focus, keeping 
in mind things like iframes.

Now insert that code just before we fire the onload handler so it can be overode 
by the existing load handlers. Not rocket science, just easier to just add the 
focus call to the load handler of whatever dialog is bothering you.

A miracle might happen and I might fix all the regressions that happened last 
week and then I'll get to this, but I doubt it. Feel free to jump in...

Well we should go one way or the other, but currently mozilla is half-assing it.
 If you summon the open location dialog, the text field has the blue
i-have-the-focus border, but it doesn't actually have the focus.  So you have to
tab five times to really move the focus into the textfield.

It is definitely misleading to highlight a widget but not move the input focus
to it.
I agree with you, I want to fix that, but I'm still hunting regressions of a 
higher priority with a deadline looming.


*** Bug 53291 has been marked as a duplicate of this bug. ***
*** Bug 53546 has been marked as a duplicate of this bug. ***
This problem appears to be fixed in recent builds, but there is no recent
activity in Bugzilla. Should this be closed?

That's true, it works for several weeks now - both on WinNT and on Linux.
Is this fixed, or is it just that all the commonly used dialogs have worked
around it by adding explicit set-focus calls?
No leave this open because it is really a feature request. The dialogs appear to
work because they set the focus in the onload handler for each dialog.
Related note: composer has lots of focus() calls sprinkled around in its JS and 
C++; most of these should never need to be there. We should purge them, and then 
fix any inherent focus problems that remain. The same is likely true of other 
parts of the app.

Simon, I agree, but we're not there just yet. The Windows dialog focus bug will
hose you still. Hopefully we can get to this point early in the next dev cycle.

Target Mozilla 1.0
Target Milestone: Future → mozilla1.0
If I use XBL to fix 58853, it looks like this would be fixed as well. This bug
looks to me like a subset or special case of that bug.
Yes, it is a subset of that bug
adding dependency then
Depends on: 58853
Blocks: focusnav
As long as the dialog is created with <dialog>, these days it will always get an
initial focus set.

If there are dialogs that aren't using that, and there is no initial focus for
them, separate bugs should now be filed for eacho those dialogs.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.