All users were logged out of Bugzilla on October 13th, 2018

ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)'

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
10 years ago
5 years ago

People

(Reporter: ginnchen+exoracle, Unassigned)

Tracking

({assertion, testcase})

Trunk
assertion, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
This is a spin off bug for Bug 484932.

Steps to reproduce:
Download the testcase
https://bugzilla.mozilla.org/attachment.cgi?id=369466
Untar it.
Open test.html. Print it.

In terminal I got some assertions. It's reproducible on all platforms.

###!!! ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)', file ../../../layout/base/nsDocumentViewer.cpp, line 2083
nsBlockReflowContext: Frameset(frameset)(1)@0xd83198 metrics=38960,1073741824!
###!!! ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)', file ../../../layout/base/nsDocumentViewer.cpp, line 2083
###!!! ASSERTION: There must always be an XMost PO!: 'smallestPO', file ../../../layout/printing/nsPrintEngine.cpp, line 1659
###!!! ASSERTION: There must always be an XMost PO!: 'smallestPO', file ../../../layout/printing/nsPrintEngine.cpp, line 1704

Back out Bug 467881 doesn't resolve it.
Created attachment 370653 [details]
testcase

I'm seeing this assertion by print previewing a page with an iframe.

Comment 2

8 years ago
On Linux, with the testcase in comment 1, I get:

###!!! ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)', file layout/base/nsDocumentViewer.cpp, line 2134

###!!! ASSERTION: no page sequence frame: 'nsnull != pageSequence', file layout/printing/nsPrintEngine.cpp, line 2282
Keywords: assertion, testcase

Comment 3

8 years ago
Created attachment 488411 [details]
jesse's stacks
The reduced testcase on Bug 652929 -- attachment 531449 [details] -- hits 
this bug's "SameCOMIdentity" assertion failure.  However, it only hits it during a Print operation -- not during Print Preview.  (As noted on that bug, the original issue there was also specific to actual-printing as opposed to print preview.)  That testcase doesn't have any iframes -- just divs with the overflow, float, & clear properties set.

(In contrast, I double-checked that Jesse's testcase here reproduces the assertion under both Print Preview and Print -- it does.)

Comment 5

5 years ago
FWIW, Bug 468568 Part 0.8 removed the "Unexpected containers" assertion:
https://hg.mozilla.org/mozilla-central/rev/d7a64a002069
Cool. I get no assertions when printing the testcase mentioned in comment 4 now.

However -- I do still see these assertions (some of which were mentioned in comment 0), when printing/print-previewing "test.html" in Jesse's attached testcase:
{
###!!! ASSERTION: Shouldn't have unconstrained stuff here thanks to ComputeAutoSize: 'NS_INTRINSICSIZE != aReflowState.ComputedHeight()', file /mozilla-central/layout/generic/nsLeafFrame.cpp, line 78
nsBlockReflowContext: Frameset(frameset)(1)@0x7f7270897168 metrics=40320,1073741824!
###!!! ASSERTION: There must always be an XMost PO!: 'smallestPO', file /mozilla-central/layout/printing/nsPrintEngine.cpp, line 1704
###!!! ASSERTION: There must always be an XMost PO!: 'smallestPO', file /mozilla-central/layout/printing/nsPrintEngine.cpp, line 1724
}

It looks like the "Xmost" assertions are tracked in bug 410166, but there's no bug filed on the NS_INTRINSICSIZE assertion. Maybe we should morph this bug to cover that?  Alternately, we can spin off a new bug and resolve this one as WFM.

Comment 7

5 years ago
(In reply to Daniel Holbert [:dholbert] (vacation through 8/31) from comment #6)

> It looks like the "Xmost" assertions are tracked in bug 410166, but there's
> no bug filed on the NS_INTRINSICSIZE assertion. Maybe we should morph this
> bug to cover that?  Alternately, we can spin off a new bug and resolve this
> one as WFM.

It's tracked in bug 441680, isn't it?  Anyway, spinning off new bugs is better because my tools will know to stop ignoring this bug's assertion.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.