bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Keystrokes lost between new window spawn command and actual spawn




Event Handling
17 years ago
8 years ago


(Reporter: Mike D, Unassigned)


Mac OS X

Firefox Tracking Flags

(Not tracked)




17 years ago
When you open a new window and start typing immediately in the location bar,
often the first half dozen to dozen keystrokes are lost, so instead of getting:
you will get
The same goes for mouseclicks and other events.  The event cue should not be
flushed or blocked upon a window open!!!
Also, a related bug: the focus is often lost out of the location bar, so
sometimes you will get
and then the cursor stops responding...

Comment 1

17 years ago
Reporter, this bug report is incomplete. Please review the Bug Reporting Guidelines at 
[http://www.mozilla.org/quality/bug-writing-guidelines.html] and, in the future, use the 
Bugzilla Helper at [http://www.mozilla.org/quality/help/bug-form.html] to submit bugs.

Marking Invalid pending more information.
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 2

17 years ago
Reopening per Reporter to collect more information.
Resolution: INVALID → ---

Comment 3

17 years ago
BuildID 2001112011.
Running on MacOS 9.2.1, Powerbook G3/400 (Pismo), VM off.
To reproduce:
 With Mozilla open,
 Type "Apple-N" (which opens a new browser window) and continue typing a URL
mmediately (i.e. don't wait for the window to open).

Results: at some point, the window opens and the cursor is set to the Location
edit field, and begins accepting your typed characters. However (this is the
bug) there are always some characters dropped.

Every other browser I've tried (IE, Netscape, ICab) performs correctly: All
characters that you type after the Apple-N are buffered correctly and show up in
the location bar, even if you are typing before the window is fully open.

One possible related fact: Mozilla opens new windows VERY SLOWLY (i.e. about 1
second after hitting Apple-N), whereas other browsers (Netscape, IE, etc.) open
the window in under 1/10th of a second. Thus, it <could> be that if I typed
really fast (or had a really slow computer), both Netscape and IE would drop
keystrokes too, but I'm not able to get this to happen, so I don't think it is
purely a speed issue.

Anyway, I've done a lot of mac programming and know that the event buffer is not
flushed unless you explicitly do it, so my guess is that the problem is that the
window is discarding keystrokes before the location bar edit field gets the
focus upon a window open.
Severity: major → normal

Comment 4

17 years ago
I confirm this occurs using 0.9.6 under both OS X and OS 9.

Note that I was able to cause the same problem in IE for OS X, although I had to
type much, much faster.
Ever confirmed: true
Summary: Keystrokes lost when window opens → Keystrokes lost between new window spawn command and actual spawn


16 years ago
Target Milestone: --- → mozilla1.2


16 years ago
QA Contact: madhur → rakeshmishra


16 years ago
QA Contact: rakeshmishra → trix

Comment 5

15 years ago
Assignee: joki → saari
QA Contact: trix → ian

Comment 6

15 years ago
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".


15 years ago
OS: Mac System 9.x → MacOS X

Comment 7

10 years ago
This is still a problem with Firefox 3.0.2 on Mac OS 10.5.5. Is this being investigated? I find it to be by far the most annoying problem with Firefox.
Assignee: saari → nobody
QA Contact: ian → events

Comment 8

8 years ago
I was still seeing this in 3.5.x on an Intel MacBook Pro running both Mac OS X 10.5.x and 10.6.x, and I'm now seeing it in Firefox 3.6.
Hardware: PowerPC → All


8 years ago
Blocks: 382445
You need to log in before you can comment on or make changes to this bug.