Closed
Bug 107534
Opened 23 years ago
Closed 23 years ago
assertions on test0.html
Categories
(Core :: CSS Parsing and Computation, defect, P1)
Tracking
()
VERIFIED
FIXED
People
(Reporter: rods, Assigned: dbaron)
References
()
Details
(Keywords: regression, smoketest)
Attachments
(2 files)
1.04 KB,
patch
|
Details | Diff | Splinter Review | |
10.83 KB,
patch
|
attinasi
:
review+
|
Details | Diff | Splinter Review |
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) {
Reporter | ||
Comment 1•23 years ago
|
||
This needs to be fixed before the tree opens.
Comment 2•23 years ago
|
||
(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.
Assignee | ||
Comment 3•23 years ago
|
||
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.)
Assignee | ||
Comment 4•23 years ago
|
||
Reporter | ||
Comment 5•23 years ago
|
||
Nope, I applied the patch to my current build and it didn't change anything.
Assignee | ||
Comment 6•23 years ago
|
||
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?
Assignee | ||
Comment 7•23 years ago
|
||
I think this a problem only with test0.html.
Summary: viewer asserts badly and is unusable → assertions on test0.html
Assignee | ||
Comment 8•23 years ago
|
||
Assignee | ||
Comment 9•23 years ago
|
||
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.
Assignee | ||
Comment 10•23 years ago
|
||
The patch where I missed the cases for :first-letter frames was for bug 56117.
Comment 11•23 years ago
|
||
sr=hyatt
Comment 12•23 years ago
|
||
r=waterson
Comment 13•23 years ago
|
||
Comment on attachment 55816 [details] [diff] [review] fix r=attinasi
Attachment #55816 -
Flags: review+
Assignee | ||
Comment 14•23 years ago
|
||
Fix checked in 2001-10-30 18:53 PDT.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•