Closed Bug 738759 Opened 13 years ago Closed 13 years ago

Add nsContentUtils::CheckSameOrigin overload taking two nsINodes

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla14

People

(Reporter: Ms2ger, Assigned: Ms2ger)

Details

Attachments

(1 file)

Attached patch Patch v1Splinter Review
Quite a few callers want an nsINode anyway.
Attachment #608828 - Flags: review?(jst)
Comment on attachment 608828 [details] [diff] [review] Patch v1 - case nsIDOMNode::ENTITY_NODE: - case nsIDOMNode::ENTITY_REFERENCE_NODE: - case nsIDOMNode::NOTATION_NODE: - { - return NS_ERROR_NOT_IMPLEMENTED; - } default: { NS_WARNING("Don't know how to clone this nodetype for importNode."); return NS_ERROR_DOM_NOT_SUPPORTED_ERR; } This is of course an observable change in behavior here. Correct as it is, we should keep an eye out for odd fallout from this. r=jst
Attachment #608828 - Flags: review?(jst) → review+
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #1) > Comment on attachment 608828 [details] [diff] [review] > Patch v1 > > - case nsIDOMNode::ENTITY_NODE: > - case nsIDOMNode::ENTITY_REFERENCE_NODE: > - case nsIDOMNode::NOTATION_NODE: > - { > - return NS_ERROR_NOT_IMPLEMENTED; > - } > default: > { > NS_WARNING("Don't know how to clone this nodetype for importNode."); > > return NS_ERROR_DOM_NOT_SUPPORTED_ERR; > } > > This is of course an observable change in behavior here. Correct as it is, > we should keep an eye out for odd fallout from this. How so? If it's an nsINode, it can't return any of these values through GetNodeType(). (At least, I sure hope so!) If it's not, we already threw from nsContentUtils::CheckSameOrigin(nsINode*, nsIDOMNode*).
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: