156405 - Tabbed browsing frequently crashes Mozilla - Trunk M130A [@ nsXULWindow::ContentShellAdded]

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect, P1)

Description

[manojd]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611
BuildID:    2002061104

I don't have a repeatable sequence but have had a crash two days in a row. Each
time, the Mozilla session had opened not more than 3 windows (in one case, only
one Mozilla window opened during entire session), but exactly one of these
windows had lot of tabs opened & closed during the session. At the time of
crash, many tabs were open; and (I think) I had asked Mozilla to open yet
another tab. Sessions were 2 - 2:30 hrs long.

Above is actually better behavior than IE - but irritating still. An IE session
on Win2K where I open lot of windows has a tendency to make Windows unusable
after a few hours - I must reboot Windows. Mozilla is at least leaving rest of
the OS & applications untouched:(

I think both have something to do with amount of windows resources consumed.
Probably some of the resources are never freed when they are no longer required.
And there must be places in HTML rendering code that are not prepared to accept
the fact that resource request to Windows can fail.

Each time, Netscape Feedback Agent popped up - but never sent anything back -
just hung (actually not even hung - its window was responding to mouse clicks
but it just didn't sent anything for a long time & then I killed it). I have
seen Feedback Agent always successfully report back the crashes from my office
PC. This hang occured at my home PC - the special thing about the environment
was: at the time of crash, I was connected to an ISP that doesn't host my mailbox.

Reproducible: Didn't try
Steps to Reproduce:
1. See description above.

Comment 1

[Adam Hauner]

-> Tabbed browser

Comment 2

[Andrew Hagen]

Is this the same as bug 143131?

Comment 3

[manojd]

"Is this the same as bug 143131?": Andrew - I don't know. Cause *could be* same
- incorrect management of lifetime of system resources, & incorrect handling of
situation where system could not give the requested resource.

But I have never seen this problem related to speed at which I am opening tabs
(as noted in bug#143131) - or may be I didn't notice.

Something else that might help someone reproduce the problem. In both sessions,
I was "killing time" browsing movie picture gallaries - may be something to do
with resources related to display of a lot of gif or JPEG thumbnails. It is
almost certainly NOT related to display of big JPEG images - only lots of small
thumbnails - if at all this is the reason. Because I rarely like the images
enough to actually bother opening the big JPG - and when do like, I typically
ask GetRight to get them for offline viewing.

Comment 4

[Andrew Hagen]

I don't know it's just related to displaying graphics. I've seen it when
displaying  a large number of news stories in tabs. Go to nytimes.com and open
every story in a tab, for example. 

Comment 5

[Jason Bassford]

Additional comments (see
http://www.mozillazine.org/talkback/read.php?f=2&i=2163&t=2163 for fuller
description):

1. When I see this I don't get a "crash" but an entire computer "hang".  Both
Mozilla and the OS are completely unresponsive for 20-30 minutes.

2. This "hang" repeats itself every 5-10 minutes untill all Mozilla sessions
(mozilla.exe processes) are shut down.

3. When I do get a hang, it doesn't happen until, generally speaking, about 5-10
minutes from the time I loaded the "suspect" site into a tab.  I can't identify
WHICH site is the suspect one but know it has to be one of them.  So, when I say
"generally speaking" 5-10 minutes I'm estimating.  I *DO* know that the freeze
never happens immediately after loading a site.  (If it did, I could clearly
indicate which sites cause the problem and be a step closer to analyzing what
they all have in common.)

4. I have seen this with only 1 window of 3 tabs open, so it seems to have
little to do with "a great number" of tabs - expect, perhaps, the fact that
having more tabs open increases the odds of hitting on a site that generate this
behaviour.

5. I have not seen this when I have been tab browsing only Bugzilla or
Mozillazine - so both of those sites are "friendly".

6. Normally I get this when I do a Google search and open a series of linked
sites - but I don't think it has anything to do with Google per se, it's just
that I've managed to hit on a "hostile" site.

7. I have noticed no correlation between graphics and this freezing.  Which is
not to say that there isn't one, just that there isn't one that's noticable.

8. This is the most obscure, annoying, unidentifiable bug I've ever seen.  I
hope somebody is able to determine some kind of pattern so we can start to work
on it.

Comment 6

[Jason Bassford]

Confirming.  (I'm not going to treat this as a dupe of bug 143141 since I don't
believe it has anything to do with "fast loading" of tabs.)
OS -> All.

Comment 7

[Andrew Hagen]

Jason, this may be an irrelevant question, but do you have HTTP pipelining enabled?

Comment 8

[Jason Bassford]

Yes, I have pipelining enabled (as well as keep-alive).  It seems to produce
faster rendered pages for the most part.  I know that there are problems with
it, but none that have ever negatively impacted me enough to turn it off (at
least that I've been aware of).

If you wish, I could turn it off for a week or so and see if my "hangs" stop
happening.

Comment 9

[manojd]

Couple of days back, I almost had a repeatable sequence. It was too late in the
night - so I didn't bother recording, but this is what I recall.

I was able to repeat the problem in a couple of minutes after starting Mozilla -
& in probably within 10 mouse clicks.

1.  Close all Mozilla windows as well as Quick Launch from task bar. So I can
start Mozilla in a clean state.
2.  Start Mozilla. Load a specific bookmark. This bookmark was really a group of
18 tabs. Don't know if it had any "unfriendly" pages - but this (large) number
is probably significant.
3.  While the various tabs are in various stages of loading, I actually have an
idea of 3-4 tabs I am likely to use in this session. And they appear at the
right end of the tabs list.
4.  So I start opening tabs from left. The moment it's URL is visible (but page
beginning to load), I stop its loading by clicking X icon in Mozilla toolbar. I
do this for all tabs except the few (it was either 3 or 4) I am interested in. I
was connected over a slow dial-up line. In a few cases, I had to wait after
opening a tab - so URL appears in its box - before hitting STOP.
5.  OK. So now I have a state where one Mozilla window is open with 18 tabs.
Each tab has a URL. In 14 tabs, the page is partially loaded - usually, it just
began to load. In remaining 4, it is fully loaded.
6.  I now start browsing - normally by opening a new tab. Usually I let these
new tabs fully load. May be in 1 or 2 cases, I killed the load half way through.
In most cases, I destroyed that tab after I was done with it. In 1 or 2 cases,
this additional tab was sitting in window - so my tab count was 19 or 20 or may
be 21.
7.  I did step 6 for perhaps 4 or 5 times. I.e., I opened only 4 or 5 tabs this way.
8.  Bingo - I had the get the crash.
9.  I repeated the at least 3 times. Wasn't looking specifically for a crash 2nd
time - but got it. Was specifically looking for the crash sequence 3rd time, but
was also watching TV & goofed up in exact recording of steps.

Comment 10

[manojd]

I too have pipelining enabled. If it is any help.

Comment 11

[Jason Bassford]

Aha!  I've identified and solved my specific problem.

This looks like a duplicate of bug 146884.  (See bug 146884 comment 21.)  With
pipelining on and visiting the URL referred to for 5 minutes or so, my computer
hangs every time.  With it off, no such problem.  (Obviously the URL mentioned
is not the only site that will do this, but it is, FINALLY, a reproducible site.)

Thanks to pointers in mentioning pipelining as the possible root cause rather
than tabs.  (It's just that tabbed browsing exposes the problem more readily. 
Also, I'm sure that those of use who use tabbed browing almost always have more
than one tab open at once.)

Comment 12

[Andrew Hagen]

There is a hang bug associated with pipelining. It's going to be fixed. I wonder
if it's a dupe of that one. It's bug 146884.

In my own testing, after I turned off pipelining, things seemed to improve a
lot. I still got some weird crashes though.

Comment 13

[Andrew Hagen]

Shows you what I get for posting without reading the last comment! Sorry, Jason.

Maybe we should dupe it now, or maybe we should wait until that one is fixed and
then see if we can reproduce with pipelining.

Comment 14

[Jason Bassford]

It's true that the pipelining issue may be just one of the things that's causing
the problem reported here.

I suggest that everybody following this bug turn pipelining off.  If, by next
Monday, nobody's encountered further problems that this bug then be marked as a
duplicate.  If somebody DOES have a problem, even without pipelining, that bug
146884 be marked as a dependency and this bug kept open.

Comment 15

[Jason Bassford]

Okay:

1. With pipelining off I have not had a crash/hang in the past 24 hours.
2. Since upgrading to the latest build (2002072704 trunk), which has a fix for
pipelining bug 146884 checked in, and re-enabling pipelining, I have not had a
crash when going to the reference site (bug 146884 comment 21) and leaving it in
a tab for up to 30 minutes.  (I could reproduce this 100% before the check in,
and cannot do so at all any more.)

Therefore, since everything points to it being related to pipelining, and the
check in for bug 146884 on the trunk corrected the problem with pipelining
enabled, I am marking this bug as a duplicate of that one.

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

Comment 16

[sairuh (rarely reading bugmail)]

marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica

Comment 17

[manojd]

This specific crash has nothing to do with pipelining.

I had pipeling disabled since the day comment#7 suggested on 26jul2002 pipeling
could be the culprit. I still continue to get crashes with their old consistency
& regularity. I finally re-enabled pipelining yesterday - I can at least get
faster page loads!

This problem certainly has something to do with tabbed browsing. And "unfriendly
sites" suggestion in comment#5 does seem to have merit. My observations during
the last 4 weeks:
1.  There was a day when I was repeatedly getting crash with a certain set of 5
or 6 tabs. The moment I started using new windows rather than new tabs, the
problem vanished. Or rather, got postponed by nearly an 30 minutes - because I
was now opening tabs in these various windows!
2.  "unfriendly sites": I actually did not do systematic confirmation - my
observation on this is based on pseudy-systematic work. In #1, I first saw crash
with about a dozen tabs. Started reducing them. Was finally getting it with a
bunch of 6 tabs but not if two of them were specific URLs. However, these 2
URLs, by themselves, were opening in new windows properly.
3.  A few days back, I was repeatedly getting crash when many tabs were created
& destroyed in a session. I have since found a workaround & haven't got a crash
since. I open the main page in first tab. Plus 4 tabs. Everytime I feel a need
for a new tab, I don't really create a new tab & destroy old ones. I simply copy
the URL from main page to appropriate already existing tab via clipboard. The
crashes have something to do with creation & destruction of tabs.

Comment 18

[Andrew Hagen]

Darn. Me too. I've seen this kind of thing myself since the pipelining fix was
checked in. Reopening. 

It would be great to get a stack.

Comment 19

[Olivier Cahagne]

anyone still seeing this with latest 1.2 build ? Please submit Talkback ID or
stack trace.
http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.2

Comment 20

[manojd]

I have seen it in 1.2 - am running build ID 2002101612. But talkback refuses to
work from my home PC. Had to kill talkback every time - it just hung - I waited
nearly 5 minutes in one cases - was connected all the time through a DSL line.

Comment 21

[James Nord]

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

Comment 22

[James Nord]

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

Comment 23

[James Nord]

Added CC.

Have some talkback ID's

TB14701753X
TB14701059Z

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021121

Comment 24

[James Nord]

reproducable -> yes (takes < 5 minutes on a dial-up)

TB14702339M

1) go to site www.cwjobs.co.uk
2) search for Java
3) open several links in new tabs
4) view next results /(next link on btm web page)
5) open some more links in new tabs
6) have a look at some of the tabs whilst they are loading (loaded may also do 
but am on a dialup so it's slow ;-) )
7) close some random tabs
8) goto 4)

