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

Status: RESOLVED FIXED

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

Description

[Hogarth]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

[Rene Pronk]

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

[Philip White]

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

[Philip White]

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

[Frederic Bezies]

Mozilla is freezing with this combination of keys.

Using build 2002081204 - WinXP.

Comment 6

[Matthias Versen [:Matti]]

-> Event Handling

Comment 7

[Andrew Schultz]

worksforme with linux build 20020811.  ctrl-shift-tab cycles through sidebar,
content area and URL bar.

Comment 8

[Hogarth]

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

[Andrew Schultz]

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).

Comment 10

[Daniel Clemente]

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.

Comment 11

[Daniel Clemente]

   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

Comment 12

[Olivier Cahagne]

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));

Comment 13

[Olivier Cahagne]

Attachment: Stack trace Linux 20030125

Comment 14

[Olivier Cahagne]

*** This bug has been marked as a duplicate of 156405 ***

Comment 15

[Daniel Clemente]

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

Comment 16

[Olivier Cahagne]

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

Comment 17

[Daniel Clemente]

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

[Daniel Clemente]

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

Comment 19

[Daniel Clemente]

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.

Comment 20

[Mike Boone]

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

[Daniel Clemente]

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).

Comment 22

[Andrew Hagen]

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

I can generate Talkbacks on Mozilla 1.7 builds if anyone wants one.

Comment 23

[chris hofmann]

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.

Comment 24

[Jay Patel [:jay]]

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.

Comment 25

[Asa Dotzler [:asa]]

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

[Jay Patel [:jay]]

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

[Asa Dotzler [:asa]]

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

[Andrew Hagen]

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

[Daniel Clemente]

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

[Jay Patel [:jay]]

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.

Comment 31

[timeless]

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

Comment 32

[Adam Hauner]

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

Comment 33

[earthsound]

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

[Adam Hauner]

(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.

Comment 35

[earthsound]

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

Comment 36

[Brian Warner]

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

Comment 37

[earthsound]

TB4579436Z & TB4853310K

Comment 38

[earthsound]

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

[Jay Patel [:jay]]

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.

Comment 40

[Ed Lee :Mardak]

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

Comment 41

[earthsound]

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

[Richard Aspden]

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

[Richard Aspden]

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

[sonya]

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

[Martin Arndt]

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

[Richard Aspden]

Had a repeat crash with this, talkback report TB11007720K

Comment 47

[:Gavin Sharp [email: [e-mail]]]

*** Bug 255909 has been marked as a duplicate of this bug. ***

Comment 48

[:Gavin Sharp [email: [e-mail]]]

*** Bug 314257 has been marked as a duplicate of this bug. ***

Comment 49

[Doug]

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

[Noa Groveman]

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

[earthsound]

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

[earthsound]

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]

Comment 53

[Richard Aspden]

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!)

Comment 54

[earthsound]

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

Comment 55

[Wayne Mery (:wsmwk)]

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

[Noa Groveman]

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

[Richard Aspden]

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

[Ed Lee :Mardak]

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.

Comment 59

[Alex Vincent [:WeirdAl]]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061106 SeaMonkey/1.5a

Comment 60

[Tony Mechelynck [:tonymec]]

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

Comment 61

[Tony Mechelynck [:tonymec]]

(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

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch (for 1.8)

Perhaps we could do just something like this?

Comment 63

[Olli Pettay [:smaug][[e-mail]]]

(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 64

[Brian Ryner (not reading)]

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

I think Mats Palmgren would probably be a better reviewer for this.

Comment 65

[Olli Pettay [:smaug][[e-mail]]]

Mats, any chance to get a review ;)

Comment 66

[Mats Palmgren (inactive)]

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...

Comment 67

[Mats Palmgren (inactive)]

Attachment: 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.

Comment 68

[Olli Pettay [:smaug][[e-mail]]]

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)

Comment 69

[Boris Zbarsky [: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?

Comment 70

[Boris Zbarsky [:bzbarsky]]

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....

Comment 71

[Mats Palmgren (inactive)]

Attachment: 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 ;-)

Comment 72

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 73

[Mats Palmgren (inactive)]

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().

Comment 74

[Brent Newland]

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).

Comment 75

[Daniel Veditz [:dveditz]]

Old bug, no owner ("[e-mail]"), 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?

Comment 76

[Mats Palmgren (inactive)]

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...

Comment 77

[Mats Palmgren (inactive)]

Attachment: 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.

Comment 78

[Olli Pettay [:smaug][[e-mail]]]

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 ?

Comment 79

[Mats Palmgren (inactive)]

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

Yes, I think so.

Comment 80

[Mats Palmgren (inactive)]

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?

Comment 81

[Mats Palmgren (inactive)]

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

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

-> FIXED

Comment 82

[Ed Lee :Mardak]

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

Comment 83

[Tony Mechelynck [:tonymec]]

(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.

Comment 84

[:Gavin Sharp [email: [e-mail]]]

Ctrl+Tab being broken on Mac trunk builds is bug 374076.

Comment 86

[Arie Paap [:wildmyron]]

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

[Marc Bejarano]

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

Comment 88

[Marc Bejarano]

nominating

Comment 89

[Daniel Veditz [:dveditz]]

Not a top crash anymore, doesn't fit the branch blocking criteria.