For the image load event patch, wine-gecko always sends them asynchronously, which is the same behavior as IE9+ modes. See `dom/base/nsImageLoadingContent.cpp: nsImageLoadingContent::FireEvent`. The comment there, funnily enough, is what script56.chm's script protects against (and breaks because of async behavior), but there's no way to selectively override it (because of compat mode), so we have to workaround it on mshtml side.
Note that we only hook the gecko events (nsevents) being dispatched, and that's obviously on purpose. We wouldn't want to skip a load event dispatched by some script or app's code.
--
v2: include/mshtmhst: Add CGID_ScriptSite and CMDIDs for it.
mshtml/tests: Expect UpdateUI, Exec_UPDATECOMMANDS and Exec_SETTITLE in
mshtml/tests: Allow BINDINFO_OPTIONS_ENABLE_UTF8 in bind options.
mshtml: Don't lock document mode when querying IEventTarget.
jscript: Pass correct 'this' to host objects in ES5 mode.
mshtml: Send load event synchronously for img elements that loaded instantly
mshtml: Keep a ref to the window during the doc nsevent handlers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1598
I've finally found time to review it properly. Sorry for the delay.
The patch needs lots of cleanup - starting from separating it into multiple patches (preferably adding one function in every patch) and changing commit message to describe what the patch implements (instead of what application it fixes). Taking in account next comments, I would suggest picking one function first and sending more patches after it gets in.
I'm worried about adding the stubs (instead of full implementation). The functions are returning reference to object that can never be NULL on Windows. I'm expecting it to crash if application tries to use returned object.
On the implementation note, I've done some initial testing of _Cout_func. It looks like it's almost compatible with msvcr80. The only difference I have found is that it uses __clrcall calling convention for virtual functions. I haven't found documentation for it but it seems to be similar to __fastcall (it additionally allows lazy compilation on function call but it can be probably ignored). Anyway I think that the way to go is to either copy implementation from msvcp and change relevant calling conventions or try to use PARENTSRC (I'm not sure if it will work well without trying).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1418#note_18069
Fixes an out of bounds access in `show_popup`.
```c
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); // <- can crash here
menu->FocusedItem = NO_SELECTED_ITEM;
}
```
Menu resets focused item on show, not on close.
If items were later deleted, next time user opens the menu, menu can crash on out of bounds access and won't show up again, as menu thinks it's still on screen.
In other words:
- open split button dropdown
- click on any item
- clear dropdown items
- open dropdown again
Menu borked and won't open again.
Source for the testing app for reproduction.
[test.c](/uploads/2f703f63891b33e1a0eb0fcd27c912b7/test.c)
I guess, the alternative is to reset focused item when menu is closed, but not sure where's the best place to do that, haven't dug deep enough.
--
v4: win32u: Reset focused item if it was removed when removing a menu item
win32u: Allow select_item to work with off-screen menus
win32u: Add deselect to HiliteMenuItem
win32u: Return FALSE in HiliteMenuItem when window handle is NULL
https://gitlab.winehq.org/wine/wine/-/merge_requests/1554
The LFH being automatically enabled after several allocations of the same sizes are done, its reallocation strategy differs from non-LFH blocks and was messing with the tests. I previously removed the HEAP_REALLOC_IN_PLACE_ONLY flag from LocalReAlloc, based on the test results, but the outcome is different when a non-LFH block size is used.
This adds more tests and restores the flag to fix the regression.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1613