182460 - crash if XSLT-generated document contains <script> and XSLT-generated <iframe> [@ nsBoxFrame::CreateViewForFrame]

Status: RESOLVED WORKSFORME

(Core :: XSLT, defect, P1)

Description

[Manko]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

If XSLT-generated page contains both <script> and XSLT-generated <iframe>á
Mozilla crashes

Reproducible: Always

Steps to Reproduce:
1. Go to URL http://bugzilla.nm.ru/xslt/table.xml.
2. If crash doesn't appear, click reload button a few times.

Comment 1

[Manko]

If I load these files from local disk, crash comes instantly. If you try to open
URL, click reload some times quickly.

Comment 2

[Olivier Cahagne]

can you post Talkback ID for this crash "mozilla/bin/components/talkback.exe" ?

Comment 3

[Manko]

Attachment: Details from Talkback agent

Details form Talkback agent report. Privacy-sensitive data were removed.

BTW, the same crash appears on fresh installation at another computer.

Comment 4

[Peter Van der Beken [:peterv]]

That's rather useless, we need the TalkBack Incident ID

Comment 5

[Andrew Schultz]

Attachment: stacktrace

crash occurs with linux trunk build 20021127

###!!! ASSERTION: GetParentWithView failed: 'parent', file nsBoxFrame.cpp, line
2573

Comment 6

[Andrew Schultz]

marking NEW

Comment 7

[Andrew Schultz]

regression between linux trunk builds 2002102004 and 2002102204

Comment 8

[Ronald Tilby]

Instantly crashed for me using 2002111408 nightly on Windows 98.
Talkback ID: TB14492553M

Comment 9

[Peter Van der Beken [:peterv]]

Reassigning to Sicking for now. Probably fall-out from the branch landing
(http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&date=explicit&mindate=10%2F21%2F2002+00%3A00%3A00&maxdate=10%2F21%2F2002+23%3A59%3A59&cvsroot=%2Fcvsroot).
Sicking: do you think you can look at this anytime soon?

Comment 10

[Dawn Endico]

talkback stack for Talkback ID: TB14492553M




Stack Signature  nsBoxFrame::CreateViewForFrame 209e541c
Email Address [e-mail]
Product ID MozillaTrunk
Build ID 2002111408
Trigger Time 2002-11-28 10:02:03
Platform Win32
Operating System Windows 98 4.10 build 67766222
Module GKLAYOUT.DLL
URL visited http://bugzilla.nm.ru/xslt/table.xml
User Comments Mozilla bug 182460 Page never displayed.
Trigger Reason Access violation
Source File Name c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp
Trigger Line No. 2580
Stack Trace
nsBoxFrame::CreateViewForFrame
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 2580]
nsScrollbarFrame::Init
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsScrollbarFrame.cpp, line 90]
nsCSSFrameConstructor::InitAndRestoreFrame
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 6806]
nsCSSFrameConstructor::ConstructXULFrame
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 5850]
nsCSSFrameConstructor::ConstructFrameInternal
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 7432]
nsCSSFrameConstructor::ConstructFrame
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 7307]
nsCSSFrameConstructor::CreateAnonymousFrames
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 5290]
nsCSSFrameConstructor::BuildGfxScrollFrame
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 6230]
nsCSSFrameConstructor::BeginBuildingScrollFrame
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 6004]
nsCSSFrameConstructor::ConstructRootFrame
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 3876]
StyleSetImpl::ConstructRootFrame
[c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp, line 1507]
PresShell::InitialReflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 2790]
nsXMLContentSink::StartLayout
[c:/builds/seamonkey/mozilla/content/xml/document/src/nsXMLContentSink.cpp, line
1299]
nsXMLContentSink::OnTransformDone
[c:/builds/seamonkey/mozilla/content/xml/document/src/nsXMLContentSink.cpp, line
523]
txMozillaXMLOutput::SignalTransformEnd
[c:/builds/seamonkey/mozilla/extensions/transformiix/source/xslt/txMozillaXMLOutput.cpp,
line 762]
txMozillaXMLOutput::endDocument
[c:/builds/seamonkey/mozilla/extensions/transformiix/source/xslt/txMozillaXMLOutput.cpp,
line 205]
txXSLTProcessor::transform
[c:/builds/seamonkey/mozilla/extensions/transformiix/source/xslt/XSLTProcessor.cpp,
line 1656]
txMozillaXSLTProcessor::TransformDocument
[c:/builds/seamonkey/mozilla/extensions/transformiix/source/xslt/txMozillaXSLTProcessor.cpp,
line 385]
nsTransformMediator::TryToTransform
[c:/builds/seamonkey/mozilla/content/xsl/document/src/nsTransformMediator.cpp,
line 109]
nsTransformMediator::SetStyleSheetContentModel
[c:/builds/seamonkey/mozilla/content/xsl/document/src/nsTransformMediator.cpp,
line 144]
nsXSLContentSink::DidBuildModel
[c:/builds/seamonkey/mozilla/content/xsl/document/src/nsXSLContentSink.cpp, line
134]
nsExpatDriver::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsExpatDriver.cpp, line 973]
nsParser::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 1265]
nsParser::ResumeParse [c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp,
line 1811]
nsParser::OnStopRequest
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 2440]
nsStreamListenerTee::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamListenerTee.cpp, line 66]
nsHttpChannel::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 3008]
nsOnStopRequestEvent::HandleEvent
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp, line 213]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 645]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 578]
_md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line
1336]
KERNEL32.DLL + 0x242e7 (0xbff942e7)
0x00648b62 

