sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: docs container - Storybook preview hooks can only be called inside decorators and story functions
Labels: bug,has workaround,upgrade:8.2

### Describe the bug

I'm using `storybook-dark-mode` to toggle my stories between light and dark mode.

It works in stories, but the theme in the autodocs are not updated automatically.

To address that, I use a custom doc container:

```ts
// .storybook/preview.tsx
import type { Preview } from '@storybook/react';
import { DocsContainer, type DocsContextProps } from '@storybook/blocks';
import { themes } from '@storybook/theming';
import React, { type PropsWithChildren } from 'react';
import { useDarkMode } from 'storybook-dark-mode';

export interface DocsContainerProps {
  context: DocsContextProps<any>;
}
function ThemedContainer(props: PropsWithChildren<DocsContextProps>) {
  const dark = useDarkMode();
  return (
    <DocsContainer context={props} theme={dark ? themes.dark : themes.light}>
      {props.children}
    </DocsContainer>
  );
}
const preview: Preview = {
  parameters: {
    controls: {
      matchers: {
        color: /(background|color)$/i,
        date: /Date$/i,
      },
    },
    docs: {
      container: ThemedContainer,
    },
  },
};

export default preview;

```

This is working is storybook 8.1, but broken in 8.2.

### Reproduction link

https://stackblitz.com/edit/github-2sfagn?file=.storybook%2Fpreview.tsx

### Reproduction steps

open the repro

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.5
    CPU: (10) arm64 Apple M1 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v20.12.2/bin/npm
    pnpm: 9.0.4 - ~/.nvm/versions/node/v20.12.2/bin/pnpm <----- active
  Browsers:
    Chrome: 127.0.6533.72
    Safari: 17.5
