sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Initial value is changed and repeated inside AnimationController.repeat, which results into unexpected controller.value on first run
Labels: framework,a: animation,d: api docs,P2,team-framework,triaged-framework

When calling `animationController.repeat()`, the controller's `value` gets set to the supplied `min` parameter _plus_ its current value.

I don't know if this is by design, or a bug, but it's very confusing:

```
final animationController = AnimationController(
   vsync: this,
   duration: Duration(seconds: 1),
);
animationController.value = 0.1;
animationController.repeat(min: 0.2, max: 1.0);
print(animationController.value); // Value is 0.3
```

My use case is wanting to play the first part of an animation, then once the value is at a certain point, loop the middle of it. I have to set `value = 0` before calling `repeat`.

Should this be changed or just documented?
Repository: create-react-app
Issue: Jest configuration support for "resolver"
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

https://github.com/facebook/jest/pull/10393 gives a simple way to add a resolver that resolves 'module' field. There's already an NPM package for it: https://www.npmjs.com/package/jest-module-field-resolver

However, at the moment I cannot pass the jest option `resolver` in an un-ejected CRA.

### Describe the solution you'd like

Pass jest option `resolver` to jest.
Repository: TypeScript
Issue: Go to definition broken by existance of tsconfig.json in JavaScript project.
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.0.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** go to definition javascript

**Code**

```js
'use strict'

// javascript file.
const uuid = require('uuid')
```

**Expected behavior:**

When I hit Go to definition with F12 on uuid it goes to the source code.

