text:
Conditional types shortcircuit incorrectly when using mapped types in the condition

TypeScript Version:  3.0.0-dev.20180712

Search Terms: conditional Types, shortcircuit, shortcircuiting
Code
type StripOptionalFromProperties<T> = { [K in keyof T]-?: T[K] };
type MapPropsToString<T> = { [K in keyof T]: string };

type Foo<T> = T extends { val: string } ? true : false;

type FooWithMapped<T> = StripOptionalFromProperties<T> extends { val: string } ? true : false;
type FooWithMapped2<T> = MapPropsToString<T> extends { val: string } ? true : false;

type Bar = { val?: string };
type Bar2 = { val: number };

type MappedBar = StripOptionalFromProperties<Bar>; // { val: string }
type MappedBar2 = MapPropsToString<Bar2>; // { val: string }

type Result1 = Foo<MappedBar> // true - correct
type Result2 = Foo<MappedBar2> // true - correct

type Result3 = FooWithMapped<Bar> // false - wrong!
type Result4 = FooWithMapped2<Bar2> // false - wrong!

Expected behavior:
All ResultX types should be true
Actual behavior:
Result3 and Result4 are false
When checking the type of FooWithMapped or FooWithMapped2 it shortcurcuits both to false:

Playground Link:
https://goo.gl/hgx57H

We probably should defer the evaluation if the checkType is a mapped type whose type parameter is itself a instantiable...

These are now true as expected

authors: Nimelrian RyanCavanaugh mhegazy


text:
Shouldn't be able to access bogus properties on globalThis even under lax settings

We determined it should be permissible to access bogus members on this outside of noImplicitAny. However, I would assert that this is for backward-compatibility reasons.
Something that I just noticed is that when noImplicitAny is off, we allow you to access any property on globalThis.
globalThis.wargarbl;
globalThis.dsfargeg;

Both of these should be errors in TypeScript regardless of strictness settings.
@sandersn @RyanCavanaugh

No. globalThis should behave the same as this, because people will want to do (1) unsafe things or (2) counter-factual things with it, neither of which the compiler understands. This should be allowed with noImplicitAny off.
In other words, as soon as this ships in browsers, people will want to use it in place of self, this, window, etc since it's a guaranteed way to access the global object.
eg
// counter-factual
if (globalThis.blah) {
    export(globalThis.blah, true)
}
// unsafe
init(globalThis.trustMeItsThere, global.somebodyElsePutItThere);

Is there any new code that uses globalThis that's guiding our decision? Would the behavior suggested in this issue keep the design space open such that we could revert to the current behavior?

No, old code based on window and this, which I think that authors will think can be find/replaced with globalThis.
Being stricter would keep the design space open, but at the cost of preventing widespread usage as in (1). The question is how breaky any future improvements to knowledge about global usage would be to globalThis. I think future improvements will be much like top-level this: typeof globalThis, in that it only finds good bugs.

source: gharchive/issue

authors: DanielRosenwasser sandersn

repo: Microsoft/TypeScript

license_type: permissive

license_source: github-api


text:
Object spreading a Record<string, any> gives wrong type

TypeScript Version:  3.4.0-dev.20190322
Search Terms:
object spread, Record, index signature
Code
const fn = (a: Record<string, any>) => {
  const obj = { p: 1, ...a };

  obj.foo; // ts-error: Property 'foo' does not exist on type '{ p: number; }'
};

const fn2 = (a: { [_: string]: any }) => {
  const obj = { p: 1, ...a };

  obj.foo; // ts-error: Property 'foo' does not exist on type '{ p: number; }'
};

Expected behavior:
obj has type {p: number} & Record<string, any>.
This matches how typescript handles Object.assign.
Actual behavior:
Type of object-spreaded thing is ignored.
Playground Link:
link
Related Issues:

This is a duplicate of #27273

authors: ajafff golopot


text:
Ignore missing vendor definitions

Typescript is amazing. But when it comes to work with vendor libraries written in pure javascript it sucks. It sucks because afaik you have only one option: create a definition file for these vendors. And this is a bad option. Typescript says that "creating defintion files is easy". Yes it is, but it is only on surface. Why it is not easy:

you need to cover all api of the vendor library, otherwise its meaningless. But its complicated and not always possible because of related issues
vendor should have a good api documentation for all its methods, which is not always true, and when its not true you either create definitions with half of the avalible methods, either your definition file will be confusing. creating definition files from vendor sources almost impossible
it takes lot of my time that I dont have, and my product dont have it as well

And Dont tell me about DefinitelyTyped.org because you never find  "high quality" definition files from there when you want. in all other times you'll find that DefinitelyTyped definitions are outdated - vendor api is changed and you cant use it with outdated definition files.
Some of my friends (very good and expirienced developers) who tried to use typescript stopped to use it only because of these issues. People dont have time to create and mainitan defintion files.
This is really anonying when you are building your project.
When angular2 will come stable, millions of people gonna use it, but how do they react that they cant use millions of vendor libraries and plugins that exist. This is really anonying when you are building your project.
Personally Im using typescript with nodejs and lot of node modules Im using also needs in defintion files.
I think one of the solution to this problem is to add a compiler feature of ignoring missing vendor definitions. Probably it can be done with configuration files. Something like this:
{
     "ignoreDefinitions": [ "somelib" ]
}

import * as somelib from 'somelib';
somelib.someOfItsMethod(); // here typescript will not give any errors, just will treat that somelib is *any* and contains *anies*

Yes, its not typesafe, but it will make Typescript more user-friendly, and make it more as an amazing addition to javascript, instead of being something isolated with its own annoing rules and restrictions of using (like dart and coffescripts are. for the same reason their concept isnt as best and good-fit for community and people, as typescript is)
If this solution is not acceptable, then Typescript team should figure out something else, better. The goal is to make typescript more user-friendly, product-friendly and integrate typescript into community of javascript world.

This is a community problem and not a technical problem. I think a better way to tackle this problem is to encourage people to submit declarations not to TSD, but to repo owners directly. I have also seen many repos being outdated and not even being present at TSD. TSD is not a good option in my mind. So current strategy of encouraging people to use TSD is not an effective strategy.
Also submitting PR:s to JS repo owners will effectively encourage people to write in TS, because I think many people will like me discover it being much more powerful than JS.

You can write "vendor definition" this way:
declare var $: any;
declare var ko: any;
declare var somelib: any;
// etc...

Looks like the original issue has been answered. please reactivate if you are running into other issues.

@mhegazy,
This problem has not been solved, IMHO. I'm working on a new TypeScript project, and already there are 13 modules that do not have definitions available.
This means that I have to maintain a definitions file (I call it typings.d.ts) with temporary declarations like this:
declare module "gulp-print" {
    var gulpPrint: any;
    export = gulpPrint;
}

This is not elegant, and this is not a community problem as previously suggested – there will always be cases where definitions are not available, and while I would like to write some and contribute back to the community, this is a low-priority task and I'm unlikely to find the time to write 13 high-quality definitions (not to mention the maintenance).
Because of this, I would really appreciate a mechanism for temporarily ignoring Cannot find module 'x' errors.
Here are some of the options:

import foo: any from "foo"; – the method mentioned by yourself in #2709. One downside, as mentioned by another user, is that when type definitions become available for module "foo", you will have to update your code (most-likely in multiple places).
A compiler option to implicitly assign type any to modules lacking definitions, as suggested by @dfaivre, also in #2709. When definitions become available, they are used without requiring any changes to the code.
A compiler option to explicitly list modules to temporarily ignore, as suggested by the OP. When definitions become available, you will need to update tsconfig.json (or the arguments to tsc).

Option 2 is probably ideal, but I might be missing something.
Please consider re-opening this issue (or pointing me to an existing, open issue).
Thanks. =)

option 1 is covered by #2709. option 3 is similar, IMO, to declare module "..." { export = any }, except that it is in code instead of configuration. for option 2, suppressing the error generally would not be a good idea, as you are throwing the baby with the bath water, and ignoring all errors because of handful of missing modules.

Hmm, you're right about option 2.
I don't like option 1 because it means that a bunch of files have to be updated when definitions become available.
WRT option 3, has something like this been considered? It seems a bit more elegant than this type of thing (which I am currently using).

Tried TypeScript for the first time tonight. Had some code switched over and webpack builds setup.
Really loved the idea of typescript and being able to incrementally add type safety to my code.
It's not a necessity to me. Just a "nice thing" at this point.
But I got stopped dead in the tracks due to third party plugins. While stuff in DefinitelyTyped worked like a charm, the difficulty setting up custom typings and why you can't just ignore non-typed plugins takes the value away.
As for custom typings and jQuery extensions, none of the solutions I researched via Google worked. The time I'd have to invest isn't worth what I'd get out of it at this point.

why you can't just ignore non-typed plugins takes the value away.

you do not have to type things unless you want to.. not sure what is the issue you are running into.

As for custom typings and jQuery extensions, none of the solutions I researched via Google worked. The time I'd have to invest isn't worth what I'd get out of it at this point.

again, do not know what solutions you tried, and what worked/did not work for you. please consider filing a new issue, and giving us some context on what is not working.

I'm trying this from a js lib:
import MirageServer, { Factory } from 'mirage-server';
How do I defeat this error:
./src/index.tsx
(10,39): error TS7016: Could not find a declaration file for module 'mirage-server'. '/Users/nikos/WebstormProjects/client/node_modules/mirage-server/lib/index.js' implicitly has an 'any' type.
Try npm install @types/mirage-server if it exists or add a new declaration (.d.ts) file containing declare module 'mirage-server';
the types don't exist btw

authors: QuantumInformation glen-84 mhegazy pleerock tinganho tony wgebczyk


text:
Fix formatting of parameter list of a multiple-line call expression

Fixes #14675

This works great, thank you!

One additional (somewhat related, but I understand this is PropertyAccessExpression vs ElementAccessExpression, not about CallExpression) question, shouldn't the following be formatted the same way?
Promise
['then'](
  cb
);

Promise
['then'](
  cb,
);

Yes that does make sense, I'll try to cover this case later. Thanks for pointing out!

Sorry to bother you, but I think this is kind of duplicated work of #13574?

@SaschaNaz  Hmm I was not aware of your PR. I'll take a look and if it covers my fix I'll close this. Thanks.

Is this or #13574 going to be merged some time?

source: gharchive/pull-request

authors: SaschaNaz magnushiie zhengbli


text:
Instantiate this-type in super property access

