236894 - [ActiveX] IHtmlElementCollection methods tags() & item(), when more than one element is found, are not implemented

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: ActiveX Wrapper, enhancement)

Description

[Alexandre Trémon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7b) Gecko/20040303
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7b) Gecko/20040303

The IHtmlElementCollection methods tags() and item(), when more than one element
is found, are not implmented.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Alexandre Trémon]

Attachment: implementation of tags and item methods

The item() method returns an IHtmlElementCollection when more than one element
is found when a string is passed as search criteria.

Comment 2

[Alexandre Trémon]

Attachment: Changed de get_NewEnum method

If you want to write in VB something like:

dim el as IHTMLElement
for each el in MozillaBrowser1.document.all 'or
MozillaBrowser1.document.body.children
    ' do something
next

then get_NewEnum should return an array of IDispatch variant, not IUnknown.

Comment 3

[Alexandre Trémon]

Comment on attachment 145172 [details] [diff] [review]
Changed de get_NewEnum method

Hi Adam,

Could you review this?

Comment 4

[Alexandre Trémon]

Attachment: Move SetParent from FindOrCreateIEElement to PopulateFromDOMHTMLCollection

See bug http://bugzilla.mozilla.org/show_bug.cgi?id=236812

Comment 5

[Adam Lock]

Comment on attachment 145732 [details] [diff] [review]
Move SetParent from FindOrCreateIEElement to PopulateFromDOMHTMLCollection

r=adamlock

Minor nits use OLE2CW instead of OLE2W. I am also concerned about the
ATLASSERT(). Perhaps we shouldn't use a smart pointer if we have to hack it to
make it work properly. There could be reference counting implications.

Comment 6

[Alexandre Trémon]

ATLASSERT(NULL == (pHtmlElement.p = NULL)) is to avoid assertion, in debug
builds, in AtlBase.h, because pHtmlElement.p is not equal to NULL.
So I force pHtmlElement.p to NULL only in debug builds, and in release builds,
the line won't be compiled.

As for smart pointers, it's just to avoid QIing and Releasing too much. I
checked for these objects refcount, and everything is OK. They die at the right
moment. But I'll attach a patch with no smart pointers anyway.

Comment 7

[Alexandre Trémon]

Attachment: OLE2CW replaces OLE2W, no more smart pointer in item() method (l.623)

Comment 8

[Alexandre Trémon]

Attachment: OLE2CW replaces OLE2W, no more smart pointer in item() method (l.623)

Comment 9

[Adam Lock]

Comment on attachment 146018 [details] [diff] [review]
OLE2CW replaces OLE2W, no more smart pointer in item() method (l.623)

r=adamlock

Comment 10

[Johnny Stenback (:jst)]

Comment on attachment 146018 [details] [diff] [review]
OLE2CW replaces OLE2W, no more smart pointer in item() method (l.623)

sr=jst

Comment 11

[Adam Lock]

Fix checked in