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

[Gabriel Ivăncescu]

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? 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?

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). The exact COM 
interfaces exposed are not that important in comparison.