The default bug view has changed. See this FAQ.

Add a method to specify the style context of a frame to nsIAnonymousContentCreator so we don't have to use CreateFrameFor

RESOLVED FIXED in mozilla6

Status

()

Core
Layout
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: mounir, Assigned: bz)

Tracking

Trunk
mozilla6
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
See bug 633209 comment 13.
(Reporter)

Updated

6 years ago
Blocks: 654990
Created attachment 530407 [details] [diff] [review]
part 1.  Allow handing out both an nsIContent and an nsStyleContext from CreateAnonymousContent.
Attachment #530407 - Flags: review?(roc)
Created attachment 530409 [details] [diff] [review]
part 2.  Use the nsStyleContext handed back from CreateAnonymousContent.   asserts the parts of AddFrameConstructionItems that should never matter for anonymous content and then just copies the one-line style context get if it's needed.
Attachment #530409 - Flags: review?(roc)
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Priority: -- → P1
Comment on attachment 530407 [details] [diff] [review]
part 1.  Allow handing out both an nsIContent and an nsStyleContext from CreateAnonymousContent.

Review of attachment 530407 [details] [diff] [review]:

r+ with that.

::: layout/generic/nsIAnonymousContentCreator.h
@@ +102,5 @@
    */
   virtual nsIFrame* CreateFrameFor(nsIContent* aContent) { return nsnull; }
 };
 
+typedef nsTArray<nsIAnonymousContentCreator::ContentInfo> nsAnonymousContentArray;

Personally I wouldn't bother with this typedef, I think it just obscures things. Instead I would have "typedef nsIAnonymousContentCreator::ContentInfo ContentInfo;" so that you can write nsTArray<ContentInfo> everywhere you currently have nsAnonymousContentArray (which is actually longer!).
Attachment #530407 - Flags: review?(roc) → review+
Comment on attachment 530409 [details] [diff] [review]
part 2.  Use the nsStyleContext handed back from CreateAnonymousContent.   asserts the parts of AddFrameConstructionItems that should never matter for anonymous content and then just copies the one-line style context get if it's needed.

Review of attachment 530409 [details] [diff] [review]:

::: layout/base/nsCSSFrameConstructor.cpp
@@ +9548,5 @@
 #endif
+    // Assert some things about this content
+    NS_ABORT_IF_FALSE(!(content->GetFlags() &
+                        (NODE_DESCENDANTS_NEED_FRAMES | NODE_NEEDS_FRAME)),
+                      "Should not be marked as needing frames");

This is not likely to cause instability so should just be an NS_ASSERTION IMHO.

@@ +9551,5 @@
+                        (NODE_DESCENDANTS_NEED_FRAMES | NODE_NEEDS_FRAME)),
+                      "Should not be marked as needing frames");
+    NS_ABORT_IF_FALSE(!content->IsElement() ||
+                      !(content->GetFlags() & ELEMENT_ALL_RESTYLE_FLAGS),
+                      "Should have no pending restyle flags");

Ditto.

@@ +9553,5 @@
+    NS_ABORT_IF_FALSE(!content->IsElement() ||
+                      !(content->GetFlags() & ELEMENT_ALL_RESTYLE_FLAGS),
+                      "Should have no pending restyle flags");
+    NS_ABORT_IF_FALSE(!content->GetPrimaryFrame(),
+                      "Should have no existing frame");

This could cause strange crashes so should stay an NS_ABORT_IF_FALSE.

@@ +9556,5 @@
+    NS_ABORT_IF_FALSE(!content->GetPrimaryFrame(),
+                      "Should have no existing frame");
+    NS_ABORT_IF_FALSE(!content->IsNodeOfType(nsINode::eCOMMENT) &&
+                      !content->IsNodeOfType(nsINode::ePROCESSING_INSTRUCTION),
+                      "Why is someone creating garbage anonymous content");

I think AddFrameConstructionItemsInternal will just not create frames for these without breaking stuff, so again this can just be an NS_ASSERTION.

@@ +9560,5 @@
+                      "Why is someone creating garbage anonymous content");
+
+    nsRefPtr<nsStyleContext> styleContext;
+    if (anonymousItems[i].mStyleContext) {
+      anonymousItems[i].mStyleContext.swap(styleContext);

Clearer to write
  styleContext = anonymousItems[i].mStyleContext.forget();
Attachment #530409 - Flags: review?(roc) → review+
> Instead I would have "typedef nsIAnonymousContentCreator::ContentInfo
> ContentInfo;

Should I just move ContentInfo outside nsIAnonymousContentCreator?
> This is not likely to cause instability 

It is, actually; if those flags are set and don't get unset then we'll end up trying to double-construct frames, no?  I guess if we go through AddFrameConstructionItems for that we'll just NS_ERROR and bail out... but that's a thin thread to hang on.

> I think AddFrameConstructionItemsInternal will just not create frames for
> these without breaking stuff

It'll create nsTextFrames for them.  Not sure what you mean by "Breaking stuff", but that doesn't sound like a happy situation.

> styleContext = anonymousItems[i].mStyleContext.forget();

Will do.
(In reply to comment #6)
> > This is not likely to cause instability 
> 
> It is, actually; if those flags are set and don't get unset then we'll end up
> trying to double-construct frames, no?  I guess if we go through
> AddFrameConstructionItems for that we'll just NS_ERROR and bail out... but
> that's a thin thread to hang on.
> 
> > I think AddFrameConstructionItemsInternal will just not create frames for
> > these without breaking stuff
> 
> It'll create nsTextFrames for them.  Not sure what you mean by "Breaking
> stuff", but that doesn't sound like a happy situation.

OK, never mind!
(In reply to comment #5)
> > Instead I would have "typedef nsIAnonymousContentCreator::ContentInfo
> > ContentInfo;
> 
> Should I just move ContentInfo outside nsIAnonymousContentCreator?

Actually, just remove this typedef. It looks like most places that use it inherit from nsIAnonymousContentCreator anyway.
Indeed.  OK, will do.
Whiteboard: [need review] → [need landing]
Pushed:
  http://hg.mozilla.org/projects/cedar/rev/c13b634ef7aa
  http://hg.mozilla.org/projects/cedar/rev/fde4fa1ec726
Flags: in-testsuite-
Whiteboard: [need landing] → [fixed-in-cedar]
Target Milestone: --- → mozilla6
Fixed:
  http://hg.mozilla.org/mozilla-central/rev/c13b634ef7aa
  http://hg.mozilla.org/mozilla-central/rev/fde4fa1ec726
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
You need to log in before you can comment on or make changes to this bug.