Closed Bug 42074 Opened 24 years ago Closed 24 years ago

URL bar focus problems: keystrokes ignored or caret is invisible

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: mjudge)

References

Details

(Whiteboard: [nsbeta2+][dogfood-]) 

2000060908

related to enderlite on windows, perhaps?  

If I type random letters in the URL bar (i.e. fsijfls) and press enter, the URL 
bar no longer accepts keyboard input.  also happens with file:/// urls.

I highly, highly, highly doubt this is an editor problem, but I can't stand 
browser-general :)
I actually have no clue what the problem is here.  after you press enter when 
typing non-http:// protocol urls, the URL bar seems to lose focus.  even when 
you try to set focus back, keyboard input doesn't work.  it's not until you 
switch windows and then switch back does the URL bar start functioning again.
Summary: no-protocol, random letters in url bar prevent further input → URLs without http protocol in url bar prevent further input
this is not an editor bug, maybe someone in DOn's group knows what to do -- any 
ideas Don?
Assignee: beppe → don
Component: Editor → Browser-General
removing myself from Cc: list
QA Contact: sujay → claudius
Blake, I'm confused, if you type 'adfghda' in the url bar and hit enter you trigger a smart-browsing keyword lookup. When that 
fails you get dumped into a netscape/google search. Which either produces results or doesn't. Are you saying this happens after 
all of that?
...
Oh wait, I did some more testing and yes it looks like you get locked up _while_ the above things are going on OR  if you click 
stop. I was able to continue typing shortly afterwards without doing anything special. If I let the page load though, i was able to 
continue typing just fine.

I noticed this whether I used a protocol (http) or not though.

were you pressing stop, waiting for the page to load, or trying to type as it was doing the lookup?
I see two potential problems:
1. Not being able to type while doing a lookup/page load
2. Still not be able to type after pressing stop.

Claudius -- you're right; has nothing to do with the protocol, and it only 
seems to happen while the page is loading or if you press stop in the middle.  
updating summary to reflect that; can someone test this on a platform other 
than win32?  If it's win32 only, I'd have trouble believing that it's not ender 
lite-related.
Summary: URLs without http protocol in url bar prevent further input → URL bar ignores keystrokes while page is loading, or if stop is pressed
This occurs on Linux as well, from the build that I pulled last night, at 1 am PDT.

Entry into text boxes is also VERY slow.

And the caret keeps flashing in the url bar, even when other fields have focus.
Well, it's not an XPApps bug either.  Can't seem to repro the problem ...
Assignee: don → ben
Target Milestone: --- → M16
OK, I can repro A problem, but not quite the way that Blake describes ... and it
appears to be cross-platform.

Just talked to Radha and she hasn't changed any URL bar code in weeks.  So who
fucked this up?

Mike, nobody on the Navigator team has even touched the URL bar code or focus
stuff in days, maybe longer.  Your the last person that _might_ have affected
this.  Can you help us out here and figure out who boned the URL bar?  We are
without clue.  Maybe Chris Saari can help ...
Assignee: ben → mjudge
Target Milestone: M16 → ---
yes, sorry about my original description - please ignore...it was pretty late 
and I didn't really know how to reproduce the problem or its symptoms, I just 
basically knew there was a problem.  there just seem to be general focus issues 
with the URL bar...after pressing enter in the URL bar, focus switches from the 
url bar to the content area.  apparently this is by design.  however, if you 
set focus back to the URL bar, you're no longer able to type in it.  I've also 
heard reports that people can't even set focus back to the URL bar at that 
point.

changing to ALL/ALL, this does seem to be xp
OS: Windows 98 → All
Hardware: PC → All
cc saari for any clues here
Blake, did this first show up on Friday, June 9?

OK, there seems to be a simple workaround for this: just click in the content
area and click back in the URL bar.  So leaf and I agreed that this shouldn't
hold the tree closed today.  But, I'm nominating this for dogfood.
Keywords: dogfood
*** Bug 42245 has been marked as a duplicate of this bug. ***
Moving over Cc list for dup'd bug.
A quick look at this in the debugger shows that after the return key is pressed,
the key events are being dispatched via the XUL document's EventListenerManager
instead of the one the input element uses when it works.

Is this a focus problem?
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.
Whiteboard: [nsbeta2+][dogfood-]
*** Bug 42297 has been marked as a duplicate of this bug. ***
We need to come up with a better summary for this bug, because of bugs like 
42297...I don't think the problem is limited to just that you can't type in the 
URL bar while the page is loading or if you press stop, because of the problem 
described in bug 42297.  I don't know enough about the core problem here, but 
I'd appreciate it if someone who does would update the summary to be more 
specific about the real problem.
mjudge and myself worked out a fix for this today. He'll check it in tomorrow.

A more appropriate summary would be: Ender lite exposed new focus code paths and 
bugs. Actually, the current summary is more human readable :-)
*** Bug 42379 has been marked as a duplicate of this bug. ***
*** Bug 42556 has been marked as a duplicate of this bug. ***
*** Bug 42664 has been marked as a duplicate of this bug. ***
I believe this may be related to bug 31485. That bug, basically was to do with
the location bar not accepting input. There was a work around which was to set
the focus to the location bar when Mozilla started up, which fixed that
particular case, and the bug was marked resolved. However, I don't believe the
underlying cause was ever fixed. It may be that this bug is a manifestation of
the same thing.

no, I don't think they're related.  That bug was fixed over a month ago, and 
this seems to have more to do with enderlite...
*** Bug 42571 has been marked as a duplicate of this bug. ***
This seems fixed.  I cannot reproduce the problem on Linux build 2000061618.
setting to m16, where + bugs live
Target Milestone: --- → M16
this is still a problem, at least on winNT using 2000.06.21.08 optimized
commercial bits.
M16 has been out for a while now, these bugs target milestones need to be 
updated.
this is fixed on the tip. are you testing on the branch?  please try the current 
m17 nightlies.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I am seeing this in the latest Win32 build 2000-06-22-08-M17 comm.
Status: RESOLVED → REOPENED
OS: All → Windows 98
Hardware: All → PC
Resolution: FIXED → ---
Actually I see this on windows NT too. If I enter some random characters in the 
url bar, the browser takes me to the google.netscape.com query results page and 
then the url textfield loses focus when I click with the mouse. But I can 
certainly type in the url textfield.
moving over to m17, adjusted priority and severity
Severity: major → critical
Priority: P3 → P1
Target Milestone: M16 → M17
*** Bug 43924 has been marked as a duplicate of this bug. ***
updating summary to reflect more general problem and catch dups
Summary: URL bar ignores keystrokes while page is loading, or if stop is pressed → URL bar focus problems: keystrokes ignored or caret is invisible
*** Bug 44165 has been marked as a duplicate of this bug. ***
fixed as of tonite
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
VERIFIED Fixed with 2000070608 build
Status: RESOLVED → VERIFIED
Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
This bug is *not* fixed.
Comment #10 describes precisely how to reproduce it.
I was trying to figure out what was going on with my sometimes losing ability to
type.
It was occurring more frequently recently as I used up my connection with
bittorrent.

Looks like I'd try to interrupt a slow url load by hitting stop or refocusing to
the URL window.
Once I did this, I was no longer able to type *anywhere*  (textareas, urlbar,
googlebar, move cursor within content area...).

Using a gentoo ebuild of the 1.4 release.
GTK2, xft.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.