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

RESOLVED FIXED

Status

()

Core
Layout: Misc Code
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: Bernd, Assigned: bz)

Tracking

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

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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
Created attachment 355635 [details] [diff] [review]
Remove some unused args and the code needed to support them
Attachment #355635 - Flags: superreview?(roc)
Attachment #355635 - Flags: review?(roc)
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
Last Resolved: 9 years ago
Resolution: --- → FIXED
Depends on: 476295
You need to log in before you can comment on or make changes to this bug.