--
v2: jscript: Get rid of the funcprot argument.
mshtml: Release the node if there's no script global when handling events.
jscript: Obtain the jsdisp for host objects in other contexts.
mshtml: Keep the link from the inner window to the outer window even when
https://gitlab.winehq.org/wine/wine/-/merge_requests/7425
This MR adds tests to `mfplat` to illustrate the timestamp values output on the samples for the respective Byte Stream handlers.
I have also included a fix for a bug in `winegstreamer` (and copied to `mfsrcsnk`) where a `NULL` value for the `pguidTimeFormat` parameter in `IMFMediaSource::Start` causes a segmentation fault. On Windows this is allowed. It is included in this MR as the `mfplat` tests pass NULL (so without this fix, the tests crash).
--
v12: mfsrcsnk: Allow NULL for time_format.
winegstreamer: Allow NULL for time_format.
mfplat/tests: Fix leak of media source.
mfplat/tests: Fix leak of media events.
mfplat/tests: Fix crash in MFShutdown on Windows.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7569
For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects.
--
v12: win32u: Use the session shared object for user handle entries.
win32u: Use the session shared object to implement is_window.
server: Move the user object handle table to the shared memory.
server: Allocate a session shared memory header structure.
server: Use NTUSER_OBJ constants for user object types.
include: Implement ReadAcquire64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7610
Yak-shaving for https://gitlab.winehq.org/wine/wine/-/merge_requests/7618.
I added a test to show that DefWindowProc, specifically, sends this event.
The timing is slightly off compared to WM_CTLCOLOR* sometimes, but I think that's fine. There's no reason to expect accessibility tools, specifically, to be sensitive to that.
The spurious events with MDI children changing state may be less fine. The MDI code (in user32) uses DefWindowProc internally to change the window text. Somehow, Windows must accomplish this without sending the event, so presumably there's some backdoor or internal interface in win32u that allows for it. There's a possibility that a screen reader responds to the NAMECHANGE by speaking the window title (I have no idea if any screen reader actually does this), which could be annoying to a user. Still, given that I don't know whether it's a problem, and it's extra complexity that we may not even need, I thought it'd be better to send the MR first with that known issue and see what people think.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7704