Comment 11

[Peter Van der Beken [:peterv]]

No patch yet, not sure we know the exact problem either, so don't nominate this
please.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

sending this over to layout since that is where this crashes. It might be that
transformiix needs to do some extra work that the contentsink usually does, but
i have no idea what that would be.

Comment 13

[Manko]

Jonas, this bug didn't persist in 1.1, 1.2b. Probably it becomes after fixing
bug 158457.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

No, this was most likly caused by the landing of bug 155578, which made us
produce a HTML rather then an XML document.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

manko: the testcase is gone, Could you please attach it to this bug so that we
could try to fix this?

Comment 16

[Manko]

Attachment: Zipped testcase

OK, there is a zipped testcase here.

Unzip file then open table.xml in Mozilla.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: iframe xsl

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: iframe xml

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: top xhtml. BE AWARE! CRASHES!

this is a smaller testcase properly linked to bugzilla urls. Just click and go,
but be aware, it crashes!

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: iframe xml

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: top xhtml. BE AWARE! CRASHES!

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: top xhtml. BE AWARE! CRASHES!

ok. *this* one should really work!

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: zip of minimal testcase

since this seems hard to reproduce on the bugzilla-server i've put the exact
same testcase in this .zip

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

cc-ing dbaron and bz. This is a 100% reproducable crasher

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looks like you managed to create an nsViewportFrame without a view.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, I'm guessing you're somehow going through neither
DocumentViewerImpl::MakeWindow nor DocumentViewerImpl::Show.  Does this need to
be fixed in DocumentViewerImpl::SetDOMDocument?

Comment 27

[Ronald Tilby]

I cannot get the testcases to crash using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030430

Comment 28

[Andrew Schultz]

loading the original testcase locally still crashes with linux trunk 20030430

Comment 29

[Boris Zbarsky [:bzbarsky]]

OK, I'm seeing the bug on the "Zipped testcase" (the first testcase in this
bug).  Modulo asserts from bug 204319 the problem is that we have a viewmanager
with no root view:

(gdb) frame 9
#9  0x40f9adf0 in nsCSSFrameConstructor::ConstructRootFrame (this=0x87a3210, 
    aPresShell=0x87a32c0, aPresContext=0x87a73d8, aDocElement=0x87a4920, 
    aNewFrame=@0xbfffe7f8)
    at
/home/bzbarsky/mozilla/profile/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:3875

