Fixes #3117 On mouseExit we sent a cursor position event with (-1, -1). Negative values are meant to indicate that the cursor is not on the surface. The magnitude of the values are irrelevant. However, we never reset the cursor position on mouseEnter. This has the effect of the previous cursor position being stuck outside the viewport which makes certain things such as `button` mouse reporting not report until the mouse is moved. This commit sends the correct cursor position event on mouseEnter.
Fixes #3117 On mouseExit we sent a cursor position event with (-1, -1). Negative values are meant to indicate that the cursor is not on the surface. The magnitude of the values are irrelevant. However, we never reset the cursor position on mouseEnter. This has the effect of the previous cursor position being stuck outside the viewport which makes certain things such as `button` mouse reporting not report until the mouse is moved. This commit sends the correct cursor position event on mouseEnter.
Extracted from #3110 Initial fix is relatively basic, and catching it with a test only required a little bit of extra scrutiny of the cursor state after one of the tests that we already had. However, the fix revealed faulty dirty tracking logic throughout the `cursorScrollAbove` function (and therefore bad results that were being tested for when they should not have been). I've ended up clarifying things, fixing the asserted dirty states in all the `cursorScrollAbove` tests, and then finally implementing another very trivial fix that catches the mistake. Fixing the dirty tracking is really just an exercise in correctness though, since when the scroll happens it inherently invalidates the viewport, and therefore will trigger a full rebuild in the renderer... unless, I guess, another operation is performed that cancels things out and results in the viewport pin being in the same place as the previous render, but that seems an exceptionally difficult scenario to make happen on purpose much less accidentally. This PR is almost entirely changes to comments and tests, there are only 2 lines of real code it changes, the one added to the start of `cursorScrollAbove` and the one modified at the start of `cursorScrollAboveRotate`. I believe these changes are entirely safe. (I wonder if they might have a bad effect on our `vtebench` scrolling performance though...)
Extracted from #3110 A simple fix, with a unit test that covers the issue. This could cause memory corruption and crashes in fairly realistic scenarios, since it can occur whenever `cursorAbsolute` is used to move to a page that happens to be at capacity for some form of managed memory and the cursor is carrying some managed memory with it (style, hyperlink, etc.). I really wish Zig had affine types so we could make `cursorChangePin` "consume" its argument so it can't be accidentally used afterwards... I think I'll audit the rest of the codebase anywhere we use `cursorChangePin` to make sure we don't have similar problems.
gtk_event_controller_get_current_event() is documented to possibly return NULL. Fixes: #3088 Link: https://docs.gtk.org/gtk4/method.EventController.get_current_event.html
gtk_event_controller_get_current_event() is documented to possibly return NULL. Fixes: https://github.com/ghostty-org/ghostty/issues/2022 Fixes: https://github.com/ghostty-org/ghostty/issues/3088 Link: https://docs.gtk.org/gtk4/method.EventController.get_current_event.html Signed-off-by: Tristan Partin <tristan@partin.io>
explained in comment