Implement the function `IXMLDOMElement_removeAttributeNode`. Essentially
pass the hard work to `IXMLDOMNamedNodeMap_removeNamedItem`.
Use the fact, that attribute names are unique in elements.
One case that isn't checked is wheter or not the value of the provided
attribute match with the one stored in the dom-element.
This MR implements according to the tests introduced in https://gitlab.winehq.org/wine/wine/-/merge_requests/8928
--
v3: fix formatting of if clause
https://gitlab.winehq.org/wine/wine/-/merge_requests/9056
In wined3d_swapchain_cleanup, before decrementing the reference counts of each of the back/front
buffers, we first set their swapchain to NULL, presumably to stop the current under-destruction
swapchain from being used through them. But there is an oversight.
When we call wined3d_texture_decref on the front_buffer, the back_buffers still have their
swapchains pointing to the swapchain being destroyed. In texture_resource_unload, we call
context_acquire(device, NULL, 0), note the NULL texture parameter here. When the texture parameter
is NULL, wined3d_context_gl_acquire (in turn called by context_acquire) will default to using the
first back buffer from the implicit swapchain of "device", which, as previously stated, has not had
their swapchain set to NULL yet. From here, we reach wined3d_context_gl_activate with a texture
whose swapchain is currently being destroyed. This swapchain is then assigned to "context_gl" here
before being freed, leaving a dangling pointer.
When this context_gl is acquired again later, we will try to access
context_gl->c.swapchain->win_handle, thus complete the use-after-free cycle.
This commit makes sure the swapchain pointer of ALL front and back buffers are set to NULL before
decrementing their reference counts.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58325
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8406
Unlike the message queue for which I believe we can get rid of any special handling, I don't see a way to avoid a dedicated inproc sync for user APCs. This will make sure that the sync gets created on thread creation. It could arguably be lazily allocated instead, but I don't see a reason to delay the failure to a later time and end up with successfully created but unalertable thread when they are supposed to be.
--
v2: server: Create an inproc sync for user APC signaling.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9014
--
v2: win32u: Track mouse events based on last mouse message data.
win32u: Move mouse tracking info into per-thread data.
win32u: Use internal message to hanlde NtUserTrackMouseEvent() for other thread window.
user32/tests: Add test for (no) messages during TrackMouseEvent() call.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9069