This is first part in a series that implements Cycle Collection for every mshtml object (dispex) and cleans up rest of the code based on it, which is obviously needed due to dynamic props and other extra object-specific refs.
In an effort to split it up as much as possible, since it already has quite a lot of restructuring and changes, some of the earlier patches will introduce temporary leaks or cyclic refs, but that's because we'll later handle them properly with the dispex CC. These shouldn't affect behavior, though, so it shouldn't pose problems for functionality.
Nodes are, initially, not changed much (other than to make it compatible with the dispex) to keep changes as small as possible. They still use their own CC mechanism and refcounting, which is hackish but that is solved in a follow-up MR, so it's temporary only.
Eventually, every object (including nodes) will use the dispex's vtbl to do its Cycle Collection, except for stuff like outer window (which is a special case).
In this first part, the objects that are using the node CC will have no-op dispex CC methods since they are using the node's, but this is temporary only.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3408
Ensured to work with both the current `klist` implementation and the one modified to use KerbQueryTicketCacheExMessage. Patch for `klist` will be sent separately.
--
v4: dlls/kerberos: Implement KerbQueryTicketCacheExMessage.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3393
This framework is present in all macOS SDKs we support, starting at macOS 10.13 and still present in macOS Sonoma.
Getting pcsclite completely working correctly is a lot harder on macOS and this would give us better integration.
--
v2: configure: Use PCSC.framework when pcsclite is not available on macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3389
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55283
---
It has been causing every merge request to get a GitLab CI error ever
since the move to Debian 12 on 2023-07-10. That makes the GitLab CI
pretty horrible.
If there is a quick fix for this issue then this MR can be ignored.
Otherwise, since there is no way to tell the GitLab CI that a specific
test is expected to crash or fail in a certain way, there is no other
option than to skip the test entirely until it works again.
Side-note: Finding failures in the GitLab CI logs is quite annoying. As
far as I can tell the only way not to miss any is to perform a set of
four searches:
- "Test f" -> regular failures
- "todo " -> Todo tests that unexpectedly succeed
- "ne (2" -> Timeouts (and test units with 2 failures)
- "ne (-" -> Crashes (with or without an 'unhandled exception' line)
If anyone has an emacs macro to automate this...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3361