File is wrongly renamed if the widget title is changed by extension

[djangoliv]

Description

I have an extension that renames the title of the notebooks tab. In this case, opening the file with collaborative editing will rename the file according to the tab title.

Reproduce

Create en extension with this few lines:

 const newWidget = this._docmanager.openOrReveal("notebook_name.ipynb");
 newWidget.title.label = "custom-title"

In this case, the file "notebook_name.ipynb" will be renamed to "custom-title".

Expected behavior

There is 2 solutions:

• prevent developer from changing tab title
• don't base filename on tab name (better)

Context

• JupyterLab version: 3.1.7

[hbcarlos]

Hi @djangoliv, thanks for opening this issue!
After digging a little bit, I find out this is coming from #10518.
There is a discussion here #10269.

Pinging @cameron-toy and @jasongrout since they were working on this.

[krassowski]

Ouch, this is bad. I am changing tab titles for external files in a couple of extensions (LSP, jump-to-definition) to show " (external)" annotation. It turns out that now it renames the files, including system files on disk, see https://github.com/krassowski/jupyterlab-lsp/issues/669#issuecomment-913055706, breaking users conda/Python installations. I really believe we should retain the separation between tab label and the file name or this use case is doomed.

[jasongrout]

I really believe we should retain the separation between tab label and the file name or this use case is doomed.

We hadn't considered a usecase like this (the tab title for a document not being the document name). We'll have to figure out, then how to reconcile that with the workflow of double-clicking on a tab to edit the document name. I suppose an obvious solution is to introduce a new piece of data in the widget title, which is the editable data in the title. Another solution would be to have a concept of annotations to a widget title that are displayed (for example, I can imagine annotating the title with an emoji signifying the current kernel state). Another solution would be to have the document hook into the double-click event on the tab somehow and present its own dialog (is that what we used to have?). That wouldn't be in-place editing, though.

[krassowski]

I'm assigning this to 4.1 milestone as this is a data-safety critical bug and several extensions/code use-cases would benefit from being able to change tab label or add admonitions without triggering deleterious side-efects, for example:

• read-only indicator, e.g. custom icon (see UX: Clearer Read Only Status #7980 (comment))
• outside of open project, e.g. by appending (external), as done by jupyterlab-lsp (see File is wrongly renamed if the widget title is changed by extension #10856 (comment))
• indicating pinned preview status e.g. in jupyterlab-git (see Preview tab lumino#498 (comment))

This was also requested on our gitter channel.