```


### Additional context

_No response_
Repository: electron
Issue: [Bug]: No shared WebLocks in same origin between frames an popups
Labels: platform/macOS,bug :beetle:,status/confirmed,has-repro-gist,web-platform-apis,31-x-y,32-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

32.0.0-beta.2

### What operating system(s) are you using?

macOS

### Operating System Version

macOS 14.5

### What arch are you using?

x64

### Last Known Working Electron version

27.3.11

### Expected Behavior

When I acquire a web lock in exclusive mode (same origin) in a popup (or iframe) then acquiring a lock with the same id in iframe (or popup) should fail.
<img width="1166" alt="Screenshot 2024-07-30 at 16 28 16" src="https://github.com/user-attachments/assets/058c75b2-dddf-4875-ace2-dabc4c256264">


### Actual Behavior

Currently it is possible to acquire a lock twice in same origin. One in a popup, one in an iframe.

### Testcase Gist URL

https://gist.github.com/be13a27c115f90868db65376698c8d56

### Additional Information

Some time ago we updated Electron version from `22.0.3` to `31.1.0` (yup, lot of versions) and from that point I saw WebLock were not shared between those both contexts (even if they're running in same origin). Not sure if it's related to my misuse / misunderstanding. Created a minimal example for reproduce.

I went through few versions and found:
Last working version: 27.3.11
First not working version: 28.0.0

Edit: There is no broadcast channel communication and localStorage is not shared between frames and popups too.
Repository: godot
Issue: physics_interpolation makes PackedVector2Aray keyframed animations inconsistent
Labels: feature proposal,documentation,topic:physics,topic:animation

### Tested versions

- Not reproducible in 4.2 stable
- Not reproducible in 4.3-dev5
- Reproducible in 4.3-dev6 and later versions

### System information

Godot v4.3.rc1 - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3050 (NVIDIA; 31.0.15.4633) - AMD Ryzen 5 1600 Six-Core Processor (12 Threads)

### Issue description

I noticed this problem when I had to animate a ```Line2D``` parent's position, and cancel-out the movement moving only the ```Line2D``` ```points``` back into place. Later I tested trying to do the same using a ```Polygon2D``` and realized it may be related to the ```PackedVector2Array``` being animated. The problem disappears if I turn ```physics_interpolation``` off in Project Settings.

Here's a comparison with ```physics_interpolation``` turned on and off:

https://github.com/user-attachments/assets/e5521ea1-5554-4753-8040-ea541eb2a4a6

https://github.com/user-attachments/assets/9255b90f-16f3-49d9-bd50-a1cdfa6fb7e7

It looks way worse If I drag the window while the animation is playing:

https://github.com/user-attachments/assets/1b7d91fb-47cc-4bf8-ab4f-6eb0b0ecad30

For comparison, notice that the ```Sprite2D``` child is doing the same counter-movement and it interpolates as intended in all cases.

### Steps to reproduce

- Have any node as a parent of ```Line2D```
- Animate the ```Line2D```'s parent to move up by any amount
- Animate the ```Line2D``` ```points``` property to keep the ```Line2D``` in place while the parent moves
- Run the project

It is only noticeable while running the project. In the editor, everything looks fine.
![image](https://github.com/user-attachments/assets/6acba9cd-59d5-44bf-a728-ddee047c4b0b)


### Minimal reproduction project (MRP)

[physics_interpolation-bug.zip](https://github.com/user-attachments/files/16429860/physics_interpolation-bug.zip)
Repository: vscode
Issue: Bring true inline view to all diff viewers
Labels: feature-request,diff-editor

I've enabled the new true inline view for diffs and would like to see them in all presented diffs. e.g. the view zone diffs when clicking on scm gutter decorations.
Repository: pytorch
Issue: [dynamo] Context manager
Labels: triaged,oncall: pt2,module: dynamo,dynamo-ctx-manager

### 🐛 Describe the bug

Tracking issue for comments made in  https://github.com/pytorch/tensordict/pull/929

### Error logs

_No response_

### Minified repro

_No response_

### Versions

NA

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames
Repository: terminal
Issue: Cannot run Windows Terminal as the same user from two different sessions
Labels: Issue-Bug,Product-Terminal,Area-Remoting

### Windows Terminal version

1.20.11781.0

### Windows build number

10.0.22631.0

### Other Software

_No response_

### Steps to reproduce

1. Log on to user _User1_.
2. Launch Windows Terminal.
3. "Lock".
4. Log on to user _User2_.
5. (Optional: Launch Windows Terminal and see that it works.)
6. Launch Windows Terminal as user _User1_.
   Ways to do it:
   1. While holding Shift, right-click on `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.20.11781.0_x64__8wekyb3d8bbwe\wt.exe`, pick _Run as a different user_, and enter credentials.
   2. From whatever command-line shell you like run `runas.exe /user:User1 cmd.exe`, enter credentials, and in the resulting `cmd.exe` instance run `wt.exe`.
   3. ... Any other way you like.

### Expected Behavior

Launch.

The same as would have happened if we had closed Windows Terminal is the first TS session.

### Actual Behavior

<img width="419" alt="Screenshot 2024-07-30 190000" src="https://github.com/user-attachments/assets/38f38bbd-ba5e-4929-90bf-0a86ece36cc2">

### Important

Note that:

- If we don't launch the first Windows Terminal, or if close it before attempting to launch the second instance, Windows Terminal would launch properly.
- If the two sessions belonged to the same user (e.g. on a Windows server that's configured to allow multiple sessions for the same user) Windows Terminal would launch properly.
- If we use the [ZIP distribution of Windows Terminal](https://github.com/microsoft/terminal/releases/download/v1.20.11781.0/Microsoft.WindowsTerminal_1.20.11781.0_x64.zip), we can launch it as the same user from multiple sessions belonging to different users.
- This is not an inherent limitation of apps distributed via the Microsoft Store or as MSIX outside the Microsoft Store, since WinDbg is distributed as an MSIX (https://windbg.download.prss.microsoft.com/dbazure/prod/1-2308-2002-0/windbg.msixbundle) and it can launch as the same user from different sessions belonging to different users and it works also with the older version of WinDbg that's on the Microsoft Store.
Repository: tauri
Issue: [bug] Videos loading 200 bytes at a time
Labels: type: bug,platform: macOS

### Describe the bug

It appears that when using a `video` element videos load anywhere from 100bytes at a time to 100kb at a time. I cant imagine this is intended as it's creating thousands of requests in the network panel.

I've also noticed that when pausing videos that there's a chance that the player just becomes blank.



### Reproduction

minimal repro: https://github.com/FinnDore/tauri-byte-by-byte. Do note that you need to change this path to point toward a video before building. https://github.com/FinnDore/tauri-byte-by-byte/blob/main/src/App.tsx#L6

one of the videos I was using to test is: https://www.youtube.com/watch?v=dUIQvqqq-cg

### Loading 200bytes at a time
https://github.com/user-attachments/assets/ec6b9c04-27c6-457d-b68f-ad15aaf1da95

### Pausing troubles
https://github.com/user-attachments/assets/9bce57bd-7cbb-49dd-bcb9-e74074c6baf3


### Expected behavior

I would expect media to load in bigger chunks. ( but I may be incorrect ovcourse )

### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.2.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.12.2
    - pnpm: 7.33.5
    - yarn: 1.22.19
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.25
    - tauri-build [RUST]: 2.0.0-beta.19
    - wry [RUST]: 0.41.0
    - tao [RUST]: 0.28.1
    - cargo-tauri [RUST]: 1.1.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.16
    - @tauri-apps/cli [NPM]: 2.0.0-beta.23

[-] App
    - build-type: bundle
    - CSP: default-src 'self' ipc: http://ipc.localhost; img-src 'self' asset: http://asset.localhost
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

here im using the tauri 2 beta
Repository: PowerToys
Issue: The if running option for remap shortcuts is not working as expected
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.82.1

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

So I set Alt(left) + O as a shortcut to run the calculator program. There are two file locations I tried "C:\Windows\System32\calc.exe" and "C:\Windows\SysWOW64\calc.exe". Both opened the calculator app, but I had the <If running> option set to <show window> and it did not show the window, it instead opened another calculator window when pressing the keyboard shortcut again. 

I also tried changing the <if running> option to <do nothing>, <close>, and <end task> but none of those worked as expected and it would just open another window.

Here is how I have it setup.
![image](https://github.com/user-attachments/assets/9353ef02-6c2e-4705-9323-02dfad9cdf3e)

If there is something that I missing please let me know any help if greatly appreciated. 

### ✔️ Expected Behavior

I would expect it to show the already opened window if the <show window> option is selected.
Then the other ones to perform as purposed.  

### ❌ Actual Behavior

No matter the option I have selected for <if running> it opens another calculator window. 

### Other Software

_No response_
Repository: flutter
Issue: CanvasKit renderer does not handle platform view clipping properly
Labels: engine,a: platform-views,platform-web,e: web_canvaskit,P2,team-web,triaged-web

I am adding some platform view clipping unit tests in https://github.com/flutter/engine/pull/54201 and it appears the CanvasKit renderer is not actually clipping the platform views as expected. The platform views end up fully invisible in each of the clipping test cases. The picture content is clipped as expected.
Repository: flutter
Issue: HTML renderer does not clip picture content properly with platform views
Labels: engine,a: platform-views,platform-web,e: web_html,P3,team-web,triaged-web

I am adding some platform view clipping unit tests in https://github.com/flutter/engine/pull/54201. While it appears the HTML renderer clips the platform views themselves properly, the surrounding picture content gets clipped incorrectly (it is basically entirely removed in most of the test cases.
Repository: rust
Issue: Tracking Issue for `bufreader_peek`
Labels: T-libs-api,C-tracking-issue,F-bufreader_peek

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(bufreader_peek)]`

