If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

I hit ctrl+shift+tab and mozilla fell over - [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell]

RESOLVED FIXED

Status

()

Core
Event Handling
--
critical
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: Hogarth, Assigned: mats)

Tracking

({crash, topcrash})

Trunk
crash, topcrash
Points:
---
Bug Flags:
blocking1.7 -
blocking1.8.1.4 -
wanted1.8.1.x ?
blocking1.8.0.12 -
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [STEPS TO REPRODUCE:comment 58], crash signature, URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

15 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020809
BuildID:    2002080908

I had quite a few tabs up and I was browsing lxr.mozilla.org. It was the last
tab in a whole line of tabs. I hit ctrl+shift+tab (at least I'm 99% sure I did
actually hit them all well enough). Instantly mozilla crashed.

Unfortunately I was not able to reproduce the bug but I do have a talkback id
that I hope will help. :/

Talkback ID: TB9239822G
nsEventStateManager::GetPrevDocShell()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp,
line 5016]
nsEventStateManager::ShiftFocusByDoc()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp,
line 643]
nsEventStateManager::PostHandleEvent()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp,
line 1907]
PresShell::HandleEventInternal()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6125]
PresShell::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6028]
nsViewManager::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2050]
nsView::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/view/src/nsView.cpp, line 301]
nsViewManager::DispatchEvent()
[/builds/client/linux22/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1903]
HandleEvent() [/builds/client/linux22/seamonkey/mozilla/view/src/nsView.cpp,
line 83]
nsWidget::DispatchEvent()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 1476]
nsWidget::DispatchWindowEvent()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 1365]
nsWidget::OnKey()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 104]
handle_key_press_event()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,
line 640]
dispatch_superwin_event()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,
line 953]
handle_gdk_event()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,
line 817]
libgdk-1.2.so.0 + 0x17457 (0x4034a457)
libglib-1.2.so.0 + 0x104d8 (0x4037a4d8)
libglib-1.2.so.0 + 0x10ae3 (0x4037aae3)
libglib-1.2.so.0 + 0x10c7c (0x4037ac7c)
libgtk-1.2.so.0 + 0x8d7e7 (0x4029a7e7)
nsAppShell::Run()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsAppShell.cpp, line 334]
nsAppShellService::Run()
[/builds/client/linux22/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 452]
main1()
[/builds/client/linux22/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1892]
main() [/builds/client/linux22/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1880]
libc.so.6 + 0x1914f (0x404f914f) 

Comment 2

15 years ago
Build 2002080119 on Win2000

I got Mozilla to hang in an endless loop (using 100% cpu) while pressing
ctrl+shift+tab. Can't find the magic touch to reproduce it yet, but I managed to
hang it twice.

Comment 3

15 years ago
On KDE 3.0.0-10 and build 2002072204, pressing this combination on the last tab
simply minimizes the window.  No crash and performance after this event is
seemingly unaffected.

Comment 4

15 years ago
2002081104 also minimizes in my environment, but after holding the key
combination pressed for more than a split second, I notice that it's because KDE
intercepts this combination to cycle backwards between virtual desktops.  So, my
report is useless.

Comment 5

15 years ago
Mozilla is freezing with this combination of keys.

Using build 2002081204 - WinXP.
-> Event Handling
Assignee: Matti → joki
Status: UNCONFIRMED → NEW
Component: Browser-General → Event Handling
Ever confirmed: true
QA Contact: asa → rakeshmishra

Comment 7

15 years ago
worksforme with linux build 20020811.  ctrl-shift-tab cycles through sidebar,
content area and URL bar.
(Reporter)

Comment 8

15 years ago
I have played with this some more and I think I can reliably reproduce it now:

1. Open moz
2. open a buttload of tabs (holding down alt-t for a while works well)
3. select a tab in the middle somewhere
4. close a few of the tabs in quick succession
5. hold down ctrl+shift+tab until crash happens

