96843 - 'Find in this page' textfield doesn't get focus by default

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Chase Tingley]

Build ID 2001082406 Linux

When opening 'Find in this page' with CTRL-F, the dialog textfield isn't given
focus by default -- if I start typing immediately (to enter a search term), the
keystrokes don't go anywhere (well, at least they don't go to the dialog...) 
Instead, I must click in the textfield before I can type.

This is a recent regression -- builds as recent as 20010822 would give the
dialog focus so that a search term could be entered immediately.

Comment 1

[Benjamin Mucci]

Reproduce on MacOS should be All/All

Very annoying bug.

Comment 2

[sairuh (rarely reading bugmail)]

i see this on os x, 2001.08.28.05-comm.

simon/kin, who'd be working this?

Comment 3

[Chase Tingley]

*** Bug 98145 has been marked as a duplicate of this bug. ***

Comment 4

[Chase Tingley]

Attachment: patch from James Kelley <[e-mail]>

Comment 5

[Chase Tingley]

James Kelley ([e-mail], sorry, I misspelled his name above) had
attached a patch to the dup.

cc'ing him and adding keywords.

Comment 6

[Elmar Ludwig]

The patch from James Kelly (attachment #48144 [details] [diff] [review]) fixes the focus problem for me.
This is on Linux, Build ID 2001090400.

Comment 7

[Elmar Ludwig]

BTW:
Since the patch is almost trivial, is there any chance this will be fixed
in time for 0.9.4 (or is it too late already)?

As Benjamin said... "Very annoying bug".

Comment 8

[Chase Tingley]

nominating.

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 99040 has been marked as a duplicate of this bug. ***

Comment 10

[sairuh (rarely reading bugmail)]

this is a regression [since 6.1rtm], so nominating for nsbranch/moz0.9.4.

Comment 11

[grega]

Let's fix this.  Marking nsbranch+ and PDT+.

Comment 12

[Jeremy M. Dolan]

Can't even get to the field with tab. This is extremly bad for usability. Adding
access kw. This should be a 094 stoper.

Comment 13

[Chase Tingley]

cc'ing alecf and sfraser, who appear to have worked on this code.

This bug is PDT+, nsbranch+, nominated for 0.9.4, and has had a patch from James
Kelley attached for over a week.  Can anyone take a look at it?  Thanks.

Comment 14

[Alec Flett]

please attach a patch with diff -u - there's no context here.

Comment 15

[James Kelly]

Attachment: unified diff

Comment 16

[Alec Flett]

Comment on attachment 49101 [details] [diff] [review]
unified diff

sr=alecf

Comment 17

[kinmoz]

Comment on attachment 49101 [details] [diff] [review]
unified diff

r=[e-mail]

Comment 18

[Chase Tingley]

James, do you have cvs commit access?

If not, one of your reviewers can check this in for you.

Comment 19

[James Kelly]

Nopes.  I don't have commit access.  If someone could check this in for me it
would be much appreciated.

Comment 20

[Chase Tingley]

Umm... you know what's weird?  The fact that I can't see this problem on
2001091208 trunk linux or on the latest branch build.

Am I imagining this, or whatever underlying cause broke this originally get
fix/backed out?

Comment 21

[Elmar Ludwig]

I don't have a current build at the moment to verify tingley's comment.

Bug #58853 is closely related ("Dialog boxes should always get initial keyboard
focus"), by nothing has been checked in there as far as I can see.

Comment 22

[Arnoud Berendsen]

This also works for me on build 2001091303 on Win2k.

Comment 23

[Jeremy M. Dolan]

WFM 9/13 linux. Where is tab sending focus one tab after [Cancel] though? It
disapears before it goes back to the text.

Comment 24

[Jeremy M. Dolan]

No, I take it back, this is NOT fixed. The first find works fine. The second,
when there is already stuff in the Find text: [             ] box, it DOES NOT
get focus.

Comment 25

[Chase Tingley]

Ahh, you're right.  Thanks Jeremy...

This is ready for checkin.  kin/alecf, if you get a sec?

Comment 26

[Elmar Ludwig]

Jeremy M. Dolan wrote:
> The first find works fine. The second, when there is already stuff in the
> Find text: [             ] box, it DOES NOT get focus.

See also my original description in bug #98145, which was marked duplicate
of this bug. It occurs only with text already present in the entry field.

Comment 27

[Elmar Ludwig]

Jeremy M. Dolan wrote:
> Where is tab sending focus one tab after [Cancel] though? It disapears
> before it goes back to the text.

That is bug #64052.

Although it was filed for the Prefs dialog, it applies to all dialogs in
Mozilla (Find in Page, Open Web Location, Open File, File Bookmark etc.).

Comment 28

[Jaime Rodriguez, Jr.]

Peter/Alec/Kin - Can you take owenership of this patch and get this one in?

Comment 29

[Peter Trudelle]

cc pchen. Paul, could you please help Blake get this on the branch?

Comment 30

[Simon Fraser [no longer active]]

This seems like such a hack. Why isn't the toolkit focussing the text field by 
default?

Comment 31

[Elmar Ludwig]

Simon Fraser wrote:
> This seems like such a hack. Why isn't the toolkit focussing the text field
> by default?

That would clearly be the correct solution. This is covered by:

 - bug #58853 "Dialog boxes should always get initial keyboard focus",
              which is marked P3/mozilla1.1 (enhancement)
 - bug #35087 "dialog with one text field should set focus",
              which is marked P3/mozilla1.0 (normal)
From reading the comments in those bugs I don't get the impression that
this issue is likely to be fixed anytime soon. Hence this "hack".

Maybe voting for 58853/35087 would help?

Comment 32

[Jaime Rodriguez, Jr.]

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

Comment 33

[Jeremy M. Dolan]

If 58853/35087 aren't going to be fixed for PDT/0.9.5, what is this workaround
checkin waiting on? This bug locks up all of Nav every time I hit ctrl-f... no
way out... can't tab to cancel and ESC does nothing.

s/sr are over two weeks old

Comment 34

[jag (Peter Annema)]

Checked in to trunk and branch.

Comment 35

[Fabian Guisset]

Does anyone else find it bothering that textfield.select() doesn't focus the
textfield at the same time?

Comment 36

[Asa Dotzler [:asa]]

->0.9.6

Comment 37

[Hrvoje Niksic]

Q: Does the target change to 0.9.6 mean that the workaround for this bug will
not be present in 0.9.5?

Comment 38

[Chase Tingley]

No, the fix should be in 0.9.5 since it was checked into the trunk on 9/30.  It
looks like Asa was doing a mass-retarget of open bugs.

I'm not sure why this bug is still open, actually.  There may be an underlying
bug that caused the problem initially, but this may not be the right place to
address it.  

Comment 39

[sairuh (rarely reading bugmail)]

vrfy fixed using 2001.10.08.0x-0.9.4 [branch] comm bits on linux, winnt and mac
10.1.

Comment 40

[Jeremy M. Dolan]

vrfy fixed using linux trunk and 095 branch

Comment 41

[sairuh (rarely reading bugmail)]

i'm gonna vrfy this one [tested on mac 10.1 and winnt with 2001.10.08.xx-trunk
comm bits].

*however* i sometimes notice that [on the trunk, not with 0.9.4 branch so far]
Find in Page doesn't focus the textfield --a recent bug was filed on this, bug
103484, which i will reopen to cover this intermittent issue... eg, today i saw
it on Mac 10.1 with a one profile, but not another [both existing, non-migrated
ones].

Comment 42

[R.K.Aa.]

*** Bug 110715 has been marked as a duplicate of this bug. ***