Closed Bug 303625 Opened 15 years ago Closed 15 years ago

nsXFormsSubmissionElement::LoadReplaceAll uses wrong document

Categories

(Core Graveyard :: XForms, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Biesinger, Assigned: allan)

References

()

Details

(Keywords: fixed1.8.0.5, fixed1.8.1)

Attachments

(1 file)

The code gets the ownerDocument and a container from that (in order to load a
new document there).

It seems to me like the code really wants to use the current document
(GetCurrentDoc()) of the node.
(In reply to comment #0)
> The code gets the ownerDocument and a container from that (in order to load a
> new document there).
> 
> It seems to me like the code really wants to use the current document
> (GetCurrentDoc()) of the node.

Nobody ever did anything about this. Why should we use GetCurrentDoc() instead? Mind you that it is an XTF element.
If the element comes from an XBL binding (could it?) then the owner doc and current doc would be different in XBL2 -- the owner doc would be the XBL binding document while the current doc would be the bound document.

More to the point, anything involving presentation (including containers) should be using the current document, since it's depending on messing with the "view" the element is in, not where the element hails from.
(In reply to comment #2)
> If the element comes from an XBL binding (could it?)

No.

> then the owner doc and current doc would be different in XBL2 -- the owner doc
> would be the XBL binding document while the current doc would be the bound 
> document.
> 
> More to the point, anything involving presentation (including containers)
> should be using the current document, since it's depending on messing with the
> "view" the element is in, not where the element hails from.

But the submission element has no visual representation.
> No.

So if XBL anonymous content includes a submission element nothing will happen?  What if XBL anonymous content includes a complete XForms form?

> But the submission element has no visual representation.

That's a matter of its CSS display type, no?
(In reply to comment #4)
> > No.
> 
> So if XBL anonymous content includes a submission element nothing will happen? 
> What if XBL anonymous content includes a complete XForms form?

Ah, sorry, understood that the wrong way around. submission's not going to be very happy unless it's a child of a model, but that said, you could stash it inside XBL anonymous content, yes.

> > But the submission element has no visual representation.
> 
> That's a matter of its CSS display type, no?

Hmmm, it inherits from nsIXTFGenericElement which iirc should have no visual representation.
> which iirc should have no visual representation.

It's just treated as "display: none !important" in the UA style sheet, basically.  Except hardcoded in C++ in a hacky way.

But back to the XBL anonymous content issue.  Would you be wanting to do the load in the XBL binding document, or the document the binding is attached to?  That's the line between GetOwnerDoc and GetCurrentDoc.

Assignee: aaronr → xforms
(In reply to comment #6)
> > which iirc should have no visual representation.
> 
> It's just treated as "display: none !important" in the UA style sheet,
> basically.  Except hardcoded in C++ in a hacky way.
> 
> But back to the XBL anonymous content issue.  Would you be wanting to do the
> load in the XBL binding document, or the document the binding is attached to? 
> That's the line between GetOwnerDoc and GetCurrentDoc.

(oops, this disappeared in my bugmail) We want to load in the document that the binding is attached to.
Then you want GetCurrentDoc() and this bug is valid.
Flags: blocking1.9a2?
Attached patch PatchSplinter Review
Assignee: xforms → allan
Status: NEW → ASSIGNED
Attachment #223753 - Flags: review?(bzbarsky)
Attachment #223753 - Flags: review?(bzbarsky) → review+
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: xf-to-branch
Keywords: fixed1.8.0.5
Keywords: fixed1.8.1
Whiteboard: xf-to-branch
Flags: blocking1.9a2?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.