Closed
Bug 355100
Opened 18 years ago
Closed 18 years ago
Remove XTF visuals
Categories
(Core Graveyard :: XTF, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: smaug, Assigned: smaug)
References
Details
Attachments
(2 files, 2 obsolete files)
(deleted),
patch
|
alex
:
review+
bryner
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
doronr
:
review+
|
Details | Diff | Splinter Review |
.
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•18 years ago
|
||
Alex, what do you think about this?
Attachment #240941 -
Flags: review?(alex)
Assignee | ||
Comment 2•18 years ago
|
||
This is needed for XForms.
Attachment #240942 -
Flags: review?(aaronr)
Assignee | ||
Comment 3•18 years ago
|
||
Comment on attachment 240941 [details] [diff] [review]
Remove XTF visuals, leaving only nsIXTFElement/nsIXTFElementWrapper
This patch doesn't include the to-be-removed-files in layout/xtf
Comment 4•18 years ago
|
||
There's more code in frame constructor that could go. For example, I think all the mInsertionContent/CreateInsertionPointChildren/PushAnonymousContentCreator thing is XTF-only, as well as some of the extra args to CreateAnonymousFrames.
Might be worth looking at the CVS log for frame constructor to find all the code that XTF has its tentacles in.
Assignee | ||
Comment 5•18 years ago
|
||
This backs out also Bug 269023 and Bug 270136.
(The patch doesn't contain layout/xtf)
Attachment #240941 -
Attachment is obsolete: true
Attachment #241043 -
Flags: review?(alex)
Attachment #240941 -
Flags: review?(alex)
Comment 6•18 years ago
|
||
Comment on attachment 241043 [details] [diff] [review]
Remove more XTF related code
Looks good to me.
Attachment #241043 -
Flags: review?(alex) → review+
Assignee | ||
Comment 7•18 years ago
|
||
Comment on attachment 241043 [details] [diff] [review]
Remove more XTF related code
Bryner, could you look at this too. Especially the layout part, since I'm not too familiar with that and basically I was just trying to back out your patches.
(And if things look ok, I'll ask sr?)
Attachment #241043 -
Flags: review?(bryner)
Updated•18 years ago
|
Attachment #241043 -
Flags: review?(bryner) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #241043 -
Flags: superreview?(bzbarsky)
Comment on attachment 240942 [details] [diff] [review]
For XForms
>Index: extensions/xforms/nsXFormsStubElement.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/extensions/xforms/nsXFormsStubElement.cpp,v
>retrieving revision 1.11
>diff -u -8 -p -r1.11 nsXFormsStubElement.cpp
>--- extensions/xforms/nsXFormsStubElement.cpp 24 May 2006 07:49:02 -0000 1.11
>+++ extensions/xforms/nsXFormsStubElement.cpp 2 Oct 2006 15:19:40 -0000
>
> NS_IMETHODIMP
> nsXFormsStubElement::GetScriptingInterfaces(PRUint32 *aCount, nsIID ***aArray)
> {
>- return nsXFormsUtils::CloneScriptingInterfaces(sScriptingIIDs,
>- NS_ARRAY_LENGTH(sScriptingIIDs),
>- aCount, aArray);
>+ *aCount = 0;
>+ *aArray = nsnull;
>+ return NS_OK;
> }
should probably test the pointers before doing this, right? Or is it safe to assume that they are good?
r=me
Attachment #240942 -
Flags: review?(aaronr) → review+
Olli, please check out http://www.mozilla.org/projects/xforms/samples/insurance_form/app_certificates.xhtml with these two patches built. We lose our nice table layout. I don't see anything in your xforms changes to explain that, so maybe is caused by the other stuff? I dunno.
Assignee | ||
Comment 10•18 years ago
|
||
I had removed aWrapper->SetClassAttributeName(nsXFormsAtoms::clazz)
Now the example should look ok.
Attachment #240942 -
Attachment is obsolete: true
Attachment #241314 -
Flags: review?(doronr)
Comment 11•18 years ago
|
||
(In reply to comment #10)
> Created an attachment (id=241314) [edit]
> For XForms, v2
>
> I had removed aWrapper->SetClassAttributeName(nsXFormsAtoms::clazz)
> Now the example should look ok.
>
form works for me now. Thanks.
Updated•18 years ago
|
Attachment #241314 -
Flags: review?(doronr) → review+
Comment 12•18 years ago
|
||
Comment on attachment 241043 [details] [diff] [review]
Remove more XTF related code
>Index: content/xtf/src/nsXTFElementWrapper.cpp
>+nsXTFElementWrapper::GetInterfaces(PRUint32* aCount, nsIID*** aArray)
What part of the old code is this replacing?
>+ if (!iids[i]) {
>+ for (PRUint32 j = 0; j < i; ++j) {
>+ nsMemory::Free(iids[j]);
>+ }
>+ nsMemory::Free(baseArray);
>+ nsMemory::Free(xtfArray);
>+ nsMemory::Free(iids);
But doesn't that leak the actual ids in xtfArray and baseArray? I'm not sure how those are supposed to be deallocated in general, but...
>+ if (!iids[i]) {
Similar here.
>+ nsMemory::Free(baseArray);
>+ nsMemory::Free(xtfArray);
And here.
sr=bzbarsky with that addressed.
Attachment #241043 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 13•18 years ago
|
||
(In reply to comment #12)
> (From update of attachment 241043 [details] [diff] [review] [edit])
> >Index: content/xtf/src/nsXTFElementWrapper.cpp
> >+nsXTFElementWrapper::GetInterfaces(PRUint32* aCount, nsIID*** aArray)
>
> What part of the old code is this replacing?
>
Not really replacing, but combining the functionality of XTFBindableElement and other XTFElements. So XTF elements can define which interfaces to expose (like currently in XTFElements), but the
default interfaces are there too (like in XTFBindableElement).
> But doesn't that leak the actual ids in xtfArray and baseArray? I'm not sure
> how those are supposed to be deallocated in general, but...
>
I'll use NS_FREE_XPCOM_ALLOCATED_POINTER_ARRAY.
(That is used also in nsDOMClassInfo)
nsDOMClassInfo
Assignee | ||
Comment 14•18 years ago
|
||
Checked in and removed the xtfvisual files from content/xtf and layout/xtf. code savings ~24000-28000.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•