341730 - Shortcuts (like Ctrl+T) do not work anymore while page is loading

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Frank Wein [:mcsmurf]]

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.

Comment 1

[Frank Wein [:mcsmurf]]

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

Comment 2

[Frank Wein [:mcsmurf]]

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).

Comment 3

[Frank Wein [:mcsmurf]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 5

[Simon Bünzli]

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

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Simon Bünzli]

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

Comment 9

[Darin Fisher]

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?

Comment 10

[Simon Bünzli]

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

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 12

[Darin Fisher]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch per comment 7, just in case

This just does what I said in comment 7.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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.

Comment 15

[Simon Bünzli]

(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

Comment 16

[Rob Campbell [:rc] (:robcee)]

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.

Comment 17

[Haudy Kazemi]

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.)

Comment 18

[:Gavin Sharp [email: [e-mail]]]

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

Comment 19

[Aaron Leventhal]

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.

Comment 20

[Anko]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

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").

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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...

Comment 24

[Boris Zbarsky [:bzbarsky]]

So it looks like bug 303260 covers the underlying issue.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch with more comments

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

Comment 26

[Boris Zbarsky [:bzbarsky]]

Attachment: Trunk version

Comment 27

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

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

a=drivers, please land on the 1.8.1 branch

Comment 29

[Boris Zbarsky [:bzbarsky]]

Fixed on branch.

Comment 30

[Adam Guthrie]

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

Comment 31

[Adam Guthrie]

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