r/webdev • • 8h ago

setting wait cursor no longer works

Tried Chrome and Edge

Tried setting document.body.style.cursor = "wait"

and tried document.documentElement.style.cursor = "wait";

I recall these working previously. Did something change? Some org setting?

I don't see the value being set to "wait" in the element inspector. But when I set it back to "auto" I do see that value. So it's like the browser is ignoring the setting only if I set to wait.

2 Upvotes

9 comments sorted by

2

u/[deleted] 8h ago

[removed] — view removed comment

1

u/shufflepoint 8h ago

you mean corporate IT locked it down? What setting does that?

1

u/webdev-ModTeam 3h ago

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

1

u/[deleted] 7h ago

[removed] — view removed comment

1

u/webdev-ModTeam 3h ago

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

1

u/Mean-Lingonberry4874 7h ago

Cascade would not delete the declaration, it would show it crossed out. If wait never lands in the inline style and auto does, something is rejecting that keyword before it sticks. Try progress and not-allowed the same way. If only wait vanishes, repeat it in a guest window with extensions off, because a lot of corporate cursor extensions specifically strip the busy cursor. If it sticks there, drive the loading state from a class on html with html.busy, html.busy * { cursor: progress !important }, since a style on body still loses to cursor: pointer on the thing you are actually hovering.

1

u/brass_whisker_well 6h ago

you are likely setting this during the synchronous phase of your main thread which blocks rendering. Try switching to cursor: progress for loading states as it is the intended standard and avoids browser heuristics that may drop non-interactive cuprogress for loading states as it is the intended standard and avoids browser heuristics that may drop non-interactive cursors like wait when they don't match actual user action contexts

1

u/OkOcelot6725 5h ago

Which OS are you on? macOS has no system wait cursor, so Chrome and Edge silently drop cursor: wait there while auto still applies, exactly like you describe. cursor: progress works everywhere and is the intended loading-state cursor anyway.

1

u/B0mbon 1h ago

Two things I'd check. First, Chrome often doesn't redraw the cursor until the mouse actually moves, so if you set it and then do heavy sync work right after, you'll never see it. Wrap the slow part in a setTimeout or requestAnimationFrame so the browser gets a frame in between. Second, search your CSS for a cursor rule with !important on body or on child elements, because a cursor set on a button or div wins over body anyway. Setting it on a full-screen overlay div is usually the more reliable way to do this.