Unable to move player after joining room

[rmatab]

Bug description
After joining a room the player is teleported to the top left most position within the viewport or map and I am unable to move the player around.

Steps to reproduce

1. Go to spACK (beta) v0.9.0 at https://pauper.tel/spack/
2. Fill in room name (e.g. 'test') and click on 'Enter Room'.
3. Configure player (reproducible with any configuration).
4. Click 'Join'.

Current result
Player is teleported to top left most position within viewport.
Position may coincide with top left most position of map (I can't tell).
I can not move the player to another position using WASD.

Expected result
Player's initial position is at spawn point, and viewport is centered around player.
Move around the map freely (at least when there are no obstacles).

Screenshots

Environment:

• application version (v0.9.0, online beta)
• occurs on desktop (Manjaro Linux, i3wm)
• occurs on mobile
• Browser: Firefox (148.0.2)
• occurs on Production
• occurs on Staging
• occurs on Test (I assume this is deployed from commit hash: 0a57895)

Notes, context or workaround

• No errors in console.
• I could not reproduce the issue with Firefox Developer.

[xopr]

Thanks for taking the time to report.
Unfortunately, I wasn't able to reproduce using:

• FF 148 on Linux Mint 21
• FF 149 on Ubuntu MATE 24
  I did however, noticed that it starts off in the top left, but settles on the center of the map after the full initialisation is done; this is most likely related to Portal room (teleport) displays wrong intermediate room #62.
  There are still things that could trigger this:
• problems with the set-up of livekit (or, less feasible: the access request of mic, which by default should be off)
• request wake lock triggering a problem
• resource load order problem of some sort triggering a deadlock or missing a reactive update halting the mechanism.
• something with re-requesting the token too often; I've noticed this and created a separate issue for it: Token requested too often #64

For the former 2 I'd expect an error on the debug console; the latter 2 might be silently triggering this issue to is more likely to be the culprit.

Did the problem still occur when (hard) reloading the page?

[rmatab]

Still able to reproduce on my desktop PC (Manjaro Linux, Firefox 148.0.2) even after (hard) reloading the page.

Tried to reproduce on a different PC (Manjaro Linux, Firefox 138.0.4): unable to reproduce.

[rmatab]

Found it!

I have privacy.resistFingerprinting set to true via about:config.
When I change the value to false it works as expected and I was able to move the player around.

Possible Root Cause

privacy.resistFingerprinting forces Firefox to clamp performance.now() to 100ms precision.

The game loop in GameView.tsx computes:

const deltaTime = performance.now() - time!;
// ...
const step = 40 / 100 * deltaTime;

When performance.now() is clamped to 100ms buckets, consecutive calls within the same 100ms window return identical values, making deltaTime = 0. This means step = 0, and then in stepDelta:

const delta = newValue - value;
// delta / 0 = Infinity or NaN
return value + Math.ceil(delta / step);  // breaks

With step = 0, you get Infinity or NaN for position, which would freeze or corrupt all player movement interpolation, both local and remote players.

Possible Fix

Guard against deltaTime = 0 (or very small values), and cap it to avoid huge jumps after tab backgrounding:

const raw = performance.now() - time!;
time = performance.now();
const deltaTime = Math.min(Math.max(raw, 16), 200); // clamp: min 16ms (~60fps), max 200ms

The minimum of 16 ensures step is always positive even when performance.now() has reduced precision.
The max of 200 prevents huge jumps when the tab was backgrounded.

[xopr]

Great find, thanks for looking into this and reporting in detail!

And yes; I was able to reproduce as well.

To be honest, I've used performance.now() to calculate a high-res delta but only to include a delta for the first frame as well; I'll look into using the provided timestamp with the requestAnimationFrame callback but I won't be able to work on this project until beginning of next month; I'll do some rewriting of this logic and report back to you.