Frank Wein [:mcsmurf] Reporter
	Description • 18 years ago

In current trunk builds it seems (some?) shortcuts in the browser do not work anymore while a page is loading. For example with older builds it was possible to use Ctrl+T (Open New Tab) while a page was loading, with current builds this sometimes fails. This bug here might have been caused by Bug 255942, but i'm not sure yet.

	Frank Wein [:mcsmurf] Reporter
	Comment 1 • 18 years ago

Seems like this also occours on 1.8 branch so it's unlikely the bug here was caused by Bug 255942.

	Frank Wein [:mcsmurf] Reporter
	Comment 2 • 18 years ago

This regressed on trunk between 2006-06-07 09:00:00 and 2006-06-08 09:00:00 (tested with SeaMonkey) and on 1.8 branch between 2006-06-07 04:00:00 and 2006-06-08 04:00:00.
bz: Looking at the checkins it seems likely that your patch from Bug 326645 might have caused this bug here. Can you confirm? I wonder if anything can be done about this regression (it's only a minor regression so and not that visible).

	Frank Wein [:mcsmurf] Reporter
	Comment 3 • 18 years ago

Oh I forgot: To reproduce either run some Bugzilla or Bonsai query (which should take a bit longer to process/load). While it then says "Transferring data from bonsai.mozilla.org" in the status bar but not rendering anything yet (so blank/white screen), try to use any shortcut like Ctrl+T, Ctrl+R, etc. It will not work in 99% of cases.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 4 • 18 years ago

Yeah, bug 326645 could have caused this if either the focus code or command handling or some such depended on the broken document teardown behavior...

bryner, aaronlev, neil, mats, any ideas here?  This is sorta blocking us fixing a crash bug on the stable branch.  :(

	Simon Bünzli
	Comment 5 • 18 years ago

*** Bug 342247 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 6 • 18 years ago

blocking1.8.1+, although we might change our mind depending on how scary the patch is.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 7 • 18 years ago

Worst case, we back out the patch for bug 326645 and land the 1.8.0.5 patch instead...

	Simon Bünzli
	Comment 8 • 18 years ago

*** Bug 342603 has been marked as a duplicate of this bug. ***

	Darin Fisher
	Comment 9 • 18 years ago

I'm not able to reproduce this bug using the 6/25 nightly 1.8 branch build Bon Echo on Windows XP.  Could something have fixed this?

	Simon Bünzli
	Comment 10 • 18 years ago

(In reply to comment #9)
I'm afraid not. This issue is still present in the 2006062803 Bon Echo nightly.

	David Baron :dbaron:
	Comment 11 • 18 years ago

Could you give more precise steps to reproduce?  e.g., specific sites, specific actions (key presses vs. mouse clicks, etc.).

	Darin Fisher
	Comment 12 • 18 years ago

We'll keep an eye on this during the beta1 cycle.  If we can get more information about how to reproduce this that'd be helpful.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 13 • 18 years ago

This just does what I said in comment 7.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 14 • 18 years ago

Maybe we should take the "just do a null-check" thing just to be safe.... The mRootContent thing seems like a better general approach, but if focus code is involved I'm just not sure it's worth it.

	Simon Bünzli
	Comment 15 • 18 years ago

(In reply to comment #11)

Steps to reproduce (cf. bug 342247):
1. Open a new tab and load a page which isn't cached and which doesn't load too
quickly (e.g. https://bugzilla.mozilla.org/)
2. As soon as the tab title switches from "Loading..." to the page's title, hit
[Esc] or [Ctrl]+[T] or [Ctrl]+[Tab] or [Alt]+[F] or any other key combo handled
by Firefox

	Rob Campbell [:rc] (:robcee)
	Comment 16 • 18 years ago

What is the build string on this? I'm also seeing similar behavior under OS X in Ffx2b1 (2006071020). I can't reproduce it by partially loading a page and hitting a keystroke but it seems to occur when changing window focus.

	Haudy Kazemi
	Comment 17 • 18 years ago

I think I've seen this since at least the beginning of July.  (I'm not on my Bon Echo testing machine right now.)  I remember reproducing it by these steps:
1. position the mouse cursor over the 'home' button (I have the default Bon Echo home page...I think it is http://www.mozilla.org/projects/bonecho/ )
2. press Ctrl-T to open a new tab
3. quickly click the 'home' button
4. quickly press Ctrl-T to open another new tab (while 'home' is still loading)
5. observe that Ctrl-T doesn't work right while the page is loading.
6. (if you didn't see the funniness yet, try repeating the pressing of Ctrl-T and the home button close together in time.)

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 18 • 18 years ago

*** Bug 344628 has been marked as a duplicate of this bug. ***

	Aaron Leventhal
	Comment 19 • 18 years ago

How can this be minused for 1.8.1 and be so major? It does not have the access keyword or anything that would have gotten my attention.

I don't see why the patch has to be scary if someone finds the regression window and sees what broke it in the first place.

	Anko
	Comment 20 • 18 years ago

Forgive me if I'm misunderstanding, but I'd just like to chime in and say this should be blocking for Firefox 2.0

Keyboard shortcuts that only work some of the time really makes this product look bad from a new users perspective - "Oh yeah, that's a known bug, it works some of the time".  Also from an accessibility perspective, this bug makes Firefox next to useless.  

This bug really will give Firefox a bad name.  It's an extremely prominent bug.

Sorry again for comment spam, but this is extremely important for 2.0.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 21 • 18 years ago

Aaron, there's no need to figure out the regression window.  See comment 4.

I think that if there's no progress on this from someone who actually knows the focus code we should just land attachment 227501 [details] [diff] [review] on trunk and 1.8 branch.  It'll be a perf hit, but I really don't have the time to dig into focus stuff any time in the near future (hence the "helpwanted").

	David Baron :dbaron:
	Comment 22 • 18 years ago

Plussing for 1.8.1 per drivers meeting.  Sounds like we should do comment 21, and sooner rather than later.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 23 • 18 years ago

For debugging the focus issue, just loading the following:

  javascript:void(document.removeChild(document.documentElement))

Will break all keyboard shortcuts for that tab/window.  Easier than trying to catch pages in mid-load...

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 24 • 18 years ago

So it looks like bug 303260 covers the underlying issue.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 25 • 18 years ago

This has already been reviewed for 1.8.0 branch, but just in case...

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 27 • 18 years ago

Fixed on trunk.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 28 • 18 years ago

Comment on attachment 229519 [details] [diff] [review]
Patch with more comments

a=drivers, please land on the 1.8.1 branch

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 29 • 18 years ago

Fixed on branch.

	Adam Guthrie
	Comment 30 • 18 years ago

*** Bug 345676 has been marked as a duplicate of this bug. ***

	Adam Guthrie
	Comment 31 • 18 years ago

*** Bug 345927 has been marked as a duplicate of this bug. ***