We won't receive a ConfigureNotify event if the embedded window has been
reparented without moving or resizing it. Top-level windows always
receive synthetic ConfigureNotify from the window manager.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57370
The X event merging logic removes events from the queue in advance, and
putting a dummy ConfigureNotify back in the queue will override any
previously received event.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57370
Instead of keeping the same offset as from the previous window parent,
which may cause offsets to stack up with embedded windows.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57370
We have to introduce special handling for jscript, as it's probably integrated
on native mshtml.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
When GLOBAL_DISPEXVAR is used, we store the id of the dynamic prop and
invoke it using the same id. But this is not the case if we have a jsdisp,
which is redirected from InvokeEx and results in an invalid id.
The actual way this works on native (in IE9+) is that element/frame props
are special and not part of the window object at all. They're actually
looked up after the prototype is, in a special way, but that requires a
revamp. Storing over it just creates an actual prop on the window (which
is what we are doing here).
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Instead of E_NOTIMPL.
We can't use the dispex's delete because it also applies to dynamic and
builtin props and it also happens too late when deleting by name (after
looking it up), where existing tests show it doesn't look up the dispid
at all.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
The previous tests bailed out too early on IE8, and did not test builtin
props. Also added todos for tests that we did not even test because of
returning early.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
NVidia and WARP clamp before interpolation in the oFog case; AMD clamps only
after interpolation (which we also do).
On the other hand, test_fog() proves that clamping should not be done before
interpolation in the FFP case, for any driver.
In order to emulate an FFP vertex shader with a real compiled shader, we need to
avoid clamping before interpolation, choosing the AMD behaviour here.
The previous commit ensures that the WTPACKET fields align between
32-bit and 64-bit architectures, so now we can use the same
tablet_get_packet without needing another thunk.
WTPACKET's structure is never directly exposed via the API; it's
internal to Wine. The HCTX value is only used on the wintab32 side,
not the driver side, and it is used as an integer rather than a
pointer, so this should be safe to do.
This eliminates the need to have a wow64 thunk for tablet_get_packet.
