jiebi/CodeConvo huggingface dataset:
Change:
micromatch "^3.1.4" semver "^5.0.1" <del> tsec@googleinterns/tsec#630b53fe2b23815c28dd219119cc98dbd59e29b2: </del> <ins> tsec@googleinterns/tsec#7bf4ab23686500522341b977b3e2cc04b1f720b1: </ins> version "0.0.1" <del> resolved "https://codeload.github.com/googleinterns/tsec/tar.gz/630b53fe2b23815c28dd219119cc98dbd59e29b2" </del> <ins> resolved "https://codeload.github.com/googleinterns/tsec/tar.gz/7bf4ab23686500522341b977b3e2cc04b1f720b1" </ins> dependencies: "@types/node" "^13.13.5" <ins> typescript "^4.1.2" </ins> tslib@^1.8.1, tslib@^1.9.0: version "1.9.3"

Discussion:
Steps to Reproduce: that 52 of 69 issues are unrelated to security
btw I am seeing 84 errors, many of those are errors for async-import-statements. I am also surprised that complains about the use of trusted types policies. What are we supposed to do with such errors?
84 errors ? After I only see 19 and related issues. The issues are a current limitation of tsec which does not yet understand the Worker construction (we will fix it in tsec and send you and update when it is done, likely sometime next quarter). As for the errors, these are "expected" as they indicate the "vulnerable surface" of your code that requires manual review. In google, usages of are only allowed for the security team, which we use to exposes secure by construction APIs. That being said this does not necessarily translate well to your case, and I will invest some time in the first half of 2021 to: reduce / restrict and review current usages of improve devX around non-TrustedTypes supported browsers The good news is that apart from , it seems that all of your code is Trusted Types compatible & you should be able to start experimenting with enforcing Trusted Types through the header. For reference, here are all the errors I see:
Yeah, the is something new and an oversight. There is also still this then we should we good. I have running locally with trusted types enforced and default policy that logs and haven't found more places
Yeah, after that. I have a feeling that yarn handle these packages well.
Change:
item1Handle.close(); assert.strictEqual(called, 1); assert.strictEqual(model.notifications.length, 2); <del> assert.strictEqual(lastNotificationEvent.item.severity, item1.severity); assert.strictEqual(lastNotificationEvent.item.message.linkedText.toString(), item1.message); </del> <ins> assert.strictEqual(lastNotificationEvent.item.severity, Severity.Warning); assert.strictEqual(lastNotificationEvent.item.message.linkedText.toString(), 'Different Error Message'); </ins> assert.strictEqual(lastNotificationEvent.index, 2); assert.strictEqual(lastNotificationEvent.kind, NotificationChangeType.REMOVE);

Discussion:
https://user- a new codespaces using the vscode repo clicking on the logs link :bug: Unable to click on the link Upon inspecting the DOM, it appears that elements are being /removed/updated every second so that may be blocking the link from being clicked on Codespaces Extension: v0.10.2 Version: 1.57.0-insider Commit: Date: 2021-05-20T05:11:47.260Z Electron: 12.0.7 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Darwin x64 20.3.0
Following up upstream first...
what do you think about not rerendering the notification message if the content didn't change between calls to report? In the codespaces extension I send fake progress updates quickly to smooth out the progress bar, and you can't click a link if it updates at the moment you are clicking it
good catch, indeed we should not update the DOM when contents have not changed. Is this something you would be interested in doing a PR for? I see to locations that could benefit of a check to not emit change events when nothing changed:   I would think for the latter, a simple check for would be sufficient.
Sure
PR:
It looks like "starting codespace" is no longer a link: 
you have to create a new codespace in order for the build logs to appear, connecting to an existing one just resumes the codespace. I can try to reproduce.
Verified <img width="1024" alt="CleanShot 2021-06-07 at 11 29 00 src="https://user-"
Change:
'out-build/vs/workbench/browser/media/*-theme.css', 'out-build/vs/workbench/contrib/debug/**/*.json', 'out-build/vs/workbench/contrib/externalTerminal/**/*.scpt', <ins> 'out-build/vs/workbench/contrib/terminal/browser/media/*.ps1', 'out-build/vs/workbench/contrib/terminal/browser/media/*.sh', </ins> 'out-build/vs/workbench/contrib/webview/browser/pre/*.js', 'out-build/vs/**/markdown.css', 'out-build/vs/workbench/contrib/tasks/**/*.json',

