107021 - followup work on nsIFrame clean up

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Cathleen]

we're taking the performance boosts from bug 104336

quote from dbaron's comment in bug 104336

>
> Further cleanup that should happen after this lands:
>
>   Make nsIFrame not inherit from nsISupports (but still have QI).
>
>   Make nsRuleNode::Transition return its result.
>   Make nsIStyleContext::GetRuleNode return its result. (?)
>
>   Make nsIFrame::SetParent take an |nsIFrame*| (look ma, no const!).
>
>   Removing many of the |nsresult| return types.
>

Comment 1

[Christopher Hoess (gone)]

->Misc Code

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

dbaron, do you want to do an nsISupports superclass with QI only that we can use
in nsIFrame and elsewhere? It doesn't sound hard. I could do it instead if you
prefer.

Comment 3

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

I think it would be nice, although the XPCOM folks probably wouldn't want it to
be a superclass of nsISupports itself.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not sure if we can use it for nsIFrame and nsIView unless it's a superclass
of nsISupports. For nsIView at least, we need to make it the type of private
data for nsIWidget, which is sometimes an nsISupports thing and sometimes a
view. For nsIFrame, some places use XPCOM iterators on nsIFrames.

Comment 5

[Vedran Miletic]

retargeting

Comment 6

[Mats Palmgren (inactive)]

The things listed in comment 0 have been fixed in other bugs.