gdb) p rootView
$10 = (nsIView *) 0x0
(gdb) p (nsViewManager)*viewManager.mRawPtr     
$11 = {<nsIViewManager> = {<nsISupports> = {
      _vptr. = 0x417b0f20 <nsViewManager virtual table>}, <No data fields>},
mRefCnt = {
    mValue = 2}, _mOwningThread = {mThread = 0x80a1800}, 
  static gLastUserEventTime = 70607832, mContext = 0x863e488, 
  mTwipsToPixels = 0.0666666701, mPixelsToTwips = 15, mObserver = 0x87a32c4, 
  mRootWindow = 0x0, mTransCnt = -1, mRefreshEnabled = 0, mPainting = 0, 
  mRecursiveRefreshPending = 0, mMouseGrabber = 0x0, mKeyGrabber = 0x0,
mUpdateCnt = 10, 
  mUpdateBatchCnt = 0, mDisplayListCount = 12, mDisplayList = {<nsVoidArray> = {
      mImpl = 0x87bca60, _vptr. = 0x40694d94}, 
    mAutoBuf =
"\b\0\0\0\b\0\0\0\030Ê{\bàZ{\b\230Z{\bPZ{\bðY{\bxY{\b\030Y{\b¸X{\b"}, 
  mTranslucentViewCount = 0, mTranslucentArea = {x = 0, y = 0, width = 0, height
= 0}, 
  mRootScrollable = 0x0, mCachingWidgetChanges = 0, 
  mDefaultBackgroundColor = 4294967295, mMapPlaceholderViewToZTreeNode = {mLock
= 0x0, 
    mHashtable = {ops = 0x40694340, data = 0x0, hashShift = 28, maxAlphaFrac =
192 'À', 
      minAlphaFrac = 64 '@', entrySize = 12, entryCount = 0, removedCount = 0, 
      generation = 0, entryStore = 0x87a2ea0 ""}, mEnumerating = 0, 
    _vptr. = 0x40694308}, static mVMCount = 5, static gCleanupContext = 0x83517b8, 
  static gViewManagers = 0x8318990, mBlender = {mRawPtr = 0x0}, 
  mCompositeListeners = 0x87b5670, mRegionFactory = {mRawPtr = 0x815f6d8}, 
  mRootView = 0x0, mX = 0, mY = 0, mAllowDoubleBuffering = 1, 
  mHasPendingInvalidates = 1, mEventQueueService = {mRawPtr = 0x81002e0}, 
  mInvalidateEventQueue = {mRawPtr = 0x0}}

Over to roc, who may have some idea of what's up here....

Comment 30

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

David is right on the money in comment 26 here. I'm just not sure which calls to
add in DocumentViewerImpl::SetDOMDocument. Should it call into
DocumentViewerImpl::Show, or should it call something else directly?

Comment 31

[Manko]

Still persists in 1.5 and 1.4.1

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Changing component to XSLT (since IIRC DocumentViewerImpl::SetDOMDocument is a
hack designed for the XSLT code), and I think the problem is there.  (I don't
know the answer to sicking's question in comment 30 offhand, although I could
look into it.)

Comment 33

[Asa Dotzler [:asa]]

not going to block 1.6a or 1.4.2 releases for this.

Comment 34

[Neil Paris]

Crash still (very-first testcase) with 1.7 Beta:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316

Talkback ID is TB10340Y
Captured at 04/02/04 at 12:35 AM

Comment 35

[fianna]

came across this problem this week, mozilla also crashes when xslt-generated
pages contain document.write(" ") in a <script> tag, not just <iframe>.

Comment 36

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

problems with document.write is a different bug then this one.

Comment 37

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So what seems to be happening here is that when we start layout for the outer
document it will end up calling ::Show on the iframes documentviewer which will
perform the initial reflow including hooking up views and everything. Then the
xslt transform finishes and we tear all that down but doesn't set it up properly
again.

So either we should just call Show or something similar in SetDOMDocument, or we
should stop the source document from being shown in the first place. Seems like
the latter is the better solution since we're not interested in showing the
source document just to have it replaced.

Comment 38

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Come to think of it. I wonder if we could hold off creating the documentviewer
entierly until the transform is done. That could be the answer for bug 281022

Comment 39

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Continued from discussion started in bug 312858 comment 15:

I'd rather find some other way of blocking initial reflow on xslt documents
rather then not putting content into the document. First of all we'd need to
keep a list of all root contents (comments, PIs, docElement). Second, i'm
worried about what happens once the content is put into the tree, whatever got
blocked by keeping the content out of the tree musn't trigger at that point.

We also must not create any layout objects that could be specific to the
document object since the document node too is replaced after the transformation.


Could we block the creation of the presshell and prescontext? That should block
any intial reflows right?

Comment 40

[Boris Zbarsky [:bzbarsky]]

I suppose we could always add an nsIDocument api to get/set a boolean and the
content viewer could check that before creating a presentation...  Not sure what
the now-showing iframe would end up painting in that case... ;)

Comment 41

[Radoslaw Zielinski]

None of the attachments seem to be able to crash my session, but this URL always does it: http://timesofindia.indiatimes.com/cms.dll/xml/uncomp/articleshow?msid=167551


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080422

Comment 42

[Jesse Ruderman]

WFM on Mac.  I'll take the zipped testcase and make it into a crashtest.

Comment 43

[Jesse Ruderman]

Crashtest: http://hg.mozilla.org/mozilla-central/rev/4da43cad0331