Comment 25

[Asa Dotzler [:asa]]

This is showing up as the #50 crash in 1.2 data (not going to hold alpha for
this). nsXULWindow::ContentShellAdded is the location of the crash. It's still
showing up in the nightly data (three incidents at least, the ones in this bug)
The talkback data contains a couple of comments about tabs and a number of URLs
but isn't particularly helpful. The top of the stack looks like this:

nsXULWindow::ContentShellAdded
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1419]
nsChromeTreeOwner::ContentShellAdded
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsChromeTreeOwner.cpp, line 185]
nsHTMLFrameOuterFrame::AttributeChanged
[c:/builds/seamonkey/mozilla/layout/html/document/src/nsFrameFrame.cpp, line 695]
nsCSSFrameConstructor::AttributeChanged
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 10685]
StyleSetImpl::AttributeChanged
[c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp, line 1582]
PresShell::AttributeChanged
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 5292]
nsXULDocument::AttributeChanged
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 2210]
nsXULElement::SetAttr
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 2750]
nsXULElement::SetAttribute
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 1330]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2014]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1282]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 841]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2804]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 857]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 932] 

Comment 26

[Andrew Hagen]

Okay. QA still wanted. Reporters, please install latest-trunk to get up to 1.3.
Then, if you have any more tabbed browsing crashes, please generate a Talkback
report. Include as full a description as possible, and report the Talkback ID
number to this bug. I will do the same. Thank you.

