[PATCH 02/11] mshtml: Implement IHTMLElement::toString.

[Jacek Caban]

On 9/22/21 5:00 PM, Gabriel Ivăncescu wrote:
> On 22/09/2021 17:36, Jacek Caban wrote:
>> On 9/22/21 4:15 PM, Gabriel Ivăncescu wrote:
>>> On 22/09/2021 15:55, Jacek Caban wrote:
>>>> On 9/21/21 5:50 PM, Gabriel Ivăncescu wrote:
>>>>> On 21/09/2021 16:31, Jacek Caban wrote:
>>>>>> On 9/21/21 2:32 PM, Gabriel Ivăncescu wrote:
>>>>>>> But where would we even get the name from? In 
>>>>>>> HTMLElement_Create, get_tag_desc is used for specific tags, 
>>>>>>> which is similar, but the "fallback" goes to 
>>>>>>> HTMLGenericElement_Create, since not all tags are included there.
>>>>>>
>>>>>>
>>>>>> Sure, but I think that's what you need, see this test for an 
>>>>>> example:
>>>>>>
>>>>>> var s = document.createElement("winetest").toString();
>>>>>> ok(s === "[object HTMLUnknownElement]", "s = " + s);
>>>>>>
>>>>>>
>>>>>>> For example the "div" tag is not. 
>>>>>>
>>>>>>
>>>>>> It should probably be made a separated object.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jacek
>>>>>>
>>>>>
>>>>> Ok, I tested all the tags from:
>>>>>
>>>>>   https://www.w3schools.com/TAGS/default.ASP
>>>>>
>>>>> It looks like there's way too many tags to properly implement each 
>>>>> as separate object just for this.
>>>>
>>>>
>>>> It's not just for this, objects that return something different 
>>>> class names should eventually expose different sets of interfaces 
>>>> (like IHTMLDivElement in case of div element). It should be easy 
>>>> enough to distinguish between HTMLElement and HTMLUnknownElement 
>>>> using the existing logic. While div would also be nice to have, as 
>>>> long as the logic is right, it's not too bad to return slightly 
>>>> wrong strings objects that we don't support yet.
>>>>
>>>>
>>>> Jacek
>>>>
>>>
>>> Wait I'm confused a bit here. Isn't the patch I attached going in 
>>> the right direction? If not, why? It basically just adds a string 
>>> name for toString for each tag.
>>>
>>> Whether the tag itself is implemented as a separate object (like 
>>> IHTMLDivElement you mentioned) or not doesn't really matter here, 
>>> because even when it will be at some later point, it should still 
>>> obtain the name from this table, just like we do for the constructor.
>>>
>>> I guess I'm a bit confused as to what exactly you're referring I 
>>> should do now to fix this.
>>>
>>> Currently, all tags use the same toString implementation, even if 
>>> they are already separate objects, so this would implement it for 
>>> all of them in one spot without duplicating code, whether they have 
>>> a constructor or not.
>>
>>
>> I'm not suggesting separate implementations. In fact, I think we 
>> could share the implementation with more objects than just HTML 
>> elements. toString is supposed to use a type name and we have a 
>> mechanism to store type-specific things, why don't you want to use that?
>>
>>
>> Jacek
>>
>
> Do you mean store them in static dispex data?


Yes.


> But in that case, only separately implemented objects would receive 
> their proper names—so for example "div" which is not implemented would 
> receive something like HTMLElement. Is that what you meant?


Yes, it's nothing new that unsupported elements don't behave exactly right.


> I'm a bit worried, though, because this is accessible from javascript 
> code, so it might break something that depends on it (like Final 
> Fantasy XIV Online launcher, which I know calls toString, but I don't 
> know what it does with it or whether it uses it for identification).


Sure, that's why I suggested to support interesting cases. We already 
support most of them. Adding a new type is as simple as a constructor 
and new dispex description. I think we should at least distinguish 
between HTMLElement and HTMLUnknownElement, maybe also div.


> The exact COM interfaces exposed are not that important in comparison.


It's not COM interfaces that matter in this context, but the fact that 
they are supposed to be separated objects.


Jacek