sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Inline scripts in built `index.html` cause CSP errors
Labels: bug,core,security

### Describe the bug

In the most recent (`7.4.6`) version of Storybook (but also older ones), when you build, the generated `index.html` contains an inline JS script that loads multiple modules from the `sb-addons` directory like this:
```html
<script type="module">
      import './sb-manager/runtime.js';
      import './sb-addons/links-0/manager-bundle.js';
      ...
</script>
```
Because of those inline scripts you cannot deploy the built Storybook to servers which disallow inline scripts - those without the `'unsafe-eval'` keyword in the `script-src` directive of the `Content-Security-Policy` header. In such a case the following errors are printed to the console

```
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src-elem 'self' (...) 
Either the 'unsafe-inline' keyword, a hash ('sha256-RhcCYMSY2FJ3z4CfT91f0yzMRMOnSRU4Enu8927xA3E='), or a nonce ('nonce-...') is required to enable inline execution.
```
Having `'unsafe-eval'` turned on is dangerous from the security perspective. Instead of importing modules in an inline script, the code should be extracted to a separate file and loaded via a path.

### To Reproduce

1. Set up a new Storybook project with `npx storybook@latest init`
2. Run `npm run build-storybook`
3. Inspect the file in `storybook-static/index.html`
4. Notice the inline script at the bottom of the file

### System

_No response_

### Additional context

_No response_
Repository: godot
Issue: File paths not escaped properly when opening VSCode as the external editor on Linux
Labels: bug,topic:editor,needs testing

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

Godot v4.1.1.stable.mono - Ubuntu 23.04 23.04 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (nvidia; 535.113.01) - AMD Ryzen 5 3600X 6-Core Processor (12 Threads)

### Issue description

When I attempt to open a .cs file from Godot's filesystem window, nothing happens. Editor settings are set up as they should be.

After some investigation of how the actual parameters Godot passes to VSCode look like, it turned out that the problem is in the spaces in the path. A project stored at `/media/grizeldi/Stuff/Godot Projects/Project` will not open the .cs files properly, while a project stored at `/home/grizeldi/Desktop/Project` will open VSCode just fine.

Manually trying to launch VSCode from the terminal with the exact parameters Godot uses weirdly does end up in VSCode opening, but it creates some bogus files in the process as it treats the string on one end of the space as one path and the other end as another path. Escaping the paths with double quotation marks when launching from the terminal fixes the problem and opens VSCode as intended.

### Steps to reproduce

1. Be on Linux
2. Set up Godot for c# usage with VSCode
3. Create a project in a folder which contains a space in its name
4. Create a .cs file in the project
5. Attempt to open the file from Godot's filesystem window

### Minimal reproduction project

N/A
Repository: stable-diffusion-webui
Issue: Editable diffusion
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Exist a extensión to editate like in paint, and see interactively results like this:

https://youtube.com/shorts/YecV3sJCigk?si=SB_2WTyVumFG087J

?



### Proposed workflow

1. Found or Construct a extesión to drawing in master draw with colors palets, like paint.
2. Make a interface to changin latent automaticaly manual draw to stable diffusion generated, similar to img2img but overposeed like this: https://youtube.com/shorts/YecV3sJCigk?si=SB_2WTyVumFG087J
3. Joy

### Additional information

Joy
Repository: flutter
Issue: Windows trackpad pinch gesture has wrong focal point
Labels: engine,platform-windows,a: desktop,P2,team-windows,triaged-windows

### Steps to reproduce

Create a gesture detector and add a callback on ScaleUpdate to inspect the focal point of the scale gesture and the number of pointer that it has.
```
 GestureDetector(
      onScaleUpdate: (d) {
        print("Focal Point: ${d.focalPoint} Scale: ${d.scale}, Pointer Count: ${d.pointerCount}");
      },
      child: Container(
        color: Colors.red,
        child: Center(),
      ),
   );
```

