[FIX]implement a better storage/retrieval method for nsSubDocumentFrames content parent

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
15 years ago
Last year

People

(Reporter: bernd_mozilla, Assigned: bzbarsky)

Tracking

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

this is a followup from bug 240129
>+ the nsSubDocumentFrame needs to know about its content parent during ::Init.
>+      // there is no reasonable way to get the value there.
>+      // so we store it as a frame property.
Can you file a bug on this?  cc me and roc.  I think this should be easy to
fix.

(done)
Hmm... so I actually read the comment in nsSubDocumentFrame::Init this time.  I
thought we could just force the view in CreateViewForFrame, but we're actually
needing the view before CreateViewForFrame has been called....  We also can't
create the view till after the superclass Init() has been called.  So perhaps
what we have now is the simplest way to do it after all.  :(
The good news is that we don't need this anymore.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Summary: implement a better storage/retrieval method for nsSubDocumentFrames content parent → [FIX]implement a better storage/retrieval method for nsSubDocumentFrames content parent
Attachment #355635 - Flags: superreview?(roc)
Attachment #355635 - Flags: superreview+
Attachment #355635 - Flags: review?(roc)
Attachment #355635 - Flags: review+
Pushed http://hg.mozilla.org/mozilla-central/rev/a67b8808aadd
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 476295
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.