> The IID would have the IHTMLStyle3 interface (which is correct), but when looking the "zoom" prop up on HTMLCurrentStyle via DISPID, it would get the one from CSSStyleDeclaration, which has different behavior. Yes, it's weird as hell, and my explanation isn't that great either.
It seems to me that we could just use `IHTMLCSSStyleDeclaration` to expose `zoom` for applicable compat modes. It's implemented by both style and current style. What are other examples? Note that for some cases we may use some private interface, like we already need to in other a few cases.
> Instead I'm now using a mixed approach where I have a new method (but a normal method in the vtbl like PropInvoke rather than a function pointer callback) that uses a "func_ctx" which is basically the `func_info_t` (it's opaque to jscript, it doesn't care).
The problem with `func_info_t` is that it carries information specific to the instance (like hooks), not only abstract things like the signature, so you can't just apply "current style" function info to "style" object without some additional refactoring. It's hard to comment in more details without the code.
> Anyway, this is not very related to this MR, is there something I can do to get this moving?
I'm still hoping to see how the interface capable of handling prototype chains looks like.
Meantime, I noticed that we could prepare MSHTML for the change better by completing dispex refactoring (and document objects split), see https://gitlab.winehq.org/jacek/wine/-/commits/mshtml-dispex/ for a draft. Unfortunately, it needs a few more vtbl entries, but the unification seems worth to me. On top of that, you wouldn't need to have a dedicated new interface implementation for document node and the window variant should be easier as it could be just a forwarder. What do you think?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71748
I was going to reimplement path resolution in ShellExecute, but half way through I realized that's very unnecessary.
Since what I wanted is a version of `PathResolve` that behaves differently _only_ for filespec paths, I ended up duplicating a lot of code, then I realized I can still pass filespec paths onto `PathResolve` and only deal with non-filespec paths.
--
v3: shell32: Fix ShellExecute for non-filespec paths.
shell32: Make sure array passed to PathResolve is big enough.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5692
The first commit adds some test infrastructure to be able check raw input keyboard events, along with a few tests relevant to the code paths in this MR.
The second commit fixes raw input behavior with unicode inputs, and adds regression tests. Note that it was difficult to express the current Wine behavior with TODOs in the expected sequence, that's why I didn't introduce these regression tests independently.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5754
Presently the wine file explorer has a create shortcut entry that does nothing. This implements the FCIDM_SHVIEW_CREATELINK command.
This is a patch that was first submitted in 2017 and I unfortunately let the revision request fall unimplemented.
--
v5: shell32: Implement FCIDM_SHVIEW_CREATELINK
https://gitlab.winehq.org/wine/wine/-/merge_requests/5373