Closed Bug 31485 Opened 24 years ago Closed 23 years ago

Location field (URL bar) becomes inaccessible (can't set focus, click & edit don't work)

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: gabriel, Assigned: saari)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Minimal testcases (frames, www.slashdot.org, google.com)
1.60 KB, text/html
Details 
When Mozilla is first started it is possible to click in the location bar and
enter text. After loading a few pages, clicking in the bar has no effect, i.e
the caret does not appear. I am now using version 2000031013.
moving to editor...

reporter - are you seeing this on newer builds?
Assignee: cbegle → brade
Component: Browser-General → Editor
QA Contact: asadotzler → sujay
I will check and see. It doesn't happen very often, and I've not figured out how
to reproduce it consistently.
I've not seen this for a while with the latest builds. I think you can close it
now.
resolving as fixed per reporter's comments
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified in 3/28 build...
Status: RESOLVED → VERIFIED
Please reopen this, as I am seeing it again in linux build 2000040109. I start
up Mozilla, which goes to my home page (www.slashdot.org). Once this has loaded
I delete the 'slashdot' and type 'mozilla' and press return. After this, I
cannot set focus to the location bar. In the terminal I see this error:

Gdk-CRITICAL **: file gdkgc.c: line 288 (gdk_gc_unref): assertion `gc != NULL'
failed.

reopening bug per bug author
Status: VERIFIED → UNCONFIRMED
Resolution: FIXED → ---
Changing severity to major, as it should be easily reproducible.
Severity: normal → major
Fix for 34473 may have fixed this too. Perhaps pavlov can confirm this ?
I can't reproduce this....
Maybe it's a version thing...I'm using gtk 1.2.6-6mdk.

Gabriel, are you able to reproduce this using a current version of mozilla?
The problem is *still* there with 2000040708. I am still seeing the gdk error !
Changing to critical, it's totally stopping me from using Mozilla ATM !
Severity: major → critical
Gabriel--what window manager are you using?  Can you tell us more about your 
setup so we can try to reproduce this?

I'm using Enlightenment 16.1-devel-9. I'm gonna try upgrading to the latest
stable release of E (16.4) and see if that makes anything difference. Anything
else you need to know about my config (Linux 2.2.14, AMD3) ?
OK - I think I got it. It's actually quite tricky to reproduce. First, you have
to set your homepage to http://www.slashdot.org. Exit and restart Mozilla using
"sh ./run-mozilla.sh". Wait for Slashdot to load completely. Then click on the
location bar, and change it to http://www.mozilla.org. Hit return. Allow the
Mozilla page to load completely. Then try clicking in the location bar again.
It's important that a) you set your home page to Slashdot, and b) that you allow
both pages to load fully. Hope this helps !
The symptoms are the same as in my testcase reported in bug 32120,
where www.slashdot.org is replaced by my homepage, or simpler
	http://www.ags.uni-sb.de/~afranke/bug32120/
The windowmanager should not be relevant, since I saw this under
KDE and fvwm95-2.
CC'ing pavlov and me. Can confirm that this is the same symptom
as my testcase. The page source of slashdot seems to be quite
different, but this really is the same bug.
Confirming bug, adding testcase keyword.

I tried to find the minimal fragment of www.slashdot.org
that causes this. The following seems to be minimal:
<html>
<body>
  <form><input type=password></form>
</body>
</html>
So this is a different code than the other testcase,
but the effects are identical.

If nobody objects, I'll close bug 32120 again
because this bug seems more appropriate to 
discuss my testcase.

To reproduce:
1. Set your homepage to http://www.ags.uni-sb.de/~afranke/bug31485/
2. Restart mozilla, wait till the homepage is loaded.
3. Click into the location field. 
4. Press return (page gets reloaded, Gdk-Critical messages appear)
5. Click into the location field again. No cursor appears, no typing possible.

Bug 32120 differs from this only in that the hompage code contains a
frameset instead of an password input field.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
*** Bug 34813 has been marked as a duplicate of this bug. ***
I just checked, and I can also reproduce both test cases in NS PR1.
This is a focus issue -- the focus isn't getting through to the text field.

But Mike and Hyatt are in the process of rewriting the event handling for text
fields (see bug 34896) and anything done about this bug before they complete
that is basically a waste of time.

BTW, the repro instructions don't work on a debug build, because debug builds
start up pointed at the smoketest instruction page rather than the home page. 
An easier way to repro is just to run mozilla as:
  mozilla "http://www.ags.uni-sb.de/~afranke/bug31485/"
then click in the urlbar, hit return, wait a while, then click in the urlbar
again.

Note that after the first click/return, you see a dns message in the status line
that never goes away; after the second, you see a message about loading the page
which also never goes away.  We might have some netlib problems here, but with
any luck they're not related.
Assignee: brade → saari
Depends on: 34896
Akkana: 34896 ? Are you sure that's the right bug ?
Yes, that's the one.  Mjudge and Hyatt are going to rewrite the handling of text
fields (very screwed up right now), which will cause all the event and focus
handling involving text controls to be rewritten.
*** Bug 35976 has been marked as a duplicate of this bug. ***
*** Bug 32120 has been marked as a duplicate of this bug. ***
Merging CC lists from all bugs I've marked dup.
Note that bug 32120 was marked XPApps and scheduled for M16.
Extending summary, hoping that this bug will show up in more queries.

From bug 35976, we've got a third test case: google.com (see attachment).
The minimal fragment here consists of a javascript function that is 
triggered "onLoad" to give focus to an <input> field in the body.

This bug is also triggered by editing the URL manually directly after 
opening a new navigator window, which is quite frequent.

Note that the Gdk-CRITICAL messages do not appear in the shell output any more
(except in the M15 branch).
Also note that each time this bug is triggered we're leaking a webshell.
Summary: Clicking in location bar doesn't always work → Location field (URL bar) becomes inaccessible (can't set focus, click & edit don't work)
Also from bug 32120, the workaround for this problem is to collapse and
uncollapse the toolbar containing the URL bar, but that is not currently 
possible because of bug 35181, "Using grippie to collapse toolbars completely 
hides them" -- there is no way to get them back, short of opening a new window.
I can't understand this. I downloaded the M15 milestone and tried this out with
the Slashdot/Mozilla combination. As I expected the bug showed up. Now however,
I can't reproduce it any more in the milestone - the bug seems to be gone, but
it was definately there !!! This is weird...(unless Slashdot suddenly changed
their page ?)... 
The randomness is seen by other people too. I've had friends report it, but only
on linux which makes me wonder if this is actually a different bug that Pav has
been working on.
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Perhaps it's something to with resizing the page ?
Text field editing is broken in 2000042113 Mac build--broken completely all the time, not 
just at random. (Didn't experience this in the M15 milestone build.)
Changing severity to normal, critical is reserved for crashes, data loss and 
severe leaks; being easy to reproduce doesn't make it critical.
Severity: critical → normal
Depends on: 35181
I've not yet figured what causes the randomness, but deleting ~/.mozilla and
creating a new profile seems to always enable the bug to be reproduced.
Interestingly, the location field works if I launch Mozilla by dropping a local HTML file onto 
the Mozilla icon. (This is on Mac OS.)
*** Bug 32849 has been marked as a duplicate of this bug. ***
Seems to me that this has been fixed between 2000042709 and 2000042809
(PC/Linux). Is anyone still seeing this with a sufficiently recent build?
Maybe with different steps to reproduce?

There was a 5-lines-fix by brade%netscape.com for bug 35184 "Location bar
doesn't accept drag and drop until it initially gets focus", which as a 
side-effect fixed bug 30472 "Inconsistant selection bahavior in location/URL
bar" and might also have caused this problem to go away:

04/28/2000 06:33 brade%netscape.com 
mozilla/xpfe/browser/resources/content/navigator.js 1.150 
	fix bug #35184; give urlbar focus so that the
	editor is activated and d&d can work properly 

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/browser/resources/content&command=DIFF_FRAMESET&file=navigator.js&rev1=1.149&rev2=1.150&root=/cvsroot

CC'ing brade.
Looks indeed like it's working (build 2000050608). The focus seems to be set to
the location bar automatically when mozilla starts up, which appears to fix the
problem. I'm not sure how good an idea that is, but it should do the trick until
we get the 'real' solution  ( bug 34896 ?). Anyway I'm happy :-) I would say
mark it as fixed unless anybody has any objections. 

resolving as fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified in 5/8 build.
Status: RESOLVED → VERIFIED
I'm having address bar focus issues that might be related to this problem. 
Mozilla 0.9.1 on MacOS 8.6 and Red Hat Linux 7.1 -- same problem on both platforms.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Ed, have a look at bug 83919. It might be that.

There's also bug 82534.

Reclosing this under the assumption that any problems are now covered by 83919
or 82534. If they are not, please reopen with a full description.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
whew!

verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: