fix: reset title element to previous value on removal

[dummdidumm]

This started as an attempt to fix #7656, but I now ran into some questions where I'm not sure what's the best answer, to I'm pushing this up as a WIP

The questions:

• is resetting the title to the previous value the correct move? or should we reset it to the empty string?
• assuming we reset it to the previous value, what does happen if you have multiple title elements at the same time in different components, and the parent title is set to A, then the child title is set to B, then the parent title updates its title to A2. Upon removal, with this PR, it would go back too A. Is that fine?

[pkg-pr-new]

pnpm add https://pkg.pr.new/svelte@14116

commit: 3265021

[trueadm]

I wonder what other frameworks do here? However, it's maybe the correct behaviour if another <title> set the value.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3265021

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Rich-Harris]

preview: https://svelte-dev-git-preview-svelte-14116-svelte.vercel.app/

this is an automated message

[Rich-Harris]

I haven't been able to break this, but it feels like we should put the setup in an effect so that there's no possibility of another component setting the title to a new value immediately before the teardown nukes it. might just be superstition

Suggested change

	const previous = document.title;
	document.title = text;
	teardown(() => {
	document.title = previous;
	});
	const previous = document.title;
	effect(() => {
	document.title = text;
	return () => {
	document.title = previous;
	};
	});

[dummdidumm]

The effect does nothing, since text is a static value; I kept the "add document.title = .. to the shared effect" part within the compiler which is why it's updating still. The assumption is that it's rare that people have a reactive title. But we can move it into here

[Rich-Harris]

It's not about reactivity, it's about preventing this sequence of events from being a possibility:

1. component A is removed and component B is created at the same moment
2. component B sets document.title
3. component A is removed and reverts document.title to whatever it was before A was created

That may already be impossible, hence 'superstition'

[dummdidumm]

In which way does adding a render_effect help with this? The render effect is called synchronously, and teardown is a render effect under the hood.

[Rich-Harris]

was more of a belt-and-braces thing — see #14116 (comment). but it also means that if/when we introduce forking, we won't set the title until the fork is committed

[trueadm]

Sorry, I was going on about the above suggestion. If it's a render_effect, then that's not right.

[Rich-Harris]

Surely render effects other than blocks wouldn't run until forks are committed? The whole point is to not update the DOM until then

[trueadm]

Maybe. Too early to say for sure how that will all end up. Let's just keep it as is then.

[dummdidumm]

But keeping it as is currently, i.e. using a render_effect for the thing instead of just a teardown does nothing, as I've just explained.

Not gonna die on this hill, maybe I don't understand what this proofs against exactly, and using teardown is a microoptimization regardless.

[Rich-Harris]

yeah, no-one is updating the title at 60fps. given that there's potential upside and no real downside i reckon we can just keep things as they are here — this is ready to merge from my perspective

[dummdidumm]

What we could also do: Last one wins, always, i.e. it doesn't matter whether or not A is first and updates after B comes in, if B is after A then B always takes precedence. In DEV mode we could also warn then "hey there are multiple competing, and the last one which is currently X wins".

[trueadm]

What we could also do: Last one wins, always, i.e. it doesn't matter whether or not A is first and updates after B comes in, if B is after A then B always takes precedence. In DEV mode we could also warn then "hey there are multiple competing, and the last one which is currently X wins".

That gets complicated with error boundaries though, no? What if you trigger an update and the title changes, but then an error occurs? Is this warning then useful here?

[Rich-Harris]

That gets complicated with error boundaries though, no? What if you trigger an update and the title changes, but then an error occurs?

that feels like a good reason to put the assignment to document.title in an effect

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@14116

[dummdidumm]

This should handle another edge case - thoughts?

Suggested change

	document.title = previous;
	// Preserve later updates to title from other sources
	if (document.title === text) {
	document.title = previous;
	}

[Rich-Harris]

Which case would this prevent? It actually seems to me like this might make bugs more likely, since if a component had a <title> and also contained a component that set document.title in a user effect, it wouldn't revert either when the parent was removed

[dummdidumm]

This handles the case where A sets the title, then B is mounted and sets the title, then A updates the title (in other words it contains something like <title>{foo}</title>), then B is removed - in that case we wouldn't want the title to be reverted back to what A had initially, we want to preserve the title.

Setting document.title in a user effect manually feels a bit like "working against the framework", you should just do that declaratively.

They are both edge cases either way, so I'm ok with not adding this suggestion.

[dummdidumm]

We can also do this, would handle the case described in https://github.com/sveltejs/svelte/pull/14116/files#r1876874053

Suggested change

	const previous = document.title;
	document.title = text;
	return () => {
	document.title = previous;
	const previous = document.title;
	const own = {};
	// @ts-expect-error
	document._last_title_setter = own;
	document.title = text;
	return () => {
	// @ts-expect-error
	if (document._last_title_setter === own) {
	document.title = previous;
	}

[dummdidumm]

Looking at how the code is generated, we should switch it up anyway - right now if your title would contain dynamic content, you would set it two times on an update - once to revert to the previous value, then right away again for the updated value. Wasteful.

[webJose]

Generally speaking, what's supposed to happen in a case like the following?

• Component A sets title. Backs up previous title => backupA.
• Component B loads and sets new title. Backs up previous title => backupB.
• Component C loads and sets new title. Backs up previous title => backupC.
• Component B unloads. Title is not set to backupB because component C owns the title (was the last one that set it).
• Component C unloads. C is the current owner of the title, so it restores using backupC. But Oh Oh! This has revived the title from Component B, which has already unloaded.

[webJose]

I think the solution to my proposed scenario would be to centralize the "history" of backups. The owner, which will be at the top of the history stack, will pop the next one, and as components unload, they remove the next item in the history which is their contributed value.

In the example, as Component B unloads, it takes backupC out because it contains its contribution to the history of titles.

[webJose]

Assuming my proposal is carried into reality, here's another scenario:

• Component A
• Component B
• Component C

At this point, say all 3 components are loaded and they submit titles reactively during the course of the application. What should happen here?

Possibilities:

1. The title can only be changed by the owner, which is component C because it was mounted last.
2. The title changes from changes from A, B or C as they happen.

If the latter, then my proposal needs ammending: Now the component needs to clean up its contribution to history on every change, and then become the owner (be on top of the list), acquiring a new position in the history of contributions.