I doubt this is the only way to trigger this but it's worked 3 times for me so far.

Linux Build: 2002081604

Comment 9

15 years ago
ok, doing that, I see the crash with current builds back to 1.0 release...

I also got the hang (comment 5) to happen under normal browsing conditions (just
a few bugs open in tabs).

Updated

15 years ago
QA Contact: rakeshmishra → trix

Comment 10

15 years ago
Ok, this is my most feared bug in Mozilla. Linux 20030103.

I can't reproduce it, but it happens a lot. I usually have a lot of open tabs
and cycle among them with Ctrl+Tab and Ctrl+Shift+Tab.
Ctrl+Tab works ok, but sometimes, when the current tab is loading and others
too, I press Ctrl+Shift+Tab, then Mozilla hangs for a while consuming 100% CPU,
and after that it crashes.

It can happen with any page, but always with Ctrl+Shift+Tab. It's not related to
the 100% CPU caused by holding these keys down for some seconds; that doesn't
crash Mozilla.

I will submit a Talkback ID next time if I can get it working on my nightly build.
Keywords: crash

Comment 11

15 years ago
   Yes, I made it crash! Using URL of bug 189621 makes it easy to reproduce.

   Just opened a lot of tabs ('in background') by middle-clicking links at the
left frame, and when I had about 20, and pressed Ctrl+Shift+Tab while the
last-opened tabs were still loading. It should have left the first tab and pass
to the last one... Talkback ID is TB16339965H

Updated

15 years ago
Keywords: stackwanted
Whiteboard: TB16339965H

Comment 12

15 years ago
confirming crash using build 20030125 (CVS) on Linux, I just hit Ctrl-Alt-Tab
until I crashed (with 20 tabs open)

JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIBrowserBoxObject.docShell]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://global/content/bindings/browser.xml#browser.docShell (getter) :: onget
:: line 0"  data: no]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 2175)]
nsXULWindow::ContentShellAdded (this=0x814c058, aContentShell=0x0, aPrimary=1, 
    aID=0xbfff6708) at nsXULWindow.cpp:1438
1438      aContentShell->GetTreeOwner(getter_AddRefs(treeOwner));
Keywords: stackwanted
Summary: I hit ctrl+shift+tab and mozilla fell over → I hit ctrl+shift+tab and mozilla fell over [@ nsXULWindow::ContentShellAdded ]
Whiteboard: TB16339965H

Comment 13

15 years ago
Created attachment 112667 [details]
Stack trace Linux 20030125

Comment 14

15 years ago

*** This bug has been marked as a duplicate of 156405 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 15

15 years ago
This is happening for me again in Linux, with latest builds. Ctrl+Shift+TAB, and
it closes suddenly.

Comment 16

15 years ago
Daniel, can you attach a stack trace or submit a Talkback ID with steps to
reproduce ?

Comment 17

15 years ago
Sorry for the lateness, it was hard to make it crash... :-)
Anyway, using Mozilla Firebird 20030518 on Linux, I made TB20250262G
It's very clear that the crash is caused by Ctrl+Shift+Tab, as it closes
immediately after pressing them when browsing normal pages that always work. I
haven't got any instructions on how to reproduce it; sorry.

Comment 18

15 years ago
Another crash, with Mozilla FireBird 20030530. TB ID: TB20852688Z

Comment 19

14 years ago
I have to reopen this bug as it's still there. I have just crashed Mozilla
20031220 on Linux and had seen it on all earlier builds. My notes on this:

1) it's not about 'tab browsing' in general, it's only when you press
Ctrl+Shift+Tab. So this is not a dup of 156405

2) the current tab must be loading when you press the keys. It doesn't matter if
the left one is loading or not, only the current one.

3) it can happen on any tab, not only first or last

4) you don't need to open a lot of tabs or hold the keys until it gets mad; one
time at the correct moment is enough

   I submitted several TalkBack IDs and there are several stack traces. At the
moment we don't know a reliable way to reproduce it. Just use that combination
frequently.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 20

