TotalCross / TotalCross/totalcross

Review SDL mouse event timestamp passed as modifier flags

Open
#428 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
227
Forks
42
Avg merge
1d 19h
Merged PRs (30d)
11

Description

Summary

handleMouseEvent in TotalCrossVM/src/event/linux/event_c.h computes a getTimeStamp() value and passes it as the last argument to postEvent for SDL mouse events.

However, the last postEvent argument is mods, not an event timestamp:

void postEvent(
    Context currentContext,
    TotalCrossUiEvent type,
    int32 key,
    int32 x,
    int32 y,
    int32 mods);

postEvent already generates the event timestamp internally when it calls the Java _postEvent method. Before posting, it also calls keyGetPortableModifiers(mods). Consequently, the lower bits of the elapsed-time value supplied by handleMouseEvent may be interpreted as keyboard modifier flags.

Current code:

void handleMouseEvent(SDL_Event event) {
   int32 timestamp = getTimeStamp();
   ...
   postEvent(mainContext, PENEVENT_PEN_DOWN, 0,
      event.button.x, event.button.y, timestamp);
}

Relevant internal behavior:

executeMethod(currentContext, _postEvent, mainClass,
   (int32)type, key, x, y,
   keyGetPortableModifiers(mods), getTimeStamp());

Why this is being deferred

The runtime timing APIs are being redesigned to separate monotonic time from Unix wall-clock time and to remove the legacy native getTimeStamp helper. This SDL call site should not be mechanically migrated to the new monotonic function because its apparent timestamp value is passed through the modifier parameter. It needs a focused event-semantics review instead.

Questions to resolve

  1. Should SDL mouse events pass -1, 0, or modifier state derived from SDL APIs as mods?
  2. Should handleMouseEvent preserve mouse or keyboard modifier state from the original SDL event?
  3. Does the event.button.button access remain valid for SDL_MOUSEMOTION, or should the event union member be selected by event type?
  4. Are there tests that assert modifier values and timestamps for SDL mouse down, up, drag, and move events?

Expected outcome

  • Remove the misleading local timestamp variable.
  • Pass intentional modifier data to postEvent.
  • Keep event timestamps generated exactly once inside postEvent, unless the event API is deliberately redesigned.
  • Add focused tests for SDL mouse event type, coordinates, modifier flags, and timestamp ordering.

Acceptance criteria

  • Mouse down, mouse up, drag, and move events carry the expected modifier flags.
  • Their Java-side Event.timeStamp values are generated by the event posting path and remain monotonic.
  • No elapsed-time value is interpreted as modifier bits.
  • The SDL event union is accessed through members valid for each handled event type.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in TotalCrossVM/src/event/linux/event_c.h at handleMouseEvent and compare its SDL event handling with postEvent's modifier and timestamp path. Locate existing SDL or event tests, then verify mouse down, up, drag, and move behavior, including event-union access, modifier flags, coordinates, and monotonic Java-side timestamps. Done means no timestamp is passed as mods and the acceptance criteria are covered by focused tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.