Closed Bug 341730 Opened 15 years ago Closed 15 years ago
Shortcuts (like Ctrl+T) do not work anymore while page is loading
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.
Seems like this also occours on 1.8 branch so it's unlikely the bug here was caused by Bug 255942.
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).
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.
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. :(
*** Bug 342247 has been marked as a duplicate of this bug. ***
blocking1.8.1+, although we might change our mind depending on how scary the patch is.
Flags: blocking1.8.1? → blocking1.8.1+
Worst case, we back out the patch for bug 326645 and land the 126.96.36.199 patch instead...
*** Bug 342603 has been marked as a duplicate of this bug. ***
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?
(In reply to comment #9) I'm afraid not. This issue is still present in the 2006062803 Bon Echo nightly.
Could you give more precise steps to reproduce? e.g., specific sites, specific actions (key presses vs. mouse clicks, etc.).
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.
This just does what I said in comment 7.
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.
(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
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.
Version: Trunk → 1.0 Branch
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.)
*** Bug 344628 has been marked as a duplicate of this bug. ***
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.
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.
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").
Plussing for 1.8.1 per drivers meeting. Sounds like we should do comment 21, and sooner rather than later.
This has already been reviewed for 1.8.0 branch, but just in case...
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 229519 [details] [diff] [review] Patch with more comments a=drivers, please land on the 1.8.1 branch
Attachment #229519 - Flags: approval1.8.1? → approval1.8.1+
Fixed on branch.
*** Bug 345676 has been marked as a duplicate of this bug. ***
*** Bug 345927 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.