Fixes #7728.
Also improves the baseline of superPropertyAccessNoError to no longer have errors (it used accessors without specifying --target es5.)

:+1:


text:
Placeholder update during git checkout takes a long time

[2019-02-20 21:29:15 +02:00] ClearNegativePathCache_ClearedCache {"Area":"GitIndexProjection","Message":"ClearNegativePathCache: Cleared negative path cache","totalEntryCount":0,"negativePathCacheUpdatedForGitCount":0,"clearCacheResult.Result":"GVFS.Virtualization.FileSystem.FileSystemResult","clearCacheResult.RawResult":1}
[2019-02-20 21:29:22 +02:00] UpdatePlaceholders (Start) {"File placeholder count":117135,"Folder placeholders count":29978}
[2019-02-20 21:29:25 +02:00] Warning {"WarningMessage":"WaitToAcquireGVFSLock: BackgroundFileSystemTaskRunner unable to acquire lock, retrying"}
[2019-02-20 21:29:26 +02:00] UpdatePlaceholders (Stop) {"DurationMs":4103}

Loading PlaceholderListDatabase took 7s, updating placeholders took another 4s. This is just one sample, but this behavior is reproducable with this amount of hydrated files.

@jrbriggs are you guys seeing any such behavior on your side, when the number of placeholders is large? Or is that not a concern for your use cases?

We haven't seen this perf problem yet @turbonaitis, but we have some suspicions about what might cause this, and it will likely apply to our large Mac repos too.

Related: #873

Not sure - #873 mostly talks about the placeholder files themselves, if I'm reading it correctly, while in this case the bottleneck seems to be more related to the implementation of PlaceholderListDatabase. I'm working on a PR to address this, hope to submit in the next couple of days (but essentially I'm switching from text format to binary format for PlaceholderListDatabase). We can discuss the solution, once the code is there.

Also, it would seem to me, that performance should be just as bad on Windows, as the code is shared.

Closed with #1140

authors: jrbriggs turbonaitis

repo: Microsoft/VFSForGit

license: MIT


text:
No symlink from python to python3

This bug-tracker is monitored by developers and other technical types.  We like detail!  So please use this form and tell us, concisely but precisely, what's up.  Please fill out ALL THE FIELDS!
If you have a feature request, please post to the UserVoice.  If you're reporting a BSOD, don't post here!  Instead, e-mail "secure@microsoft.com", and if possible attach the minidump from "C:\Windows\minidump".

Your Windows build number:  (Type ver at a Windows Command Prompt)
Microsoft Windows [Version 10.0.15063]

What you're doing and what's happening:  (Copy&paste specific commands and their output, or include screen shots)

After the Creators update, there is no longer a symlink from python to either python2 or python3.
On other Ubuntu 16.04 systems this is the case but not in WSL so user has to run sudo ln -s /usr/bin/python3 /usr/bin/python manually.
See https://www.python.org/dev/peps/pep-0394/#recommendation

What's wrong / what should be happening instead:

Expected python to be a symlink to python3 and it is not so python command fils.

Strace of the failing command, if applicable:  (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)

See our contributing instructions for assistance.

Cannot reproduce here. Was this an in-place upgrade from 14.04? Maybe something went wrong in that process?
Try a remove/replace of Bash on Windows as described here: https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/
tbehrens@Meep:~$ which python /usr/bin/python tbehrens@Meep:~$ ls -l /usr/bin/python lrwxrwxrwx 1 root root 9 Dec  9  2015 /usr/bin/python -> python2.7

I have the same issue here since Creators Update. I did not do an in-place upgrade, but rather
lxrun /uninstall followed by lxrun /install (Note: No /uninstall /full, since I followed some instructions where this was not included, and everything else seems to work.)

@yorickdowne This was a fresh Windows VM with build 10.0.15063.
Only Python 3 is installed. Python 2 is not available.

Interesting. The issue then is that Python 2.7 is missing, and with it the symlink.
What do you think is different from installations where this is happening, and installations where Python 2.7 comes in correctly?

Has Python 2 been removed from Bash on Windows after the Creators update?

@derekbekoe -- it looks like Canonical has removed Python 2.7 from their default cloud image, which is what WSL uses, as of Ubuntu 16.04.  If you want it, you can get it by doing sudo apt install python2.7.
The reason that Python 3 is included by default is not because developers might use it.  It's included because some of Ubuntu's own core utilities require it.  The only included languages are ones that need to be there for the image to work.  (Python 2 was included in Ubuntu 14.04's cloud image, which is what Anniversary used, because some of Ubuntu's core tools still required it.)  I believe the idea is, you start off with a small initial download that's just enough to run apt and raw shell scripts; then you use apt to install whatever tools and languages you need.

@aseering - I see the point you are trying to make but I think the missing symlink MUST be created on the base install for those that have no intention of installing legacy python.  If you try 'sudo apt install python3' you get told that there is nothing to do (assuming your system is up to date).  So to actually get a configuration where only python3 is on the system you need to manually create this symlink.  Given the soon to be out of support status of legacy python (https://pythonclock.org/) I don't think that people doing a fresh install should have to know something as arcane as establishing the symlink before they can use python (or more pointedly be encouraged to install versions of python prior to version 3 unless there is a very good reason for it).
I am not going to try uninstalling python3 and re-installing it to see if that establishes the link as that will more than likely bork the subsystem given that so many Ubuntu and other tools rely on it (with my luck it would be apt-get).
I'm good now that I have created the symlink but I do think it should be there by default for the reasons above.

Just a quick follow-up on this.  The symlink alone will not give a fully usable python3 configuration.  It will be necessary to do 'sudo apt install python3-pip' before you can really get going.
I don't think that pip3 should be installed by default as it brings down another 200MB or so of packages (pretty much the whole g++ toolchain).  Once you realise it is not there, the remedy is pretty straightforward and follows standard python3 install practice for pip3.

@kaybee335 -- I see where you're coming from, but I think it's not so clear-cut:
According to Python's PEP-394, python should not refer to Python 3.  For now, it should only refer only to Python 2.  According to that PEP, unless I'm mis-reading it?, developers who need Python are expected to always explicitly refer to the Python binary as python3, even with new Linux distributions.  (The PEP does acknowledge that some Linux distributions, notably Arch, have nonstandard behavior here.)  This is definitely annoying for Python 3.  But, as discussed on the PEP, there's a feeling that it is necessary.
The Ubuntu Python 3 Wiki page states that python will never refer to Python 3 by default as long as PEP-394 stands.
WSL's stated objective is not to provide you with your favorite Python dev environment.  It is to provide you with Ubuntu 16.04.  And it sounds to me like it's doing just that :-)
You can certainly continue to advocate here.  But my personal opinion (not that my personal opinion matters; I'm not a WSL engineer) is that WSL should follow upstream as much as possible; it should not diverge and set a whole new set of standards.  Here are some ways that you could get python to refer to Python 3 without forcing WSL to break with upstream:

Bring up you concerns with the Python community.  Get them to decide that Python 3 is mature enough that they can update PEP-394 to permit having python refer to the Python 3 binary.  Then get Ubuntu to update their packages to reflect the new standard.  WSL will then automatically pick up Ubuntu's changes.
Lobby WSL to add support for Arch Linux.  Arch Linux has chosen to break with PEP-394 and to expose Python 3 as python.  WSL initially only supported Ubuntu 16.04, but these days it also officially offers CentOS and a couple flavors of SuSE through the Windows Store.  Arch support would be tricky for technical reasons (because its rolling releases often start depending on brand-new kernel features before WSL has had a chance to implement them), but IMO it's a very reasonable ask.

@aseering - Nope, I did not realise that what I was suggesting was in violation of a PEP.  Now that I have been made aware of that I completely agree that the symlink should NOT be there. Using python3 works as it should. I am just getting used to working in environments where this mapping is automatically made (for example conda environments).
The good news is that my WSL is python3 only as I desired and functioning well enough that I could install anaconda using the linux install procedure.  Now I can set up python environments with whatever version of python I so desire while leaving the base WSL python at whatever is currently being distributed from the base repositories.
I have what I am looking for so I am a happy camper.  The support for USB-serial that was added as well means that I can do all my micropython development under WSL.  All tested and working, it's pretty amazing how good WSL is now.

WSL's stated objective is not to provide any particular Python dev environment. It is to provide Ubuntu 16.04. And it sounds to me like it's doing just that :-)

This one got lost in the noise since last spring I guess. The kernel (WSL or Real Linux) doesn't know python3 from Perl.

This one got lost in the noise since last spring I guess. The kernel (WSL or Real Linux) doesn't know python3 from Perl.

Let's not go there... Although I did spend a couple of years programming in APL which made moving to perl seem like nirvana!

authors: Boddlnagg aseering derekbekoe kaybee335 therealkenc yorickdowne

repo: Microsoft/WSL


text:
Unable to get DBus System bus connection: Failed to connect to socket: System_bus_socket missing

My Windows Build Version: Microsoft Windows [Version 10.0.17134.320]
My Linux Version: Ubuntu 18.04.1 LTS (Bionic Beaver)
My Kernel Version: 4.4.0-17134-Microsoft
I wanted to be able to connect to Xen Server or other virtualization servers via Libvirt and Libvirt requires having a daemon running in order to use Libvirt API. The problem with that is the D-Bus socket is being missing on WSL.

To reproduce the steps:
sudo apt-get update
sudo apt-get install libvirt-daemon
sudo libvirtd
There seems to be a lack of support for D-bus for WSL, this is preventing me from porting my workspace on Linux to Windows. My intention isn't to run any sort of virtualization on this library, but to use it to connect to existing virtualization server external to my machine and to migrate any settings/configurations on my machine for virtualization over to those servers.

#1579 (message)

The problem with that is the D-Bus socket is being missing on WSL.

That socket isn't part of WSL (or Linux™). It's part of freedesktop.org.

authors: BlackCentipede therealkenc


text:
NSCompoundPredicate.ArchiveAndUnarchiveObject fails on OSX

[ RUN      ] NSCompoundPredicate.ArchiveAndUnarchiveObject
unknown file: Failure
Unknown C++ exception thrown in the test body.
[  FAILED  ] NSCompoundPredicate.ArchiveAndUnarchiveObject (1 ms)

https://github.com/Microsoft/WinObjC/issues/746 has a similar issue re: archiving/unarchiving

repo: Microsoft/WinObjC


text:
Lost ability to build store package after addintion SDKReference

