Ed Avis Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070529 Minefield/3.0a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070529 Minefield/3.0a5pre

If you open a new tab and enter some keystrokes quickly, the keystrokes are lost.  This is an instance of the more general bug: typing a particular key sequence quickly should have the same effect as typing the same key sequence slowly, but often does not.

To reproduce, preferably start Firefox on a fairly slow machine.  (I can reproduce this on a 3.2GHz Xeon, but using a debug nightly build.)  Type quickly:

Ctrl-Tab h t

Expected result: a new tab opens and 'ht' is entered in the address bar, as if beginning to type a URI.

Actual result: if you do it quickly enough, the new tab opens but the 'h' keystroke (and sometimes the 't' as well) is lost.

By contrast, if you leave a one second gap between keystrokes then the behaviour is as expected.

It will be easier to reproduce this on a slow or heavily loaded machine.

The important question here is whether this is considered a bug.  In my opinion, the app should not behave differently just because the machine is running slowly.  It should give the same results, although it may take longer to do so.  If this principle holds, there are other similar bugs to be fixed.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

	Thomas F. O'Connell
	Comment 1 • 15 years ago

I'm seeing this in Firefox 3.0.x and 3.5 on a Mac, as well, for new tabs and new windows.

If this becomes confirmed as a bug, the platform should probably be updated.

	Thomas F. O'Connell
	Comment 2 • 15 years ago

I have not been able to find a duplicate bug, so I went ahead and updated the platform.

	Thomas F. O'Connell
	Comment 3 • 15 years ago

I'm using Firefox 3.5.3 on a new MacBook Pro 2.26 GHz Intel with 2GB RAM, and I'm still seeing this issue. I see it in new tabs and windows, so I updated the description.

	Thomas F. O'Connell
	Comment 4 • 15 years ago

Well, I just discovered bug 109404, so maybe the Mac bug is different from Windows? Is this a duplicate, or should I restore the platform to Windows?

	Eli Greenberg
	Comment 5 • 13 years ago

I'm seeing this on Mac using FF 4.0.1 as well. :(

	Daniel Griscom
	Comment 6 • 13 years ago

I see this on Mac OS X 10.5.8, 2 x 2.8 GHz quad-core Xeon Mac Pro, FF 4.0.1. It's very easy to reproduce when opening new windows. This has been around for quite a while. My assumption is that the last thing the "New Window/Tab" code does is flush input events; it shouldn't.

	Wayne Mery (:wsmwk)
	Comment 7 • 12 years ago

FFankie, can you reproduce?

	Frankie
	Comment 8 • 12 years ago

WFM on my current Mac (2011 i7). I'll try to test on an older Mac some time.

	Daniel Griscom
	Comment 9 • 12 years ago

Reproduced with Firefox 11.0 running on Mac OS X 10.6.8 on a MacBook Pro. Easy to reproduce: type "Command-N" rapidly followed by a letter; the letter should appear in the address bar, but doesn't. Can be quite annoying.

	arpita.siddiquee
	Comment 10 • 9 years ago

I have tried to reduce it and it's working. No issues found.

Firefox Version -37.0
User Agent -
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Os- windows 7

	Daniel Griscom
	Comment 11 • 9 years ago

I just tried (OS, FF and hardware greatly updated from when I could reproduce it) and can't reproduce the problem. So, it looks like it's been fixed.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0

	Wayne Mery (:wsmwk)
	Comment 12 • 9 years ago

Thanks for the update