This is a tracking issue for the `BufReader::peek` method.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// std::io

impl BufReader {
    fn peek(&mut self, n: usize) -> io::Result<&[u8]>
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] ACP Accepted: https://github.com/rust-lang/libs-team/issues/417
- [x] Implementation: https://github.com/rust-lang/rust/pull/128406
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- what should happen if `n` > `capacity`? options are: short slice, error, or panic.
- should the buffer be completely filled, or should it only read the number of bytes requested?

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"lolbinarycat"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: ollama
Issue: Refactor num_parallel tracking in scheduler 
Labels: bug

### What is the issue?

The current code passes a pointer and mutates it as we try to determine what the optimal parallel setting is, which makes the code hard to follow. 

### OS

_No response_

### GPU

_No response_

### CPU

_No response_

### Ollama version

_No response_
Repository: go
Issue: net/http: client/transport should be more defensive against servers which write a body in response to HEAD requests
Labels: NeedsInvestigation

### Go version

go version go1.22.5 linux/amd64

### Output of `go env` in your module/workspace:

```shell
N/A
```


### What did you do?

The Go HTTP client/transport may reuse connections which have been used for a HEAD request. If the server wrote a body to the response, the Go HTTP client/transport may use that body as if it were the start of a new request.

Ref: #68609

### What did you see happen?

```
attempt 0
2024/07/26 16:17:17 Unsolicited response received on idle HTTP channel starting with "<!DOCTYPE html>\n<html>\n  <head>\n    <title>Thomas</tit"; err=<nil>
attempt 1
2024/07/26 16:17:17 Unsolicited response received on idle HTTP channel starting with "<!DOCTYPE html>\n<html>\n  <head>\n    <title>Thomas</tit"; err=<nil>
attempt 2
2024/07/26 16:17:17 Unsolicited response received on idle HTTP channel starting with "<!DOCTYPE html>\n<html>\n  <head>\n    <title>Thomas</tit"; err=<nil>
attempt 3
2024/07/26 16:17:17 Unsolicited response received on idle HTTP channel starting with "<!DOCTYPE html>\n<html>\n  <head>\n    <title>Thomas</tit"; err=<nil>
attempt 4
2024/07/26 16:17:17 Unsolicited response received on idle HTTP channel starting with "<!DOCTYPE html>\n<html>\n  <head>\n    <title>Thomas</tit"; err=<nil>
attempt 5
2024/07/26 16:17:17 Unsolicited response received on idle HTTP channel starting with "<!DOCTYPE html>\n<html>\n  <head>\n    <title>Thomas</tit"; err=<nil>
attempt 6
attempt 7
2024/07/26 16:17:18 do: Head "http://localhost:8080": net/http: HTTP/1.x transport connection broken: malformed HTTP status code "html>"
exit status 1
```

### What did you expect to see?

The Go HTTP client/transport should be more defensive and not get tripped up on servers misbehaving like this. It's not uncommon for this to happen, as noted in https://github.com/golang/go/issues/68609#issuecomment-2253684837. It's quite problematic as there are lots of reverse proxies which rely on the net/http transport (cloudflared, caddy, etc).

![image](https://github.com/user-attachments/assets/fa15bb4a-0cd5-4def-9df1-9d6f38a610b7)

![image](https://github.com/user-attachments/assets/d5519d78-b455-4714-be69-28f93d052f2b)
Repository: ui
Issue: [bug]: support nonces for usage of inline CSS required for certain components to work, currently incompatibility when using a Content Security Policy (CSP) that doesn't add unsafe-inline for CSS
Labels: bug

### Describe the bug

Certain components don't work when unsafe-inline is not defined in the CSP, a security incompatibility that should be resolved so shadcn can also be used by development teams under strict security requirements. I hope the shadcn team also takes security seriously and wants to support this 🙏 

If CSS can be injected by an attack, it can aid in social engineering attacks by confusing the target users.

Seems to be a problem with Toast as well as the third-part library Sonner: https://github.com/emilkowalski/sonner/issues/449

This issue seems to remain closed even after requesting it to be re-opened: https://github.com/shadcn-ui/ui/issues/2891

### Affected component/components

Toast, Sonner, Tabs, Dialog, Sheet, Command

### How to reproduce

Use any CSP with the `style-src` directive set to anything other than `unsafe-inline`.

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash
Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-xxx'". Either the 'unsafe-inline' keyword, a hash ('sha256-xxxx='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
```


### System Info

```bash
Not relevant
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: godot
Issue: Exports from CLI return exit code 0 when failed to build project.
Labels: bug,topic:editor,needs testing,topic:export

### Tested versions

- Reproducible in v4.3.rc1.mono.official.e343dbbcc
- Reproducible in v4.3.dev6.mono.official.64520fe67

### System information

Tested on Linux and macOS

### Issue description

Godot returns exit code 0 when the build fails.

Errors when exporting a project should be communicated via the process exit code, so that build systems can pick up the failure instead of continuing.

A workaround is to grep for error strings (either known strings that can false-negative when a new error happens, or broad generic strings that can false-positive with minor errors, from Godot or the project itself).

Related issues:
- https://github.com/godotengine/godot/issues/90646
- https://github.com/godotengine/godot/issues/83449
- https://github.com/godotengine/godot/issues/83042
- https://github.com/godotengine/godot/pull/89234
- https://github.com/godotengine/godot/pull/89229


### Steps to reproduce

Create a new project, add C# script with a syntax error, and export to Linux (any other platform should behave the same way) with:

`$ godot --headless --export-release Linux output`

The exit code (you can check it with `echo $?`) should not be 0 since there was a failure during the export. It is 0.

(see `run_export.sh` on the linked repo or zip below)

### Minimal reproduction project (MRP)

https://github.com/franciscod/godot-exit
[godot-exit.zip](https://github.com/user-attachments/files/16432162/godot-exit.zip)
Repository: TypeScript
Issue: Reference counts are incorrect in TS code lenses
Labels: Bug,Help Wanted

In TypeScript, the reference counts shown in codelenses are incorrect

* open `async.ts` and go to `first`
* observe the code lens shows 7 references
* in reality, there are only 4 references, 3 of those locations are imports which are an artefact of the real references, they should not be counted as references.
* this dillutes a lot the value of having a number in the code lens and makes it difficult to understand




![Image](https://github.com/user-attachments/assets/881bdc3e-6a2f-45be-b51a-1f4b8a1a3519)