feat(addons): let an add-on talk to its own full-tab pages
api.emit() only ever reached the sidebar, even though addon-tab-preload has always exposed silentmode.on() — so an add-on could hear from its panel but had no way to tell its own editor tab anything. An add-on that wants a second document to land in the editor already open, instead of a third tab full of ribbon, needs exactly that. Two small pieces: - emitToPanel now also delivers to every tab owned by the same add-on. The sidebar keeps its existing condition; tabs are additional, not instead. - addon-tab-focus, the counterpart of addon-tab-close: a page asking for its own tab to be fronted. Needed because the click that hands an open page something new usually happens somewhere else — the sidebar — and the result would otherwise appear in a tab nobody is looking at. Both derive the tab from the sender's webContents, the way the close handler already does, so a page can only front or close the tab it is itself in.
This commit is contained in:
parent
aee4b44d15
commit
53965db74d
1 changed files with 3 additions and 0 deletions
|
|
@ -17,4 +17,7 @@ contextBridge.exposeInMainWorld("silentmode", {
|
||||||
// Escape. Main derives the tab from the sender's webContents id so an
|
// Escape. Main derives the tab from the sender's webContents id so an
|
||||||
// add-on page can only close its own tab, never anyone else's.
|
// add-on page can only close its own tab, never anyone else's.
|
||||||
closeTab: () => ipcRenderer.invoke("addon-tab-close"),
|
closeTab: () => ipcRenderer.invoke("addon-tab-close"),
|
||||||
|
// Bring this page's own tab to the front. Main derives the tab from the
|
||||||
|
// sender, so a page can only front itself.
|
||||||
|
focusTab: () => ipcRenderer.invoke("addon-tab-focus"),
|
||||||
});
|
});
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue