167021 - URL bar loses focus when mouse enters document window

Status: RESOLVED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[Trevin Beattie]

I've just compiled the mozilla 1.1 release after having used 1.1beta.

When I click on the URL bar, it gets the keyboard focus, as expected.  But as
soon as I move the mouse into the document window, the focus is lost; I have to
move the mouse back and click on the URL bar again to continue typing.

The problem is only evident when a page is displayed (including the blank page,
"about:blank").  If the browser starts up with no page loaded, the URL will not
lose its focus.

I did not have this problem with the beta release.  In the beta version, the
focus stayed where I put it.

Comment 1

[Trevin Beattie]

In a follow-up for bug #167618, I found that the URL bar works properly in the
binary mozilla distribution.  Something went wrong with building it from
source.  (Note: I also built 1.1b from source, which didn't have a problem.) 
I'm recompiling now with altered configuration options to see which option is
causing the problems.

Comment 2

[Trevin Beattie]

I just found the cause!  This bug, and bugs #167617 and #167618, were all caused
by configuring mozilla with the option:

	--enable-default-toolkit=xlib

When I changed the default toolkit to gtk, cleaned, and rebuilt mozilla,
everything worked as it should.  (Cleaning is very important.  The first time
around, I reconfigured with --enable-default-toolkit=gtk, but recompiled without
'make clean' first.)

Now, can anybody tell me why we have the --enable-default-toolkit option, if it
doesn't work?  Better yet, how much work would be involved in reworking mozilla
to use the Motif toolkit?

Comment 3

[Andrew Schultz]

> Now, can anybody tell me why we have the --enable-default-toolkit option

did you make a complete build with "xlib" and have it still be broken, or only
the partial one that was also part "gtk"?

Comment 4

[Trevin Beattie]

Yes, I did do a complete rebuild from scratch yesterday morning (actually
overnight).  I've actually done several complete rebuilds with slightly
different options; that's why it took so long to get back with an answer.

Another thing I've found (among my several builds) is that using optimization
flags of "-O2 -march=k6 -fomit-frame-pointer -funroll-loops" causes mozilla not
to run at all.  It pauses, then exits without displaying any window or console
message.

So the other builds I optimized with "-O1 -march=k6".  The complete configure
command for the xlib build was:

configure  --with-system-jpeg --with-system-zlib --with-system-png
--with-system-mng --enable-default-toolkit=xlib --enable-crypto
--enable-extensions --disable-debug '--enable-optimize=-O1 -march=k6'
--disable-logging --enable-strip

This is the one that had the select/paste problems.  The very next build was
configured with gtk instead of xlib as the default toolkit; all other options
remained the same.  I then re-ran gmake to create a "dirty" build, tested it,
then ran "make clean" and gmake again for a clean build and tested that.

Comment 5

[Kenneth Herron]

Trevin, in comment 2 you imply this bug is specific to the Xlib toolkit. Have
you continued to build xlib-based versions of mozilla and do you know if this is
still a problem with xlib?

Comment 6

[Trevin Beattie]

No, I have not built mozilla lately with any specific toolkit (just using the
configure default).  I need a browser that works.  My latest build is on a new
computer system with Gnome 2, and I tried setting --enable-default-toolkit once
(I think to gtk), but mozilla wouldn't even compile.  So I left it out.

Comment 7

[Alexander Opitz]

Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.

Comment 8

[Trevin Beattie]

I'm sorry, but I cannot close this yet.  I have just built Mozilla 1.4 (release)
and tried the URL bar.  As long as the mouse remains within the URL bar after I
click on it, I can type there.  But as soon as the mouse leaves the text field,
I can no longer type.  And this time, the problem is manifest whether I'm on a
web page or a blank page.

(The build was done on RedHat 9.0 using the following configure options:
configure  --with-pthreads --enable-default-toolkit=xlib --enable-xft --enable
-crypto --enable-xinerama --disable-accessibility --enable-extensions --disable-
debug '--enable-optimize=-O2 -march=athlon' --disable-dtd-debug
)

I've also done a build with --enable-default-toolkit=gtk2, and noticed some odd
behavior in there as well.  After starting Mozilla, the first time I click in it
and start typing, navigation keys don't work (arrows, Ctrl-f, Ctrl-b, Ctrl-a,
etc.).  Regular characters and backspace still work just fine.  If I
subsequently click in the document window and then back in the URL bar, or if I
click on another application window and then back on Mozilla, navigation keys
work properly from then on.  The problem only manifests itself after Mozilla
first opens up and the keyboard focus has not changed.

In case it makes any difference, I'm using GNOME 2.2.1.

Comment 9

[Asa Dotzler [:asa]]

unable to reproduce with current linux builds on fedora core 1 or an older
severn beta.

Comment 10

[Trevin Beattie]

I am currently using Mozilla 1.4.1 with default-toolkit=gtk2 and Gnome 2.5.90. 
This is no longer an issue.  (Works for me too)