I add two SDKReference to my project:
<SDKReference Include="WindowsDesktop, Version=10.0.10240.0">
<Name>Windows Desktop Extensions for the UWP</Name>
</SDKReference>
<SDKReference Include="WindowsMobile, Version=10.0.10240.0">
    <Name>Windows Mobile Extensions for the UWP</Name>
</SDKReference>
You can find same references in some samples for example in LockScreenApps.csproj
After that, I lost ability to build store package. I got next error message when trying to build package to upload to the store:
LOGGERBASEDEXECTASK : ILC error ILC1004: Directory 'C:\Program Files (x86)\Windows Kits\10\References\Windows.UI.Xaml.HostingHostingContract\1.0.0.0' passed to argument 'externalReferencePath' does not exist.
And actually this dir really does not exist. But exist another one:
Windows.UI.Xaml.Hosting.HostingContract  - exist in my system
Windows.UI.Xaml.HostingHostingContract   - VS2015 try to find
The difference that VS2015 try find HostingHostingContrac without dot inside:
HostingHostingContrac
Hosting.HostingContract

This is not a problem with the sample, please follow up with this known issue:
https://social.msdn.microsoft.com/Forums/en-US/2887e169-348d-4d97-a359-aee413b5fa26/rtm-known-issue-release-configuration-fails-to-build-on-using-desktop-and-mobile-extension-sdks-in?forum=Win10SDKToolsIssues

repo: Microsoft/Windows-universal-samples

license: mit

license_source: bigquery


text:
TextBox ignores Foreground color when focused

Whenever we focused TextBox to start writing the Foreground color changes from the one we defined to black. We found no way to change it even when editing it's XAML definition.

By XAML definition do you mean it's style template? You can learn more about that here. Note that Blend is used in that post, but you can do the same in Visual Studio.

Also don't forget that even if you set specific values for the foreground color in the template as an override, you'll need to set it in all the visual states as well. Probably those are the things that you haven't changed yet.

Yes, sorry! I meant the style template! I will try that again and let you know. Thanks!

authors: mjracca robmikh tomzorz

repo: Microsoft/WindowsUIDevLabs


text:
Adding ApiVersioning causes RouteData to be cleared in HttpContext's IRoutingFeature

Bug occured after the migration to .NET Core 2.0 / ASP .NET Core 2.0.
Adding ApiVersioning with the method
 services.AddApiVersioning(o =>
            {
                o.AssumeDefaultVersionWhenUnspecified = true;
                o.DefaultApiVersion = new ApiVersion(1, 0);
            });

causes RouteData to be removed from HttpContext's IRoutingFeature (taken by HttpContext.GetRouteData())
The RouteData still exists in ControllerContext/ActionContext though.
Reproduction:
 public class Startup
{
	public Startup(IHostingEnvironment env)
	{
		var builder = new ConfigurationBuilder()
			.AddEnvironmentVariables();
		Configuration = builder.Build();
	}

	public IConfigurationRoot Configuration { get; }

	public void ConfigureServices(IServiceCollection services)
	{
		services.AddMvc();

		services.AddApiVersioning(o =>
		{
			o.AssumeDefaultVersionWhenUnspecified = true;
			o.DefaultApiVersion = new ApiVersion(1, 0);
		});
	}

	public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
	{
		app.UseMvc();
	}
}

public class Program
{
	public static void Main(string[] args)
	{
		BuildWebHost(args).Run();
	}

	public static IWebHost BuildWebHost(string[] args) =>
		WebHost.CreateDefaultBuilder(args)
			.UseStartup<Startup>()
			.Build();
}

public class ValuesController : Controller
{
	[HttpGet("/test/{MyValue:int}")]
	public string Get()
	{
		// equals to this.HttpContext.Features.Get<IRoutingFeature>().RouteData;
		var fromHttp = this.HttpContext.GetRouteData();
		var fromController = this.ControllerContext.RouteData;

		if (fromHttp.Values.Count != fromController.Values.Count)
		{
			throw new Exception("Different RouteData values when taken from HttpContext and ActionContext.");
		}

		return "VALUE";
	}
}

Web Application: netcoreapp2.0
Microsoft.AspNetCore.Mvc.Versioning: 2.0.0-preview2-final
Microsoft.AspNetCore: 2.0.0
Microsoft.AspNetCore.Mvc: 2.0.0
Operating system: Windows 10 Professional 15063.540
IDE: Visual Studio Professional 2017 15.3.2

This is an interesting find, but it is a bug. The explanation for why this happens is a bit long, but it occurs during the application of the versioning policy. The original route data is provided to the action context, which eventually makes it's way to the controller context, but the route data is not restored on the route context. The route context provides the route data for the IRoutingFeature. That's why they don't match.
I've located the issue and I should have the fix out soon.

authors: commonsensesoftware maciejjarzynski

repo: Microsoft/aspnet-api-versioning


text:
Adding a direct route doesn't work

Hey,
I'm manually mapping a single route (which does't work) + using attribute routing (which does work).
For a single controller i'm calling the following:
  config.Routes.Add(
                action,
                new HttpRoute(
                    $"api/helloworld/sayhello",
                    new HttpRouteValueDictionary { { "controller", "helloworld" }, { "action", "sayhello" } }));

I then use
   config.AddApiVersioning(
                    o =>
                    {
                        o.Conventions.Controller<HelloWorldController>().IsApiVersionNeutral();
                    });

However i get

If i supply an api version i get

All routes that use attribute routing work fine i'ts just the manually added route. Is this supported?

Yes - this is supported.
First, I'll say that I would avoid mixing direct routing (aka attribute routing) and convention-based routing. While it's a supported scenario, it's difficult to reason about. You definitely should not mix styles for a logical API controller (e.g. "HelloWorld") or you could hit an unsupported scenario due to the limitations in Web API's routing.
You didn't provide your controller description, but I assume it's something like:
public class HelloWorldController : ApiController
{
    [HttpGet]
    public IHttpActionResult SayHello() => Ok("Hello world!");
}

You also didn't say what the route was that you requested, but I assume that it was probably:
http://localhost/api/helloworld/sayhello
This would not work because you have not specified an API version. A version-neutral controller means that it accepts any API version, including none at all. This often trips developers up. I document it as opting out of API versioning, but that is a misnomer. I use that language because it tends to be the easiest to understand, but it's not entirely accurate. API versioning requires and enforces that all APIs have an API version. A version-neutral controller just means it doesn't care which version you give it.
To make this request work without specifying any API version, you must also configure options.AssumeDefaultVersionWhenUnspecified = true. Use caution when configuring this option as it may have other unintended side effects. This option was meant to support legacy APIs that are grandfathered into versioning, but some developers use it for other purposes.
If you don't want to allow requests without an API version, then all you need to do is add an API version to your request - any API version. The following will work as currently configured:
http://localhost/api/helloworld/sayhello?api-version=1.0
I hope that helps.

Were you ever able to get things working?

Seems like you found a solution. Feel free to re-open this or open a new issue if you're still stuck. Thanks.

authors: Steveiwonder commonsensesoftware


text:
Add new runtime WildFly 14 for Linux Web App

Hold this till the service is ready then we could test it.

Codecov Report

Merging #471 into develop will decrease coverage by 0.03%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##           develop     #471      +/-   ##
===========================================
- Coverage    45.33%   45.29%   -0.04%
===========================================
  Files           68       68
  Lines         2380     2382       +2
  Branches       268      268
===========================================
  Hits          1079     1079
- Misses        1235     1237       +2
  Partials        66       66

Impacted Files
Coverage Δ

...ure/maven/webapp/parser/V1ConfigurationParser.java
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6c56eae...f804969. Read the comment docs.

authors: SummerSun codecov-io

repo: Microsoft/azure-maven-plugins


text:
task.setvariable does an implied create, is there a task.deletevariable to allow for explicit variable removal

I am currently seeing an issue where a variable is created in a called template, persists into the calling of a subsequent instance of the same template. It would be nice if I could explicitly delete a variable upon exit of the template. Is this possible? I have tried deleting the variable from within Powershell however that doesn't seem to delete the variable in the next invocation of a following Powershell task.

I believe can just call setvariable again and set the variable to an empty string (it works like environment variables).

I'm going to close, just let me know if you'd like me to reopen.

authors: damccorm gtalton

repo: Microsoft/azure-pipelines-tasks


text:
Make botadapter have single connectorclient for perf reasons

Remove lazy static HttpClient, as it is not sufficient for high perf scenarios

@tomlm any updates

Done.

authors: tomlm vishwacsena yochay

repo: Microsoft/botbuilder-dotnet


text:
Update the oracles to match LUIS.

