34813 - URL bar loses focus permanently

Status: VERIFIED DUPLICATE of bug 31485

(SeaMonkey :: General, defect, P3)

Description

[Chris Dunn]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.5 i686; en-US; m14) Netscape6/6.0b1
BuildID:    2000032406

When a URL is typed into the URL bar, enter pressed, and then the mouse is
clicked somewhere else or the browser window loses focus, it is impossible for
focus to return to the URL bar.  Clicking, tabbing, etc. have no effect.  Only
seems to happen in initial browser window.

Reproducible: Sometimes
Steps to Reproduce:
1.Let homepage load on browser startup
2.Type in a URL and hit enter



Actual Results:  The URL bar lost focus and I was unable to give focus back to it.

Expected Results:  Upon clicking on the URL bar, it should gain keyboard focus.

Comment 1

[Sean Richardson]

Unable to reproduce on WinNT with 2000-04-06-10-M15 after multiple trials.
Linux-only?

Comment 2

[Chris Dunn]

Haven't tried Moz on any platform other than Linux, so yes.  Actually I found
that I can reproduce this bug every time.  When a URL is typed and ENTER
pressed, the bar loses focus permanently.

I'm running Linux-Mandrake 6.0, XFree86 version 3.3.3.1, glibc2.1.1, kernel 2.2.5

Comment 3

[Andreas Franke (gone)]

[e-mail]: Please check if this a duplicate of my testcase 
in bug 32120. Does your homepage consist of frames?

Comment 4

[Andreas Franke (gone)]

Another example of the testcase I mentioned is described in bug 31485
with www.slashdot.org as homepage.

Comment 5

[Chris Dunn]

It seems to be a duplicate of the other two bugs you mentioned.  I was able to
reproduce it using slashdot as the homepage.  My homepage does consist of
frames, but it's on an intranet so I couldn't give you the URL.

Is mozilla dynamically linked against gtk+ on Linux?  If so, I should give you
my gtk+ version :

gtk+-1.2.3-6mdk

Comment 6

[Andreas Franke (gone)]

Since the homepage _has_ frames (like the testcase in bug 32120)
and the symptoms are the same as on slashdot (bug 31485), marking 
this duplicate.

Asa: I'm sure that this is the same as bug 31485 and the remaining issue
of bug 32120, and I'd like to have exactly one bug report that deals with
this issue. Unfortunately, these three bugs have different components,
and thus are assigned to different people, have different CC lists etc.
I think bug 31485 is best suited to become THE bug for this. 
Could you please help in finding out who can deal with this best? 
Is the "Editor" component the right one? I fear XPApps is not the 
correct thing because this is only reported on linux, as far as I 
can see. Bug 31485 has the highest severity, but I doubt it's the
correct one. On the other hand, I'd really like this to be beta.
Note that the workaround (reported in bug 32120: collapse and reopen
the url toolbar) is currently broken due to bug 35181 which I don't
expect to be fixed soon. And there are really two useful testcases
now: 
http://www.ags.uni-sb.de/~afranke/bug32120/ (a minimal frameset)
http://www.ags.uni-sb.de/~afranke/bug31485/ (<input type=password>)
This problem exists since I first tried mozilla (around M13), 
and I'd be happy to have some realistic ETA for a fix.

Thanks for your help.


*** This bug has been marked as a duplicate of 31485 ***

Comment 7

[Joseph Elwell]

marking verified.