Closed Bug 280875 Opened 20 years ago Closed 13 years ago

Location bar occasionally stops accepting input - focus remains in page.

Categories

(SeaMonkey :: UI Design, defect)

SeaMonkey 1.1 Branch
x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: svl-bmo, Unassigned)

Details

(Keywords: regression)

Occasionally, hitting ctrl-l and trying to type in the location bar, nothing
will happen (although the current URL appears to be selected). When this is the
case, the location bar doesn't accept input in any way. Switching to a different
tab and typing in the location bar there seems to fix.
I haven't yet found steps to reproduce, but this _has_ happened to me several
times now (in the span of 24 hours).
This regressed between 20050111 and 2005020106. I don't see any relevant errors
in the javascript console, though I didn't have strict warnings enabled.
Ah, I just had it happen again. It's a focus issue, apparently. Mozilla shows a
cursor in the location bar, but arrow up and down still scrolls the page.
Switching to a different tab actually has the same problem there, but creating a
new tab does fix it. Still don't have steps to reproduce.

Has anyone else experienced this? If it's not unique to my system, I think this
should probably block 1.8b1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Location bar occasionally stops accepting input → Location bar occasionally stops accepting input - focus remains in page.
Just had this happen again while ctrl-clicking open a lot of tabs for
downloading old mozilla nightlies from the ftp site. Yet try as I might, I can't
find steps to reliably reproduce from that.

I'm going to pick a mozilla build from the the middle of the regression window
and use that as my main mozilla browser for a day to at least in that way try
and narrow the window. 
Aaron: if you happen to have an idea of any changes potentially being
responsible for this and can thus direct me as to what timeframe to focus on,
that would be helpful. For now I'll try 20050124, simply because that's the
oldest build on the ftp server.
Sander, still happens?   (I've never seen it)

have you tried a trunk build?

Yes, it still happens (I'm tracking branch at the moment, but am pretty certain I saw it when I last tested a trunk build a week or two ago as well). Hitting F6 moves focus to the location bar for real, and I do that nearly instinctively now, so it's less of an issue for me, but annoying nonetheless.
I've had this happen a couple or three times running SM 1.1a or 1.1b nightlies.  I think the  last one may have actually been with the official SM 1.1b release.  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061102 SeaMonkey/1.1b   

The times I've had it occur, I was on a page with form fields.  I could click around between the fields and Location field and the fields would seem to get focus (the vertical bar cursor would move to the field), but keyboard input would not be accepted.  I got unstuck by clicking on the desktop, then back into SM.  No idea how to reproduce.  :( 

Changed OS & Hardware to ALL since this is cross-platform.  Ooopsie, not empowerd enough to do that.
It is especially entertaining to hit CTRL-L, happily *start* entering text, then look up and notice only some URL content has been accepted by the location bar but somewhere along the line a page element has stolen focus
Can you reproduce with SeaMonkey v1.1.9 ?
Assignee: guifeatures → nobody
QA Contact: guifeatures
Version: unspecified → SeaMonkey 1.1 Branch
I still see it from time to time in 1.1.9.
OS: Windows 2000 → All
Component: XP Apps: GUI Features → UI Design
Haven't seen anything like this is in a long time.  (Heck, I barely remember this bug.) I'm guessing it went away with SM 2.0?  Maybe it's time to resolve it as WFM?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110704 Firefox/5.0 SeaMonkey/2.2
Agreed with WFM.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Probably fixed by the new focus manager code.
You need to log in before you can comment on or make changes to this bug.