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)

defect
Not set
critical

Tracking

()

VERIFIED DUPLICATE of bug 83810

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
what's F6 supposed to do? do other keyboard accelerators make it crash?
F6's windows default behavior is to cycle through elements on a window. What exactly that means for Mozilla I'm not sure.
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...)
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()
well then, over to rod!
Assignee: alecf → rods
cc saari and danm due to focus issues
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.
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.
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
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
*** Bug 85635 has been marked as a duplicate of this bug. ***
> 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
taking for now, but i could use some help with the tabbing/focus bugs.
Status: NEW → ASSIGNED
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
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.