Closed
Bug 86011
Opened 24 years ago
Closed 24 years ago
Crash on hitting F6 or TAB key after hiding sidebar panel
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
People
(Reporter: kazhik, Assigned: bryner)
References
Details
(Keywords: crash)
Crash happens when you hit F9 key and F6 key.
(1) Hit F9 key to close sidebar panel.
(2) Hit F6 key.
Win32 build crashes. Linux build doesn't crash.
Talkback ID: TB31738066Q
Comment 1•24 years ago
|
||
what's F6 supposed to do?
do other keyboard accelerators make it crash?
Comment 2•24 years ago
|
||
F6's windows default behavior is to cycle through elements on a window. What
exactly that means for Mozilla I'm not sure.
Comment 3•24 years ago
|
||
It cycles the focus (between urlbar, content area, and sidebar, I think). This
sounds familiar, so it might be a dup. Anyways, I'm pretty sure this belongs to
rod (who implemented all the F6 stuff...)
Comment 4•24 years ago
|
||
It appears that Mozilla is trying to set forcus to the nonexistent sidebar.
Here's a stack trace.
PresShell::GetSubShellFor(const PresShell * const 0x02700e00, nsIContent *
0x036a5650, nsISupports * * 0x0012f02c) line 5070 + 13 bytes
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x036a5650, nsIDocShell * 0x03311790) line 4217
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x0361d258, nsIDocShell * 0x03311790) line 4231 + 25 bytes
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x031af6c8, nsIDocShell * 0x03311790) line 4231 + 25 bytes
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x031a9698, nsIDocShell * 0x03311790) line 4231 + 25 bytes
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x028a20b0, nsIDocShell * 0x03311790) line 4231 + 25 bytes
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x028a2028, nsIDocShell * 0x03311790) line 4231 + 25 bytes
nsEventStateManager::FindContentForDocShell(nsIPresShell * 0x02700e00,
nsIContent * 0x02755308, nsIDocShell * 0x03311790) line 4231 + 25 bytes
nsEventStateManager::FigureOutKindOfDoc(nsEventStateManager * const 0x041adda8,
nsIDocument * 0x03f81c70, nsIEventStateManager::eDocType * 0x0012f348) line 4328
+ 38 bytes
nsEventStateManager::ShiftFocusByDoc(int 1, nsIContent * 0x00000000) line 4825
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x041adda8,
nsIPresContext * 0x0364e8b8, nsEvent * 0x0012f760, nsIFrame * 0x03f99bd8,
nsEventStatus * 0x0012f6cc, nsIView * 0x036717e0) line 1698
PresShell::HandleEventInternal(nsEvent * 0x0012f760, nsIView * 0x036717e0,
unsigned int 1, nsEventStatus * 0x0012f6cc) line 5537 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x04270ff4, nsIView * 0x036717e0,
nsGUIEvent * 0x0012f760, nsEventStatus * 0x0012f6cc, int 0, int & 1) line 5444 +
25 bytes
nsView::HandleEvent(nsView * const 0x036717e0, nsGUIEvent * 0x0012f760, unsigned
int 8, nsEventStatus * 0x0012f6cc, int 0, int & 1) line 377
nsView::HandleEvent(nsView * const 0x035a60e8, nsGUIEvent * 0x0012f760, unsigned
int 8, nsEventStatus * 0x0012f6cc, int 0, int & 1) line 350
nsView::HandleEvent(nsView * const 0x0337cf90, nsGUIEvent * 0x0012f760, unsigned
int 28, nsEventStatus * 0x0012f6cc, int 1, int & 1) line 350
nsViewManager::DispatchEvent(nsViewManager * const 0x03f71088, nsGUIEvent *
0x0012f760, nsEventStatus * 0x0012f6cc) line 2051
HandleEvent(nsGUIEvent * 0x0012f760) line 68
nsWindow::DispatchEvent(nsWindow * const 0x03f74a5c, nsGUIEvent * 0x0012f760,
nsEventStatus & nsEventStatus_eIgnore) line 715 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f760) line 736
nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 0, unsigned int 117)
line 2384 + 15 bytes
nsWindow::OnKeyDown(unsigned int 117, unsigned int 64) line 2451
nsWindow::ProcessMessage(unsigned int 256, unsigned int 117, long 4194305, long
* 0x0012fba4) line 3142 + 32 bytes
nsWindow::WindowProc(HWND__ * 0x01a4030c, unsigned int 256, unsigned int 117,
long 4194305) line 983 + 27 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
nsAppShellService::Run(nsAppShellService * const 0x00d00008) line 418
main1(int 1, char * * 0x003588c8, nsISupports * 0x00000000) line 1110 + 32 bytes
main(int 1, char * * 0x003588c8) line 1408 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()
Comment 6•24 years ago
|
||
cc saari and danm due to focus issues
Comment 7•24 years ago
|
||
F9 and then tab works as well.
OS should be all, Linux 2001061308 dies as well.
Hitting F9, exiting mozilla, starting mozilla and hitting tab or F6 works. I
think something is being cached too aggressively when we get rid of the sidebar.
Comment 8•24 years ago
|
||
This is a dup of bug 85635, which is the same bug but using TAB instead of F6.
The stack trace attached to that bug matches this one.
But since, uh, the gang is all here, perhaps 85635 should be duped instead of
this bug.
Comment 9•24 years ago
|
||
who should own this bug, since rods will be going on sabbatical Real Soon?
sidenotes:
in mozilla/n6.x, F6 [and shift+F6] is supposed to cycle through frames in the
browser window, and thru panes in the mailnews 3pane window...
also, methinks there's a bug for F6/shift+F6 not quite working right wrt the
Sidebar.
Severity: normal → major
Keywords: crash
Comment 10•24 years ago
|
||
Ok the problem is this -- each of the "active" sidebar panels has a webshell
associated with it. When each of these nsWebShells is created
(in nsHTMLFrameInnerFrame::CreateDocShell nsFrameFrame.cpp line 906 ), the inner
frame registers an association between the webshell and the content with the
presentation shell. When the sidebar is collapsed the inner frame and the web
shell are destroyed, but the association remains in mSubShellMap of the
presentatin shell. When we hit tab or F6 we pull the pointer to the subshell
out of them map and it points to nothing in particular. AddReffing pointers to
nothing in particular is less than optimal.
It seems to me that the thing to do would be to remove the association when we
destroy the web shell, but at that point in time we do not remember where we put
it. I think that we don't want the map addreffing.
Note: I am less than fluent in the code, and may be completely misunderstaning
things.
I am moving this to layout, though I am less than sure that that is the right place.
I am going to dup bug 85635 over to here, apologies if anyone is overly offended.
Component: Keyboard Navigation → Layout
Comment 11•24 years ago
|
||
*** Bug 85635 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
> Note: I am less than fluent in the code, and may be completely
> misunderstaning things.
Geez. Could have fooled me! :-]
At any rate, rods is now on sabbatical so this needs a real owner. It is
a core layout thing, but it is biting us in the UI and the use of sidebar.
(By the way, this happens on mac/linux/win32, although not all the same
keyboard shortcuts (e.g., F9) are available on all platforms)
I think that as people get familiar with the app, and keyboard nav continues
to improve in the app, that casually loading a page, collapsing the sidebar,
and hitting tab to move through the page is something that will be hit by
users (i.e., we should consider this for rtm).
-> bryner (although, are you taking some time off soon, or something? maybe
this needs someone else to look into it (dr, jag)).
Assignee: rods → bryner
Severity: major → critical
Keywords: mozilla0.9.2,
rtm
OS: Windows 2000 → All
Hardware: PC → All
Summary: Crash on hitting F6 key after hiding sidebar panel → Crash on hitting F6 or TAB key after hiding sidebar panel
Assignee | ||
Comment 13•24 years ago
|
||
taking for now, but i could use some help with the tabbing/focus bugs.
Status: NEW → ASSIGNED
Comment 14•24 years ago
|
||
I see joki just fixed this bug as bug 83810.
*** This bug has been marked as a duplicate of 83810 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 15•23 years ago
|
||
mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".
if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•