Closed Bug 70484 Opened 20 years ago Closed 18 years ago
browser windows go 'keydead': keyboard stops working
BUILD ID: 2001022705 Sorry for filing this under Browser-General but I really have no idea.... For the last few builds I have noticed that keyboard input will just randomly stop working on a window-by-window basis in mozilla. When this happens the following things don't work - typing in the location bar - typing in a text input box - keyboard shortcuts (e.g. C-n for new window, C-w for close window) Although the location bar doesn't work correctly in these keydead windows, it does respond to some keystrokes. For example if I type a lower-case 'f' into a keydead window which has some forward history, it will act as though I clicked on the forward button. I have put off reporting this bug for a few builds now since I wanted to see if I could notice a pattern for what was causing it. I have not yet noticed any such pattern. The only thing I can say is that no window has gone keydead on me while I was typing in it.
*** Bug 70486 has been marked as a duplicate of this bug. ***
Maybe this is differently but, can you activate your taskmanager, when it happens, to see if the CPU usage is 100%! That might cause this bug, it's the same for me. When it happens, I press CTRL-ALT-DEL, and then click on the taskmanager, then the CPU usage drops to something like 5% and I can work again! Note, I'm also using NT.
One way to get mozilla into this "keydead" state is bug 30841, "Double right- clicking on a page disables keyboard".
I don't see any extra CPU activity but I can confirm that the double right click does in fact produce a keydead browser window. That control-alt-delete task manager hubbub does not seem to have any effect. The only thing to do is open a New Navigator Window using the mouse.
I looked at <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=30841">30841</a> and the symptoms are the same but I get this all the time and I without double-right-clicking. I do use single-right-click Open Link In New Window a lot but I'm pretty sure it's only a single click. I just tested it a few times and that by itself does not cause keydeadness.
OK, one more symptom: As I noted before a lowercase 'f' typed into a keydead window causes the Forward action to be executed. I just noticed that an 'l' (lowercase 'L') does a Select All. Both of these correspond to keyboard shortcuts on the rightclick popup. Sounds like someone needs to figure out a more bulletproof method of managing popups.
Ok, I will file a new bug for this issue, and sorry for the possible confusion.
Confirmed Platform: PC OS: Windows 98 Mozilla Build: 2001022805 Its a very hard one to track down. All of a sudden the keyboard does go 'keydead'. I dont think it 30841, very odd and seems to happen randomly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think I've seen this too lately.
over to event handling
Assignee: asa → joki
Component: Browser-General → Event Handling
QA Contact: doronr → gerardok
I would just like to add that this is currently the bug in mozilla which annoys me the most.
Most of these keys things tend to be focus related. I'm going to bounce this one of saari to see if he recognizes it.
Assignee: joki → saari
Resetting priority, since the priority should only be set by the owner of the bug. (Jeff, you can vote for this bug if you want.) Setting severity to major.
Severity: normal → major
Priority: P1 → --
FYI: I used the 0.8.1 for a few days and I did not experience this bug even once. I installed the 2001032904 build this morning and it has been happening all over the place. Apparently it got fixed in 0.8.1. Any chance that fix will get into the trunk anytime soon? Until it does I have to choose between working IMAP/SSL and keydead windows.
Nevermind. I switched back to 0.8.1 and while this bug does not crop up as often as it does with the latest nightly it does still happen.
Yeah, I'm seeing this now, and it cannot be fixed by the usual focus twiddling of the window. So I'm not sure what happened.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Priority: -- → P1
The best guess I have for 'steps to reproduce' is to do a lot of right-click Open Link in New Window as you browse around. It is quite annoying in that it doesn't happen very often. The only consistency I have noticed is that after I have New Windowed a bunch of links of a page (e.g. slashdot, memepool, etc...) that page eventually becomes keydead. I will say that it doesn't happen nearly as often as it used to.
How much is "a lot"? How often are you seeing it? How long after startup do you start seeing it?
Has anyone ever seen this in an embedded Gecko (WinEmbed, MFCEmbed, ...)?
It is fairly random. It was quite frequent in the nightlies leading up to the 0.8.1 branch. It was definitely present but infrequent in the 0.8.1 release. I have not noticed it in either of the last two builds (04-11-09 & 04-12-14). This bug has the same symptoms as bug 30841 which has consistent Steps To Reproduce. Perhaps it would be better to fix that first and then come back to this one.
In the absence of an ability to reproduce (we still don't even know what the bug is here), moving off to 0.9.1.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1
I just had a window go 'keydead', after using mail and multiple browser windows for an hour or so, using today's mozilla build on Win98. No right clicking involved, and no unusual CPU usage. It only affected one window though, and I was even able to recover full keyboard use in that window by minimizing and restoring it. Lowering priority to P2, cc self.
Priority: P1 → P2
I found I have this bug hitting me almost instantly when I visit www.iht.com and read one of the articles. First I thought it had something to do with their top menu bar that moves with the text, but sometimes the keyboard still works. It is really erratic with other sites but IHT is the one that brings it out the most. I don't know if this is the same bug since I am not talking about menu shortcuts. I have frustrations enough that the up and down keys aren't working. FYI, I am using release 0.8.1 on an NT4SP6 machine. Good hunting.
Bryner taking keydead bugs
This _could_ be related to bug 58250. Can anyone check whether the latest patch attached to that bug helps with this at all?
QA contact updated
QA Contact: gerardok → madhur
I've found another case where the window will go keydead - this will happen if you click a link inside a <frame> that loads a new toplevel document. Patch coming up.
cc'ing saari for review.
sr=hyatt, although you should probably put some comments in explaining what you're doing here.
r=saari, but add a comment and this bug number so my feeble brain can remember what we were doing :-)
I'm no longer seeing this behavior, except with the double-right-click case as noted in bug 30841. If there are any remaining ways to make this happen, please open new bugs with specific steps. Thanks.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
the only scenario which causes the keyboard to stop working - go keydead - is when I do double-right clicks continuosly. Bug 30841. None of the other scenarios mentioned in the comments causes "keydead" marking verified. Bug 30841 needs to be fixed.
Status: RESOLVED → VERIFIED
This is still a problem -- try loading http://www.mba.com/bucks After it says "Transferring" on the status bar, but before the new page appears there is a long period where you cannot use the keyboard for *anything* in Mozilla. During paint suppression you're still supposed to be able to interact with the document. However, failing that -- you should at least be able to hit Alt+F for File, or Accel+L for the URL bar, Escape to stop the load or something. There's also a related problem where both Escape and the Stop button don't work right during paint suppression. It will still take you to the new page, but it will be blank. It should just throw away the contents of what it was trying to load. Anyway, I have a patch that fixes this, but it's going to need more work. Will post it in a moment. Hope it's the right general approach.
The problem is that the document is "half gone" -- the presshell is still there, and so is it's dom tree, but the docshell and the content nodes think the document is gone. nsDocShell really needs to keep track of 2 content viewers during a page load. One content viewer for the currently visible document, and one for the suppressed document which is loading. Once the load is completely finished, the suppressed shell can become the current mContentViewer, and the old mContentViewer can be completely destroyed.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.2 → mozilla1.3alpha
I think there's another bug somewhere with a bunch of duplicates that was morphed into covering this problem, although it was originally about something else. I can't find it, though. Does the docshell really need to track both, or can you call GetPreviousViewer on the current one to get the old one, if present?
Target Milestone: mozilla1.3alpha → mozilla0.9.2
Also fixes Stop() so that you stay in the current page, if the new page hadn't been displayed yet. It just throws away the stuff that's loading. Problems: 1. When the stop button is pressed, the status bar shouldn't make it appear that the document is still loading. That should be easy to fix. 2. This is the big one: <script>'s and event handlers don't work on the newly loaded page. This has something to do with pollman's comment at http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#4517 4517 // Do NOT to maintain a reference to the old content viewer outside 4518 // of this "copying" block, or it will not be destroyed until the end of 4519 // this routine and all <SCRIPT>s and event handlers fail! (bug 20315) I need to be able to hold onto the contentviewer for the document until it's no longer visible on the screen, so I need to figure out more about what's happening.
> Does the docshell really need to track both, or can you call GetPreviousViewer > on the current one to get the old one, if present? I think it needs mContentViewer to still be equal to the old one, but my brain is a little fried from working on this. Let me try that and see what happens.
Assignee: bryner → aaronl
Status: ASSIGNED → NEW
David, you're right -- I can just use the mContentViewer->Set/GetPreviousViewer() I have a new patch that does, and uses a new member variable PRPackedBool mIsViewerSuppressed. However, my script problem still occurs. It turns out that the script problem goes away if I use mContentViewer->Close() sooner rather than later; however, then I'm still left with the keydead problem. I see a comment from dbaron as follows: // Close is also needed to disable scripts during paint suppression, // since we transfer the existing global object to the new document // that is loaded. In the future, the global object may become a proxy // for an object that can be switched in and out so that we don't need // to disable scripts during paint suppression. I wonder if that future suggestion would help or not.
Still has problems, not seeking review
Attachment #105513 - Attachment is obsolete: true
// In the future, the global object may become a proxy // for an object that can be switched in and out so that we don't need // to disable scripts during paint suppression. How hard is this? I think we need it, because the user may press Escape before the new document becomes visible, which should leave them in the current page. That would be pretty useless if the current page's scripts stopped working.
Well, it was something jst (and hyatt?) were talking about doing at one point. I'm not sure how hard it would be, although it doesn't sound too easy.
I have a new patch working with scripts now, will submit it soon. Also, if you hit escape when a loading page hasn't appeared yet, it will stay on the current page and scripts will work again. However, scripts won't work for the visible page during the time after you clicked on a link, but before the new page has appeared. Also, unload appears to fire to early -- I'm going to look into getting it to fire at the last possible moment. And yes, I'm aware of the dangers of giving the js the info about the wrong page. Jst, Hyatt -- could you comment on this comment? // In the future, the global object may become a proxy // for an object that can be switched in and out so that we don't need // to disable scripts during paint suppression.
This bug has dependencies and comments relating to another class of bugs (windows sometimes permanently becoming keydead, often in a random-seeming way), so I'd rather not see it get morphed. Aaron's patch belongs on bug 76495 or bug 110718. Bug 76495 comment 117 explains the difference between 76495 and 110718. I don't completely understand the difference, but it's something like: bug 76495 can't interact with old page after initiating load of new page bug 110718 can't interact with browser ui using the keyboard during some stages of loading a page. keyboard commands like ctrl+t and alt+left are ignored.
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.