Docs: bug in docs of typer site when clicking "restart" and "fast"

[phalberg]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the documentation, with the integrated search.
• I already searched in Google "How to X" and didn't find any information.
• I already read and followed all the tutorials in the docs and didn't find an answer.

Example Code

See: 
1) for typer docs (seems broken here): https://typer.tiangolo.com/
2) for fastapi docs (seems functional here): https://fastapi.tiangolo.com/

Description

Hello,
Upon looking more closely in the documentation (https://typer.tiangolo.com/), and especially in the "bash" boxes showcasing small short animations of code and completions, two small events happen which are a little annoying.

The buttons Restart and Fast

Upon clicking the restart / fast button on an animation, one is focused to the top of the page, which makes it slightly akward to find the place where you hit restart again, but the functionality requirement seems to work properly (i.e it does restart when hitting restart, it does go fast upon clicking on fast)

Reproducibility

Upon trying to reproduce this issue, I see it sometimes works, without going to the top of the page, and sometimes does not - the behavior is slightly wierd - but I am sure there is a reason for this...

An example of a bash box in typer (or what i call the animations...):

(with restart button)
and

(with fast button)

FastAPI

At least I see that FastAPI docs (https://fastapi.tiangolo.com/) its animations, seem to work as expected, (i.e upon hitting fast/ restart one does not get pushed to the top of the page). So something here is going more right, and its cleaner and more smooth for the experience for the user of these docs.

Conclusion

I am glad to try to investigate and make a PR for this, as it's just slightly inconvenient, at least when you are far down on the page, and it seems FastAPI docs has this issue already solved.

Operating System

Windows

Operating System Details

No response

Project Version

0.26.8

Python Version

No response

Additional Context

Not fully sure if this issue has been identified, I tried searching for it, but could not find it.

[DhruvalAnandkar]

Hi @phalberg! Good catch, and good news — this one's already been solved, just not here yet.

FastAPI hit this exact bug and fixed it back in fastapi/fastapi#13714. The root cause: the Restart and Fast buttons in the terminal widget (termynal.js) use href="#", and clicking an anchor with an empty # target makes the browser jump to the top of the page. That's the scroll you're seeing on both buttons.

The fix was a one-line change in two places (generateRestart and generateFinish in termynal.js): swap href="#" for href="javascript:void(0)". That keeps the click handler working exactly the same, it just stops the browser's built-in anchor-jump behavior.

That also explains the "sometimes it happens, sometimes it doesn't" part you noticed - it's not actually random it depends on how far you'd scrolled and whether the jump-to-top was even noticeable from where you were on the page. And it explains the FastAPI vs. Typer difference too: they're separate repos each shipping their own copy of termynal.js as a doc asset. The fix landed in FastAPI's copy but was never ported over to Typer's.

Since you already offered to open a PR - this should be a very safe one to make, since it's the exact same change already tested and merged on the FastAPI side. Just find Typer's copy of termynal.js and apply the same href swap in both functions.

Let me know if you want a hand tracking down the file path in this repo! (And if this clears things up, I'd really appreciate it if you could mark this as the answer! )

[phalberg]

Hey @DhruvalAnandkar,
Thank you for the review and pointers.
I will look into it when time opens up and look into the fix.
I will probably mark the PR link as the answer, which will contain the solution, which I can link up later.

Appreciate it!

[svlandeg]

@DhruvalAnandkar: Thanks for the review & pointers. Please do be careful to not make it seem like you're a maintainer approving the creation of a PR though ("Since you already offered to open a PR"), as this may come across as confusing.

@phalberg: if you can replicate the fix and it's indeed parallel to a recent FastAPI PR, please feel free to PR it here as well and link the relevant FastAPI PR. Thanks!

[phalberg]

Thanks @svlandeg,
I will look into the fix and make the relevant PR when time persist, which I will link up in this discussions page - as the solution.
You will hear from me soon.

-Please if anyone sees this issue, I will make the PR myself, so do not make the PR linking up the discussion ( this is for anyone using LLMs for creating PRs etc)-

Thanks for both of you!