jiebi/CodeConvo huggingface dataset:
Change:
width: 1px; } <del> .monaco-editor.vs-dark .lines-content .cigr, </del> <ins> .monaco-editor.vs-dark .lines-content .cigr { background: #404040; } </ins> .monaco-editor.hc-black .lines-content .cigr { <del> background: #353535; </del> <ins> background: #ffffff; </ins> }

Discussion:
Testing on a MacBook Pro Retina display with brightness 2 steps below max while using a power adapter. This is my usual setting a regularly lit environments. In the following themes the indentation guides should be changed to improve their visibility: [x]  Abyss [x]  High Contrast [x]  Monokai In the following themes the indentation guides are subtle and easy to miss. However, changing those is optional. [x]  Dark (and Dark+)
I am using the color from the theme, 100% the same as . owns the Dark and Dark+ themes (including the color):
Assigning to the UX team to decide on changes to the default colors.
Some of the reported themes (Dark, Dark+, High Contrast) are owned by us. Others (Abyss, Monokai) are cloned and packaged along with VS Code. It means indirectly we own them and have to maintain them. So we should provide proper color for indent guides for all these themes. Can you please go through all our default packaged themes and come with a nice indentation guides color ? Note: TM theme setting to use for identation guides is . Also, as mentioned in description, except reported themes others look good to me Abyss Dark Dark+ HighContrast Monokai
Reopening until PR is merged in
Moving this to September milestone, since it is too late to make into August
Change:
} else { let stream: streams.ReadableStreamEvents<Uint8Array> = res; <del> if (res.headers['content-encoding'] === 'gzip') { </del> <ins> // Responses from Electron net module should be treated as response // from browser, which will apply gzip filter and decompress the response // using zlib before passing the result to us. Following step can be bypassed // in this case and proceed further. // Refs https://source.chromium.org/chromium/chromium/src/+/main:net/url_request/url_request_http_job.cc;l=1266-1318 if (!options.isChromiumNetwork && res.headers['content-encoding'] === 'gzip') { </ins> stream = res.pipe(createGunzip()); }

Discussion:
When requests from shared process are redirected to main, the main request service is throwing errors for some valid requests. The same request is working when using browser XHR in shared process. To reproduce: Start VS Code using fresh user data dir and extensions dir Enable this setting - this is an internal developer setting, so you have to set manually in the file Turn on settings sync using your insiders settings sync service (Disable syncing settings) Extensions Syncing fails because of above error cc
What is the exact request URL and headers? We should be able to reproduce in a Electron fiddle maybe.
is an error from the chromium network stack, it happens when the request contains one of the following forbidden headers ;l=22-48
Here is the request info URL: Headers: Payload:
Are we setting the header ? The runtime will add that during payload upload, but if we override it then it will cause the above error.
Yes, we are
BTW we do the same request also in the renderer for querying extensions, so does removing the impacts the request in the renderer that uses XHR ?
Just tried removing the header and I am getting following error
The header will get by the runtime for payload requests, you should be able to confirm after removing the header. So, I don't think it will impact requests from renderer via XHR Hmm, why is zlib module being involved ? Are we using request API by any chance ?
We are not using request. Request service in main extends Node request service and pass electron net request API to Node request service for making request. See here: While handling the response, Node request service is checking for header and using zlib if it is set to . See here: May be main request service shall not use node request service at all?
Possibly an easier repro that was discovered by is calling the command also fails with the same network error. You should be able to do this via an extension
Can we now also make sure to go back to the Electron solution for maybe insiders to validate it works over some time?
Enabled -
Change:
const file = this.extHostFileSystemInfo.extUri.joinPath(outputDir, `${this.namePool++}-${name.replace(/[/:*?"<>|]/g, '')}.log`); const logger = this.loggerService.createLogger(file, { logLevel: 'always', donotRotate: true, donotUseFormatters: true, hidden: true }); const id = await this.proxy.$register(name, file, languageId, extension.identifier.value); <del> return new ExtHostOutputChannel(id, name, logger, this.proxy, extension); </del> <ins> return new ExtHostOutputChannel(id, name, file, logger, this.proxy, extension); </ins> } private async doCreateLogOutputChannel(name: string, logLevel: LogLevel | undefined, extension: IExtensionDescription): Promise<ExtHostLogOutputChannel> {

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/No <!-- 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. --Version: 1.90.0-insider Commit: Date: 2024-05-31T01:05:41.342Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.90.0-insider Chrome/122.0.6261.156 Electron/29.4.0 Safari/537.36 Steps to Reproduce: There is no test-log-channel in the output panel.
Thanks for reporting this I have the exact same issue. In the meantime I have a workaround: I was surprised this does not throw, usually if you create something that was not previously disposed, it will throw an error like "command was already registered" or "notebook controller already exists". I am currently commenting out my line in my extension. It's not ideal though.
PR fixing it
Change:
hover.isLocked = true; return; } <ins> const event = new StandardKeyboardEvent(e); const keybinding = this._keybindingService.resolveKeyboardEvent(event); if (keybinding.getSingleModifierDispatchParts().some(value => !!value) || this._keybindingService.softDispatch(event, event.target)) { return; } </ins> this.hideHover(); }

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/No <!-- 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.70.1 OS Version: Windows_NT x64 10.0. From some versions until now, I noticed that the copy and paste behavior of the TreeView component's markdown tooltips stopped working. Simply when I click on CTRL the tooltip disappears, and does not perform the action. In the GIF below you can also see issue occurring sporadically when hovering over the item. !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.70.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Yes, problem persists in 1.70.2.
does this ring any bells, or should I investigate?
This seems to be a regression. Adding to this iteration, if you have any time to look into this it would be appreciated as I'll be pretty busy this week.
thanks for fix!
Verified on mac - not sure if this was windows specific
The issue was not Windows specific, verifying on mac is good.
Change:
previousOutputParent.classList.toggle('scrollbar-visible', previousOutputParent.scrollHeight > previousOutputParent.clientHeight); previousOutputParent.scrollTop = scrollTop !== undefined ? scrollTop : previousOutputParent.scrollHeight; } else { <ins> const existingContent = outputElement.querySelector(`[output-item-id="${outputInfo.id}"]`) as HTMLElement | null; </ins> let contentParent = existingContent?.parentElement; if (existingContent && contentParent) { existingContent.replaceWith(newContent);

Discussion:
Inconsistent repro, not sure what triggers it yet. <img width="301" alt="image" src=""
this is caused by the first one or two lines of output to be in one output item and the rest in another. In the case above: While the second output keeps streaming in, it is supposed to be replaced each time, but we were looking in the wrong element for the previous output to be replaced. I don't know why the outputs are split like this and is the first time I've ever noticed it happening.
Another progress with simple ASCII output (previous sample was HTML) (install using )
Some other samples, that seems to be flaky Code
verification steps: run the example that Don provided in a notebook cell only one progress bar should appear and refresh
Change:
public static create( resource: vscode.Uri, previewColumn: vscode.ViewColumn, <ins> resourceColumn: vscode.ViewColumn, </ins> locked: boolean, contentProvider: MarkdownContentProvider, previewConfigurations: MarkdownPreviewConfigurationManager,

Discussion:
Issue Type: <bBug</b! When using the Markdown preview, the "Show Source" action should be smart enough to know that the source is open and go to that tab. Same applies to the preview tab, if there is already a preview tab open switch focus there. Otherwise you're in this endless loop of creating duplicate tabs. VS Code version: Code - Insiders 1.35.0-insider (, 2019-05-20T05:15:57.974Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<details<summaryExtensions (30)</summaryExtensionVersion ------ vscode-browser-preview0.5.4 vscode-opennewinstance0.0.6 bracket-pair-colorizer1.0.61 vscode-svgviewer2.0.0 vscode-eslint1.9.0 gitlens9.7.4 vsc-material-theme2.8.2 prettier-vscode1.9.0 azure-virtual-machine-explorer0.0.2 vscode-pull-request-github-insiders1.137.0 vscode-colorize0.8.10 theme-monokai-pro-vscode1.1.13 vscode-azureappservice0.14.0 python2019.4. remote-containers0.53.0 remote-ssh0.37.0 remote-ssh-edit0.37.0 remote-ssh-explorer0.37.0 remote-wsl0.36.0 azure-account0.8.4 azurecli0.4.5 vscode-typescript-tslint-plugin1.0.0 debugger-for-chrome4.11.3 vetur0.21.0 vscode-docker0.6.2 vscode-yaml0.4.0 code-settings-sync3.2.9 ayu0.18.0 WebTemplateStudio-dev-nightly0.0. markdown-all-in-one2.3.1 (17 theme extensions excluded) </details<!-- generated by issue reporter --
I'd like to give this a try
Ok, I could use some help on this issue. I traced the click call to the function , but am not sure if I should be making any changes here since it will very likely affect other functionalities as well.

I also noticed that if I have the file already open in the same split window pane, it will open that instead of creating a new split pane, but it is even when it opens a new pane with a new tab. So I am confused how calling the same function with the same parameter exhibits different behaviors (opening a new pane with a new tab vs opening an already open tab in the same pane). ! Some pointers around this would be very helpful, thanks
sorry for tagging you, not sure if you got a chance to see my previous comment. Can you please help out?
The api you linked to is a good starting point but that is part of core VS Code. You want the caller of that api, which in the case is the markdown extension. How I think this feature should work: the markdown extension, we maintain a . These should track which column created the preview. This is likely already passed in with , we just don't store the resourceColumn anywhere as far as I remember. the is invoked, use the preview's column information to decide which column to show the preview in
Change:
return promise.then(() => assert.deepStrictEqual(order, ['in callback', 'afterCreate', 'cancelled', 'afterCancel', 'finally'])); }); <ins> test('execution order (async with late listener)', async function () { const order: string[] = []; const cancellablePromise = async.createCancelablePromise(async token => { order.push('in callback'); await async.timeout(0); store.add(token.onCancellationRequested(_ => order.push('cancelled'))); cancellablePromise.cancel(); order.push('afterCancel'); }); order.push('afterCreate'); const promise = cancellablePromise .then(undefined, err => null) .then(() => order.push('finally')); return promise.then(() => assert.deepStrictEqual(order, ['in callback', 'afterCreate', 'cancelled', 'afterCancel', 'finally'])); }); </ins> test('get inner result', async function () { const promise = async.createCancelablePromise(token => { return async.timeout(12).then(_ => 1234);

Discussion:
The CancelablePromise disposes its CancellationTokenSource inside a onCancellationRequested listener. That means that any other onCancellationRequested listeners that were after that one won't be called, because the EventEmitter has been disposed. In practice that means that any listener that was after an async step inside the callback function is not called. This caused issues in chat, but the function is used in many places and I think it's likely that some of those are affected. My suggested fix is in but I don't think this is safe to check in at the end of the iteration, so I will wait until December. Looks like you guys have touched this code, lmk what you think: Transferred from a private issue. Original issue discussion below <detailsa question such as "Explain recursion in detail to me" hit cancel Watch the copilot chat log, you will see the request continues and even follow ups are computed even though no tokens are shown to the user. This is a bit weird. Order of events is this: Call to get a token Attach some listeners to it, some after async steps Cancel the cancellable promise The cancellable promise disposes the token source The cancellation listeners that were after an async step don't get called because the event emitter is disposed before it can call them The last step is suspicious but I guess that's how EventEmitter works? And the cancellable promise seems like it's doing the right thing. I need to check that the same thing happens with a normal CancellationTokenSource because the logic is the same. Still not sure of the right solution. Essentially has a listener which disposes the . Listeners that were later than that first listener will not be called because the event emitter will be disposed in the middle of emitting, which is by design for EventEmitter. But there is no way to guarantee that all listeners have been called before disposing, besides something like which doesn't seem nice </details
That's a good find and something we shouldn't be doing. Looks like a regression from
Disposables and leaks are tricky... Thanks for finding this! Here is the PR that introduced this: Ironic that I introduced leaks with the goal to reduce leaks...
Change:
.test-output-peek-message-container .preview-text { padding: 8px 12px 8px 20px; <del> height: calc(100% - 16px); </del> <ins> line-height: normal; white-space: normal; </ins> } .test-output-peek-message-container .preview-text p:first-child {

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/No <!-- 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. --Version: 1.92.0 (Universal) Commit: Date: 2024-07-31T23:26:45.634Z Electron: 30.1.2 ElectronBuildId: Chromium: 124.0.6367.243 20.14.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.5.0 Steps to Reproduce: this snippet in the test-provider-sample project running the test, both the editor peek view and test result view do not render correctly. !
Sorry, this got lost in the shuffle of the call stack UI :(
Verification steps: out the of vscode-extension-samples into and F5 the "easy math" test in Open the error messages for all the tests that fail and verify they're all visible
Change:
this._processManager.relaunch(this._shellLaunchConfig, this._cols, this._rows, this._accessibilityService.isScreenReaderOptimized(), reset); <del> this._xtermTypeAhead?.reset(this._processManager); </del> <ins> this._xtermTypeAhead?.reset(); </ins> } @debounce(1000)

Discussion:
This started yesterday. I am on Remote WSL. !
Setting to -1 works as a temporary workaround.
any ideas? Could adding the pty host process in remote have caused this somehow? Not sure what other changes could have caused it.
I can't look into this for a few hours, I'm guessing something that it expected was synchronous is now asynchronous.
I wonder... when you hit ENTER, does it run correctly? I wonder if this is more of a cosmetic issue than impacting what is actually run.
Yes it's cosmetic only
Typeahead hasn't changed in several weeks, so I'm guessing pty in the remote is it. I was able to reproduce this in Insiders, but annoyingly could not do so in a dev setup from OSS -- anything that was fixed since the last Insiders? Would any of the pty process work cause to no longer be synchronous? That would be a prime suspect. It seems to only happen when typing somewhat rapidly (i.e. when there's multiple predictions written and one is validated) so the is probably incorrect in these scenarios. I can try to debug Insiders off sourcemaps if we can't get an OSS repro...
I don't repro this on Insiders today. Let me know if you do, or if it comes back
I could reproduce it the other day in WSL but not out of sources, but now can't . Good news I guess, do you see it anymore?
No more repro!
Change:
const historyService = accessor.get(IInteractiveHistoryService); const editorControl = editorService.activeEditorPane?.getControl() as { notebookEditor: NotebookEditorWidget | undefined; codeEditor: CodeEditorWidget } | undefined; if (editorControl && editorControl.notebookEditor && editorControl.codeEditor) { const notebookDocument = editorControl.notebookEditor.textModel; const textModel = editorControl.codeEditor.getModel();

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. --four cells from the interactive window input box, e.g. , , , reexecute multiple commands from earlier in your history, e.g. and use via the up arrow executing an entry from earlier in the history e.g. , scroll position resets to the bottom of the history, and you have to start over and scroll up from the most recent command (4 -3 - 2 -1). This can be frustrating for users who are trying to reexecute multiple commands. Note also that the original interactive window used to preserve your scroll history in the interactive window so that you didn't have to scroll back up through the entire history, and users have complained about this behavior change:
The expectation is that the interactive window input behaves just like a REPL. would address this. Per discussion with we should have shared logic for handing history traversal.
Any news on that? I agree with the PR that the current behavior is quite frustrating and deserves further attention.
Yes this is one of my main frustrations with the IW still. At minimum I just want the up arrow to go to the last executed code, not have cycle through like 20 cells every time I need to re-run something. And it did used to work this way ~1.5 yrs ago.
Change:
}), this.editorService.openEditors(readmes.filter(readme => !isMarkDown(readme)).map(readme => ({ resource: readme }))), ]); <ins> } else { // If no readme is found, default to showing the welcome page. await this.openGettingStarted(); </ins> } } }

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.77.3 arm64 OS Version: macOS 13.3.1 Steps to Reproduce: user preference, set an empty workbench (or a new window), or a folder without readme. Expected: it should fallback to "welcomePage" and open the welcome page. Actual: no startup editor opened.
Either the description of the option is wrong or the above code needs an block to run when no readmes were found.