Add roles to testing.
Revert node-only change that caused passing through raw resolutions.
In particular for email instead of email:["chrimc@hotmail.com"] the change
would cause email: [{score:0.9, value:"chrimc@hotmail.com"].
Testing
This added roles everywhere to the models and tests.

Pull Request Test Coverage Report for Build #2243

11 of 11 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 85.671%

Totals

Change from base Build #2236:
-0.02%

Covered Lines:
3262

Relevant Lines:
3670

💛  - Coveralls

repo: Microsoft/botbuilder-js


text:
"Dispatch add" command containing a typo gets no error message.

The command:
dispatch add type luis -name v-brhale-luisapp -id 046b01bd-1de4-4a14-a0a4-0d828c749755
The error in the above command: "type" parameter is missing the hyphen ("-").
Actual behavior:
Displayed no message, returned to the command prompt.
Expected behavior:
An error message would be displayed, like "Argument 'type' not recognized."

Fixed!

authors: BruceHaley tsuwandy

repo: Microsoft/botbuilder-tools


text:
#40 Feature to add virtual network to Terraform template for shared services

PR for Issue: https://github.com/Microsoft/entref-appservice-containers/issues/40
As an IT admin or developer, I can now provision a virtual network as a resource in the shared/core services, so that I can provision additional resources that require an existing virtual network.
This PR is dependent on the base test framework in #45 (assert.sh) as it adds unit tests to test virtual network and subnet created using the template.

@manojvazirani  Please rebase off the new folder structure branch erisch/features/contrib-guidelines and submit a new commit to this PR.

@erikschlegel @code4clouds: Will close this PR and create a new PR for vnet with the new folder structure. Merging this PR with the new folder structure under erisch/features/contrib-guidelines is more complicated than starting from scratch.

authors: erikschlegel manojvazirani

repo: Microsoft/cobalt


text:
First opening of error/warning widget causes uncaught JS error "Cannot read property 'heightInLines' of null

monaco-editor npm version: 0.7.0
Browser: Google Chrome 55.0.2883.87 (Official Build) unknown (64-bit)
OS: 64-bit Linux Ubuntu 16.10
Pressing F8 to bring up the error widget gives the following javascript error:
TypeError: Cannot read property 'heightInLines' of null
    at t.e._relayout (zoneWidget.ts:298)
    at t._relayout (gotoError.ts:440)
    at gotoError.ts:400
    at n.Class.define.cancel.then (winjs.base.raw.js:1566)
...

This is trivially reproducible by:

Visiting https://microsoft.github.io/monaco-editor/
Typing something that is an error (e.g. "broken123") at the top of the document
Pressing F8
Checking the JS console output.

Confirmed on Firefox (OS and version as above); FF v50.1.0

This NPE appears to be already fixed on master

authors: alexandrudima mattgodbolt

repo: Microsoft/monaco-editor


text:
How to detect Cannot find module error to on-demand call addExtraLib?

I would like to detect when "Cannot find module" in Typescript occurs, get the path of the module and then on-demand download the file and and put it into addExtraLib.
How can I do that?

You cannot do that with monaco-typescript which is purpose-fully kept simple in this regard. The design is that the project needs to be resolved upfront. Also, the underlying TypeScript API don't support to asynchronously feed in more source files. Things must be resolved synchronously.

authors: czb jrieken


text:
Update kubernetes Resource Handling Configuration

#915

Coverage increased (+15.6%) to 62.365% when pulling 77bedcac4964608a4d4ac5819f4eb226f39256f8 on yuye/image-gc-k into 34ee6ec6830c0ae31b625aba2509b17fa63be20c on master.

Coverage increased (+15.6%) to 62.365% when pulling 77bedcac4964608a4d4ac5819f4eb226f39256f8 on yuye/image-gc-k into 34ee6ec6830c0ae31b625aba2509b17fa63be20c on master.

Coverage increased (+15.6%) to 62.365% when pulling 77bedcac4964608a4d4ac5819f4eb226f39256f8 on yuye/image-gc-k into 34ee6ec6830c0ae31b625aba2509b17fa63be20c on master.

May I ask what's the issue? @ydye

@YitongFeng  Didn't find it on the changelog of 1.9

authors: YitongFeng coveralls ydye

repo: Microsoft/pai


text:
Local Running Broken Fix & Re-Enable Local Attach

The changes to GetPhysicalProcessId in the remote attaching code broke local script running. This change fixes it. Explanation: local running needs a GUID, while remote attaching needs to have the remote process' pid. Thus, the fact that the ScriptDebugProcess created during local running doesn't have a PID is used to differentiate the two cases.
Pull request also contains re-enabling of local process attaching per convo with @AndreSayreMSFT.

Looks good on AppVeyor Happiness!

Looks good to me.

authors: AndreSayreMSFT EricMSFT MrayerMSFT

repo: Microsoft/poshtools


text:
Make prop types external

#33

Should we add a peerDependency?

authors: abettadapur navneet-g

repo: Microsoft/redux-dynamic-modules


text:
Building package pcl:x64-windows failed with: BUILD_FAILED

Package: pcl:x64-windows
Vcpkg version: 2018.11.23-nohash
The following packages will be built and installed:
pcl[core]:x64-windows
Starting package 1/1: pcl:x64-windows
Building package pcl[core]:x64-windows...
-- Using cached C:/vcpkg/downloads/PointCloudLibrary-pcl-pcl-1.9.1.tar.gz
-- Using source at C:/vcpkg/buildtrees/pcl/src/pcl-1.9.1-898b5a3155
-- Configuring x64-windows
-- Building x64-windows-dbg
CMake Error at C:/vcpkg/scripts/cmake/vcpkg_build_cmake.cmake:175 (message):
Command failed: C:/Program Files/CMake/bin/cmake.exe;--build;.;--config;Debug;--target;install;--;-v;-j1
Working Directory: C:/vcpkg/buildtrees/pcl/x64-windows-dbg
See logs for more information:
C:\vcpkg\buildtrees\pcl\install-x64-windows-dbg-out.log
Call Stack (most recent call first):
C:/vcpkg/scripts/cmake/vcpkg_install_cmake.cmake:24 (vcpkg_build_cmake)
C:/vcpkg/ports/pcl/portfile.cmake:66 (vcpkg_install_cmake)
C:/vcpkg/scripts/ports.cmake:71 (include)
Error: Building package pcl:x64-windows failed with: BUILD_FAILED
install-x64-windows-dbg-out.log

@ZYberTanC Thanks for your feedback. I could install pcl:x64-windows successfully with VS 2017 15.9.11. Please reopen a new issue if it is still a problem for you!

authors: Cheney-W ZYberTanC

repo: Microsoft/vcpkg


text:
Remote SSH for Linux Containers

Relies on this PR: https://github.com/Microsoft/vscode-azuretools/pull/466
Fixes #493
Looks like this on the context menu:

We should probably start moving some of these context actions to other menus, such as Deploy/Configure Deployment Source.

https://github.com/Microsoft/vscode-azureappservice/issues/926

repo: Microsoft/vscode-azureappservice


text:
Chrisdias/license

The new "LICENSE" button in the command palette will open the license in the marketplace:

In order for the marketplace to scrape the license you need to set the license property of package.json to "SEE LICENSE IN <<< filename >>>". This PR does this.

Won't this break then break the license detection in npm?
Can a custom licenseFile field in package.json be used for this instead?

It shouldn't, this is standard according to the package.json docs.
CC @joaomoreno

Well it will probably work but it's technically not following the spec since it's MIT which has an SPDX identifier. Could we not use the SPDX identifier in the ext install? That would be much easier than clicking through to a web page.

If you use the SPDX identifier you will get a generic license, correct? I know Joao did some work here (see https://github.com/Microsoft/vscode-vsce/issues/66).
In this case we want the slightly customized MIT license found in License.txt, which "SEE LICENSE IN License.txt" should pick up.

Talked with @joaomoreno. With https://github.com/Microsoft/vscode-vsce/issues/66 vsce will now find the custom License.txt, so this PR is no longer necessary and we just need to republish the extension. I will open a new issue on that.

authors: Tyriar chrisdias

repo: Microsoft/vscode-eslint


text:
Semantics of CancelToken

Could you clarify what happens to the result promise if the request was canceled?
In C# you would get an OperationCancelledException, but looking at the code in vscode-jsonrpc, it seems like the promise is never resolved and pending forever. That seems like a bug to me

This code here sends the $/cancelRequest but does not reject result promise a few lines above.:
https://sourcegraph.com/github.com/Microsoft/vscode-languageserver-node@e0cfdc96bb513809e6ac8aa239f27ce85b6e5615/-/blob/jsonrpc/src/main.ts#L799:1-800:1
That means if you have code like this:
// Do something that requires clean up afterwards like spawning a process, creating a temp file, opening a socket
const tmpFolder = await fs.mkdtemp(...);
try {
  await connection.sendRequest(params, token);
} finally {
  // Clean up
  await rimraf(tmpFolder);
}

The finally will never get executed and no clean up is done, which means the code will leak disk space / memory / file descriptors / processes / whatever and crash sooner or later.

We can't through an exception or reject the promise since it is the servers responsibility to do that (it is speced in that way in the protocol). So the LSP client library for VS Code sends a $/cancelRequest request to the server. The server then needs to respond to the cancel request. It is up to each request to decided what to do on cancel. The server can either reject the request (error it and pass the new OperationCancelled error code) or resolve with a partial result if the client supports that or ignore the cancel request.
In C# the OperationCancelledException is not thrown automatically either. The operation itself receives the cancel request as well (either through an event or through polling) and is free to decided what to do with the cancel request (it can ignore it as well if for example the operation knows it is 99,9% done anyways).

Thanks for the explanation, makes sense. So I guess after every request I should throw myself if cancellation was requested.
What happens though if the cancelRequest cannot be sent because eg the underlying socket was already closed? Will the promise be rejected then?

The jsonrpc library fires an event if the connection is closed. It is the up to the client of the library to decide what to do. Usually the client will call connection.dispose() which will error all outstanding request promises.
However looks like the VS Code client doesn't do this in server crash cases correctly right now. It does on shutdown. Opened #187.

authors: dbaeumer felixfbecker

repo: Microsoft/vscode-languageserver-node


text:
Provide an API to get diagnostic from the client

I open this issue after https://github.com/Microsoft/vscode/issues/9973#issuecomment-237245214
I'd like the ability to get diagnostic collection for a document from the client side.
//cc @dbaeumer

This is really cool! Thanks a lot!

When will this eventually land into VSCode? I'm still not able to find the new function!

Is available in the 2.5.0 version of the client.

@dbaeumer I've just updated but still I'm not able to find this method. Which object should now have it? textEditor?

authors: XVincentX dbaeumer


text:
linne wait for emulator to start

Environment data

VS Code version: XXX
Extension version (available under the Extensions sidebar): XXX
OS and version: XXX
Python version (& distribution if applicable, e.g. Anaconda): XXX
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): XXX
Relevant/affected Python packages and their versions: XXX

Actual behavior
XXX
Expected  behavior
XXX
Steps to reproduce:

XXX

Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
XXX

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)
XXX

Closing as no information has been provided.

authors: DonJayamanne apklinker

repo: Microsoft/vscode-python


text:
Debug: is there a way to terminate preLaunchTask process (when debug stops)?

Steps to Reproduce:
I am debugging my server (node) code and I added a "start cdn server" preLaunchTask. This task is starting an express server which serves my static files (I want to be able to open my browser and enter server code in debug mode).
While it works fine, I want to be able to kill this cdn server process when debug stops. I was expecting the prelaunch task to be a child process of the debug process, which would solve my problem, but it isn't (it is a child process of VS Code).
Is there a reasonable solution to my problem?

You could launch a wrapper.js that first starts your cdn server and then the actual debugging target. That should make the cdn server a child process of the wrapper. Would that work for you?

Thanks @chrmarti. I was thinking about a similar solution, the problem is that I'll have to spawn index.js from wrapper, which I found hard to debug.
I have several scenarios which I want to start a process (watch/cdn) before debug and kill it when debug ends. It would be nice if we can have some control (in the form of event?) or have the option to run pre launch task as child process

@yanivefraim You could probably also 'require' index.js from debug.js once the cdn server has started. That should allow you to debug index.js. Would that work?
Or: Let the cdn server check if the debug target is running and exit after 10s of not seeing it?
Maybe VS Code could check if the preLaunchTask is still running when the target exits and send it a signal (as you suggest). Will mark this as a feature request for that.