Then try to pinch and zoom first with a trackpad and then with a touch device.

### Expected results

When Using The Touch device, the `focalPoint` stays correctly around the center of the gesture (give or take a take a few pixel due to human error) and the `pointerCount` is 2 as expected.

### Actual results

When performing the same gesture on the trackpad (I am using the same device,  a windows laptop with a touch screen), the focal point changes a lot (it appears to coincide with the location of one pointer) and the pointerCount is 1 despite using two fingers to perform the action.

### Code sample

<details><summary>Code sample</summary>

```dart
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      title: 'Flutter Demo',
      home: MyHomePage(),
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onScaleUpdate: (d) {
        print("Focal Point: ${d.focalPoint} Scale: ${d.scale}, Pointer Count: ${d.pointerCount}");
      },
      child: Container(
        color: Colors.red,
        child: const Center(),
      ),
    );
  }
}
```

</details>

### Flutter Doctor output

<details><summary>Doctor output</summary>

```console
[√] Flutter (Channel stable, 3.13.6, on Microsoft Windows [Version 10.0.22621.2283], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[X] Android toolchain - develop for Android devices
    X cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.4.0)
[!] Android Studio (not installed)
[√] VS Code (version 1.83.0)
[√] Connected device (3 available)
[√] Network resources

! Doctor found issues in 2 categories.
```

</details>
Repository: next.js
Issue: Not downloading all the required files like tailwind, APIs, public, or any any directory when the command $ npx create-next-app -e tailwindcss ./ is given to terminal
Labels: bug

### Link to the code that reproduces this issue

https://github.com/AryanParashar24/next.js_issue.git

### To Reproduce

Start the terminal command line interface or terminal in vscode and then after entering in to the required directory we want our application packages, directories and files to be present write the code:
 npx create-next-app -e with-tailwindcss ./