Comment 27

[Doug Eaton]

I installed 1.3a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021209
this morning and can reproduce this.  Incidents TB14895608Z and TB14896412Q are
both examples of this bug.  The first (Z) was created by continuously selecting
'Next' in a new tab.  On the 21st tab, the page did not render.  My attempt to
open the 22nd tab caused the crash.  The second was created by opening several
about:blank tabs and several other tabs then performing the job search.  In this
case, the crash was immediate.  I can usually reproduce this within 3 minutes of
starting mozilla with a new default profile that only has 'new tab on middle
click' enabled.

Comment 28

[James Nord]

TB14907145Y

details see  see comment #24

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021209 (2002120908)

Comment 29

[Bob Rusbasan]

This bug has driven me crazy, and I'm glad to see it's being worked on.  I have
some additional details which may help:

What happens, for me, is I'm loading links in the background, and I'll be
middle-clicking on links, and new tabs are popping up, and everything's fine. 
But then one of the tabs will pop up and never show a loading state.  In other
words it immediately appears as if the page is done loading.  If I hover my
mouse cursor over the tab, its name is just the URL, not the page title, so it
obviously hasn't loaded.  If I click on the tab, it's an instant crash.

I think this can help because if you follow the steps in comment #24, you won't
have to do this scattershot clicking of tabs, not knowing when it's going to
crash.  Just watch the tabs as you open them, and as soon as you see one pop up
immediately in the loaded state, you have the bug right there.  If there's any
doubt, hover over it and see if it's a URL instead of a page title.  Usually all
subsequent tabs will load in the same way (and also be instant crashes if
clicked), although by messing around and doing "reload all" I can sometimes make
new tabs work (but the old tabs never reload and stay little bombs ready to
explode when clicked).