Thanks! I think this can be really helpfull

Dup of https://github.com/Microsoft/vscode/issues/11522
@chrmarti gives a nice workaround also

authors: chrmarti isidorn yanivefraim

repo: Microsoft/vscode


text:
Too many binary downloads/installations

Every two days or so there's a binary installer I have to download and install. The "restart and update" prompt is there almost every day. It's distracting.
I bet these updates are primarily updates to the scores of JS files in the package? e.g. not actually updates to any binaries, DLLs, etc.?
Can't you roll out the core JS updates a JS files, centrally, from a package repository, like you do with plugins? Does it really have to be a full binary distribution for every minor change?

Is that just because of this: http://code.visualstudio.com/blogs/2016/11/3/rollback

@mindplay-dk could you please which versions you are using these days? We did release 1.7 but later on we found some issues with NPM site then we roll back real quick. That might lead to your concern.

Closing due to lack of information.

authors: aeschli ffes mindplay-dk rebornix


text:
API Access to "Open Editors"

I have a use case where I would like to be able to get a list of all the open editors (basically exactly what is shown here).

I understand that Editors are disposed but I just need a list of filenames.
Something like: workspace.openDocuments:Array<TextDocument> or even just workspace.openFiles:Array<string>.
Long term, it might be nice to have API access to operate on this list (EG: sort open editors pane by last opened, name, etc).

Also, just wanted to add that this is blocking our vscode Salesforce IDE extension (mavensmate) from reaching feature parity with Sublime and Atom (and thus increasing the risk of it being abandoned by users).
Background:  Salesforce requires that classes be compiled on their servers.  In order to refactor multiple classes, you must send a single compilation request with all classes.  Because compilation is slow, you typically only want to compile a subset of your project (IE only files related to a refactor).
The way existing salesforce IDE's handle this, is by allowing users to compile all open tabs.

@ChuckJonas I don't know if this is still blocking you, but I've used a hack here that might work for your depending on your use-case. You can see it in action in the Restore Editors extension.

@eamodio ahhh very nice! Never would have thought to use the workbench.action.nextEditor cmd to loop through all the editors.

@ChuckJonas totally agree, but it was the best I could figure out with the tools available ;)

fyi @dbaeumer

Cheers @eamodio, using your work around for something I'm working on too!
Also noticed I had to copy the way you wait in between executing commands because sometimes the activeEditor wont be set yet? Is that a separate issue worth reporting do you think?

@lukebatchelor getting an active editor of undefined is to be expected at this point. It gets set to undefined if there are really no editors, but also if the focus switches to a non-editor window

@eamodio, Im not getting undefined in these cases, but sometimes the same editor.
I assumed that was why have the 500ms pauses in your code?

@lukebatchelor sort of -- the timeout is because while the workbench.action.nextEditor will move to the next tab, if you have 2 non-text editors next to each other, the active editor becomes undefined when it switches to the first (and the active editor changed event will fire), but now when it switches to the next, it will still be undefined, but no event will fire, because it went from undefined to undefined -- so the timeout is a safety net for the event not firing

Oh okay. Thats different to what i was getting.
I'll try again but i was executing closeActiveEditor then logging the active editors document uri and would sometimes be the same still, until i added the pause. Same with nexrEditor.
Weird.

This would be really nice to have!
I am working on an extension that takes encrypted files and decrypts them. The problem is I need the encrypted file path so that I can decrypt the file.
vscode doesn't let you access the file uri of a binary file because the active editor is undefined.

#11247 is about making the tab-model not only readable but also writeable, e.g. open a background-tab which we must consider when implementing this

FYI there is some further conversion about this here: https://github.com/Microsoft/vscode/issues/26568#issuecomment-322384117

Is there any progress or plan for this functionality? It feels really odd that there is still no way for an extension to be able to simply get a list of the currently opened files (even if they are not loaded).

I'm hitting this too. I need to provide my language service with a list of "priority files" and I was sending what I believed to be:

Visible documents
Other open (non-visible) documents

However I've discovered that my means for getting open (non-visible) documents (workspace.textDocuments) is flawed and contains documents that had their editors closed, but the documents are still "open" according to Code.
This means I'm unable to write tests to ensure that my priority files are working correctly, as I have no way of telling which files a user actually has open (but not visible).

We need this for VSCodeVim as well. Our use case is explained here: https://github.com/Microsoft/vscode/issues/51001#issuecomment-397177893

@c10b10 Hopefully thumbs up attract more attention to this issue. For non-vim users, we cannot effectively edit the same file opened in two different editor groups (e.g. split one file vertically and view/edit different parts in each pane)

+many. The API feels needlessly restrictive. What's the downside for MS to make this available for extension developers? I can't think of one.
Much as I like vscode the API could really use some love. Not to sound unappreciative, but the quality of extensions has so much potential if only the API would open up a bit more.

+1 ! Needed for a personal extension that keeps me from opening too many files :0

@jrieken  Is there any update on this? The tab model issue (that I was pinning my hopes on) has been closed...
This issue has been open for over 2 years?

As the fifth highest voted open issue for the API, I hope to see this in the VS Code Roadmap 2019 as the final release of 2018 wraps up in the few weeks.

Haha. Funny you linked that, my comments above were for when I was making that add-on :P
You'll be pleased to know that "close all saved" is actually built into VSCode now (thanks to @soneymathew)

It's 2019. Ouch

it'd be cool to be able to switch between tabs in your workspace on a branch switch.

it'd be cool to be able to switch between tabs in your workspace on a branch switch.

This workflow any many others will be supported in the extensions that I'm building for VS and VS Code - http://contextkeeper.io/?ref=DC8
I want to cover all aspects of "dev context" that is created when working at specific PR/task/feature/bug. There is often a need to switch to something else and there is no easy way to turn back and restore lost context. Moreover there will be a way to save and share your contexts with entire team because they will be saved as diffable files (aka mental snapshots). Ready to commit in git. Stay tuned!

@PiotrKarczmarz

extension that I'm building for VS and VS Code

But how? How do you get the open editors when there's no API for it (hence this issue)?

Good question. When there is no official API it will be harder to implement but I believe possible. In the second comment @eamodio mentioned hack that his Restore Editors is using. When you will dig long enough sometimes you find a way.
Visual Studio also doesn't have any explicit API for its internal engine that restores last opened windows and tabs. It has .suo file when it stores them but it's like black box. You could save or restore certain windows state but you have no control how it will be done at window/tab level. Because VS's last opened files engine has many flaws I wrote independent engine that ContextKeeper is using to position VS's windows and restore tabs. It works very well and allows a whole range of possibilities like opening the same mental snapshot when you switch from your desktop box to laptop without manual windows repositioning - it's detects current resolutions of connected monitors and prepare appropriate layout where all windows fit nicely to new environment. The ContextKeeper's engine allows to save mental snapshots to human-friendly diffable files so you could not only switch between different contexts easily but also track what was change in them via git. Sharing contexts with a team opens another range of possibilities.
Nothing above would be possible when I would give up and tried to use broken and limited ".suo" API. It took a lot of time but I found a way and created "alternative" API.

@PiotrKarczmarz

extension that I'm building for VS and VS Code

But how? How do you get the open editors when there's no API for it (hence this issue)?

Good question. When there is no official API it will be harder to implement but I believe possible. In the second comment @eamodio mentioned hack that his Restore Editors is using. When you will dig long enough sometimes you find a way.
Visual Studio also doesn't have any explicit API for its internal engine that restores last opened windows and tabs. It has .suo file when it stores them but it's like black box. You could save or restore certain windows state but you have no control how it will be done at window/tab level. Because VS's last opened files engine has many flaws I wrote independent engine that ContextKeeper is using to position VS's windows and restore tabs. It works very well and allows a whole range of possibilities like opening the same mental snapshot when you switch from your desktop box to laptop without manual windows repositioning - it's detects current resolutions of connected monitors and prepare appropriate layout where all windows fit nicely to new environment. The ContextKeeper's engine allows to save mental snapshots to human-friendly diffable files so you could not only switch between different contexts easily but also track what was change in them via git. Sharing contexts with a team opens another range of possibilities.
Nothing above would be possible when I would give up and tried to use broken and limited ".suo" API. It took a lot of time but I found a way and created "alternative" API.

For vscode, it ounds like you'll end up hacking the application code rather than building an extension then, which is a shame. On your website it says you have a commit ready for git - I assume that's for Visual Studio and not vscode?

For vscode, it ounds like you'll end up hacking the application code rather than building an extension then, which is a shame. On your website it says you have a commit ready for git - I assume that's for Visual Studio and not vscode?

@Gruntfuggly ContextKeeper will be pure extension for both VS Code and VS. I know that are limitations. Some of them discussed in this thread but also others like no support for floating windows in VS Code  #10121 which were always supported in VS. Workaround will be to use grid layout #14909 when you will try to open context from VS in VS Code to simulate the same windows and tabs layout (yes, opening the same context in both VS and VS Code will be possible!). I want to deliver similar experience for both VS and VS Code but knowing the limitations.

Well if you find a way to access open editos, please share! :grin:

Would like to call out here that this kind of hobbles VSCodeVim, and it sure would be nice to have.

I'm starting to wonder if an extension which manually tracks opened editors might be useful...

I know that this issue is primarily concerned with exposing a tab/editor API, but since it's somewhat related, is there an existing way to target and close the "Welcome" page in code, or would this be tied to the features requested here?

@coltonoscopy "workbench.startupEditor": "none",

@Yzrsah I have that in the extension already, but what if we want to close it for them to provide a different starting point upon installation?

@coltonoscopy check pull request https://github.com/Microsoft/vscode/pull/60061

@coltonoscopy check pull request https://github.com/Microsoft/vscode/pull/60061 and issue https://github.com/Microsoft/vscode/issues/38778

As the fifth highest voted open issue for the API

Now 4th...  not even a comment on this thread from the devs for nearly 2 years. :disappointed:

hope never dies

cmon

Really miss the zentabs of atom. Although there is one similar extension in vscode market, but its functionality is incomplete.
The main reason is there is no API to manage tabs.

