Closed Bug 70484 Opened 24 years ago Closed 22 years ago

browser windows go 'keydead': keyboard stops working


(Core :: DOM: UI Events & Focus Handling, defect, P2)






(Reporter: jlb-bugz, Assigned: aaronlev)


(Blocks 1 open bug, )


(Keywords: access, helpwanted)


(3 obsolete files)

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="">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.
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. 
Ever confirmed: true
I think I've seen this too lately.
Blocks: keydead
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.
Priority: -- → P1
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.
Target Milestone: --- → mozilla0.9
Assignee: saari → hyatt
Priority: -- → P1
Need steps to reproduce, adding qawanted & helpwanted keywords. 
Keywords: helpwanted, qawanted
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.
Blocks: 75642
Blocks: 75664
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.
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 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.
Keywords: nsCatFood+
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Blocks: focusnav
No longer blocks: focusnav
Blocks: focusnav
No longer blocks: focusnav
Assignee: hyatt → bryner
Bryner taking keydead bugs
No longer depends on: focusnav
Blocks: focusnav
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 :-)
a= for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
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.
Closed: 23 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.
This is still a problem -- try loading
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. 
Keywords: access, sec508
Resolution: FIXED → ---
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.
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
OS: Windows NT → All
Hardware: PC → All
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.

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
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
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
Attachment #39070 - Attachment is obsolete: true
> 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
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

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.
Attachment #105555 - Attachment is obsolete: true
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.
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
Keywords: qawanted
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.