Promote webview Api to stable

[mjbvz]

Promotes the proposed webview Api to stable

Fixes #43713
Fixes #28263

[jrieken]

Not yet sure about that... We can make is deprecated from the start (grid layout) so that it compares to editors. Also, since it optional is can work like the editor-case (think of embedded editors or output-editors)

[mjbvz]

Ok, I'll make it as deprecated. The intent is that property could be extended in the future to use other locations such as panel positions:

position?: ViewColumn | PanelPosition;

[mjbvz]

The other option is that we change this back to viewColumn and introduce the position property for use with grid layout

[jrieken]

Touches on #42091

[jrieken]

Might need extra doc, how do I can add an extra root? Is this alway additive to the two default locations?

[mjbvz]

I'm writing a new section of the docs for webview. An extension can recreate the default values using extensionContext.path and workspaceRoots.

[jrieken]

👍

[jrieken]

Not sure if this is a panel or widget property...

[mjbvz]

It was a panel property but I moved it to the webview. The intention is that title is a common property pretty much anywhere the webview would be used. The owner of a webview (such as the WebviewPanel) just figures out how to display it

[jrieken]

The intention is that title is a common property pretty much anywhere the webview would be used.

Could we say the same of dispose? Somehow I was missing it from the panel and I would also miss that from something like WebviewWindow...

[mjbvz]

Yes I think most conceivable future api uses of the Webview would also want a dispose method. I'll move dispose and onDidDispose from the WebviewPanel class to the Webview itself

[jrieken]

Yeah, but that's the opposite of what I wanted ;-) It's kinda bogus to say createWebviewPanel but to then call webviewPanel.webview.dispose().

[mjbvz]

So you would prefer it on both objects?

[jrieken]

Can we sketch-up a sample for the editor-view-zone-case? Or one in which a webview would be inside a separate window?

[mjbvz]

Here's the branch with a webview widget (view zone) sketch: https://github.com/Microsoft/vscode/blob/mjbvz/webviewWidgetProto/src/vs/vscode.proposed.d.ts#L689

The window one would be similar. It could be as simple as a top level function called createWebviewWindow(...): Thenable<Webview> or we could introduce a WebviewWindow class that has window specific properties on it:

interface WebviewWindow {
     readonly webview: Webview;

     onWillClose: Event<void>;

    onDidFocus: Event<void>;

    ...
}

[jrieken]

Makes sense

[jrieken]

One more question Webview vs WebView vs TreeView...

[mjbvz]

Good question. Electron uses one word: Webview. This makes sense if we say that a webview is whole concept (like an iframe). Splitting it to Web View makes it more consistent with Tree View but it also suggests that there is a separate concept called Web that the WebView is presenting

I may be overthinking this. What do you think?

[jrieken]

that there is a separate concept called Web that the WebView is presenting

Good point, my gut wants Webview anyways

[mjbvz]

Outcomes from the API sync this morning:

• Stick to Chrome/Electron's one word Webview convention
• Move title back to the panel.

I've made these changes and am merging the PR. We'll continue to polish it based on any feedback from the test pass or from extension authors