So it appears that all this information is readily available, but it's not exported to the extension-visible API. Which would mean that we'd need to send a PR that expands that API surface.
I'm not familiar enough with how the VS Code codebase works to make a PR myself, but I was able to find some starting points, which might help if anyone interested in implementing this wants to dive in. You'll have my undying gratitude if you do!
The "Open Editors" view is able to access all this data from the Groups Service, and it does so here: https://github.com/microsoft/vscode/blob/960f567da7ab501b9be41b3fc0d3e65c8ba539af/src/vs/workbench/contrib/files/browser/views/openEditorsView.ts#L319
Taking a step back, what we do see in the extension API seems to pass through here: https://github.com/microsoft/vscode/blob/56693de122b1345d9df1c2c37fb2cb7a23705bf7/src/vs/workbench/api/common/extHostDocumentsAndEditors.ts#L97
And that extension API seems to be populated from the Main Thread via a state machine here (see the class's usage): https://github.com/microsoft/vscode/blob/f907a8c987b43aeaacdf18458212059f567be371/src/vs/workbench/api/browser/mainThreadDocumentsAndEditors.ts#L145
That state machine seems to interact with the Groups Service only here (which makes sense since it's not really getting that much from the Groups Service, only a notion of what viewColumn it's in): https://github.com/microsoft/vscode/blob/f907a8c987b43aeaacdf18458212059f567be371/src/vs/workbench/api/browser/mainThreadDocumentsAndEditors.ts#L445
It seems like the notion of moveable Groups is relatively recently tacked-on to the codebase, and that technical debt may be the only reason nobody's tried to implement this yet. I doubt that performance considerations have anything to do with it - I haven't seen much mention of performance in the above areas. It might be as simple as allowing more information from that service to percolate through the state machine, perhaps sending along a bookkeeping data structure mapping editor IDs to information about where/what tab-order they currently have in the Group system.
https://github.com/microsoft/vscode/wiki/Feedback-Channels is also something I found for those who may just be getting exposed here (like me!).
Looks like at least 200 people really want to see this work, and it's blocking parity with other editors on important functionality! (For my part, I really want to be able to context-switch between Git branches with confidence that I can restore tabs that only make sense on a different branch... but as other commenters indicate, tab restoration is very limited right now.)
Hopefully someone can jump in here! :)

In my case, would be enough to provide an event when a text document has been hidden, that is, when its tab has been closed. Even the document is still there waiting to be disposed. I just need a notification.

Finally found this issue after banging my head on the API for hours - this is a crazy oversight and I'm amazed it is 3 years in the waiting with so many interested parties.
Also https://github.com/microsoft/vscode/issues/14483 is not a duplicate. That set of features I also need to be able to deal with webViews and other non-textEditors but this request does not imply that non-textEditor tabs would be exposed in a useful way.

Any plan? It has been years.

Happy 2020! Still no plan?

Has this have any plans about getting the opend files?

I am doing some diffing, so I am relying on onDidOpenTextDocument to get an initial state, then using onDidChangeTextDocument to get the updated state. It seems when the editor restores files, it does not call onDidOpenTextDocument, or my extension is loaded after this happens (activation state is *). Being able to iterate over the open files would really help, especially if I could do that in activate. Thanks!

@jrieken has something changed here recently? In current stable code, I'm seeing onDidCloseTextDocument immediately when I close a tab in the editor. I'm unsure if I can rely on this now though?

I'm unsure if I can rely on this now though?

No

@jrieken do you happen to know what might be triggering it to happen immediately for me today? I'm trying to track down a bug that I think is related to it being called later, but I can't confirm it while it's triggering immediately. Thnks!

I stepped through the code, but couldn't figure out any case where it would not call onDidCloseTextDocument. If I understand the code correctly, when the editor is disposed, it disposes the model:
https://github.com/microsoft/vscode/blob/master/src/vs/workbench/contrib/files/common/editors/fileEditorInput.ts#L322
This results in onModelRemoved calling _updateState():
https://github.com/microsoft/vscode/blob/418d1974ca0f99529e4f55c8d05f0a202404c980/src/vs/workbench/api/browser/mainThreadDocumentsAndEditors.ts#L157
And _updateState uses the models (which no longer contains the document) to do a diff and figure out why documents to fire close events for:
https://github.com/microsoft/vscode/blob/418d1974ca0f99529e4f55c8d05f0a202404c980/src/vs/workbench/api/browser/mainThreadDocumentsAndEditors.ts#L223
I can't see any obvious way that this wouldn't happen. If there aren't any, then this issue may be resolved (which would be good, because I think delaying the close introduces weird bugs for both local extensions and LSP where the language server has invalid state for files when modifying files outside of VS Code, such as a bit branch change).

@DanTup This issue is about exposing the open editor tab model as API, not about document close events.