14 years ago
I've had a similar problem with Firebird and Firefox on Windows for several
versions. It usually happens when I have a lot of tabs open and at least one is
"busy" downloading a page. CTRL+SHIFT+TAB and it dies. Is there a similar bug
report for the Windows platform somewhere?

Comment 21

14 years ago
Mike: I'm sure it is this very bug; compare your case with the notes I wrote in
comment 19.
Changing OS -> All (other people had this bug on Windows).
OS: Linux → All

Comment 22

14 years ago
Only workaround is don't use Ctrl+Shift+Tab.

I can generate Talkbacks on Mozilla 1.7 builds if anyone wants one.
Flags: blocking1.8a?
Flags: blocking1.7?

Comment 23

14 years ago
jay, can you see if there is any talkback data for this one?

bryner might be our best chance for fixing if we can narrow the problem.
Assignee: joki → bryner
Status: REOPENED → NEW

Comment 24

14 years ago
I don't see any crashes with the nsXULWindow::ContentShellAdded, but there are a
few crashes (7) in nsEventStateManager::GetPrevDocShell with Mozilla 1.7 Beta.  

Here is the only recent crash I found with comments that confirm that this is
still happening.

Incident ID: 3319
Stack Signature	nsEventStateManager::GetPrevDocShell b7d37401
Product ID	Mozilla1.7
Build ID	2004031615
Trigger Time	2004-03-21 19:32:33.0
Platform	Win32
Operating System	Windows 98 4.10 build 67766446
Module	GKLAYOUT.DLL + (000d12cf)
URL visited	
User Comments	I had several tabs open in many different windows. One had many
photographs of the protests, but most were just text. I was switching from one
tab to antoher with Ctrl+Shift+Tab, and then the crash occurred. It said the
crash was in gklayout.dll.
Since Last Crash	sec
Total Uptime	sec
Trigger Reason	Access violation
Source File Name
c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
Trigger Line No.	5257
Stack Trace 	
nsEventStateManager::GetPrevDocShell
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 5257]
nsEventStateManager::ShiftFocusByDoc
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 5306]
nsEventStateManager::PostHandleEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2024]
PresShell::HandleEventInternal
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6072]
PresShell::HandleEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5942]
nsViewManager::HandleEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2235]
nsViewManager::DispatchEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2025]
HandleEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 79]
nsWindow::DispatchEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1068]
nsWindow::DispatchWindowEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1085]
nsWindow::DispatchKeyEvent
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 2957]
nsWindow::OnKeyDown
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3046]
nsWindow::ProcessMessage
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3942]
0x22eb84b1


I tried to reproduce, but have not been able to yet.  I will continue looking
for a solid test case/steps to reproduce.  Adding M17beta and [@
nsEventStateManager::GetPrevDocShell] to summary and topcrash keyword for tracking.
Keywords: topcrash
Summary: I hit ctrl+shift+tab and mozilla fell over [@ nsXULWindow::ContentShellAdded ] → I hit ctrl+shift+tab and mozilla fell over - M17beta [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell]

Comment 25

14 years ago
I'm unable to reproduce this in windows branch build 2004042508 on winXP. I
loaded up 30 of the Alexa top 500 plus 10 popular mozilla-related sites. I tried
reproducing with none, some and all of the tabs loading, with ctrl+shift+tab and
with ctrl+tab (and alternating quickly between the two.) I tried with
ctrl+shift+tab with 1 second pauses and holding the key down so that it cycled
through all of the tabs really quickly. I tried with pages that had flash
content loaded, pages with java content loaded and several https pages and with
ftp directory listsings. I attempted to reproduce while downloading and while
Mozilla mail was checking for incoming mail. I tried with chatzilla open and
with composer open. Nothing I tested reproduced the problem. 

Comment 26

14 years ago
I have not been able to reproduce this either. I looked through all the Talkback
reports and tried to follow the same steps/sites as other users, but no crash.

