November 2024 - wine-gitlab

[PATCH 0/1] MR6880: gitlab: Wait for the fvwm process to start.
by Rémi Bernon (＠rbernon) 22 Nov '24

22 Nov '24

I've seen some cases where the X server is a bit slow to start, and I suspect it could be a reason for some rare spurious test failures. Not 100% sure but at least this should be harmless and better than leaving it to chance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6880

3 3

[PATCH 0/1] MR6884: Draft: Iphlpapi.dll: Included SendARP
by Thi Garlet (＠garlett) 22 Nov '24

22 Nov '24

Returns MAC address by: - search local interfaces, or - send UDP packed that does not need linux privilege, then search local cache solve https://bugs.winehq.org/show_bug.cgi?id=9418 files updated - /dlls/iphlpapi/iphlpapi_main.c - /dlls/iphlpapi/tests/iphlpapi.c -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6884

4 8

[PATCH v2 0/1] MR6883: msxml3: Add indentation test.
by Orin Varley (＠ovarley1) 22 Nov '24

22 Nov '24

Adding a test to make sure the indentation of xml elements is a tab even after moving to another thread. To prevent regressions like the bug bellow. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57325 -- v2: msxml3: Add indentation test. https://gitlab.winehq.org/wine/wine/-/merge_requests/6883

2 1

[PATCH v18 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v18: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 4

[PATCH v17 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 22 Nov '24

22 Nov '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options -- v17: timeout: add minimal test suite https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

4 4

[PATCH 0/3] MR6855: server: Fix renaming file to a hardlink of itself.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6855

3 13

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

Oh yeah I forgot about that. Quick test shows it doesn't. I guess I'll go with custom interface then and just forward. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88537

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Jacek Caban (＠jacek) 22 Nov '24

22 Nov '24

On Fri Nov 22 16:13:26 2024 +0000, Gabriel Ivăncescu wrote: > What about just using `IHTMLCommentElement2` for CharacterData's > interface, since it exposes the exact same props that it has? I mean > instead of the custom interface. Sounds better but should `QI(IHTMLCommentElement2)` succeeded on text nodes? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88536

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Gabriel Ivăncescu (＠insn) 22 Nov '24

22 Nov '24

On Fri Nov 22 16:09:59 2024 +0000, Jacek Caban wrote: > The ugly part of forwarding to `IHTMLDOMTextNode2` is that you need to > implement `IHTMLDOMTextNode2` in an object that's not a text node > (comment node). > With a private interface, we could give it a proper set of properties, > so no hooks would be needed, and just forward to it from both > `IHTMLDOMTextNode*` and `IHTMLCommentElement*` interfaces. We could even > share its entire implementation with something like: > ``` > struct HTMLCharacterData { > IHTMLCharacterData IHTMLCharacterData_iface; > DispatchEx *dispex; // used to forward IDispatch to comment's or > text node's dispex > nsIDOMCharacterData *character_data; // used for the actual implementation > }; > ``` > You could then embed it both in both comment and text node structs and > just use the single `IHTMLCharacterData` implementation. What about just using `IHTMLCommentElement2` for CharacterData's interface, since it exposes the exact same props that it has? I mean instead of the custom interface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88535

1 0

Re: [PATCH v2 0/8] MR6887: mshtml: Implement proper prototype chain for text nodes and events.
by Jacek Caban (＠jacek) 22 Nov '24

22 Nov '24

On Fri Nov 22 15:47:04 2024 +0000, Gabriel Ivăncescu wrote: > Other than this, only CSS-related styles/stylesheets have a similar case > like this, but those are more convoluted. > I also don't see how introducing a private interface helps to simplify > it. We'd still have to expose it (and forward) in comment elements, but > now we'd also have to expose and forward it in text nodes, making it > actually less simple, IMO. > But is my forwarding a good idea? The ugly part of forwarding to `IHTMLDOMTextNode2` is that you need to implement `IHTMLDOMTextNode2` in an object that's not a text node (comment node). With a private interface, we could give it a proper set of properties, so no hooks would be needed, and just forward to it from both `IHTMLDOMTextNode*` and `IHTMLCommentElement*` interfaces. We could even share its entire implementation with something like: ``` struct HTMLCharacterData { IHTMLCharacterData IHTMLCharacterData_iface; DispatchEx *dispex; // used to forward IDispatch to comment's or text node's dispex nsIDOMCharacterData *character_data; // used for the actual implementation }; ``` You could then embed it both in both comment and text node structs and just use the single `IHTMLCharacterData` implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6887#note_88534

1 0

2025

2024

2023

2022

wine-gitlab November 2024