@jrieken issues about onDidCloseTextDocument not firing immediately have been closed as dupes of this (for ex #84505).

I'm confused - my comments have been marked as off-topic in this thread, yet many issues about that subject have been closed as duplicates of this. It's not clear what the expected behaviour is. If onDidCloseTextDocument fires reliably when you close a document, then many of the people interested in this thread may be unblocked (and also https://github.com/microsoft/vscode/issues/68989 would be resolved). Is it possible someone can clarify the status?

If this is going to continue to get bumped each month, could the team outline a fix here and let the community implement it? Need some pointers to which files to look at and change, and what an acceptable behavior would look like.

I just cann't understand what prevents this issue from being fixed. It's hard? It has been years.

It's currently in the May milestone.

I'm confused - my comments have been marked as off-topic in this thread, yet many issues about that subject have been closed as duplicates of this. It's not clear what the expected behaviour is.

All those issues are closed a duplicate because what you and others are trying to achieve is impossible without this API. However, it doesn't mean that using the onDidCloseTextDocument is any good when trying to know what tabs are open.
The jsdoc for onDidCloseTextDocument reads like this: https://github.com/microsoft/vscode/blob/9be0faf246ce291ca08c0a9f0fe88d2b15bf0832/src/vs/vscode.d.ts#L9160-L9168
I am not sure if "To add an event listener when a visible text document is closed, use the TextEditor events in the window namespace." is written badly or if you didn't see that.
Anyways, what that means that visible editors and closed text documents have very little in common. The only guarantee is that a document that's visible (which an editor is visible) is never closed. It also means that you cannot use the list of text documents as reliable information to know what editor tabs are open.

If onDidCloseTextDocument fires reliably when you close a document

This is a conceptual misunderstanding. You don't not close a document you close an editor or an editor tab - vscode closes the document when it thinks it is time to do so.
Tab-changes cannot be observed and are subject of this issue. In the screen shot below below, you have

1 text editor
between 1 and N text documents
1 settings editor (which has no representation in the API)
7 editor tabs

We will not change 1, we will not change 2, we will not change 3. We will add an API that allows to observe and mange the list of tabs (some like to refer to this as the open editors (not text editors) list).
Goals of the API

Have an API representation of the tab model (aka open editors)
Have an API to manipulate the tab model (open, close, activate, move tabs and more)
Have events that fire when tabs change

Note that "tab model != text editors" e.g an inactive tab has no text editor, an active tab might not show a text editor but something else. It's not yet clear how we associate a tab with editors that the API is aware of (text editors, notebook editors).
Properties that a "tab-object" should have

name, detail
view column
uri (iff applicable)
API editor object (iff applicable)
likely more

Modifiers that should exist

close, open tab
active tab
move tab within and across view columns
likely more

Potential extension use-cases

language extension validates all tabs for fooLang, not just visible editor and not the whole project
extension to group tabs by folders, file type etc ([foo.html], [foo.js], [foo.css], [bar.html], [bar.js], [bar.css])
extension to open/close a set of editor tab

Thanks for that clarification and update.
I think you've hit the nail on the head:

I am not sure if "To add an event listener when a visible text document is closed, use the TextEditor events in the window namespace." is written badly or if you didn't see that.

is not consistent with

You don't not close a document you close an editor or an editor tab - vscode closes the document when it thinks it is time to do so.

It's written badly - there is no such thing as a "visible text document".

@jrieken thanks for the details.

All those issues are closed a duplicate because what you and others are trying to achieve is impossible without this API. However, it doesn't mean that using the onDidCloseTextDocument is any good when trying to know what tabs are open.

I'm not specifically trying to know what tabs are visible. It's fine for me if there's a visible tab that doesn't have an open document. It's the opposite that I think may cause issues (an open document without an editor). This is about ensuring language server state doesn't get out of sync with what the user sees. I don't think it's the same issue that this is asking for, but since my issues were all closed I'm not sure where to post it.
Here's an issue I believe may exist if onDidCloseTextDocument doesn't fire when the user closes an editor tab, though I can't verify it right now because onDidCloseTextDocument appears to be firing immediately. I'm concerned if that ceases to be the case (which you suggest may happen), this bug may occur. I'm investigating issues where users have reported changing Git branches and seem to have phantom errors left in their Problems view (or new errors that they should not). Here's what I think might be happening:
I'll use the LSP spec for examples here as it's clearest, but I think the issue is the same for non-LSP extensions.
The LSP spec says (about textDocument/didOpen):

The document open notification is sent from the client to the server to signal newly opened text documents. The document’s content is now managed by the client and the server must not try to read the document’s content using the document’s Uri

However, if you:

Open a file in VS Code
Close the editor
At this point, if VS Code has not sent didClose, the server believes the state of the document is still managed by VS Code, even though it's not visible to the user
Change Git branch so that the file is modified on disk
I believe VS Code does not tell the server that file has modified on disk, yet the line above states that the server must also not read it from the disk. I believe this results in the server having the old contents for the file and therefore may show/send phantom errors for a file the user cannot see.

If there's some mechanism that prevents this from happening if onDidCloseTextDocument does not fire immediately, that's great - but I'd like to understand what it is so if this issue comes up again I'm able to debug better.

I believe VS Code does not tell the server that file has modified on disk,

I believe that's wrong and I am sure you'll able to file a separate bug with repro steps where a document that's considered open (e.g loaded) isn't updated anymore

It's written badly - there is no such thing as a "visible text document".

👍 Yeah, it should a text document in a visible text editor. Which is also a little bogous because all text editors visible by definition... At least we can fix the jsdoc

I believe that's wrong and I am sure you'll able to file a separate bug with repro steps where a document that's considered open (e.g loaded) isn't updated anymore

I don't have a repro because in my current testing, onDidcloseTextDocument always fires immediately. Like I said, I'm not sure that's the issue - I was trying to eliminate it. My understanding was that when the editor was visible, the user may be prompted before reloading a changed document, so I figured it might not happen if the editor is gone.
Is there some situation where onDidCloseTextDocument won't fire immediately, so I can test it?

It's written badly - there is no such thing as a "visible text document".

I raised this at https://github.com/microsoft/vscode-docs/issues/1542 previously.

@jrieken please ping me if you have something. I would like to use it in the LSP client libs to only sync documents that are visible in the editor.

Happy to give feedback on the API as well.

Hi guys,
any news about this feature?
Unfortunately it's a blocker for our extension because we absolutely need to unlock the file after the has finished to editit.
Thanks
Gian

Is there any estimate on when this will actually be worked on? It keeps getting bumped (since March!) and has been open since 2016. I held off on writing some code figuring it would be done in a month, but here we are now in the June 2020 milestone. Should I just unsubscribe from this issue and cite this anytime someone asks me for VSCode support?

@jrieken lol keep on adding it will get done in few smtg 😜

I find it sad that this issue is lower priority than something like pinned tabs...

Sorry all, I've put this on the backlog again for now, since I'm not actively working on it at the moment. I am hoping to still make some progress on the design for the next iteration, but I also don't want to get anyone's hopes up (since I could easily run out of time and not be able to get to it).

Sorry Eric,
We were waiting for more the two months.
Are you able to give us some even ugly workaround?
The use case is simple in my opinion. I need a call to free the resource that was locked when it was open in the editor.
It's a blocker for us and unfortunately without this hook we cannot proceed over.
Thanks
Gian

@eamodio
I think this issue is taking so long because its request became too broad.
It started with “I would like to be able to get a list of all the open editors”. I’m a subscriber because when I opened #13639, it was closed being categorized as a duplicate of this one (which I didn’t buy, tbh). But after all this time, some other issues, which doesn’t seems related to the original request, are referencing this one.
You have:

open/close events
opening in background
extension begin able to close documents
middle click on tabs
and so on....

I mean, is it really necessary to have all of this features, just to provide an API to access the Open Editors? @jrieken commented above a lot of features this API could have, but as I stated, the initial request is much less complex. I know you guys take API very seriously, and that’s one of the main reasons (IMHO) VS Code is so stable for developers (:claps: for that), but I think, in this particular case, the API could have started a lot simpler, and earlier, evolving with new features/areas on later releases.
Thank you

Totally agree Alessandro . A simple list of open editors would be a good
starting point. It  would help.
Thanks
On Wed, 1 Jul 2020 at 00:18, Alessandro Fragnani notifications@github.com
wrote:

@eamodio https://github.com/eamodio
I think this issue is taking so long because its request became too broad.
It started with “I would like to be able to get a list of all the open
editors”. I’m a subscriber because when I opened #13639
https://github.com/microsoft/vscode/issues/13639, it was closed being
categorized as a duplicate of this one (which I didn’t buy, tbh). But
after all this time, some other issues, which doesn’t seems related to the
original request, are referencing this one.
You have:

open/close events
opening in background
extension begin able to close documents
middle click on tabs
and so on....

I mean, is it really necessary to have all of this features, just to
provide an API to access the Open Editors? @jrieken
https://github.com/jrieken commented above
https://github.com/microsoft/vscode/issues/15178#issuecomment-624512992
a lot of features this API could have, but as I stated, the initial request
is much less complex. I know you guys take API very seriously, and that’s
one of the main reasons (IMHO) VS Code is so stable for developers (:claps:
for that), but I think, in this particular case, the API could have started
a lot simpler, and earlier, evolving with new features/areas on later
releases.
Thank you
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/15178#issuecomment-652075830,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABE35IP72AQSMK77CVNX77DRZJQDHANCNFSM4CVSGF3A
.

A simple list of open editors would be a good starting point

My request (also closed as a dupe of this) was for reliable open/close events. This is required for languages that want to prioritise the open files. From the open/close events you can maintain a list of open editors (and know when they changed), so I think if only one thing was done, events would be better than an API to just get the list (or at least, also an event when they changed).

We have understood the requirements and we can understand the frustration that our priorities aren't always matching expected priorities. I am now locking this issue because we haven't been able to retrieve additional actionable input. We take stable API very serious and we'll take our time to build a sound and solid API. Once that work has started we will report back here.

An API is currently being worked on slated for this iteration to address some of the common requests in the post.
The API we're focusing on right now is targeting reading of the tabs within VS Code. A modification API may come later but is not the focus of this iteration as a solid reading API is an important foundation and first step.
The current proposed shape of the API is as follows
https://github.com/microsoft/vscode/blob/213902e4f42a09154614296511de5fd704a0fc52/src/vs/vscode.proposed.d.ts#L2277-L2333
I've unlocked the issue to gather feedback and answer any questions surrounding this particular proposal. If your questions / comments / concerns do not relate to a Tab API I suggest opening a separate feature request after searching for existing ones as excessive off topic discussion will lead to this issue being re-locked. Thank you everyone for your patience as we want to provide the best API possible to enable extension developers to create the best extensions possible 🙂

How about a property to indicate a tab preview (italicized) state?
Tab.label: If two tabs with the same name are open, does this include the location?

What will the resource be in webview tabs?
Will they be simply null like marketplace tabs?
If they do have something, how will they be referred?
Webview url is kinda useless currently as far as I know, because you don't really have a wey to get id of a webview instance.

Rather than the resource represented by the tab, wouldn't it be more useful to have the editor it contains?

Rather than the resource represented by the tab, wouldn't it be more useful to have the editor it contains?

I'm not certain, but I thought it may be possible that there are no editors for some tabs yet. For example if you open open VS Code and it re-opened 20 tabs from a previous session, it might not create editors for those items until you actually switch to them?

Fair point - the resource will definitely be a good starting point. It would be handy though if the editor was available (if it has been created).

@Gruntfuggly Do you have a good use case of when you need the editor? There's too many types of editors and the resolution is async where as the tabs are sync it wouldn't make much sense and would be a bad design.

How about a property to indicate a tab preview (italicized) state?
@mattacosta Maybe. We don't want to get property bloat for properties that don't have viable use cases. If you have a use case for it I would be interested in hearing it

Tab.label: If two tabs with the same name are open, does this include the location?
@mattacosta They contain what group they're apart of and the array is ordered.

What will the resource be in webview tabs?
@mmis1000 Not sure will have to investigate. My guess is if it does have one it will be a special URI scheme which is how you will know it's a webview

@lramos15 My extension loops through all open editors and runs a process if the editor contains a file under SCM (git) to determine whether or not to close the tab. I guess I can probably determine that from the resource though - currently it gets the URI from the document via the editor.

After ironing out some details, I'm looking for feedback from actual users of this API. This API is in a proposed changing state and as such you must use proposed API to access it. The guide to using proposed APIs can be found here. If you have any feedback pertaining to the API please comment here. Any bugs please file separate issues. Thanks!

Hi @lramos15  - that already gets me one step further regarding my usecase.
Not sure if I am missing it in the proposed API change, but would it also be possible to access the editor for the resource within a tab?
Something like this:
vscode.window.tabs.forEach((item) => {
    item.resource // only gives Uri for File
    item.editor?.document.close() // what I am trying to accomplish
}

@martinmeinke No, it's hard to get the distinction but Tabs != editors. Tabs are merely arbitrary view containers and therefore could have anything in them. Sometimes they can even be empty, this means there is no document or resource etc. To be helpful we provide some info about what the tab contains but there isn't a document for all tabs and therefore this isn't an option. tab.close() will be a function though which will cover your case.

Thanks for the clarification! Then I'll wait for the tab.close() support!

Thanks for the clarification! Then I'll wait for the tab.close() support!

tab.close() has entered the proposed API. As always remember that things are just in a proposed state and continue to change.

I would welcome this. The default open editors widget is not very convenient, this API could help to get a reliable extensions to replace it.

Thank you for

the completion of one of our most upvoted issues

with April 2022.
As this feature request from November 2016 (issue no 15178) with 314 upvotes was done, is there now hope for #1012 (a feature request from December 2015 with 410 upvotes; not sure if the additional 10 hoorays, 35 hearts, 5 rockets and 11 eyes should be counted additional) to be re-inspected and at least get an up-to-date comment from the UX team?

Is there a way to get a file uri or get to the TextEditor from a tab?

tab.input.kind.uri for certain classes of tabs.

authors: Abbyyan ArturoDent ChuckJonas DanTup Divni GitMensch Gruntfuggly KamasamaK Noooil PiotrKarczmarz Samox TACIXAT Yzrsah alefragnani bpartridge coltonoscopy dbaeumer dongryphon eamodio flowchartsman gianpatt isc30 jascodes jpoon jrieken loligans lramos15 luikore lukebatchelor mabenson00 martin-braun martinmeinke mattacosta mmis1000 noppa qadram terminull usama8800 xiaozhuai yubaoquan


text:
Directory navigation feature

VSCode Version: 1.7.1
OS Version: Ubuntu 14.04
Is there any faster way to navigate the directory tree? I am working on a project with around 300 node_modules and everytime I need to search for one of the node_modules i need to expand the node_modules directory and manually scroll all the way to the required module. As my project goes on increasing this becomes more and more of a pain. Can there be a way to search a directory the way it works in Intellij? i.e. we focus on the directory tree and type the name of the directory we want to go to and intellij searches for and takes us to the corresponding directory.
P.S I am aware of the Ctrl+P command which opens a file, but that doesn't seem to work so well with directories

Duplicate, can be found here: #10026

authors: kaiwood nahushfcc


text:
[Feature Request] Quick Navigation as WebStorm

VSCode Version: 1.12.1
OS Version: Mac

Steps to Reproduce:

Type at slidebar could navigation file tree, just like WebStorm

Cool  👍

+1

friendly ping, @egamma , any plan on this?

@atian25 it is on our backlog, cannot be more precise currently, sorry.

hi, @isidorn dup issue id?

https://github.com/Microsoft/vscode/issues/10026

authors: atian25 egamma isidorn okoala zswang


text:
Welcome tab 'Visual Studio Code' translated as 'Visual Studio-Code' in German locale

Should not it be Visual Studio Code as in every other locale?

https://www.transifex.com/microsoft-oss/vscode-workbench/translate/#de/vs_workbench_parts_welcome/111041646

Fixed by revert to same as English.

authors: danyeh michelkaporin


text:
Launch VSCODE Application in WSL without XServer

I have installed windows 10 (b.1703) creators update recently and I am using ubuntu subsystem(WSL).There I have installed Visual Studio Code successfully(Node.js everything installed).
I followed this link too - support
Problem is that any GUI elements required application can be launch but not working(no GUI will be elements displayed reason may be WSL has no direct Graphic driver support).

As image shown above.after I command to execute vscode thorough

macxfadz@BC-LPTP:~$ code

the WSL BASH take few seconds and nothing display during that time and print second line with empty respond.
I wanted to know How to provide graphic driver support to WSL in order to facilitate GUI applications(in this case VSCODE)? without installing 3rd party software such as XMing-Xserver,putty etc.
Else do we have any other mechanism to achieve it ? only modifying Ubuntu(Linux subsystem) side? other than switching to Windows 10 Insider preview builds?
Please note that I don't want to launch VSCODE installed in windows 10 launch via WSL ubuntu bash.

I traveresed through lxss/rootfs directory nothing has been found to related with VSCODE,how verify that VSCODE installed successfully?

Verified that .

Duplicate of https://github.com/Microsoft/vscode/issues/13138

authors: Tyriar macxfadz


text:
Screen reader does not announce when hovering over drop down

Issue Type
Bug
Description
Enable screen reader
Open output panel
Hover over controls from right to left, starting with top right
Hear the screen reader announce each control "Close panel", "Move to right", "Toggle maximized panel", "Toggle output scroll lock", "Clear output" but nothing when hovering over the drop down
Expected: Screen reader should announce when hovering over the drop down
VS Code Info
VS Code version: Code - Insiders 1.20.0-insider (eed7e193125f3d4cfebe2089d1b2a9c674388754, 2018-01-30T09:51:29.494Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz (4 x 2594)

Memory (System)
7.89GB (1.45GB free)

Process Argv
C:\Program Files\Microsoft VS Code Insiders\Code - Insiders.exe

Screen Reader
yes

VM
0%

Extensions (12)

Extension
Author (truncated)
Version

html-snippets
abu
0.2.1

vscode-eslint
dba
1.4.4

tslint
eg2
1.0.24

vscode-great-icons
emm
2.1.22

vscode-gutter-preview
kis
0.12.2

csharp
ms-
1.13.1

vs-keybindings
ms-
0.1.7

vsliveshare
ms-
0.1.0-preview.171

team
ms-
1.122.0

debugger-for-chrome
msj
4.1.0

addDocComments
ste
0.0.8

cordova-tools
vsm
1.3.3

Reproduces only with extensions

Found when testing: https://github.com/Microsoft/vscode/issues/40589

@cleidigh I would expect that no ARIA role is required given that this is a pretty standard HTML control that a screen reader should be able to announce, no?

Triage...
@bpasero
Don't want to pretend to be an expert but, as far as I can see from the specs as well as the issue thread below, this is more of a design decision to either have readable tooltips or live ARIA content.  I don't think there's any technical issue , including Electron, preventing us from doing this.  I'm not sure it makes sense though.  There are plenty of other examples of elements that could have this but, again I don't think it makes sense.
Consider closing?
https://github.com/nvaccess/nvda/issues/6048

@cleidigh are you suggesting to have a aria-label role or title attribute on the select element?

I just realized several of the clients for selectbox do not pass in a label, outputs and terminal for example.
ironically I just posted two issues for this earlier this evening.  Maybe some readers can be configured to read on  mouse hover press.
I will check tomorrow

@isidorn can we ask our accessibility experts what the expectations are? Should a screen reader announce a dropdown when hovering over?

@isidorn what drop down is this?

@stevencl
If the standard NVDA supports it presumably by reading the main label, then it certainly makes sense.  I was just raising concerns about some of the oddities mentioned in the NVDA issue thread.
I need to see this working as right now I do not get output from mouse hovers but there may be an issue with my use of Dragon for both mouse and keyboard.  I will find a helper to do some more testing.
This directly dovetails with my efforts to make the selectbox a well implemented accessible widget.
@isidorn this affects any drop-down.
BTW I have a couple of issues opened on just the related main labels.
#60724
#60726

@stevencl
I got a little bit of testing done.  Trying several recent versions of Code and NVDA 2018.2 under Windows 10, I have not been able to hear output on the panel buttons.  I did find an option under mouse configuration for speaking tooltips on hover.  That option is disabled by default for the current version.  When enabled I get output like:
"Close Panel tooltip"
Your example output mentioned above does not include "tooltip".  Unless you just omitted that, I assume I instill seeing something different.  With or without this option enabled, I do hear output on text items.
Any thoughts on configuration issues since I cannot reproduce this?

This still may be an upstream issue with Chromium/Electron.
I discovered that at some point after my July 5 Commit that added
label support for selectbox , things regressed and this label
no longer works in 1.28.  Below is the setup that initially worked.
This was just before moving to Electron 2.x
@bpasero pointed me to the 28.2 Exploration version.  I just tested
in that version the new labeling works again.  I still cannot
hear output over the panel buttons, but the issues may be related.
I'm thinking that there may be a 2.x Electron that somehow allowed
NVDA to announce the buttons and then regressed similarly to my issues
with the main selectbox label.
Version: 1.26.0
Commit: Unknown
Date: Unknown
Electron: 1.7.12
Chrome: 58.0.3029.110
Node.js: 7.9.0
V8: 5.8.283.38
Architecture: x64

@stevencl
I am still unable to reproduce reader output hovering with mouse over panel buttons.  Is it possible your
NVDA is set up to read tooltips?

Sorry for the slow response. I've uploaded a video demonstrating this: https://flic.kr/p/2cp7bBv
This is with NVDA set up not to announce tooltips.

@stevencl
Great, thanks.
Can you let me know what version of NVDA you are using?
I still cannot reproduce the output you hear.  There are multiple
issues related to the Electron version that could be part of this and the problem is the version you tested
was 1.x now we have 2.12 I believe and test with Electron 3 all show slightly different ARIA oddities.
That said, until I can reproduce your baseline, it's hard to approach this.  I will keep on trying.

My NVDA version is 2018.3.2
I just installed today's VSC insiders release and the screen reader now announces when hovering over the drop down. The video I shared yesterday is from the latest VSC stable release.
Thanks for persevering with this @cleidigh

@stevencl
Excellent ! I just wish I could still reproduce this.  I did Discover that Dragon NaturallySpeaking interferes with NVDA.  Actually it's more correct to state that the reader does not recognize the virtual mouse of Dragon.  I bribed my daughter to use the mouse directly and found this out.
I still need to figure out why I do not The same output especially because this means I cannot reliability testing on some of the main issues I am working on.
I'd like to keep this open for that reason.  @bpasero can you get the correct output with your NVDA?
BTW:  I still believe this type of output with default reader set up is reading text as opposed to the elements specifically.

@stevencl @cleidigh I am also on NVDA 2018.3.2 but I neither see any output when hovering over the dropdown, nor when hovering over the actions next to it (in the output panel). I am inside a VM though, so that could have easily an impact.

@stevencl  @bpasero
I am on a native Windows 10 set up with identical behavior as @bpasero 's VM ,  I am doubtful the VM is an issue.
@stevencl if you are still up for pursuing this, I would like to try to resolve the issue.
Perhaps you could export your configuration, maybe were missing something there.

Sorry again for the delay.
@cleidigh - what configuration do you want me to export?

@stevencl
The NVDA configuration, I cannot really use a perfectly   default configuration myself an adjustment to make sure we somehow have some little difference causing our different results.

Here is the contents of my NVDA.ini file. Hope this is useful. Happy to get on a call with you too so you can inspect some more in detail.
schemaVersion = 2
[upgrade]
[update]
autoCheck = True
startupNotification = True
allowUsageStats = True
askedAllowUsageStats = True
[general]
language = Windows
saveConfigurationOnExit = True
askToExit = True
playStartAndExitSounds = True
loggingLevel = INFO
showWelcomeDialogAtStartup = True
[speech]
synth = oneCore
[[oneCore]]
voice = HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Speech_OneCore\Voices\Tokens\MSTTS_V110_enUS_DavidM
volume = 100
[presentation]
reportTooltips = False
[braille]
[[noBraille]]
port = ""
[uwpOcr]
language = en-US

@stevencl
Thanks.  Certainly don't see anything suspicious as you alluded prior.  I will try to do some more testing and perhaps as you say a phone call might be good just  to noodle.

authors: Neurrone bpasero cleidigh stevencl


text:
Add jsconfig.json option to resolve directory-named-webpack-plugin paths

Issue Type: Feature Request
In our Webpack configuration, we use directory-named-webpack-plugin to remove redundant segments from our file pathing.  i.e.
'components/Dropdown/Dropdown' becomes 'components/Dropdown'
It would be great if the IDE was able to understand this pathing and look for files named after their directory, rather than only looking exclusively for index.js files.
I propose adding an option within jsconfig.json to support this functionality.
VS Code version: Code 1.23.1 (d0182c3417d225529c6d5ad24b7572815d0de9ac, 2018-05-10T16:03:31.083Z)
OS version: Darwin x64 17.4.0

This issue was moved to Microsoft/TypeScript#24116

authors: mjbvz tylerkayser


text:
Test: Active terminal extension API

https://github.com/Microsoft/vscode/issues/47615

[ ] macOS @seanmcbreen
[ ] Linux @chrmarti
[ ] Windows @auchenberg

Complexity: 2
Test these two new proposed APIs for the terminal that allow tracking of the active terminal:
https://github.com/Microsoft/vscode/blob/d88b3dd55be626154bf1d43c6d8570e02b4a32bb/src/vs/vscode.proposed.d.ts#L467-L480

From @ joaomoreno:
FYI - to test against the latest API do the following:

open your extensions package.json file
change the engine.vscode property to *
run npm run postinstall (assuming you have the vscode module as dev-dependency)
undo the engine-version change from step 2
from the vscode-repo copy the vscode.proposed.d.ts-file into your project
in your package.json file add enableProposedApi: true

authors: Tyriar chrmarti


text:
Selecting text in Mardown Preview leads to weird visual errors

VSCode Version: 1.25.1
OS Version: Mac OS High Sierra 10.13.6

Steps to Reproduce:

Open .md file in Markdown Preview
Select Text in Markdown Preview

Checkout the GIF below & check the top right panel move 👇

Does this issue occur when all extensions are disabled?: Yes

This is related to #53918 but not similar as I'm talking about the top right panel & the linked issue is talking about Copy+Paste Bug

Double clicking on an element in the preview switches the editor by default. Set "markdown.preview.doubleClickToSwitchToEditor": false to disable this

@mjbvz Can I ask why it isn't default as from my perspective it should be default🤔


text:
How to find Unused typescript classes?

needs a bit more info...

We don't detect unused, exported variables as we do not know if they form part of a public api


text:
The file menu missing

The file menu on the toolbar is missing @#55624

Duplicate of #55624

authors: mjbvz xiaoliufly