126843 - (---------) Occasionally unable to get Focus set to URL bar and other text fields

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Paul]

If the URL bar has focus, and you "tab" out of it, it will not accept focus
again.  Also, when 
creating a new Tab, the URL bar will not take focus.  Also, on certain pages,
text fields
will not take focus.  The later seems to be due to javascript within the site.

Comment 1

[Sergei Dolgov]

There is another issue with URL entering. It locks if "Show List" option in
Smart Browsing is enabled. Especially badly it locks if there is enabled search
for matches outside already visited pages.Really i can live only with "show
list" disabled.

Comment 2

[Paul]

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

Comment 3

[khindenburg]

Using Linux, Mozilla build 2002031008, this bug happens a lot.  I first thought
it was due to 'tabs', but even with tabs disabled, you are unable to enter text
into the url field, as well as text fields (ie can't get focus).  The only way
to get rid of this is to close the browser.  0.9.8 did NOT have this bug.  This
affects simply text fields like google search box, yahoo box, hotmail login, etc...
I have found no way to reproduce it everytime.

Comment 4

[Prognathous]

Same here.
Tested under BeOS 5.1/Dano, not the best test platform, but I 
don't think it's related.
BTW, The Win32 version works fine.

A (poor) 
workaround is to use the "Open Web Location" from the File-Menu, but this too 
sometimes lock.

Comment 5

[Spiros Ioannou]

Confirming on win2k, nightly build of 2 Apr. 
Re-trying today's build, but this reproduces rarely.

Comment 6

[Michael Lefevre]

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

Comment 7

[Colin S]

This bug can only be squashed by closing the ENTIRE browser window (when using
tabs, this is a major problem) and invoking a new window.

MAJOR bug, but was unable to change severity.
Also, occurs on Windows 2000 as well as BeOS, but was unable to change OS to ALL.

Comment 8

[Sergei Dolgov]

Attachment: not perfect but fix for lot of focus-related issues

Though it seems not perfect solution, it cures lot of focus-related bugs
previously reported here.
There is far more advanced solution e.g. in GTK and Qt to track focus, but...

Comment 9

[Sergei Dolgov]

Attachment: not perfect but real fix for focus-related issues

Sorry - previous attachment was wrong (whole nsWindow.cpp instead diff) - so
please remove it.

In reality, there are more sofisticated and advanced focus tracking solutions
for other platforms, e.g. for GTK and Qt, but this one seems working.

Tested on 30.Apr.2002 sources.

Related to bugs:
http://bugzilla.mozilla.org/show_bug.cgi?id=137510
http://bugzilla.mozilla.org/show_bug.cgi?id=68518
http://bugzilla.mozilla.org/show_bug.cgi?id=128753

and maybe other

Comment 10

[Paul]

Comment on attachment 81943 [details] [diff] [review]
not perfect but fix for lot of focus-related issues

marking obsolete

Comment 11

[Paul]

This does seem to fix things.  Nice work.
As for the patch, it should be cleaned up a bit.  
Remove the comments inline with the code for the for the first segment, and
remove the commented code and fix the indentation in the second segment.
As per some of the other comments about this happenning under Win2k as well,
check to see if there is a bug report for win2k, as this bug is really BeOS
only, even though the symptoms may be occurring on other platforms.
Another note: when tabbing out of the url bar, the main document view gets
focus, not any of the items within it.  So, a second tab key press takes you
right back to the url bar.  If you click in the main view, tabbing will take you
from link to link and to form widgets.  After the last item that can get focus
in the main view is reached, the URL bar gets focus, as expected, but then a
subsequent tab focuses the main view again like before.  The main view itself
should not be able to gain focus, would be my guess.  Can we prevent this?

If you clean up the patch, and possibly find a solution to the issue I just
brought up, I will give this my r=

Comment 12

[Paul]

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

Comment 13

[Paul]

Sergei, I am assigning this bug to you.

Comment 14

[Sergei Dolgov]

Paul, not only this issue  with tabbing appeared, but also another one:
If you some load page, and then open any link via right-click menu in New Window
- text in URL bar in this new window cannot be changed (though, may be selected).
Dunno if it is related to same reason as focus tabbing issues or is caused by
bug in "common" Mozilla code.

But what i can say about tabbing issue - some other platforms implement specila
handling in SetFocus for "TopLevelWindow" or "TopLevelWidget". Maybe i should
investigate it more detailed.
Also, please check if above problem with URL-bar appears in your builds with my
focus patch, because i changed some code in TextWidgetBeOS part - and it maybe
also the reason here.

Comment 15

[Sergei Dolgov]

Paul, seems I got origin of problem with new window  - there is call
widget->SetFocus(PR_TRUE) in dom/src/base/nsGlobalwindow.cpp in method
GlobalWindowIml::Focus(). As our SetFocus implementation does not handle this
case (PR_TRUE), e.g. by setting focus for any BView - focus event remains
undispatched and so on.

Comment 16

[Prognathous]

Good luck at the helm, Sergei!

I tested the latest nightly under 5.1/Dano and it still shows this problem very
often.
I would really like to test this under 5.03Pro, but for some reason it does not
install properly.

We really need to fix this, because other than stability issues and slow
loading, this is truly the biggest problem with Bezilla.

The Severity of this bug should be set to Major, not Normal.

Comment 17

[Paul]

First, Dano is unsupported, and should not be supported.  Period.
Second, this is NOT a major bug.  Yes, it is annoying.  But, the system is still
functional, and you can get focus back to the text field.  (Usually what I do is
right click the field, then I can type in it again).  This, however, does not
come up for me very often.

Sergei, as you have stated, I think there is a lot more needed to fix this
properly.  Focus has been a problem within the beos port for a long time.  A
couple small changes will not fix things.  Yes, we will need something to track
the focus of widgets, like the other ports.  We must remember, mozilla likes to
controll everything, which is very contradictory to the way things are done in
beos.  

Comment 18

[hacker formerly known as [e-mail]]

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

Comment 19

[Sergei Dolgov]

Attachment: Patch for focus issues.

Seems fixes lot of problems. Replaces previous patch.
Should be revised quickly...without it 1.0 release for BeOS is too buggy

Comment 20

[Sergei Dolgov]

Patch 
http://bugzilla.mozilla.org/attachment.cgi?id=86741&action=view
also helps in http://bugzilla.mozilla.org/show_bug.cgi?id=138761
(without it select-by-drag needs additional first click on page text)

Comment 21

[Lee Sam]

Maybe related to bug <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=146853">146853</a>?

Comment 22

[Sergei Dolgov]

2 LeeSam
With last patch this problem (bug 146853) disappeared from BeOS.
It was happened here in some special builds where case PR_TRUE==aRaise were
dropped without any handling.

But it is possible for Windows, because i didn't notice in Windows code any
special threatment or check for situation if window/widget was recently already
activated.
As far as i can catch, BeOS SetFocus() code was done initally following rather
Win code, than gtk or any other UNIX-related.
And last patch follows some approach from gtk build 

Comment 23

[Sergei Dolgov]

Attachment: correction of previous

workaround for password dialog windows in previous patch causes problems with
copy/pase via menus in 1.0. So removed

Comment 24

[Sergei Dolgov]

Attachment: patch for 1.0.0

Last patch working on my home computer.
What works: no infinite loops, no blocking of focus in new tab and windows URL
bars (even if opened by link download), no blocking input in password dialogs,
ability to move with TAB key from URL-bar to page content, ability to scroll
downloaded page immediately, working from first click selecting by drag (bug
138761).

Issues: sometimes needs double click to put focus in text input field. Password
dialog first field don't get focus automatically on activation - needs click in
input field.

Comment 25

[Paul]

Sergei,  on the last line added in the patch, you have an "s", probably an accident.
Also, I would remove the line:
 //DispatchFocus(NS_GOTFOCUS);//workaround for focus 
as it is commented out.

Other than that, it seems to work.  r=arougthopher
If you don't have any other changes, I will check this in.

Comment 26

[Sergei Dolgov]

do it, Paul. At least we'll have some working solution

though, on my todo list:
implement Raise (autoset focus properly in newly created windows)
revise KILL_FOCUS case.
Maybe i will open later another bug when get it done, or reopen this one

Comment 27

[Paul]

Attachment: updated patch, fixes type-o and indentation

I removed the type-o I mentioned, and reformated the entire file, for 
consistency.
Sergei, if you could just check this quick, to make sure I didn't miss 
anything.  If I didn't, I'll check it in.

Comment 28

[Sergei Dolgov]

Attachment: to check-in

Seems final to this bug
Added gJustGot* handling (via callback from BWindow::WindowActivated()). Added
focusing on first inpput field in dialogs on creation/activation.

Comment 29

[Sergei Dolgov]

Attachment: idents

Stupid AI in editors - it handles tabs as it wanna.
Same as previous

Comment 30

[Paul]

This has been checked in.

Comment 31

[Paul]

found a minor problem in the patch, after being checked in.  reopenning to 
add minor change/patch

Comment 32

[Paul]

Attachment: patch to above patch

fixes "minor" problems with above patch, where an assertion was being called.
also, I removed the unused arguments being passed, and cleaned up the 
OnActivate method.

Sergei, are these changes ok with you?

Comment 33

[Sergei Dolgov]

seems OK

Comment 34

[Paul]

the latest patch was just checked in.
Sergei, could you verify that all is ok with this now :)

Comment 35

[Sergei Dolgov]

r=[e-mail]