More fun facts:  If you simply avoid these deadly tabs and close the window, you
can avoid the crash.  I actually once had tons of tabs and was able to very
carefully look at all of the good ones, evening opening up a few new ones, and
then when I was done close the whole window.

This seems to have nothing to do with the page content, as it happens on many
different pages, and I can reload the same pages later without incident.

Also, if you have some tabs in this state, you cannot bookmark all tabs.  It
does very weird things or gives you weird messages.  For example, I have a
window in this state right now, and if I try to bookmark all tabs it tries to
load the site "http://bookmarks_groupmark/" in the first tab.  Another time I
got an error message; perhaps the difference is related to different proxy settings.

Comment 30

[Greg K.]

Attachment: Crash report generated by FizzillaMach/2002121607 showing crash at nsXULWindow::ContentShellAdded

Reproduced using FizzillaMach/2002121607 by continually creating new tabs and
loading <http://komodo.mozilla.org/buster/random/random.html> into them until
Mozilla crashes (in this instance, at the 17th tab).

Comment 31

[Greg K.]

Setting Hardware=All per comment 30.

Comment 32

[Greg K.]

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

Comment 33

[thebeastwitheyesthatstared]

Steps I used to crash in nsXULWindow::ContentShellAdded] are (also):

a) load http://komodo.mozilla.org/buster/random/random.html
b) load above url again in new tab
c) (continue to do b) until you reach the maximum amount of tabs, then if you
haven´t crashed, try switching to the last tab or second last tab, the last part
may help trigger the crash)

ie. all tabs should be loading (until the crash occurs)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20021219

TB15327986M
TB15329726H (confirms previous above Talkback report)

reproduceable on Windows XP everytime, but I also saw this on Windows 2000 -
following the same steps that Greg mention. I have seen this occur with Mozilla
1.3a also, both on 2000 and XP. You can also see my previous Talkback reports:

TB15085962X
TB15086038Q (both from 14/12)

bsmedberg, can you add comment including the stack trace you emailed?

Comment 34

[Olivier Cahagne]

Attachment: Linux stack trace 20021218

WARNING: Too many docshell (recursion?) so giving up, file nsFrameLoader.cpp,
line 351
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsFrameLoader.cpp, line
239

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 2472)]
nsXULWindow::ContentShellAdded (this=0x81542f8, aContentShell=0x0, aPrimary=1, 

    aID=0xbfff9578) at nsXULWindow.cpp:1435
1435	  aContentShell->GetTreeOwner(getter_AddRefs(treeOwner));

Comment 35

[thebeastwitheyesthatstared]

Benjamin sent me this yesterday, he´s on Windows 2000:

Right before mozilla crashed, I saw the following warning:

WARNING: Too many docshell (recursion?) so giving up, file
./nsFrameLoader.cpp, line 351
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file 
./nsFrameLoader.cpp, line 239

END

- so it´s exactly the same place as on linux, maybe? Benjamin sent me a
stacktrace also, which I´m uploading. I´m not sure about the build, so I´ll just
call it Windows 2000 stacktrace.

Comment 36

[thebeastwitheyesthatstared]

Attachment: Windows 2000 Fri 20 Dec 2002 nightly stacktrace

from Benjamin [e-mail]

Comment 37

[Benjamin Smedberg]

This is a really strenuous testcase... 20 tabs open, and each of these has 4
sub-frames, so you get 150+ docshells by the time it crashes. Perhaps what is
happening in normal browsing is some sort of recursive frameset causing the
number of docshells to skyrocket?

Comment 38

[thebeastwitheyesthatstared]

still crashing with 1227 nightly - win2000 SP3, 18-19 tabs seem to be enough. I
filed a talbakc report, it is  TB15567653Z

Comment 39

[Greg K.]

This bug has more than enough stack traces, TalkBack references, and
cross-platform confirmations now. No more are needed unless the assignee asks
for them explicitly.

Comment 40

[Ryan Mayor]

I just wanted to add that this has been happening for me since 1.2 came out. 
Never happened in 1.2b or previous.  I had hoped that 1.3a would solve it, but no. 

I can't reproduce reliably, but I have it occur for me at least once or twice a
day.  I always only have one browser window open, and the mail window open.  It
occurs when I am opening and closing a lot of tabs (say 10-15 max) relatively
quickly.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 

Comment 41

[Jay Patel [:jay]]

This is a current topcrasher on the MozillaTrunk (and has been showing up in
M121 and M130A Talkback data as well) Adding topcrash keyword and Trunk M130A [@
nsXULWindow::ContentShellAdded] to summary for tracking.

If anyone wants anymore Talkback data just let me know.  Thanks.

Comment 42

[Olivier Cahagne]

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

Comment 43

[Olivier Cahagne]

from bug 162283, open 20 tabs on
http://www.kingfeatures.com/features/comics/comics.htm (bug 189621), hit
Ctrl-Shift-Tab until you crash, Linux 20030125:

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 44

[Jan Carpenter]

Marking topcrash+

Comment 45

[Ryan Mayor]

Considering it's topcrash+ status, why is this bug not on the blocker list for 1.3b?

Comment 46

[Andrew Hagen]

We weren't seeing this in 1.0. Then, soon after 1.1 alpha was released, this bug
got filed. Looks like it could be a regression.

This bug is a major cause of instability and is one that we should fix for 1.3.
Nominating for 1.3 beta.

Comment 47

[Bob Rusbasan]

I second the nomination.  For me, this bug is the ONLY cause of instability for
me as far as I can tell.  The browser works extremely well otherwise.  But when
this bug hits, and it usually hits when I have a bunch of tabs and windows open,
wow, is it ever infuriating!