There are also only 12 crashes with Mozilla 1.7 beta and I can't find any for
rc1 or the latest Trunk builds.

Comment 27

14 years ago
Andrew, you can still reproduce with the latest 1.7 build? What pages do you
have open in tabs? Are you using any 3rd-party extensions? Can you try a clean
build, no extensions, new profile, etc. and see if that crashes? 

Comment 28

14 years ago
A few days ago, I upgraded to a nightly build. Since then I am unable to
reproduce this bug. I tried everything, and even got Mozilla to hang, but no
crash at all.

I'm now on the 4/29 build and that also seems very stable.

Comment 29

14 years ago
I had a lot of crashes with earlier builds, but now it seems stable:
Ctrl+Shifh+Tab doesn't crash the browser. Linux 20040426

Comment 30

14 years ago
Marking worksforme since people are no longer crashing and there aren't any
incidents in the latest Talkback data.  Please reopen if anyone is able to
reproduce this again.
Status: NEW → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → WORKSFORME

Updated

14 years ago
Flags: blocking1.7? → blocking1.7-

Updated

14 years ago
Flags: blocking1.8a?

Updated

13 years ago
Status: RESOLVED → VERIFIED

Comment 31

13 years ago
*** Bug 243522 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 32

13 years ago
*** Bug 284828 has been marked as a duplicate of this bug. ***

Comment 33

13 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225
Firefox/1.0.1

I have seen this frequently, lately. To reproduce, I have many (usually 9 or
more) tabs open, close a tab with Ctrl+W then immediately press Ctrl+Shift+Tab
to go back a tab. 

I have three crashes in two days that talkback caught:

TB4366292K, TB4366608E, TB4389813Z

Comment 34

13 years ago
(In reply to comment #33)
> TB4366292K, TB4366608E, TB4389813Z

Stacks are same as one in comment #1. There is about 57 incidents from this
year's builds <http://tinyurl.com/54s4z> with this signature, mostly Firefox
Aviary branch, but Trunk is also included.
Hardware: PC → All
Summary: I hit ctrl+shift+tab and mozilla fell over - M17beta [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell] → I hit ctrl+shift+tab and mozilla fell over - M17beta, FF101 [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell]

Comment 35

13 years ago
forgot that Ctrl+Shift+Tab is broken in 1.0.1, so add TB4417153W to the list. 

Comment 36

13 years ago
Firefox crashes when pressing Ctrl+Shift+Tab only after submitting any info in form.

Comment 37

13 years ago
TB4579436Z & TB4853310K

Comment 38

13 years ago
TB5038886X

see
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsEventStateManager%3A%3AGetPrevDocShell&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
for more talkback data on this crash

Comment 39

13 years ago
Updating summary with M17x and FF10x since this crash remains on the branches. 
However, this will most likely not be fixed there.  

Please test with the latest Trunk nightlies and see if it is a problem...  if
not we should mark this worksforme once again.  I don't see any of these crashes
on the Trunk in the latest Talkback data.
Summary: I hit ctrl+shift+tab and mozilla fell over - M17beta, FF101 [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell] → I hit ctrl+shift+tab and mozilla fell over - M17x, FF10x [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell]

Comment 40

12 years ago
*** Bug 259572 has been marked as a duplicate of this bug. ***

Comment 41

12 years ago
re: comment #39, TB8855956 and a few others listed in the results shown via the
link in comment #38 are from recent trunk builds. The one I mention above is a
linux build.

Comment 42

12 years ago
This is still occurring on Deer Park, FF1.5b1 release.

Is there some way I can track this down? Only seems to happen one in 10 times,
but specifically when I hit the submit then immediately hit ctrl+shift+tab
(generally within half a second), but it seems to happen quite a bit to me...

Comment 43

12 years ago
Another note - this appears to occur particularly on slow network connections
just after submitting the form. I've noticed when I'm weak on the wifi signal,
it happens.

Comment 44

12 years ago
I had never ever seen this in continuous use FF 1.0x in Windows XP and OS X, but
suddenly since I went to 1.5b1 it's happening to me about once a day.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4

Comment 45

12 years ago
Confirming this on Windows 2000 with Firefox 1.0.7.
Before 1.0.7 I've used 1.0.6 and the bug didn't happen to me - also the "Tab
Clicking Options"-extension is disabled due to I thought it would be the reason
for the crashes.
But after disabling the extension it just worked a couple of times - now it
(almost) always crashes if using CTRL + SHIFT + TAB and the number of open tabs
isn't important, AFAICT at least.. ;)

Comment 46

12 years ago
Had a repeat crash with this, talkback report TB11007720K
*** Bug 255909 has been marked as a duplicate of this bug. ***
*** Bug 314257 has been marked as a duplicate of this bug. ***

Comment 49

12 years ago
If this is what I think it is, I too see it once or twice a day (three times tonight). Shift-Ctrl-Tab causes a crash. Only started since upgrading to 1.5 RC1 and RC3.

Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8)
Gecko/20051111 Firefox/1.5

