107534 - assertions on test0.html

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[rods (gone)]

Viewer is still used for a ot of testing and last night's checkins have made it 
unusable.

I am currently getting a lot of asserts in nsStyleSet.cpp line 865, it is the 
thrid assert below. Mozilla starts and runs fine.

nsIStyleContext* StyleSetImpl::ResolveStyleFor(nsIPresContext* aPresContext,
                                               nsIContent* aContent,
                                               nsIStyleContext* aParentContext,
                                               PRBool aForceUnique)
{
  MOZ_TIMER_DEBUGLOG(("Start: StyleSetImpl::ResolveStyleFor(), this=%p\n", 
this));
  STYLESET_START_TIMER(NS_TIMER_STYLE_RESOLUTION);

  nsIStyleContext*  result = nsnull;

  NS_ASSERTION(aContent, "must have content");
  NS_ASSERTION(aPresContext, "must have pres context");
  NS_ASSERTION(aContent->IsContentOfType(nsIContent::eELEMENT),
               "content must be element");

  if (aContent && aPresContext) {

Comment 1

[rods (gone)]

This needs to be fixed before the tree opens.

Comment 2

[Chris Waterson]

(I'm not seeing this, but maybe I'm not going to the right pages.)

If it's holding you up, put an #ifdef DEBUG_dbaron around it and check it in. I
doubt we need to respin the verification builds (and hold the tree closed until
4pm this afternoon) for a debug-only problem in viewer.

Comment 3

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

I have what should be a fix, but my tree isn't in a state where I can build
right now.  I have no idea why we go through different frame construction code
in viewer vs. Mozilla.  (It sometimes seems like we go through different frame
construction code each time I run the browser.)

Comment 4

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

Attachment: proposed patch

Comment 5

[rods (gone)]

Nope, I applied the patch to my current build and it didn't change anything.

Comment 6

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

Well, that would fix the assertion that I saw, and I'll need to wait for my
build to finish to see what other assertions there were.

Any ideas why that code isn't executed in Mozilla?  And any ideas why frame
construction seems to go through different codepaths each time?

Comment 7

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

I think this a problem only with test0.html.

Comment 8

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

Attachment: fix

Comment 9

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

I missed some cases for :first-letter frames in my patch.  This fixes that --
letter frames always contain text nodes, so that should use the |NonElement|
versions.  I also removed two useless pseudo-elements -- a :-moz-letter-frame,
which styled everything after the first letter (when we have a :first-letter
style, we create a second letter frame for holding all the other children), and
a :-moz-placeholder-frame pseudo, that styled placeholder frames.  The former
was never used in our CSS, the latter was in html.css but only with default
values for non-inherited properties.

Comment 10

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

The patch where I missed the cases for :first-letter frames was for bug 56117.

Comment 11

[David Hyatt]

sr=hyatt

Comment 12

[Chris Waterson]

r=waterson

Comment 13

[Marc Attinasi]

Comment on attachment 55816 [details] [diff] [review]
fix

r=attinasi

Comment 14

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

Fix checked in 2001-10-30 18:53 PDT.

Comment 15

[Madhur Bhatia]

verified as per comments