Discussion:
Parent issue Main target is Windows but ideally it would just work on all platforms (might need some tweaking on how the process is launched).
We could cache and and use the latest one whenever is , this would let us get the actual latest exit code or exception.
Done, moved the improved exit code/exception checking to
Change:
this.textArea.setAttribute('role', 'textbox'); this.textArea.setAttribute('aria-roledescription', nls.localize('editor', "editor")); this.textArea.setAttribute('aria-multiline', 'true'); <del> this.textArea.setAttribute('aria-haspopup', 'false'); this.textArea.setAttribute('aria-autocomplete', 'both'); </del> <ins> this.textArea.setAttribute('aria-autocomplete', options.get(EditorOption.readOnly) ? 'none' : 'both'); </ins> this._ensureReadOnlyAttribute();

Discussion:
Testing When the accessibility view is opened, it always reads "the editor has auto complete, multi line", which is irrelevant, especially that this editor is readonly so should not mention "auto complete" at all.
interesting, I do not see that. do you have any settings that could be causing that?
It's a vanilla setup on Windows, with Jupyter and Python extension packs, and here are my settings and also I can reproduce in terminal on Windows.
ok so it turns out those are properties set here. and the screen reader is announcing those. - I think that means these messages are expected and as designed. do you agree?
Yes, I do agree. Actually, the information is not completely irrelevant since the use of the / can produce suggestions.
Can we set to none when the editor is readonly? I believe readonly implies auto complete is not possible.
I can't get the screen reader to read "multi-line" in the accessible view. What's the best way to verify this?
I couldn't reproduce that either. Could you pls test this?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I'm not sure I understand what we are trying to reproduce. I believe the only screen reader on windows that identifies multi lines text fields as such is NVDA, and it is announcing that in this case. The autocomplete is no longer present, but that's different from the mmulti line announcement. I hope that helps.
Change:
if (key) { const elements = this.currentSettingsModel.getElementsByName(key); if (elements && elements.length) { <del> // TODO https://github.com/microsoft/vscode/issues/57360 this.refreshTree(); </del> <ins> if (elements.length >= 2) { console.warn('More than one setting with key ' + key + ' found'); } this.refreshSingleElement(elements[0]); </ins> } else { // Refresh requested for a key that we don't know about return;

Discussion:
Regression from I haven't identified when the issue started happening again. Repro steps: to the Settings editor down on a checkbox or edit an inputbox on an unmodified setting, and wait for the setting to become modified, or click another nearby setting. :bug: The Settings editor settings tree jumps.
I noticed the following: Not rendering the Settings indicator labels does not fix the issue After a setting value changes, is called. Then, when is called during , the setting tree elements are all smushed together. That behaviour is even more dramatic when a setting has a multi-line description. calls , which sets the top of the DOM node to an incorrect value. It looks like the value that is used is an estimate. I believe this estimation process is what causes the settings tree elements to shift upwards and smush together.
Note, the jittering is on the right side, not the tree on the left. Regardless, this looks good to me. I could only repro in Stable on checkboxes, other types of settings didn't show the "jump".
Change:
export function registerNotificationCommands(center: INotificationsCenterController, toasts: INotificationsToastController, model: NotificationsModel): void { // Show Notifications Cneter <del> CommandsRegistry.registerCommand(SHOW_NOTIFICATIONS_CENTER, () => { toasts.hide(); center.show(); </del> <ins> KeybindingsRegistry.registerCommandAndKeybindingRule({ id: SHOW_NOTIFICATIONS_CENTER, weight: KeybindingWeight.WorkbenchContrib, when: NotificationsCenterVisibleContext.negate(), primary: KeyChord(KeyMod.CtrlCmd | KeyCode.KeyK, KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.KeyN), handler: () => { toasts.hide(); center.show(); } </ins> }); // Hide Notifications Center

Discussion:
Type: <bFeature Request</bBased on my observation in the Program-L listserv and other blind VSCode users, screen reader users prefer to have a quick way to go to the notification area. I recommend adding the following keybinding by default for convenience. It does not matter whether or not VSCode team uses this suggested keybinding, but it would be greatly appreciated if you could consider the default keybinding for and announce the new binding in the release note to be discoverable. VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-30T05:33:47.972Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
A lot of keybindings are taken already, I could only find they key chord:
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Change:
<meta charset="UTF-8"> <meta http-equiv="Content-Security-Policy" <del> content="default-src 'none'; script-src 'sha256-QA1gXilHYAUFCvp7MpjgcmyBCFzSKV0SpiecMU8aUVc=' 'self'; frame-src 'self'; style-src 'unsafe-inline';"> </del> <ins> content="default-src 'none'; script-src 'sha256-Ne5nVg2ZDLxLh1eqzYd1sGbOz022xlokwv+X6+HR1hw=' 'self'; frame-src 'self'; style-src 'unsafe-inline';"> </ins> <!-- Disable pinch zooming --> <meta name="viewport"

Discussion:
From We should fix block styling in Markdown previews in main as well, from discussing with we want to make the styling consistent across chat, settings UI, and extension webviews
The three greys look different to me. I'm unsure whether those are the colours I should be comparing. !
To verify this you just need to confirm that there is a background for blocks, since it used to just be a brownish foreground color.
Change:
const resource = channel?.log ? channel.file : undefined; LogLevelChannelClient.setLevel(this.mainProcessService.getChannel('logLevel'), logLevel, resource); <del> if (id === sharedLogChannelId || id === userDataSyncLogChannelId) { </del> <ins> if (id === sharedLogChannelId || id === userDataSyncLogChannelId || id === remoteTunnelLogChannelId) { </ins> LogLevelChannelClient.setLevel(this.sharedProcessService.getChannel('logLevel'), logLevel, resource); return true; }

Discussion:
In the shared service, in , I create a logger () and listen to it for log level changes: In the renderer, that logger that log file is registered to a channel with the name When I open the command and pick and change the level, I don't get a change event in the shared service as I would have expected. Shouldn't that work?
Change:
maxStack: number; start: string | null; ignoreCase: boolean; <ins> unicode: boolean; </ins> tokenPostfix: string; tokenizer: { [stateName: string]: IRule[]; };

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Feature request for the Monaco Editor. Create an optional flag for Monaco Monarch language definitions to indicate the usage of unicode-aware regular expressions. An example of one such regular expression is , matching the '' character.
What exactly does not work? Since you can pass in regular expressions directly e.g.
Hi, What's currently not working is the unicode-aware regular expressions supported by ES2015. Even though you're able to write a RegExp including unicode-aware characters (in the format ), and even set the unicode flag for that RegExp, they don't work in Monaco Monarch at the moment. Below is the monaco-language file for ABAP, edited to support the character in identifiers. ! This is how it shows up in the editor: ! That happens precisely because the unicode flag is stripped away by compileRegExp, causing the match to fail for that character: If we change that line to, say it works as expected: ! The proposed solution is a way for the developer to tell Monaco Monarch that, instead of stripping away the unicode flag from all the regular expressions, it should instead add it to all the regular expressions if a flag is set in the language definition, just like it's the current behavior for the option. Another option I've considered was to instead use the unicode flag if, and only if, it is set in the regular expression itself, but from what I could gather, that would force us to compile the RegExp an extra time just for testing the flag, or to parse the RegExp manually. Let me know if you need more information.
:+1: Thank you, this makes good sense!
Change:
'notebook-markdown-min-height': `${this.options.previewNodePadding * 2}px`, 'notebook-markup-font-size': typeof this.options.markupFontSize === 'number' && this.options.markupFontSize > 0 ? `${this.options.markupFontSize}px` : `calc(${this.options.fontSize}px * 1.2)`, 'notebook-cell-output-font-size': `${this.options.fontSize}px`, <ins> 'notebook-cell-output-font-family': this.options.fontFamily, </ins> 'notebook-cell-markup-empty-content': nls.localize('notebook.emptyMarkdownPlaceholder', "Empty markdown cell, double click or press enter to edit."), 'notebook-cell-renderer-not-found-error': nls.localize({ key: 'notebook.error.rendererNotFound',

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.65.0-insider (Universal) Commit: OS Version: Mac OS Monterey 12.2.1 Follow up issue to as this is a degradation in UX compared to the non-Insider version. Any input on that ? Current: ! Expected: Different columns should be aligned !
thank you for the bug report!
Change:
import { IRemoteConsoleLog } from 'vs/base/common/console'; import { Emitter, Event } from 'vs/base/common/event'; import { NodeSocket, WebSocketNodeSocket } from 'vs/base/parts/ipc/node/ipc.net'; <del> import { getResolvedShellEnv } from 'vs/platform/terminal/node/shellEnv'; </del> <ins> import { getResolvedShellEnv } from 'vs/platform/shell/node/shellEnv'; </ins> import { ILogService } from 'vs/platform/log/common/log'; import { IRemoteExtensionHostStartParams } from 'vs/platform/remote/common/remoteAgentConnection'; import { IExtHostReadyMessage, IExtHostSocketMessage, IExtHostReduceGraceTimeMessage } from 'vs/workbench/services/extensions/common/extensionHostProtocol';

Discussion:
Moved in I know there's nothing enforcing this, but the terminal folder should rarely be depended upon outside of debug/tasks. Having in platform/terminal means that platform/request depends on the terminal which creates a weird relationship: platform/request -platform/terminal contrib/terminal -platform/request Terminal only exists in platform so that it can be used in the pty host, I'd prefer to keep it similar to a workbench contrib where nothing else in platform depends on it. If no other folder makes sense I propose creating a as it's a similar theme to what's going on in The original seemed fine but I don't understand the tangle.
Change:
} const { activeChoice } = this._session; <del> if (!activeChoice || !this._choiceCompletionItemProvider) { </del> <ins> if (!activeChoice || !this._choiceCompletions) { this._choiceCompletions?.disable(); </ins> this._currentChoice = undefined; return; }

Discussion:
This problem still occurs even if you disable all extensions. This problem was confirmed in Markdown file. below the snippet (it contains a snippet choice) below the code in Markdown file snippet in Markdown file I expected to see link label suggestion, but it does not display link label suggestion... Included by snippet choice reproduces the issue. It is not displayed even if is pressed. Gif demo: ! VS Code Windows 11
Sorry but I am unaware of link label suggestions. What are those and where do they usually come from?
I'm sorry, I had my own way of saying it. I don't know the correct terminology, but I'll show you an example in action. the following markdown your cursor inside the second ! I haven't been able to find any release notes for this feature, but it's a feature in VS Code and not coming from an Installed extension. This feature doesn't work within certain snippets.
I can reproduce. Looks like the choice suggest provider is staying active despite its placeholder not being active anymore
Using a snippet seems to break label suggestions until the editor is reloaded. Even reopening the file doesn't fix it:
repro steps please
the snippet from the original issue in your global snippets a new markdown file with the contents as in the video, you can get completions until the moment you use the snippet
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Change:
private createWorkspaceTrustIndicator(): SettingIndicator { const workspaceTrustElement = $('span.setting-indicator.setting-item-workspace-trust'); <del> workspaceTrustElement.tabIndex = 0; </del> const workspaceTrustLabel = new SimpleIconLabel(workspaceTrustElement); workspaceTrustLabel.text = '$(warning) ' + localize('workspaceUntrustedLabel', "Setting value not applied");

Discussion:
Change the key event handling so that the user can tab once into the indicators container, and then use left/right arrows to focus on different indicators.
the Settings editor, search on the setting. tab should focus on the first indicator. again should go to the checkbox. -tabbing twice from there should focus the entire setting again. again to the indicator. The left and right arrow keys, along with the home and end keys should allow the user to focus onto the other indicators. indicators container should keep track of the focused indicator. If the second indicator is focused, and the user tabs to the checkbox and back, the second indicator should be the one focused rather than the first one.
Change:
private readonly _dataStore = new DisposableStore(); <ins> private _data: TemplateData | undefined; </ins> public setData(data: TemplateData): void { <ins> this._data = data; </ins> function updateOptions(options: IDiffEditorOptions): IDiffEditorOptions { return { ...options,

Discussion:
Multi diff editor issue while expanding the hidden lines VS Code Version: 1.86 insider OS Version: Windows 11 //cc Steps to Reproduce: the multi diff editor on the hidden lines at the bottom ( the blue line) now it will expand the 10 lines now scrolling top doesn't show me the '5 hidden lines' text until I scroll down and then scroll up again
Change:
import { TerminalEditor } from 'vs/workbench/contrib/terminal/browser/terminalEditor'; import { TerminalEditorInput } from 'vs/workbench/contrib/terminal/browser/terminalEditorInput'; import { SerializedTerminalEditorInput } from 'vs/workbench/contrib/terminal/browser/terminalEditorSerializer'; <del> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; </del> <ins> import { IEditorService, SIDE_GROUP } from 'vs/workbench/services/editor/common/editorService'; </ins> export class TerminalEditorService extends Disposable implements ITerminalEditorService { declare _serviceBrand: undefined;

Discussion:
Repro: terminal move from terminal view to editor the terminal editor to the right side create terminal editor command <img width="1123" alt="Screen Shot 2021-06-16 at 4 35 40 AM" src="https://user-"
One more step needed to repro this - after step 3, focus the left editor.
This works for me now off of main
Original issue still occurring in today's Insiders. !
investigating
Interesting to note - the terminal appears in the blank editor if you: move it to a new group add a terminal editor instance to its group splitting it does not bring it back though unrelated to the move terminal view to editor - can repro by: create terminal in editor area drag and drop it focus anywhere else create terminal in editor area
Removing this line resolves this issue. might cause other problems though, so testing it out
That fix breaks reconnect occasionally
This bug is caused by the terminal instance getting detached from the element when is called again to create another terminal editor. It is clear that we need a conditional within to decide when it's appropriate to . Some things I tried: - check if the is a terminal editor and if not, do not - this fixes the bug, but then that editor does not get re-attached on reload a combo of the above using the for now, the following fixes the bug and does not impact the persistence of the editors: setting within to
I've shared with you offline what I think the right fix is here (removing the pointer to the terminalEditorinput in the old re-used editor pane). As a test, I've verified that even with the SIDE_GROUP fix, you can repro this bug. Repro Steps: 2 side by side untitled editors terminal in panel terminal to editor (will be in the right group) terminal editor to left group focus is in left group terminal editor (will open in right group and left editor will be blank)