Closed
Bug 70484
Opened 24 years ago
Closed 22 years ago
browser windows go 'keydead': keyboard stops working
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
FIXED
mozilla0.9.2
People
(Reporter: jlb-bugz, Assigned: aaronlev)
References
(Blocks 1 open bug, )
Details
(Keywords: access, helpwanted)
Attachments
(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.
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.
Comment 3•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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
Comment 9•24 years ago
|
||
I think I've seen this too lately.
Comment 10•24 years ago
|
||
over to event handling
Assignee: asa → joki
Component: Browser-General → Event Handling
QA Contact: doronr → gerardok
Reporter | ||
Comment 11•24 years ago
|
||
I would just like to add that this is currently the bug in mozilla which annoys
me the most.
Comment 12•24 years ago
|
||
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
Comment 13•24 years ago
|
||
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 → --
Reporter | ||
Comment 14•24 years ago
|
||
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.
Reporter | ||
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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
Updated•24 years ago
|
Assignee: saari → hyatt
Status: ASSIGNED → NEW
Comment 17•24 years ago
|
||
->hyatt
Comment 19•24 years ago
|
||
Need steps to reproduce, adding qawanted & helpwanted keywords.
Keywords: helpwanted,
qawanted
Reporter | ||
Comment 20•24 years ago
|
||
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.
Comment 21•24 years ago
|
||
How much is "a lot"? How often are you seeing it? How long after startup do you
start seeing it?
Comment 22•24 years ago
|
||
Has anyone ever seen this in an embedded Gecko (WinEmbed, MFCEmbed, ...)?
Reporter | ||
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
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
Comment 26•24 years ago
|
||
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.
Updated•24 years ago
|
Keywords: nsCatFood+
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Updated•23 years ago
|
Assignee: hyatt → bryner
Status: ASSIGNED → NEW
Assignee | ||
Comment 27•23 years ago
|
||
Bryner taking keydead bugs
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 28•23 years ago
|
||
This _could_ be related to bug 58250. Can anyone check whether the latest patch
attached to that bug helps with this at all?
Comment 30•23 years ago
|
||
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.
Comment 31•23 years ago
|
||
Comment 32•23 years ago
|
||
cc'ing saari for review.
Comment 33•23 years ago
|
||
sr=hyatt, although you should probably put some comments in explaining what
you're doing here.
Comment 34•23 years ago
|
||
r=saari, but add a comment and this bug number so my feeble brain can
remember what we were doing :-)
Comment 35•23 years ago
|
||
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Comment 36•23 years ago
|
||
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: 23 years ago
Resolution: --- → FIXED
Comment 37•23 years ago
|
||
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
Assignee | ||
Comment 38•22 years ago
|
||
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.
Assignee | ||
Comment 39•22 years ago
|
||
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
Comment 40•22 years ago
|
||
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?
Updated•22 years ago
|
Target Milestone: mozilla1.3alpha → mozilla0.9.2
Updated•22 years ago
|
OS: Windows NT → All
Hardware: PC → All
Assignee | ||
Comment 41•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Attachment #39070 -
Attachment is obsolete: true
Assignee | ||
Comment 42•22 years ago
|
||
> 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 | ||
Comment 44•22 years ago
|
||
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.
Assignee | ||
Comment 45•22 years ago
|
||
Still has problems, not seeking review
Attachment #105513 -
Attachment is obsolete: true
Assignee | ||
Comment 46•22 years ago
|
||
// 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.
Assignee | ||
Updated•22 years ago
|
Attachment #105555 -
Attachment is obsolete: true
Comment 47•22 years ago
|
||
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.
Assignee | ||
Comment 48•22 years ago
|
||
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.
Comment 49•22 years ago
|
||
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: 23 years ago → 22 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Comment 50•6 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•