To confirm that I can reproduce. Thanks for reporting.

Seems related to:

• quarto preview does not update all pages when project-wide contents change #10392

yeah, happens for me too.. my solution is any time I want to preview I just run touch _quarto.yml and then the preview session will reload and show the changes, without that it will still reload but not show any changes, I'm also thinking into adding some file watch service and run the touch command for me to automate this until a proper fix reaches a future release.

Is there any fix to this?

btw: it is strange that it seems to work in the past
at least I don't recall there was such an annoying thing
I guess some updates of vscode broke things?

Hi,

I've been experiencing this issue as well.

I updated RStudio (to version 2024.12.1+563) and Quarto (to version 1.6.42) on 7th March, 2025 and refreshing the browser no longer updates changes made to .qmd files. I have to manually re-render each time, which feels unusual.

My writing experience is also quite affected by this issue. It seems to be connected to reloads in the previewer killing off communication at the wrong time (or something like this) for book chapters with long render times.

I think the half-fix I posted in #9933 (comment) also addresses parts of the present issue. (In standalone browser, it works for me. Autoreloads in VS Code window on the other hand still show the old version. Manual reloads in VS Code then show the correct version, which is an improvement over previous behavior where it would just ignore my edits even though the renderer completed.)

I would really appreciate if somebody more familiar with the communication flow that is supposed to happen on rerenders could look more deeply into this!

I am also having this issue. Would love for there to be a fix.

@kchaz Thanks for your interest. Prefer using reactions, such as thumb up, on the original post rather than commenting.
Reactions can be used by maintainers to prioritise issues while mitigated noise caused by notifications.

@mcanouil My impression from this issue (and #9933, #10382, #10392, #12144 …) is that, for more than a year, the preview feature in Quarto has been fundamentally broken for everyone who is working on a big multi-page project. (Maybe I'm mistaken and it sometimes works for some setups? But nobody seems to say so.) I agree with your general statement about noise reduction, but, in the very case of this issue, I really wonder how many reactions it would need for the maintainers to consider the problem a priority. :/

Edit: Did a little more search and saw that there might be new hope for a fix on this front #2795 (comment) .🥳

The team is very small. What you consider a priority is not necessarily one compared to other issues affecting Quarto in general and not only the preview command.
You can see the "preview" issues and responses from maintainers across them. They are aware but the manpower and time is limited.m (thus the importance of reducing noise).

There are 1.5k opened issues, three developers, more than 1k more issues opened each year, and almost the same amount fixed/closed by the team.

I really wonder how many reactions it would need for the maintainers to consider the problem a priority. :/

@benkeks I will ask you, fairly directly, to stop casting these kinds of aspersions. We do consider this a priority. And we are fixing it. But it really does require pretty fundamental changes to the code base. The fundamental problem is that we need to collect centralized, accurate information about which files in the file system will affect the final page, when each page is ultimately composed by a large, complex process that involves at least two separate subsystems, each of which being Turing-complete in their own right: the execution engine and Pandoc itself.

We have been doing the work since at least early 2024. As @mcanouil said, there are three full-time software engineers in quarto-cli. Please: I am asking you to be more considerate when making these comments.

I'm going to be pretty frank here: You might not be aware, but these comments are really discouraging to people working in open source, and I will not let this discussion forum become a place where my colleagues feel discouraged to participate.

I appreciate frankness. That's the point.

I've been using Quarto for almost every day for a year, and I've been affected by this bug complex for most of it, every single day. As you see, I chose not to bother you about it.

I even spent a day out of my free time trying to figure out how the preview updater flow is supposed to work and whether there is an easy fix. But I arrived at the conclusion that this is the kind of thing that can only be resolved by original authors who understand their subsystem or core maintainers who have the authority to go into a major rewrite of it.

I think it's annoying, but okay that some features just don't work in an open source project (especially if the infinite-defects world of browsers/PDF/pandoc/LaTeX is involved). If they don't work for a year and fixing them is outside the time budgets, it might be fair to place some note on known limitations in the documentation or print warning messages. (So that people do not spend hours fiddling around with their document because they think it is their fault that the previewer fails — as I, at least, did last year.)

It's okay to say that this is hard to fix or that there's more pressing matters. My remark was supposed to answers to the subtext that the handling of the previewer bugs would be a question of how many reactions there are. As far as I get it, it's neither a nice-to-have-feature-voting issue nor a question of whether this affects a lot of people. Maybe, I got the subtext wrong.

Anyways, the remark was not supposed to tell you how to run your open source project or anything. Neither do I want to discourage you or anyone from participating in it. My apologies! ☮