278369 - nsIXFormsControl should use COMArray

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Allan Beaufour]

Quoting bryner, on bug 265467:
>--- xforms.newbranch/nsIXFormsControl.idl	2004-11-04 22:12:22.000000000
>+0100
>+++ xforms.mdg-branch/nsIXFormsControl.idl	2005-01-10 16:56:24.000000000
>+0100
>@@ -33,20 +33,49 @@
>...
>+  /**
>+   * The instance nodes that the control depend on. These MUST be sorted,
>+   * pointer-order, ascending.
>+   */
>+  readonly attribute nsIArray dependencies;

>Would be nice if this could be a nsCOMArray since this method doesn't need to
>be scriptable.	It should be possible to declare it as such in IDL using
>[native, ref] or something like that... there should be some examples in the
>tree.

Comment 1

[Allan Beaufour]

Attachment: Patch v1

* Uses COMArray as bryner suggested
* Kills nsXFormsMDGSet entirely, and uses nsCOMArray<nsIDOMNode> everywhere.

I'm not too sure about the IDL-business. It compiles and "works for me", but is
it the correct way to do it?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 175109 [details] [diff] [review]
Patch v1

This breaks http://www.mozilla.org/projects/xforms/sample1.xhtml


I see the following assertions (in an endless oop?):
###!!! ASSERTION: index out of range: '0 <= aIndex && aIndex < Count()', file
nsVoidArray.h, line 71
Break: at file nsVoidArray.h, line 71

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

loop

Comment 4

[Allan Beaufour]

(In reply to comment #3)
> loop

If you hadn't written that, I would never have understood your comment. Never. I
mean it! Never! :)

Comment 5

[Allan Beaufour]

(In reply to comment #2)
> (From update of attachment 175109 [details] [diff] [review] [edit])
> This breaks http://www.mozilla.org/projects/xforms/sample1.xhtml
> 
> I see the following assertions (in an endless oop?):
> ###!!! ASSERTION: index out of range: '0 <= aIndex && aIndex < Count()', file
> nsVoidArray.h, line 71
> Break: at file nsVoidArray.h, line 71

Argh. I remember looking through the patch before uploading it, and thinking
something in the lines of "Hey stupid, that loop can be made more optimal", and
then "optimizing" it. *doh*

Comment 6

[Allan Beaufour]

Attachment: Patch v2

*ahem*. Let's try again.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 175275 [details] [diff] [review]
Patch v2

Now this looks ok to me, and it even seems to work ;)

Comment 8

[Allan Beaufour]

Doron, will you do the 2nd review?

Comment 9

[Doron Rosenberg (IBM)]

r=me

Comment 10

[Allan Beaufour]

Checked in.