![image](https://github.com/vercel/next.js/assets/118893334/791d7e36-e951-4d8f-abc3-e103e4afcf9f)


### Current vs. Expected behavior

Expected behavior: Should install all the required files like tailwindcss files, typescript files various favicons, public, node_modules, next, public and src files in the directory

Current behaviour: We get to see that only Readme.md file and a gitignore file has been initialized within the directory thus stopping/slowing down the production of code

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Home Single Language
Binaries:
  Node: 18.16.1
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 13.5.5-canary.2
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

Deployment Status: The application is currently in the development phase and has not been deployed yet. It's being used locally on your machine in Visual Studio Code for setting up the environment.

Environment: Using Visual Studio Code as your development environment.

Error Occurrence: The error started appearing during the process of setting up the environment and downloading packages.
Repository: next.js
Issue: Included library functions with similar names have different behaviour in dev vs production builds
Labels: bug

### Link to the code that reproduces this issue

https://github.com/PenguinOfWar/rdg-nextjs-bundle-bug

### To Reproduce

1. `npm install react-data-grid`
2. Configure an editable cell grid per the [common features example](https://github.com/adazzle/react-data-grid/blob/main/website/demos/CommonFeatures.tsx) of `react-data-grid` (see reproduction repo)
3. `npm run dev`, open localhost and double click to edit a name cell
4. `npm run build && npm run start`, open localhost and attempt to double click to edit name cell to see the difference in behaviour

### Current vs. Expected behavior

Following the steps from the previous section, I expected `npm run dev` and `npm run build && npm run start` to exhibit the same behaviour. Instead, two functions within the lib with the same name are bundled differently in development vs production.

Going through the compiled lib code with some strategic logging shows that the production build version of the code prefers the utility `isCellEditable` rather than the function inside `DataGrid`. As they accept two different arguments sets, this breaks the edit feature of the lib and showcases the issue within next.

The problem can be replicated on node 18 & 20, as well as across npm 9 & 10. Using dynamic imports does not help.

See: adazzle/react-data-grid#3356

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103
Binaries:
  Node: 20.5.1
  npm: 10.0.0
  Yarn: N/A
  pnpm: 8.1.0
Relevant Packages:
  next: 13.5.5-canary.2
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

I tested this on `13.15.4` and the canary release and could replicate on both.
Repository: neovim
Issue: vim.ui enhancements: proposal and tracking issue
Labels: enhancement,ui,provider,lua,options

This ticket specifically tracks enhancements and modifications to `vim.ui` proposed in #25272 and related issues.

# Problem

Creating floating windows with all of the visual goodies that most users expect and want requires a lot of boilerplate. This boilerplate has coalesced into `vim.lsp.util.open_floating_preview`, but such functionality should be both (1) pruned down and curated into a more thoughtful and coherent interface, and (2) moved out of `vim.lsp.util` and into `vim.ui`.

# Solution

Create `vim.ui.open_win` that handles the use case of creating windows of all kinds in an ergonomic way.

## Requirements

* `vim.ui.open_win` should be able to open floating windows as well as splits (horizontal and vertical) and tabs.
* `vim.ui.open_win` should substantially reduce boilerplate for creating and opening floating windows.

## Proposed interface

```lua
--- @param contents string[]|int An array of strings containing the lines
---                              of text to display in the window OR an
---                              integer representing a buffer number to
---                              display in the window
--- @param opts table Options table (see details below)
--- @return number |winid| of new window
vim.ui.open_win(contents, {
  -- Opts table is a "sum type" / "union", the type of window it
  -- creates is based on the top-level key provided. It as an error
  -- to provide more than one top-level key
  float = {
    -- Create a floating window. All keys from |nvim_open_win()| are valid in this table.
    -- Omitted keys use default values from |vim.ui.config()|.
    height = 100,
    width = 50,
  },

  split = {
    -- Create a split
    vertical = true | false, -- defaults to false
  },

  tab = {
    -- Create a new tab
  }
})
```

In addition, create `vim.ui.config()` that sets default values for some options. This should work similarly to `vim.diagnostic.config()`. Plugin authors can use `vim.ui.open_win()` and omit values to use the defaults supplied by the user in `vim.ui.config()`:

```lua
vim.ui.config({
  float = {
    border = "rounded",
  },
  split = {
    -- Prefer vertical splits by default
    vertical = true,
  },
})
```

`vim.ui.config()` is not limited to configuring options for `vim.ui.open_win()`, but covers any user-definable default/preference for anything under `vim.ui`.
Repository: angular
Issue: Control flow `for` loop - support fallback track function
Labels: area: core,core: control flow

### Which @angular/* package(s) are relevant/related to the feature request?

compiler, core

### Description

Current behavior of the new Angular Control Flow `for` loop requires user to always pass `track` expression:

```html
@for(item of parts; track item) {
    {{item}} 
}
```

Skipping `track` expression breaks angular compilation:

```html
@for(item of parts) {
    {{item}} 
}
```

<img width="664" alt="image" src="https://github.com/angular/angular/assets/6583977/07deed4f-5a1e-48e5-987e-b9b5e53d8682">

---

For application that uses `for` loop it is a common task that loops are tracked by eg. collection element unique id: `item.id`.
It would be great to have the possibility to define fallback `track` function that can be used if no `track` expression is passed.


### Proposed solution

One of the possibility is to have an injection token that user can use to provide fallback track function:

```ts
type CollectionItem = { id: number };

@Component({
  selector: 'app-component',
  standalone: true,
  template: `
    <div>
    @for(item of collection) {
        <p>{{item.id}}</p>
    }
    </div>
  `,
  providers: [
    {
      provide: FOR_LOOP_DEFAULT_TRACK,
      useValue: (item: CollectionItem) => item.id,
    },
  ],
})
export class MyComponent {
  protected collection: CollectionItem[] = [{ id: 1 }, { id: 2 }, { id: 3 }];
}
```

### Alternatives considered

???
Repository: go
Issue: html/template: investigate using x/net/html for parsing
Labels: NeedsInvestigation

In a similar vein as #63371.

There have been a number of issues with html/template related to mis-parsing HTML (e.g. [http://go.dev/cl/526157](http://go.dev/cl/526157), [https://go-review.googlesource.com/c/go/+/526156](https://go-review.googlesource.com/c/go/+/526156), etc). In part this is because the package implements a rather naive, lightweight parser, which does not implement all of the rules of html/template.

There are two particular problems this creates: (1) html/template does not catch syntactic errors in templates, meaning a user can create a template which cannot be reasonably parsed by downstream consumers (i.e. browsers), and (2) because html/template does not implement HTML normalization rules, a user can create a template which will be interpreted differently by html/template and a downstream consumer (i.e. because nodes may be moved around, or tags normalized, etc). I haven't found a particular case of this yet (mostly because I haven't looked too closely), but it is plausible that (2) could cause contextual escaping to operate incorrectly, since the context that html/template derives an action is in may be different from the context the action actually ends up in after HTML normalization rules are applied.

One option to fix this would be to use the golang.org/x/net/html parser in html/template instead of the lightweight parser we currently use. x/net/html contains a (mostly) fully specification complaint parser that applies all of the expected normalization rules when constructing the DOM tree. Using this parser we could normalize the template before doing contextual escaping, resulting in outputted HTML which will match how browsers parse the document (assuming the user isn't directly inserting additional HTML into the document).

The argument against using x/net/html is precisely because it does normalization, which could result in output which does not strictly match the template as written (i.e. because missing tags could be inserted, or nodes reordered according to the specification). I think this is arguably acceptable, since it should be clear to the user how the HTML they are producing will be interpreted (i.e. normalizing/catching syntax errors before consumption by a browser gives the user a chance to catch that something is broken, and possibly fix it). That said this arguably would be a breaking change, so if we do consider doing this it may only be viable as a v2 API of the existing package .

The main upside of this change would be no longer needing to maintain two parsers (of wildly varying quality), and providing significantly more "correct" HTML output for users.
Repository: rust
Issue: `splice` usage may be incorrect if it is possible for the source to be mutated
Labels: O-linux,C-bug,S-blocked,T-libs,A-io

It seems `std::io::copy` sometimes invokes `splice` on Linux. Don't do this! Using `splice` can lead to data corruption (one user reported that his backups was damaged). Also, Linus Torvalds said that `splice` should not be used as general-purpose copy tool. See details here: https://github.com/systemd/systemd/issues/29044 . There are situations where `splice` is okay, but it is not good as general-purpose copy mechanism. Use of `sendfile` and `copy_file_range` should be questioned, too. Any other use of `splice` in `std` should be audited, too

Rust version: 90f3a6f920df62c02c52b6a2c0e9e43aa029a778
Repository: stable-diffusion-webui
Issue: [Feature Request]: Allow viewing the images as they are being generated
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

When generating a large number of images, I'd like to be able to view the already generated ones, (and stop the generation if I find one good enough).


### Proposed workflow

1. Go to txt2img
2. Set Batch count 100
3. Click Generate
4. As soon as the first batch is done, it's added to the list of images, ready to be viewed. When I press "right" on the last image it shall not do anything!
5. As soon as the 2nd batch is done, it's added to the list of images. If I was on the last image, I can press "right" to view the first image of the 2nd batch, and so on..


### Additional information

_No response_
Repository: storybook
Issue: [Bug]: Chromatic NPM Package / Remote Deployment Broken with PNPM
Labels: bug

### Describe the bug

I install chromatic NPM package into my monorepo using PNPM, 

then I run npx chromatic --project-token=[xxxx]

build fails with message: 

Error: page.evaluate: Error: Cannot find module './node_modules/@storybook/react/template/stories/decorators.stories.tsx'



### To Reproduce

I install chromatic NPM package into my monorepo using PNPM, 

then I run npx chromatic --project-token=[xxxx]

build fails with message: 

Error: page.evaluate: Error: Cannot find module './node_modules/@storybook/react/template/stories/decorators.stories.tsx'


### System

```bash
Environment Info:

  System:
    OS: macOS 13.6
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 18.11.0 - ~/.asdf/installs/nodejs/18.11.0/bin/node
    Yarn: 1.22.19 - ~/.asdf/installs/nodejs/18.11.0/bin/yarn
    npm: 8.19.2 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: 117.0.5938.132
    Safari: 16.6
  npmPackages:
    @storybook/addon-essentials: 7.0.17 => 7.0.17
    @storybook/addon-interactions: 7.0.17 => 7.0.17
    @storybook/addon-links: 7.0.17 => 7.0.17
    @storybook/addon-styling: 1.0.8 => 1.0.8
    @storybook/blocks: 7.0.17 => 7.0.17
    @storybook/react: 7.0.17 => 7.0.17
    @storybook/react-webpack5: 7.0.17 => 7.0.17
    @storybook/testing-library: 0.1.0 => 0.1.0
```


### Additional context

_No response_
Repository: pytorch
Issue: AOTAutograd logging: log autograd graphs
Labels: module: logging,triaged,actionable,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

### 🐛 Describe the bug

For debugging purposes, it would be helpful to have something like this:

```
diff --git a/torch/_functorch/aot_autograd.py b/torch/_functorch/aot_autograd.py
index 84a176222ef..b094952890e 100644
--- a/torch/_functorch/aot_autograd.py
+++ b/torch/_functorch/aot_autograd.py
@@ -1313,6 +1313,9 @@ def create_joint(
         backward_out = []
         # Call the backwards pass
         if grad_primals:
+            from torchviz import make_dot
+            for out in needed_outs:
+                log.warning("DOT GRAPH\n%s", make_dot(out))
             with fx_traceback.preserve_node_meta():
                 # for full graph export, we always export a joint graph where we assume no tangents are needed.
                 if aot_config.no_tangents:
```

cc @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang

### Versions

main
Repository: pytorch
Issue: ValueError issued instead of TypeError when tensor is cast to a scalar
Labels: module: error checking,triaged,module: numpy

### 🐛 Describe the bug

When using `math.isfinite` with a tensor a wrong `ValueError` is issued instead of a `TypeError`. This creates bugs (see #109819). Fixing this issue will fix the other one as well.

```python
>>> import math, torch
>>> a = torch.randn(5)
>>> math.isfinite(a)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[3], line 1
----> 1 math.isfinite(a)

ValueError: only one element tensors can be converted to Python scalars

>>> math.isfinite(a.numpy())
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[4], line 1
----> 1 math.isfinite(a.numpy())

TypeError: only size-1 arrays can be converted to Python scalars
```

### Versions

`PyTorch version: 2.0.1`

cc @malfet @mruberry @rgommers
Repository: godot
Issue: Resource Variables Are Reset When Duplicated Before The Resource Has Been Saved
Labels: bug,topic:core,topic:editor

### Godot version

v4.1.2.stable.official [399c9dc39]

### System information

Godot v4.1.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - integrated Intel(R) UHD Graphics (Intel Corporation; 27.20.100.8984) - Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz (4 Threads)

### Issue description

When a resource is duplicated before it has been saved, the duplicate has the values of the original's current state, but the original resource itself is reset to the last saved state. 

### Steps to reproduce

This bug can only be reproduced if you do not save your resources right before duplication.

1. Create a GDScript that extends from resource and has an export var. Attach it to an empty resource.
2. Duplicate the resource, save your resources, and reload the project.
3. The original resource will revert to its last saved state. This could be anything from having the wrong variables to losing the attached script entirely.

### Minimal reproduction project

[ResourceTest.zip](https://github.com/godotengine/godot/files/12824881/ResourceTest.zip)