November 2023 - Wine-GitLab

Re: [PATCH v4 0/8] MR4380: mshtml: Keep inner window's link to the outer window until it's destroyed.
by Gabriel Ivăncescu Nov. 28, 2023

Nov. 28, 2023

On Mon Nov 27 20:57:03 2023 +0000, Jacek Caban wrote: > My guess is that you wouldn't be able to reproduce that with JS. If > that's the case, then web pages can't depend on that (otherwise we'd > have a way to crash web browser from JS). Do you mean crash on native? I mean it's known to be full of bugs and security exploits, to the point of becoming a meme. I could test it if I can use it from JS (actually, can't event handlers still be called after navigation on the old doc/window?), because it would be a silent "failure" or event not firing which would be insanely hard to debug otherwise, especially since you can see event handlers are registered and all. And "if it works on Windows it must be correct" that devs usually think of. I wouldn't mind trying to test this out, even if it doesn't end up as proper wine tests, I just don't want it to be a waste of time, like it feels right now, even though I was expecting matching native behavior (and fixing potential memory hazards) to be a goal. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_54096

1 0

Re: [PATCH v4 0/8] MR4380: mshtml: Keep inner window's link to the outer window until it's destroyed.
by Gabriel Ivăncescu Nov. 28, 2023

Nov. 28, 2023

On Tue Nov 28 14:17:15 2023 +0000, Jacek Caban wrote: > > As for the "hide problems in the future", I actually think the exact > opposite. Right now, we use the document's outer_window in same way, > except it's completely broken and can access invalid memory if the outer > window happens to die, which would be very hard to debug (especially > considering most apps using mshtml are bloated and slow with millions of frameworks). > Yes, it would be nice to fix that. One fix for that is to simply reset > the pointer to NULL. My understanding is that the actual reason we can't > do that is iframe navigation test and we already know that the test > works because on native, the document interface doesn't change. So what > you do is essentially working around that problem, not fixing it. Resetting the point to NULL is the same as using the `doc->window->base.outer_window`, which has potential for a lot more regressions (I don't mean the test). How is that better?!? I don't know why you think this is so risky; as mentioned in the MR's message, those are the only things that would be affected, and they're all either fixed or handled (handled means same behavior as before). I spent time carefully reviewing them, I'd like that not to be a waste and just dismissed like that. Sure I might have missed some, but it's pretty unlikely. I also tested real world apps and it seemed fine. I was hoping a review to "double check" it would provide the extra eyes on it, instead of being dismissed, even though it's correct. Also another argument for it is that, since I suspect it will have to be fixed properly at some point, the sooner we do it, the easier it will be to review, which is now. The more complicated mshtml becomes (necessarily, to implement new features), the harder it will be to revamp this. Why not do it now? It just seems to me that you dismiss it because of potential regressions without actually analyzing what could cause them at all, since my goal with this patch and the MR message was definitely to keep same behavior as before *except* in places where I fixed it (and mentioned in the message). *If* that's not the case everywhere I'd like to know, too, but I did carefully review it. Would you please reconsider? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4380#note_54095

1 0

[PATCH 0/1] MR500: vkd3d-shader/dxil: Declare IO registers as VEC4.
by Giovanni Mascellani (＠giomasce) Nov. 28, 2023

Nov. 28, 2023

Otherwise, for instance, their write masks and swizzles are not written in the D3D ASM dump. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/500

3 2

[PATCH 0/1] MR495: include: Add ID3D12InfoQueue1 definition in vkd3d_d3d12sdklayers.idl.
by Biswapriyo Nath (＠Biswa96) Nov. 28, 2023

Nov. 28, 2023

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/495

4 3

[PATCH v10 0/3] MR4452: d2d1: Acquire lock before attempt to draw to device context
by Brendan McGrath (＠redmcg) Nov. 28, 2023

Nov. 28, 2023

Fixes periodic crashes in PowerPoint 365 -- v10: d2d1: Acquire lock before attempt to draw to device context https://gitlab.winehq.org/wine/wine/-/merge_requests/4452

3 9

[PATCH 0/8] MR4533: winex11: Detach / attach vulkan window surfaces as needed.
by Rémi Bernon Nov. 28, 2023

Nov. 28, 2023

This is some preparatory work for vulkan child window and other features which currently live in Proton. I think this could be upstream already, and it will make rebasing patches on top of it simpler. To get vulkan child window upstream we'd probably still need to rework it a bit and maybe try to move the wait and blit to `vkQueuePresent` somehow. The idea here is also that although Vulkan spec does not allow multiple active swapchains for the same window, Windows tends to allow it especially with D3D, and we also need to support the case where multiple APIs are use to draw onto the same window surface (as we implement D3D on top of GL/Vk for instance). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4533

1 8

[PATCH v2 0/2] MR497: vkd3d-shader/dxil: Implement DX intrinsic Unary.
by Conor McCarthy (＠cmccarthy) Nov. 28, 2023

Nov. 28, 2023

-- v2: vkd3d-shader/dxil: Apply metadata attachments to instructions. vkd3d-shader/dxil: Implement DX intrinsic Unary. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/497

3 6

Re: [PATCH v2 0/1] MR4415: msvcrt: Pass INT_MAX as the length in implementations of the _mbscoll family.
by Piotr Caban (＠piotr) Nov. 28, 2023

Nov. 28, 2023

On Tue Nov 28 11:16:55 2023 +0000, Haoyang Chen wrote: > Hi,this patch introduces new problems in locales where UNICODE is used. > Because str single byte \0 does not necessarily terminate the string, > and thus a stack overflow occurs. And I am using a chinese local set. > I still found it to be -1 in Windows. I don't understand the comment. Please create a bug so we can move the discussion there. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4415#note_54074

1 0

[PATCH v3 0/1] MR4521: msiexec: : No longer use console/file output APIs.
by eric pouech (＠epo) Nov. 28, 2023

Nov. 28, 2023

Regular GUI apps don't. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- v3: msiexec: : No longer use console/file output APIs. https://gitlab.winehq.org/wine/wine/-/merge_requests/4521

3 2

Re: [PATCH v2 0/1] MR4415: msvcrt: Pass INT_MAX as the length in implementations of the _mbscoll family.
by Haoyang Chen (＠chenhaoyang) Nov. 28, 2023

Nov. 28, 2023

Hi,this patch introduces new problems in locales where UNICODE is used. Because str single byte \0 does not necessarily terminate the string, and thus a stack overflow occurs. And I am using a chinese local set. I still found it to be -1 in Windows. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4415#note_54069

1 0