191800 - Move FIXptr and XPointer into xmlextras

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

FIXptr (and XPointer when it lands) live in content/xml/document. However, they
are so rarely used that it would make sense to move their implementation to
xmlextras.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Filename change also needed, see 
http://bugzilla.mozilla.org/show_bug.cgi?id=182323#c30

Another issues that could be done here as well is to switch into string
iterators where appropriate, and lazily evaluate result from XPath.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: WIP - script access does not work

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Script to copy files

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

leaf: Could you copy 4 files on the CVS server for me, see the second  attachment

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Add this to nsXMLExtrasModule.cpp:

  rv = catman->AddCategoryEntry(JAVASCRIPT_DOM_CLASS,
                                "XPointerResult",
                                XMLEXTRAS_DOMCI_EXTENSION_CONTRACTID,
                                PR_TRUE, PR_TRUE, getter_Copies(previous));
  NS_ENSURE_SUCCESS(rv, rv);

and everything will work. There is one thing that I do not like, though. You can
now do this in JS: |new XPointerResult|. That should not work; the only way to
get XPointerResult object should be the return value from
document.evaluateXPointer(). How do I make that happen?

Comment 6

[Peter Van der Beken [:peterv]]

Hmm, you could try JAVASCRIPT_DOM_INTERFACE but I'm not sure it'll work since
your interface name is the same as your class name (XPointerResult).

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

jst thinks there is no way to do what I want currently, so we should file a bug
to dynamically add script accessible objects that cannot be created directly.

I will attach a cleaned up patch with this problem still present that can be
fixed later once the infrastructure is in place. There are other objects like
this besides XPointerResult: at least SOAPFault.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Fix

Proposed fix, minus changes in nsFIXptr.* and nsXPointer.* (I need leaf to copy
the files on the CVS server for that).

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

So there is a way to make it impossible to create objects with new, and that was
to pass null instead of CID as the last parameter to macro
NS_DOMCI_EXTENSION_ENTRY_END_NO_PRIMARY_IF(). Did that, and now |new
XPointerResult()| will throw exception "cannot create object in this context"
which is ok. 

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Proposed fix

leaf copied the files on the CVS server so this is now the final (?) complete
fix.

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 121330 [details] [diff] [review]
Proposed fix

sr=jst

Comment 12

[harishd]

Comment on attachment 121330 [details] [diff] [review]
Proposed fix

r=harishd

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 121330 [details] [diff] [review]
Proposed fix

harishd wiped this out - it was sr=jst earlier

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Checked in.