I must disagree about this not being in the 1.0.x versions though.  I went back
to  to 1.0.1 to try to escape this nasty bug, and I still ran into it.  I did
some tests on it, and it does seem like it's a little harder to trigger, but you
can definitely do it.

Bottom line:  This bug is extremely serious and has been around for a good six
months and probably much longer.  Please do what you can to fix it.

Comment 48

[Benjamin Smedberg]

Going through this bug, I think that this bug was probably introduced by the fix
for bug 98158. The code at:

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsFrameLoader.cpp#342
parentAsItem->GetSameTypeRootTreeItem(getter_AddRefs(root));

may be returning a chrome docshellThis causes the MAX_NUMBER_DOCSHELLS check to
count all of the docshells in chrome, which is not what was inteded. After that,
there's no good recovery: we're toasted.

A wallpaper patch for 1.3b could increase MAX_NUMBER_DOCSHELLS to 175-200. 
The actual solution looks much more complicated.

Keyword mozilla1.3 is deprecated. And I personally don't think that this is
worth blocking 1.3b. You can browse in multiple windows to avoid this problem. 

Comment 49

[Ryan Mayor]

I'd be happy if the wallpaper patch mentioned in comment #48 was put into 1.3b,
and the more complicated fix was left for 1.3 or 1.4a.

Comment 50

[Benjamin Smedberg]

Discussed this with jkeiser on #mozilla, and I think I've got a potential
solution... patch forthcoming tomorrow, I hope.

I want to disable the MAX_NUMBER_DOCSHELLS check for chrome docshells: it will
only apply to content shells. This will keep preventing DOS attacks from nested
frames, while allowing largescale tabbed browsing.

Comment 51

[Asa Dotzler [:asa]]

This is the 65th most common crasher in the last 10 days of talkback data. Not
going to hold beta for this.

Comment 52

[manojd]

Clarification on comment#46 - "it debuted in 1.1". Well, I remember having faced
it as early 0.8 or 0.9.

Comment 53

[Benjamin Smedberg]

Oops, I meant to assign this to myself. Sorry!

Comment 54

[Benjamin Smedberg]

Attachment: simple patch to propagate error codes

This patch does not solve the problem of MAX_NUMBER_DOCSHELLS being called in
chrome. It does prevent the crash by propagating error codes down to
nsCSSFrameConstructor::ConstructFrame.

Comment 55

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 113110 [details] [diff] [review]
simple patch to propagate error codes

Remove hunk at @@ -5933,6 +5934,8 @@, it's irrelevant. Given that, r+sr=roc+moz

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 113110 [details] [diff] [review]
simple patch to propagate error codes

approving for 1.3b

Comment 57

[Benjamin Smedberg]

Attachment: simple patch, fixed up

Same as above, without the extraneous patch chunk.

Comment 58

[Benjamin Smedberg]

patched-on-trunk. Release-noted for 1.3b and 1.3final... "Browsing with many
tabs (>25) may cause some tabs to stop responding. Workaround: use multiple
browser windows."

Moving the other part of this bug out to 1.4a.

Comment 59

[James Nord]

Benjamin, that description is wrong, it doesn't stop some tabs responding it
crashes mozilla.  Also the number you have used does not tie in with the numbers
reporters have seen this happen with.
Comment 27 -> 22 tabs
Comment 38 -> 18/19 tabs
Comment 43 -> 20 tabs

Could you comment on the patch not going into 1.3 as it is approved?

Otherwise please change to something like "Browsing with many
tabs (>15) may cause mozilla to crash. Workaround: use multiple
browser windows."

Comment 60

[Asa Dotzler [:asa]]

James, this patch landed for Mozilla 1.3beta. Why should the description be
changed? 

01/31/2003 13:31	timeless%mozdev.org 	mozilla/ layout/ html/ document/ src/
nsFrameFrame.cpp 	3.217 	2/1  	Bug 156405 Tabbed browsing frequently crashes
Mozilla - Trunk M130A [@ nsXULWindow::ContentShellAdded]
patch by [e-mail] r=roc+moz, sr=roc+moz, a=roc+moz

Comment 61

[James Nord]

Asa,  Sorry, I was under the (wrong) impression that 1.3 had now branched.

As for the description I beleive the number is way out there, I have seen it
with a lot less than 25 tabs (low teens), as have people here.  Ignore the crash
bit as that was due to my misconception that 1.3 had branched and the patch was
only checked in on head.

Comment 62

[Bob Rusbasan]

Using 1.3 beta, I have not been able to get Mozilla to crash with this problem.
 You still get the dead tabs, but now clicking on them does not cause an instant
crash.  Much better!

One thing that should perhaps be added to the description of this bug is that
you cannot close these tabs.  The only way to close them is to close the entire
browser window.

Comment 63

[Benjamin Smedberg]

That's interesting... you can't close the tabs with the little "X" on the
tabbrowser? I don't remember that from my previous tests. This might be a clue
to the root problem.

Changing severity back to "normal" because this is no longer a crash.

Comment 64

[Bob Rusbasan]

Right, the X will not close the tab.  Neither will right-clicking the tab,
selecting "Close Tab" from the file menu, or pressing Ctrl+W.  This is on
Windows 2000 using the compile from this site.

I have my tabs load in the background.  What happened before 1.3 beta is that
when loading pages in new tabs I'd get these bad tabs that would immediately
show their state as loaded (even though it was too quick for that to be true). 
The text on the tab was simply the URL.  When I'd click on them, instant crash.
 So it was the act of looking at the tab that did it.  For those not opening
tabs in the background that probably wasn't clear, because they were opening a
tab and looking at it simultaneously.

What happens with 1.3 beta is the exact same thing, except now when I click on
the bad tabs instead of crashing it simply changes their caption from the URL to
"(Untitled)".  I can even load new pages in these tabs.  The only issue I've
seen so far is they cannot be closed.

I noticed the inability to close them with older versions.  Since I load tabs in
the background, if I paid attention I could see when I'd get these evil little
instant-crash tabs.  I tried using "close other tabs" to get rid of them, and it
would close all my good tabs (except the one I was looking at) and leave all the
bad ones.  So the inability to close isn't new, it's just more obvious since the
program's not crashing.

It also seems a lot harder to get this problem to come up.  I was able to do it,
but I had to open a lot more tabs than I had to before.  Maybe that's just a
coincidence, or maybe something is changed.  Anyway, to respond to the debate
over how many it was, it was never strictly a "number of tabs" issue.  Some
sites would cause it with much fewer tabs, and some needed more.

Comment 65

[Ryan Mayor]

I've had this sort of problem since 1.2.1 came out, but never before that.  I 
often load a lot of pages by middle clicking the link, and have the tabs load in 
the background.  When I quickly open and close tabs in this manner (by middle 
clicking on them to close) the problem occurs.  I've never actually had a crash 
because of it, though.  For me, what happens is that all of the tabs go "bad".  
In the tab bar, whichever one I try to click on to go to will "move to the top", 
but the display of them gets weird... they will begin to overlap each other, 
some will turn solid grey... things like that.  I can never switch tabs after 
this has occured either.  The only solution is to close the window and reload 
moz.  The program doesn't ever crash though.  It still responds to clicks, just 
not properly, and I can still use mail.  

Again, I've seen this since 1.2.1, but never before.  Running WinXP SP1.  

Comment 66

[Greg K.]

Benjamin, you should open a new bug about the remaining tab problems, and
restore this bug (summary, criticality, keywords, etc.) to be a record of the
crasher.

Comment 67

[Andrew Hagen]

Greg, I agree with you. Maybe this is wrong, but I thought that the stability
issue here weren't fully addressed yet. In comment 58, Benjamin says, "Moving
the other part of this bug out to 1.4a."

Comment 68

[Benjamin Smedberg]

OK, per suggestions, marking this bug FIXED and moving followup work to a new
bug 193011. Please don't comment on that bug unless you have to, I already know
the problem and have a solution forthcoming for 1.4a.

Comment 69

[Andrew Hagen]

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

Comment 70

[Olivier Cahagne]

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