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.
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.
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?
> 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"?
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.
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?
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.
Reporter can you reproduce this bug with a newer build (1.4 final)? If not, then please close this bug as worksforme. Thanks.
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.
unable to reproduce with current linux builds on fedora core 1 or an older severn beta.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
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)
You need to log in before you can comment on or make changes to this bug.