Comment 50

12 years ago
This still happens regularly, currently with 20060127 trunk build.  It only seems to happen when a page is loading or sending POST data

Comment 51

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I thought I'd seen the last of this problem...

TB15137780G

Comment 52

12 years ago
fwiw, the stack signature was at:
 
InitExceptionObject  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsexn.c, line 441]

Updated

12 years ago
Summary: I hit ctrl+shift+tab and mozilla fell over - M17x, FF10x [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell] → I hit ctrl+shift+tab and mozilla fell over - M1.7.x, FF1.0.x [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell]

Comment 53

12 years ago
Still happening on FF 1.5.0.1 on X/GTK2/FreeBSD.

Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.1) Gecko/20060404 Firefox/1.5.0.1

Will reproduce if possible after an upgrade to 1.5.0.2. Unfortunately it disappeared without leaving any errors. This is a vanilla install compiled from source. I'll try creating a debug build to see if I can find out where it's going wrong, if I can? (Haven't tried this before!)
Assignee: bryner → events
Status: REOPENED → NEW
QA Contact: trix → ian

Comment 54

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

This one showed up out of nowhere. See TB 22792583.

Stack signature: 

nsEventStateManager::GetPrevDocShell 0e79ca81
So ... is this confirmed to be related to postdata?  In which case perhaps it belong in a different component.

Richard, Noa, Doug - is there a testcase that works in a clean environment with some high percentage?


on talkback, despite its prevelance in v1.5 it's almost non-existent in trunk 
builds - only 2:
* TB21808709 nsEventStateManager::GetPrevDocShell() 6c577342 2006-08-05 09:40:05.0
MozillaOrgFirefoxTrunkLinuxIntel2006080204 (no stack)
* TB18417644 nsEventStateManager::GetPrevDocShell f3b19173 2006-05-07 19:14:53.0
MozillaOrgFirefoxTrunkWin322006021700 (exact match to TB22792583)
for PRInt32 childCount = 0; at source location http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/events/src/nsEventStateManager.cpp&mark=5407&rev=MOZILLA_1_8_0_BRANCH#5407

And several in FF2 including:
TB22586829 
for curNode->GetChildCount(&childCount); at source location http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/events/src/nsEventStateManager.cpp&mark=5560&rev=MOZILLA_1_8_BRANCH#5560
and 
TB21779095 MAC (does not have same stack)

the lines called are not the same -> corruption?

Comment 56

11 years ago
I just tried to reproduce this bug by sending myself a large test personal message  in Invision Power Board v 2.1.7 and then holding ctrl-shift-tab quickly while having two other pages open in different tabs (gmail and this bug) - out of the 10 test messages I sent, I got 2 crashes - 99% processor usages and firefox froze.... I'm not sure what a testcase for this would look like.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060905 BonEcho/2.0b2

Comment 57

11 years ago
I've just had it happen again on 2.0RC1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20060918 Firefox/2.0). I was replying to a comment on livejournal.com, specifically on a form with 2 components, a text input (subject) and textarea (comment). I hit enter on the submit button, and immediately hit ctrl+shift+tab, and it froze on the spot. I'm unsure whether it's relevant, but the POST data DID make it to the server in one piece.

Comment 58

11 years ago
I've finally figured out a good set of steps to reproduce this bug.

1. Open a new tab
2. Open another new tab
3. Open up yet another new tab
4. On that third tab, load the page data:text/html,<input onfocus="this.disabled=true"/>
5. Close the both tabs opened in steps 1 and 2
5.5. The tab from step 3 with page from step 4 is now focused
6. Select the input
6.5. The input box is now disabled (with focus still in the input box)
7. Press ctrl-shift-tab

Basically, these steps cause a tab's 2 left neighbors to be removed, so when you ctrl-shift-tab, it fails to find the correct tab to use. If I had to guess, there's something missing with updating the pointer to the "previous" tab, so when 2 consecutive tabs are removed... bad stuff happens.

The reason for the focus on a disabled input... It seems like the crash when ctrl-shift-tab in general was fixed. (I don't have the bug/checkin for that.)

TB25626833Q - Firefox 2 Windows XP
TB25626823W - Minefield 2006110604 Windows XP
TB25627014G - Firefox 2 Mac OS X 10.4
Can't repro on the current mac trunk because ctrl-shift-tab doesn't change tabs.


Updating summary to not include the version seeing that this can be repro'd on Firefox 2 and trunk.
Summary: I hit ctrl+shift+tab and mozilla fell over - M1.7.x, FF1.0.x [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell] → I hit ctrl+shift+tab and mozilla fell over - [@ nsXULWindow::ContentShellAdded ][@ nsEventStateManager::GetPrevDocShell]
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061106 SeaMonkey/1.5a
On Linux with kde, Ctrl-Shift-Tab is intercepted by the window manager. Ctrl-PgUp either does nothing or goes to previous tab (which was the last tab before step 1 in comment #58 ). No crash.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061106 BonEcho/2.0
Build ID: 2006110604
(In reply to comment #60)
> On Linux with kde, Ctrl-Shift-Tab is intercepted by the window manager.
> Ctrl-PgUp either does nothing or goes to previous tab (which was the last tab
> before step 1 in comment #58 ). No crash.
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061106 BonEcho/2.0
> Build ID: 2006110604
> 

Oops: my other browser:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061106 SeaMonkey/1.5a
Build ID: 2006110602

Comment 62

11 years ago
Created attachment 244883 [details] [diff] [review]
possible patch (for 1.8)

Perhaps we could do just something like this?
Attachment #244883 - Flags: review?(bryner)

Comment 63

11 years ago
(In reply to comment #62)
> Created an attachment (id=244883) [edit]
> possible patch (for 1.8)
> 
> Perhaps we could do just something like this?
> 
At least for branch.
For trunk the underlaying bug should be fixed.
(The problem is probably that the childOffset isn't updated properly)
Comment on attachment 244883 [details] [diff] [review]
possible patch (for 1.8)

I think Mats Palmgren would probably be a better reviewer for this.
Attachment #244883 - Flags: review?(bryner)

Updated

11 years ago
Attachment #244883 - Flags: review?(mats.palmgren)

Comment 65

11 years ago
Mats, any chance to get a review ;)
(Assignee)

Comment 66

11 years ago
Comment on attachment 244883 [details] [diff] [review]
possible patch (for 1.8)

Looks good.  This should make ESM more robust against internal errors
in the docshell code.  r=mats

I think I found the real error though...
Attachment #244883 - Flags: review?(mats.palmgren) → review+
(Assignee)

Comment 67

11 years ago
Created attachment 253573 [details] [diff] [review]
Real fix?

The error is in nsDocShell::RemoveChild (the other changes are just
killing some compiler warnings under DEBUG_DOCSHELL_FOCUS).

When we remove a child we need to update the child offsets (unless it's
the last child we remove). I think we should take both patches.
Attachment #253573 - Flags: superreview?(bzbarsky)
Attachment #253573 - Flags: review?(Olli.Pettay)

Comment 68

11 years ago
Comment on attachment 253573 [details] [diff] [review]
Real fix?


> NS_IMETHODIMP
> nsDocShell::RemoveChild(nsIDocShellTreeItem * aChild)
> {
>     NS_ENSURE_ARG_POINTER(aChild);
> 
>+    PRInt32 childOffset = 0;
>+    aChild->GetChildOffset(&childOffset);
>+    PRBool needToUpdateOffsets = childOffset != (mChildList.Count() - 1);
>     nsRefPtr<nsDocLoader> childAsDocLoader = GetAsDocLoader(aChild);
>     NS_ENSURE_TRUE(childAsDocLoader, NS_ERROR_UNEXPECTED);
>     
>     nsresult rv = RemoveChildLoader(childAsDocLoader);
>     NS_ENSURE_SUCCESS(rv, rv);
>     
>     aChild->SetTreeOwner(nsnull);
> 
>+    if (needToUpdateOffsets) {
>+        PRInt32 i, n = mChildList.Count();
>+        for (i = 0; i < n; i++) {
>+            nsCOMPtr<nsIDocShellTreeItem> child = do_QueryInterface(ChildAt(i));
>+            NS_ENSURE_TRUE(child, NS_ERROR_FAILURE);
>+            child->SetChildOffset(i);
>+        }
>+    }
>+
Could you start for(;;) from childOffset, not 0 ?
Then you wouldn't need needToUpdateOffsets at all.

(the patch seems to be for 1.8)

Updated

11 years ago
Attachment #244883 - Flags: superreview?(bzbarsky)
Comment on attachment 244883 [details] [diff] [review]
possible patch (for 1.8)

Mmm... So the thing is, what if GetChildAt() _does_ return something but it just happens to not be the right thing?  e.g. if it returns the docshell two earlier?

Wouldn't it make more sense to search the child list until we find the right aNode and then return the previous item, instead of relying on childOffset?
Attachment #244883 - Flags: superreview?(bzbarsky) → superreview-
Comment on attachment 253573 [details] [diff] [review]
Real fix?

This one is tough.  First of all, even with this patch the offsets can be wrong if a child of docshell A is added to docshell B since we wan't call RemoveChild then but will do a "raw" remove.

Second, this could have nasty interactions with session history; the session history impl relies on its offsets matching the docshell offsets, and you're updating one but not the other....
(Assignee)

Comment 71

11 years ago
Created attachment 253698 [details] [diff] [review]
wip

Something like this perhaps (trunk patch this time).  I really don't know the
session history code well enough to know if this is correct or not though...
Someone who do should take the bug ;-)
Attachment #253573 - Attachment is obsolete: true
Attachment #253573 - Flags: superreview?(bzbarsky)
Attachment #253573 - Flags: review?(Olli.Pettay)
No one really knows that code.  Changes to session history are just some one does at great peril and with willingness to fix regressions... and someone one does in an alpha.  :(
(Assignee)

Updated

11 years ago
Whiteboard: [STEPS TO REPRODUCE:comment 58]
(Assignee)

Comment 73

11 years ago
Ok, sounds like the docshell patch is out of the question for branches then.
Your suggestion for a loop looking for the prev sibling should be safe though.
We should fix GetNextDocShell() at the same time, there a few crashes on
that one as well, although a lot less than GetPrevDocShell().
Flags: blocking1.8.1.3?
Flags: blocking1.8.0.11?

Comment 74

11 years ago
This has been happening to me frequently (including latest 2.0.0.2 build). If I have many tabs open, and some are loading, and I do CTRL+SHIFT+TAB, it crashes firefox. On 2.0.0.1 it wouldn't reload any of the tabs, thankfully this has been fixed in the latest update.  Using Windows XP MCE SP2 with no other programs running and Dachsund Soft AntiCrash in the background (saved me quite a few times).
Old bug, no owner ("events@dom.bugs"), scary code (comment 72). Doesn't seem appropriate for a security/stability update (emphasis on stability). Unless Mats's nomination means he's stepping up?
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4-
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12-
(Assignee)

Comment 76

11 years ago
I actually have a patch cooking for this (searching instead of using the
child index as bz suggested in comment 69).
I'll attach it later today hopefully...
Assignee: events → mats.palmgren
(Assignee)

Comment 77

11 years ago
Created attachment 258607 [details] [diff] [review]
Patch 4, avoid using GetChildOffset()

Iterate over the children looking for the specific docshell instead of
trusting that GetChildOffset() corresponds to its position in the child list.
This patch also applies to 1.8/1.8.0 branches.

There is still a GetChildOffset() in HandleAccessKey() that is used to avoid
traversing the same child again when calling HandleAccessKey() on the parent
ESM. I think this (theoretically) could cause a 100% CPU hang but let's
handle that in a separate bug.
Attachment #244883 - Attachment is obsolete: true
Attachment #258607 - Flags: review?(Olli.Pettay)

Comment 78

11 years ago
Comment on attachment 258607 [details] [diff] [review]
Patch 4, avoid using GetChildOffset()

Should be safe.

So after this change and a change to HandleAccessKey GetChildOffset could be removed ?
Attachment #258607 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 79

11 years ago
(In reply to comment #78)
> So after this change and a change to HandleAccessKey GetChildOffset could be
> removed ?

Yes, I think so.
(Assignee)

Updated

11 years ago
Attachment #258607 - Flags: superreview?(bryner)
(Assignee)

Comment 80

11 years ago
bryner, I plan to request approval for branches on this patch so I'd
like to land it on trunk to get some baking time...  sr please?
(Assignee)

Updated

11 years ago
Attachment #258607 - Flags: superreview?(bryner) → superreview?(roc)
Attachment #258607 - Flags: superreview?(roc) → superreview+
(Assignee)

Comment 81

11 years ago
Checked in to trunk at 2007-04-04 15:21 PDT.

Filed bug 376562 to followup on removing GetChildOffset() completely.

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 14 years ago11 years ago
Resolution: --- → FIXED

Comment 82

11 years ago
Steps from comment #58 no longer cause a crash for Windows XP and Linux builds.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/2007040504 Minefield/3.0a4pre

Mac OS X builds don't switch tabs with ctrl-tab anymore, so it's not an issue.

v
(In reply to comment #82)
[...]
> Mac OS X builds don't switch tabs with ctrl-tab anymore, so it's not an issue.

Have you (or has someone with a Mac) tested some other keyboard shortcut, such as Cmd-PgUp (go to prev tab), Cmd-PgDn (go to next tab)? If these don't work either, then it might be a _different_ issue, viz., no keyboard shortcut to walk tabs.
Ctrl+Tab being broken on Mac trunk builds is bug 374076.
Flags: in-testsuite?

Updated

10 years ago
Duplicate of this bug: 403509
Any chance of this fix making it to the branch?

There are currently 437 reports in the Talkback db with this signature and at least one extension makes this crash easier to hit than the steps in comment 58.

Comment 87

9 years ago
mats: what happened to the branch version you were hoping for in comment #80?

Updated

9 years ago
Flags: wanted1.8.1.x?

Comment 88

9 years ago
nominating
Flags: blocking1.8.1.18?
Not a top crash anymore, doesn't fit the branch blocking criteria.
Flags: blocking1.8.1.18?
Crash Signature: [@ nsXULWindow::ContentShellAdded ] [@ nsEventStateManager::GetPrevDocShell]
You need to log in before you can comment on or make changes to this bug.