![working-go-to-def](https://user-images.githubusercontent.com/479538/95315789-407bc500-0893-11eb-991e-bb9f15178125.gif)

This works fine for JavaScript because tsconfig.json does not exist.

**Actual behavior:**

When I hit Go to definition with F12 it does not do anything useful.

![broken-go-todef](https://user-images.githubusercontent.com/479538/95315828-4d98b400-0893-11eb-8984-0c4a1c1e2abb.gif)

This is because a `tsconfig.json` file exists in my JavaScript project.

**Playground Link:** 

**Related Issues:**
Repository: godot
Issue: Saving editable child as scene will remove all its children
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3 / e93af13

**Steps to reproduce:**
1. Create a scene with some multilevel hierarchy
2. Create another scene and instance the other one
3. Enable Editable Children
4. Use Save Branch as Scene on one of the instance's children
5. Any descendant of that child is removed

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[ReproductionProject.zip](https://github.com/godotengine/godot/files/5340212/ReproductionProject.zip)
Repository: node
Issue: listen: Misleading error message when directory of IPC socket does not exist
Labels: net

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version**: v15.0.0-pre (built from source on commit 40364b181d44ba90b6ce7cda4f9e3297581121c5)
* **Platform**: Linux (hostname) 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux
* **Subsystem**: net

### What steps will reproduce the bug?

<!--
Enter details about your bug, preferably a simple code snippet that can be
run using `node` directly without installing third-party dependencies.
-->

Input:
```javascript
const net = require('net')
let server = net.createServer()
server.listen('/tmp/nonexistent/ipc.sock')
```

Output (when run as script):
```
events.js:304
      throw er; // Unhandled 'error' event
      ^

Error: listen EACCES: permission denied /tmp/nonexistent/ipc.sock
    at Server.setupListenHandle [as _listen2] (net.js:1272:21)
    at listenInCluster (net.js:1337:12)
    at Server.listen (net.js:1434:5)
    at [stdin]:3:8
    at Script.runInThisContext (vm.js:132:18)
    at Object.runInThisContext (vm.js:309:38)
    at internal/process/execution.js:77:19
    at [stdin]-wrapper:6:22
    at evalScript (internal/process/execution.js:76:60)
    at internal/main/eval_stdin.js:29:5
Emitted 'error' event on Server instance at:
    at emitErrorNT (net.js:1316:8)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  code: 'EACCES',
  errno: -13,
  syscall: 'listen',
  address: '/tmp/nonexistent/ipc.sock',
  port: -1
}
```

When run directly in the node prompt, the output is different, but the difference is not relevant here.

### How often does it reproduce? Is there a required condition?

Always reproducible, no conditions

### What is the expected behavior?

<!--
If possible please provide textual output instead of screenshots.
-->

The error message tells something like "ENOENT: no such file or directory", ```code``` and ```errno``` show ```'ENOENT'``` and ```2``` (or maybe ```-2```) respectively.

### What do you see instead?

<!--
If possible please provide textual output instead of screenshots.
-->

The error message claims that there was a permission denied error (EACCES), which is not the case.

### Additional information

<!--
Tell us anything else you think we should know.
-->

Relevant excerpt from ```strace```:
```
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 18
bind(18, {sa_family=AF_UNIX, sun_path="/tmp/nonexistent/ipc.sock"}, 110) = -1 ENOENT (No such file or directory)
close(18)
```

This clearly shows that the OS actually does report ENOENT correctly, but somehow that gets mangled into EACCES.
Repository: puppeteer
Issue: Response.buffer gives misinterpreted text instead of raw network buffer
Labels: bug,upstream,confirmed,P3

### Steps to reproduce

**Tell us about your environment:**

* Puppeteer version: 5.3.1
* Platform / OS version: Windows 10 (Build 2004) 64-Bit
* URLs (if applicable):
* Node.js version: 12.19.0

**What steps will reproduce the problem?**

1. Open a page that does not define the appropriate text encoding.
2. Retrieve the `response.buffer()`.
3. Change `buffer` to `string` specifying the correct text encoding.
4. Observe that the browser did not provide the raw buffer, but rather it's (wrong) interpretation.

Code tells more than words:

```js
const http = require('http');
const puppeteer = require('puppeteer');

const server = http.createServer((_, res) => {
  const buffer = Buffer.from('Flächendeckender Blitzzauber wird ausgelöst.', 'utf8');
  res.write(buffer);
  res.end();
  server.close();
}).listen(4567);

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  const response = await page.goto('http://localhost:4567');

  // Expected: Text is interpreted as the default encoding, not UTF-8.
  const text = await response.text();
  console.log(text); // -> FlÃ¤chendeckender Blitzzauber wird ausgelÃ¶st.

  // Unexpected: I should receive the buffer without text interpretation.
  const buffer = await response.buffer();
  const bufferText = buffer.toString('utf8');
  console.log(bufferText); // -> FlÃ¤chendeckender Blitzzauber wird ausgelÃ¶st.

  await browser.close();
})();
```

**What is the expected result?**

I expect `response.buffer()` to yield the raw buffer which I can use to interpret the text as `utf-8` myself.

**What happens instead?**

I receive a buffer containing the misinterpreted text.
Repository: godot
Issue: Image.FORMAT_R8 sampler2D data is placed in the wrong color channel when using GLES2 renderer
Labels: bug,topic:rendering,topic:shaders

**Godot version:**
3.2.3 stable

**OS/device including version:**
Windows 10, GLES2 renderer

**Issue description:**
When using the GLES2 renderer, if you create an Image.FORMAT_R8 ImageTexture and read from it in a shader, the data is placed in the alpha channel instead of the red channel. When using the GLES3 renderer the data will be in the red channel as expected.

Expected result:
![GLES3_screenshot](https://user-images.githubusercontent.com/68328892/95332552-7fb21200-08a3-11eb-9126-dee6cbc8eeba.png)

Actual result:
![GLES2_screenshot](https://user-images.githubusercontent.com/68328892/95332588-90628800-08a3-11eb-8d16-4e443d82925e.png)

If I remember correctly from past experience this is an OpenGL issue caused by a difference in behaviour between OpenGL 2 and 3. To produce consistent results between the two renderers Godot will need to perform a texture swizzle behind the scenes.

**Steps to reproduce:**
Reproduction project attached below.

**Minimal reproduction project:**
[GLES2_R8_sampler_bug.zip](https://github.com/godotengine/godot/files/5340725/GLES2_R8_sampler_bug.zip)
Repository: godot
Issue: Normal map glitches, depth map crashes the driver when blend shape influence set to 1
Labels: bug,topic:rendering,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
Godot_v3.2.3-stable_win64.exe


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
OS: Win7 64 sp1
GPU: Nvidia GTX 780
Driver: 436.02 

**Issue description:**
<!-- What happened, and what was expected. -->
Ugly 'holes' appear over the model with normal map when any of the blend shape influence value set to 1. For lesser values, there are much less noticeable artifacts.
When displacement map is added in the same scenario, graphics driver crashes.
**Steps to reproduce:**
1. Open the attached project
2. Open the model glb  from 'model' folder as a scene, access the mesh shape keys, drag one of them to 1.
3. See ugly holes appear. They are different for different keys, but have similar shape and appear only when value is set to 1, any less than that like 0.999 are "ok" (not just ok since model sides show some minor artifacts, presumably also related to normal maps).
![ugly_holes_normal_map](https://user-images.githubusercontent.com/6236272/95343291-a464b480-08b8-11eb-8992-991475b34585.png)
4. Slide the shape back to 0.
5. Open the material from 'model' folder, enable depth, enable deep parallax, load model/Displacement.png as a texture.
6. Slide the shape back to 1.
7. Observe driver crash (obviously the crash itself can be driver-dependent, but something wrong is happening anyways)
![windows-error-screen](https://user-images.githubusercontent.com/6236272/95343309-a7f83b80-08b8-11eb-9b7c-99ef5aa53dac.png)

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[blendshapemas.zip](https://github.com/godotengine/godot/files/5341297/blendshapemas.zip)
Repository: vscode
Issue: resources#relativePath does not honour path casing strategy
Labels: debt,uri

It seems to me that [`resources.relativePath`](https://github.com/microsoft/vscode/blob/6e022766d135689a6a5f92a4f3d9ebf97b238dd0/src/vs/base/common/resources.ts#L228-L228) ignores the fact that path casing should be ignored depending on the underlying file system. As you can see here:

https://github.com/microsoft/vscode/blob/6e022766d135689a6a5f92a4f3d9ebf97b238dd0/src/vs/base/common/resources.ts#L232-L235

Extracted from https://github.com/microsoft/vscode/issues/107774

> I am actually no longer so sure that path casing is ignored, @jrieken is that handling for file URI intentional?

Only @aeschli knows, he wrote those utils and I didn't change their semantics when moving them to `IExtUri`. But, yeah it seems that there is some scheme and platform specific handling in there and I don't think that is good.

_Originally posted by @jrieken in https://github.com/microsoft/vscode/issues/107774#issuecomment-705017638_
Repository: storybook
Issue: Option to stop controls changing a component in Docs view
Labels: feature request,addon: controls

**Is your feature request related to a problem? Please describe**
I think it can be an issue that changes made by controls in the Canvas are also applied/kept in the Docs tab. If someone is playing with the controls for a primary/blue button for example and changes it to danger/red or disabled and then navigates to the Docs then they are shown a red or disabled button for the blue button documentation leading to confusion or misunderstanding.

**Describe the solution you'd like**
There should be an option/way to disable controls effects for stories when in Docs view, on a global, component and story level ideally. Also another option or as well as there should be a reset button in the story in Docs mode to reset the controls or props to their initial values, like there currently is in the ArgsTable.

**Describe alternatives you've considered**
Wrting duplicate stories with controls disabled. Adding an ArgsTable in Docs for each story.

**Are you able to assist to bring the feature to reality?**
No
Repository: TypeScript
Issue: Cannot annotate a field in constructor as null using jsdoc @type
Labels: Bug

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.0.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** jsdoc null type implicit any

**Code**

```js
class Foo {
    constructor () {
        /** @type {number} */
        this.bar = 42

        /** @type {null} */
        this.foo = null
    }
}
```

**Expected behavior:**

Expected to have a class with two fields, bar of type number & foo of type null

I don't know why it doesn't understand `null`; using `string | null` works fine.

**Actual behavior:** Member 'foo' implicitly has an 'any' type.

**Playground Link:** https://www.typescriptlang.org/play?useJavaScript=true#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8h0AFAJQrqaMD0AVC9AAL4CeADgKYocxALYAjfoQC+0FkwaMM+ABYBLCADoxYSgF5oAFgBMqBYtbsufQcmEgQMuWcYr1GgGaJo+uyDNTUKSA

**Related Issues:**
Repository: kubernetes
Issue: client-go example fails due to race condition in fakes+informers
Labels: kind/bug,sig/api-machinery,lifecycle/frozen,triage/accepted

This is broken off of https://github.com/kubernetes/kubernetes/issues/88508 which was stalebot closed

**What happened**:

Run the example https://github.com/kubernetes/client-go/blob/master/examples/fake-client/main_test.go#L42. It will *usually* pass. However, there is an inherent race condition in the fake client and informer code.

In the real client, we do a list, then set up a watch with the resourceVersion returned in the list. However, the fake client ignores resourceVersions. This leads to a race between https://github.com/kubernetes/client-go/blob/866e6a7e3cf35d16a6d3d5175e36d05dfe4b0797/tools/cache/reflector.go#L302 and https://github.com/kubernetes/client-go/blob/866e6a7e3cf35d16a6d3d5175e36d05dfe4b0797/tools/cache/reflector.go#L414; any creates/updates during this time are dropped.

**What you expected to happen**:

Either:
1. The race is fixed
2. The example is updated to provide best practices for testing with informers and fakes. I looked through all of the k/k tests I could find, and it seems that instead of doing `client.Create(...)` they are generally using `informer.Store.Add(...)`. Is this the recommended pattern?

**How to reproduce it (as minimally and precisely as possible)**:

Run the example test many times. using https://godoc.org/golang.org/x/tools/cmd/stress is useful, as is dropping the timeout from 30s to something smaller to speed up the reproduction (although 30s will still reproduce it - if you are patient). Adding `-race` seems to trigger it more.

If this cannot reproduce, you can inject a time.Sleep between the two code points mentioned above to exacerbate the race and make it consistent.

/sig api-machinery
Repository: terminal
Issue: Bind-able command to move forwards and backwards through Windows Terminal instances
Labels: Area-UserInterface,Product-Terminal,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

It would be nice to have a bind-able action that would select the next (or previous) running Windows Terminal instance (window). I often find when I'm editing a lot of code I have a terminal window with Vim on each of my monitors, which I have to Alt-Tab back and forth between. However, sometimes I will have opened some documentation or other various windows since the last time I visited a particular WT instance, and I have to expend a lot more mental energy figuring out exactly how many Alt-Tabs to get back to my 2nd terminal window. I used this all the time when I used mintty, which exposed it under the Ctrl-Tab key (which is already default bound to switching tabs in WT). Maybe Ctrl-Alt-Tab or something similar?

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

Sample commands:

`{ "command": "nextInstance", "keys": "ctrl+alt+tab" },`
`{ "command": "prevInstance", "keys": "ctrl+alt+shift+tab" },`

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: vue
Issue: $scopedSlots is empty until render()
Labels: bug,has PR

### Version
2.6.11

### Reproduction link
[https://codepen.io/kaelwd/pen/rNLNYGL?editors=1011](https://codepen.io/kaelwd/pen/rNLNYGL?editors=1011)







### Steps to reproduce
Open the console

### What is expected?
`"ScopedComponent beforeMount" true` to be logged

### What is actually happening?
`"ScopedComponent beforeMount" false`

---
This was discovered in vuetify: https://github.com/vuetifyjs/vuetify/issues/11533#issuecomment-705058227

The real setup is a watcher on a computed property that depends on `$slots`. The watcher is called before mount to get an initial value, causing the computed property to be executed and return an incorrect value. 

Minimal example with the watcher if that helps: https://codepen.io/kaelwd/pen/vYKYWbV?editors=1010

This works as expected in vue 3: https://codepen.io/kaelwd/pen/gOMOXoB?editors=1011

The bug seems to have existed since scoped slots were introduced in v2.1, but it wasn't a problem here until v2.6 when scoped slots started being used everywhere with `v-slot`

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: electron
Issue: Main process disappears from dedicated Node.js devtools window on exit when awaiting debugger detach
Labels: platform/windows,bug :beetle:,10-x-y,11-x-y,windows 7

<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:**
  * 10.1.3 x86
* **Operating System:**
  * win7 sp1 x64
* **Last Known Working Electron version:**
  * 4.2.9 x86
* **Chrome (inspector) Version:**
  * 86.0.4240.75

### Expected Behavior
detachment and exit on window close

### Actual Behavior
remains running

### To Reproduce
- start chrome dedicated node inspector
- run `electron --inspect`
- verify it's attached
- close the electron window
  - window closes
  - inspector gets into the disconnected state
  - "Waiting for the debugger to disconnect..." is printed to the console
  - electron processes remain

<!--
For bugs that can be encapsulated in a small experiment, you can use Electron Fiddle (https://github.com/electron/fiddle) to publish your example to a GitHub Gist and link it your bug report.
-->

<!--
If Fiddle is insufficient to produce an example, please provide an example REPOSITORY that can be cloned and run. You can fork electron-quick-start (https://github.com/electron/electron-quick-start) and include a link to the branch with your changes.
-->

<!--
If you provide a URL, please list the commands required to clone/setup/run your repo e.g.
```sh
$ git clone $YOUR_URL -b $BRANCH
$ npm install
$ npm start || electron .
```
-->