tab_close is blocked by the unsaved-changes dialog and reports a misleading tab count

[stanzhang]

Closing a tab whose layout has unsaved changes opens a TradingView confirmation window — "Close tab? There are unsaved changes on your chart layout. You will lose them if you close the tab." with Save and close / Close without saving. The dialog blocks the close, and tab_close then reports:

The close was clicked but the tab count did not drop (2 -> 2)

The message is accurate and completely misleading: it reads like a selector or window-scoping problem. I spent most of a session concluding tab_close could not reach tabs in a second Desktop window before finding the dialog.

Why it is invisible to the current code

The dialog is its own CDP page target. It is not in the chart page's DOM ([role=dialog], [data-name*=dialog] and friends find nothing) and it is not in the tab-strip shell that _withShell drives. Enumerating /json/list and reading document.body.innerText on each non-chart page target finds it immediately:

body:    "Close tab? There are unsaved changes on your chart layout. You will lose them if you close the tab. Save and close Close without saving"
buttons: ["Save and close", "Close without saving", "close-dialog-window"]

Reproduce

1. tab_new a layout, change the symbol so the layout is dirty.
2. tab_close.

Suggested fix

Detect it and say so, rather than reporting a count mismatch. Even without deciding for the user, an error like

the tab has unsaved layout changes and TradingView is asking whether to save; answer the dialog, or pass discard_unsaved: true

turns a dead end into a one-step recovery. An opt-in discard_unsaved that clicks Close without saving would make disposable scratch tabs practical — that is the use case that runs into this every time, since a scratch tab is dirty by construction.

Clicking the button from the dialog target works:

[...document.querySelectorAll('button,[role=button]')]
  .find(b => b.textContent.trim() === 'Close without saving').click()

Verified on 2.3.0 / Desktop 3.3.0 / macOS. Whatever the default, it should never be Save and close without being asked.

[stanzhang]

Follow-up: the project already has the convention this needs, in layoutSwitch.

src/core/ui.js detects the unsaved-changes dialog, cancels out of it and throws by default, and only clicks through when the caller passes discard_unsaved: true. That is a good design and tab_close following it would be consistent rather than novel — discard_unsaved would mean the same thing in both places.

Two reasons the existing helper does not already cover the tab case, both small:

1. Wrong target. layoutSwitch runs document.querySelectorAll('button') in the chart page. The tab-close dialog is a separate CDP page target, so the chart page sees nothing and dialog.present is false.
2. The label does not match. Even against the right document, the discard regex is /open anyway|don't save|discard/i and the button reads "Close without saving" — no match. The cancel regex /^(cancel|back)$/i does not match "Save and close" either, so the back-out path would not fire.

/open anyway|don't save|discard/i.test('Close without saving')  // false
/^(cancel|back)$/i.test('Save and close')                       // false

So without saving wants adding to the discard pattern regardless, and the lookup wants to span page targets rather than the chart document alone. Worth noting that this dialog has no cancel button at all — the choice is save or discard — so tab_close's default behaviour on encountering it has to be refuse and report, which is what it effectively does today, just with a message that points at the tab count instead of the dialog.