- 27 9月, 2019 40 次提交
-
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
- Extract user data sync workbench contribution - Make actions, notifications & badge respect states correctly
-
由 Sandeep Somavarapu 提交于
-
由 Benjamin Pasero 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Alex Ross 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Christof Marti 提交于
-
由 Benjamin Pasero 提交于
-
由 Christof Marti 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Benjamin Pasero 提交于
-
由 Matt Bierner 提交于
Split out from #77131 The current webview editor api is very procedural. This model has some problems when it comes to supporting editing resources, but actually does make a lot of sense for webviews that aren't backed by real file system resources. For example, if you have a webview that edits some document in the cloud, you should not be required to implement a custom file system provider just to enable basic saving. This change moves the `onWillSave` and `webviewEditorState` properties back onto `WebviewPanel` instead of keeping them specific to `WebviewEditor`. The save implementation does not fully work yet, as the will require #81521
-
由 Matt Bierner 提交于
Fixes #42243
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Miguel Solorio 提交于
-