sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tauri
Issue: [bug] Tauri does not detect system theme preference on Linux
Labels: type: bug,platform: Linux,status: needs triage

### Describe the bug

In my application I use the `prefers-color-scheme` media to change the color scheme of my app. It works on Chrome/Firefox/Epipahny (on Linux) but not on Tauri. I tried listening to `tauri://theme-changed` for what Tauri sees but the result is always `light` even if dark mode is enabled in GNOME.

### Reproduction

1. Make a new Tauri project using V1
2. Listen to `tauri://theme-changed` for theme changes or directly print the `appWindow.theme()` promise
3. See that `light` returns even if a dark theme is active in the system

### Expected behavior

I expect it to return `dark` if the system is using a dark theme.

### Full `tauri info` output

```text
[✔] Environment
    - OS: Linux Unknown X64
    ✔ webkit2gtk-4.0: 2.42.4
    ✔ rsvg2: 2.54.7
    ✔ rustc: 1.77.1 (7cf61ebde 2024-03-27)
    ✔ cargo: 1.77.1 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 18.19.0
    - pnpm: 8.15.5
    - npm: 9.2.0

[-] Packages
    - tauri [RUST]: 1.6.1
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.8
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

For instance, I am using the default theme (Adwaita) in GNOME 44.8. I also managed to reproduce the same issue using Tauri v2.
Repository: storybook
Issue: [Bug]: Mobile/Touch Zoom and Swipe are not working
Labels: bug,ui

### Describe the bug

When viewing your storybook in Mobile/touchscreen settings you are unable to pinch to zoom or swipe to refresh.  

### To Reproduce

1. Visit a storybook story on a mobile device or touchscreen capable device.
2. Attempt to pinch to zoom in and out 
3. You will be unable to zoom using touch controls

### System

```bash
Storybook - version 8.0.6
Android - Version 14
Device - Pixel 7
Browser - Brave and Chrome
```


### Additional context

_No response_
Repository: pytorch
Issue: Improve Foreach OpInfo test infra to enable meta coverage
Labels: triaged,module: testing,module: mta,oncall: pt2

## Problem
Currently, many meta tests are skipped for foreach ops. See https://github.com/pytorch/pytorch/blob/b18d8d4595aa6e0768eedd5fc7d4a4402c567181/torch/testing/_internal/common_methods_invocations.py#L9422-L9429. 

For inplace `add`, `mul`, `div`, `addcmul`, and `addcdiv` in particular, we only run the meta tests for complex dtypes because some of their sample inputs include complex Scalars that lead to errors when the Tensor is noncomplex. For example, you cannot inplace add:
```
a = torch.rand(2, 3)
a.add_(3.14 - 2.7j)
```
Since the memory for `a` is not big enough to fit the complex result. Likewise the foreach version of `add` runs into the same errors, as it should!

The problem occurs when we are attempting to compare the meta impl of `_foreach_add` to the actual implementation. The actual implementation will error (which is the correct behavior), and the meta test will also error as a result, see https://github.com/pytorch/pytorch/blob/main/test/test_meta.py#L542.

To make tests pass, the precedent has been to say "screw it, just skip all noncomplex dtypes" for inplace ops but this misses out on a lot of coverage for the other sample inputs that didn't contain complex values. This was brought to my attention from our endeavor in #123486 with @awgu, in which we uphold the precedent but it makes me sad to.

## Proposal:
We can split up the foreach sample inputs into two categories: 1. those that succeed 2. those that error, which we will separate out as ErrorInputs. For the first category, we should run all our existing tests on these. For error inputs, we should just check that they error the same way as the original nonforeach versions.

This way, we will be able to run all the meta tests for the inputs that matter. The challenge here is being able to split the current inputs into these two categories, which may be less trivial compared to a first glance.

## Alternatives
A. Modify the meta test to allow foreach ops to pass when an erroring sample input is run. 
B. Do nothing, allow the majority of dtypes to be skipped.

cc @crcrpar @mcarilli @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang
Repository: PowerToys
Issue: Steps Recorder
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

I tool like the windows 7 Steps Recorder because it will be deprecated.
https://prod.support.services.microsoft.com/en-us/windows/steps-recorder-deprecation-a64888d7-8482-4965-8ce3-25fb004e975f

### Scenario when this would be used?

When you want to make toturial for someone else or just record the steps for a process installation. It's could be share-able

### Supporting information

_No response_
Repository: terminal
Issue: [1.21] Hot reloading to set a newly-installed font doesn't work
Labels: Area-Fonts,Issue-Bug,Product-Terminal

### Windows Terminal version

1.21

### Windows build number

_No response_

### Other Software

_No response_

### Steps to reproduce

Install a new font.

Set it as the font.

Save settings.

### Expected Behavior

_No response_

### Actual Behavior

You'll get one error dialog per open terminal, and they'll switch to Consolas.

Newly-opened panes will use the specified font.
Repository: ant-design
Issue: DatePicker doesn't focus on picker panel on tab
Labels: Inactive,⌨️ Accessibility

### Reproduction link

[https://ant.design/~demos/components-date-picker-demo-basic](https://ant.design/~demos/components-date-picker-demo-basic)

### Steps to reproduce

Click on any of the DatePicker input field and press tab. It will focus on other DatePicker inputs and close the picker panel.

### What is expected?

In AntD v4 (https://codesandbox.io/p/sandbox/basic-antd-4-24-16-jzxz87), when the DatePicker input field is clicked and tab is pressed, the picker panel will be focused and you can use the arrow keys to select new dates.

### What is actually happening?

Other DatePicker input fields are being focused and the picker panel is closed when the tab key is pressed.

| Environment | Info |
| --- | --- |
| antd | 5.16.1 |
| React | 18 |
| System | MacOS |
| Browser | Chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Project Manager removes favourites on start up
Labels: discussion,topic:editor

### Tested versions

v4.3.dev5.official [89f70e98d]



### System information

Windows 11, Godot v4.3.dev5.official [89f70e98d]

### Issue description

The project manager removes the favourite markers on start up. 

### Steps to reproduce

Mark project(s) as favourite in v4.2.1.stable.official [b09f793f5] for example.
Then open v4.3.dev5.official [89f70e98d] project manager and all favourites become unset.

Saving favourites works though. When I mark projects as favourite, and then open the project manager in 4.2.1 they are marked.



### Minimal reproduction project (MRP)

Just create an empty project and mark it as favourite.
Repository: flutter
Issue: [flutter_tools] Tool should enforce that Flutter project directories only built from one host platform
Labels: P2,team-tool,triaged-tool

We should check and toolexit if a user tries to build a flutter project from multiple different operating systems (for example, Windows host and WSL host).

This is not supported and violates many assumptions in the tool.

For users who want to build the same project from multiple operating systems, they should have multiple checkouts of their application, and each should only be built from a single operating system.
Repository: storybook
Issue: [Bug]: pinia doesnt work when loading components from other apps in monorepo
Labels: bug,needs triage

### Describe the bug

When loading a story in /apps/storybook that imports .vue files from /apps/vue, which utilize Pinia and contain a store within the external .vue component, Pinia is undefined. However, this issue does not occur when the same Pinia.vue component is loaded directly from app/storybook. 

Works as expected in dev, so it's a build only issue. 
  


### To Reproduce

Clone https://github.com/olemarius/storybook-pinia-repro

run build in package.json
run build-storybook in apps/storybook/package.json
open apps/storybook/storybook-static/index.html

## Working

```js
import type { Meta, StoryObj } from '@storybook/vue3';
import Pinia from './Pinia.vue';

const meta = {
  title: 'Pinia/Works',
  component: Pinia,
  render: () => ({
    components: { Pinia },
    template: '<Pinia />',
  }),
  parameters: {
    layout: 'fullscreen',
  },
  tags: ['autodocs'],
} satisfies Meta<typeof Pinia>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Default: Story = {
};


```
![image](https://github.com/storybookjs/storybook/assets/184536/05052d80-57a2-4d1a-b2e1-a2c10e148354)

## Not working

```js
import type { Meta, StoryObj } from '@storybook/vue3';
import Pinia from '../../../../vue/src/Pinia.vue';

const meta = {
  title: 'Pinia/Error',
  component: Pinia,
  render: () => ({
    components: { Pinia },
    template: '<Pinia />',
  }),
  parameters: {
    layout: 'fullscreen',
  },
  tags: ['autodocs'],
} satisfies Meta<typeof Pinia>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Default: Story = {
};
```
![image](https://github.com/storybookjs/storybook/assets/184536/18cb288c-7954-4e95-83eb-36ab790368d1)


### System

```bash
Storybook Environment Info:

  System:
    OS: Windows 11 10.0.22631
    CPU: (22) x64 Intel(R) Core(TM) Ultra 9 185H
  Binaries:
    Node: 20.11.1 - ~\AppData\Local\Volta\tools\image\node\20.11.1\node.EXE
    npm: 10.5.1 - ~\AppData\Local\Volta\tools\image\npm\10.5.1\bin\npm.CMD <----- active
    pnpm: 8.15.6 - C:\Program Files\Volta\pnpm.EXE
  Browsers:
    Edge: Chromium (123.0.2420.65)
  npmPackages:
    @storybook/addon-essentials: ^8.0.6 => 8.0.6 
    @storybook/addon-interactions: ^8.0.6 => 8.0.6 
    @storybook/addon-links: ^8.0.6 => 8.0.6 
    @storybook/blocks: ^8.0.6 => 8.0.6 
    @storybook/test: ^8.0.6 => 8.0.6 
    @storybook/vue3: ^8.0.6 => 8.0.6 
    @storybook/vue3-vite: ^8.0.6 => 8.0.6 
    storybook: ^8.0.6 => 8.0.6
```


### Additional context

_No response_
Repository: node
Issue: [v18.x] Wrong path returned by fs.readdir withFileTypes=true
Labels: confirmed-bug,fs

### Version

18.20.1

### Platform

Linux h4ad 6.5.0-27-generic #28~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 15 10:51:06 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

### Subsystem

fs/promise

### What steps will reproduce the bug?

You can reproduce the issue by running the following commands:

```bash
$ mkdir fs-issue
$ cd fs-issue
$ touch issue.txt
$ node -e "require('fs/promises').readdir('.', { withFileTypes: true, encoding: 'utf-8', }).then(console.log)" 
```

### How often does it reproduce? Is there a required condition?

Always

### What is the expected behavior? Why is that the expected behavior?

The path should be `.`.

```
[
  Dirent {
    name: 'issue.txt',
    parentPath: '.',
    path: '.',
    [Symbol(type)]: 1
  }
]
```

### What do you see instead?

The path is different:

```
[
  Dirent {
    name: 'issue.txt',
    parentPath: '.',
    path: 'issue.txt',
    [Symbol(type)]: 1
  }
]
```

This issue only happens on `fs/promises`, on `readdirSync`, we don't see this issue:

```bash
$ node --print "require('fs').readdirSync('.', { withFileTypes: true, encoding: 'utf-8', })"
[
  Dirent {
    name: 'issue.txt',
    parentPath: '.',
    path: '.',
    [Symbol(type)]: 1
  }
]
```

Also, if we include `recursive`, we don't see the issue:

```
$ node -e "require('fs/promises').readdir('.', { recursive:true, withFileTypes: true, encoding: 'utf-8', }).then(console.log)"
[
  Dirent {
    name: 'issue.txt',
    parentPath: '.',
    path: '.',
    [Symbol(type)]: 1
  }
]

```

### Additional information

This bug was first introduced at `18.20.0`, on `18.19.1` the behavior is correct.
On latest version of node, `21.7.2` and `20.12.1`, we don't see this issue.

This bug was found by @wraithgar at https://github.com/npm/cli/pull/7352#issuecomment-2045701032
Repository: bitcoin
Issue: RFC: "Insufficient review" tag for closed PRs
Labels: Brainstorming

During PR triage today, it seems like we closed or considered closing a number of PRs purely due to lack of review and interest in reviewing, not due to any problems with the PRs themselves.

I think it's reasonable to close PRs like these, because we have a severe lack of reviewer bandwidth, so having lots of low priority PRs open can make it harder for higher priority PRs to receive the attention they deserve.

However, I think it would be good to distinguish between PRs that are good but closed because they provide relatively minor benefits, and PRs that were closed because they have problems or need more work.

**Suggestion:** I want to suggest closing these PRs with an "Insufficient review" tag and message like "This PR has not attracted enough review while it's been open, and is being closed to focus limited reviewer attention on PRs that seem like a higher priority to other project contributors. If there is more interest in reviewing this, it can be reopened."

I think an "Insufficient review" tag would be useful to know at a glance which closed PRs seem like good changes and don't have known problems, and to be able to quantify how many potentially good PRs are getting left behind due to review shortage. I also think if the closing message describes the problem as a review shortage, not a problem with the PR itself, it might be less discouraging to contributors, especially new contributors. And it might even encourage more review.

For reference, the current closing message for these PRs is "The PR didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open PRs. Closing due to lack of interest."
Repository: stable-diffusion-webui
Issue: [Feature Request]: Integrate --sd-webui-ar-plusplus
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 ?

Note that I also [requested this over at Forge](https://github.com/lllyasviel/stable-diffusion-webui-forge/issues/586)

### One of the primary elements in image generation is resolution.

**Image models are trained on various sized images, but "bucketing" has them trained on 64px increments, which is why ideal image generation resolutions are also in 64px increments.**

Most people do not understand this, and do not connect popular aspect ratios to values which are rounded to that precision.


Last week, I found myself wanting an extension that provides ideal image resolutions and found that **there are currently none**.

---

**My findings**:

<details>

<summary>The Aspect Ratio / Resolution extensions in the current list of Available Extensions</summary>

https://github.com/xhoxye/sd-webui-ar_xhox
- Makes an enormous panel of user configured static resolutions

https://github.com/bit9labs/sd-ratio-lock
- Lets you select an aspect ratio from a dropdown list and locks the sliders to it.
- Rounds to increment of 2px

https://github.com/thomasasfk/sd-webui-aspect-ratio-helper
- Lets you select an aspect ratio from a dropdown list and locks the sliders to it.
- Rounds to increment of 1px
- Has an extremely verbose configuration

https://github.com/alemelis/sd-webui-ar
- Adds a few aspect ratio buttons and static resolution buttons.
- Built in 4px rounding precision.
- Does not have any toggles.

https://github.com/LEv145/--sd-webui-ar-plus
- Same as above, but improves upon it with:
   - Toggle to switch from Width or Height being updated.
   - A verbose calculator tool that is not particularly helpful
   
</details>

---

**In my opinion**: [The fork by LEv145](https://github.com/LEv145/--sd-webui-ar-plus) is the best of these, but none of these are satisfactory.

I made [an issue](https://github.com/LEv145/--sd-webui-ar-plus/issues/21) in regards to their calculation method and rounding precision, and they were not bothered to do anything about it.

I decided I would fork that project and try to resolve the issues I perceived.

As I was nearing completion, I thought the features of this extension could be useful for everyone.  I'm suggesting that you take a look and consider integrating this.

If you are interested, but do not like one feature or another, please let me know.

---

**Default view**

<img width="944" alt="1" src="https://github.com/lllyasviel/stable-diffusion-webui-forge/assets/1613484/d33d7e87-8fc6-49a6-a21c-66890dbff484">

---

**With Information panel toggled open**

<img width="937" alt="2" src="https://github.com/lllyasviel/stable-diffusion-webui-forge/assets/1613484/ca0f01fe-056f-45e3-8a30-d15918a32f19">


### Proposed workflow

## https://github.com/altoiddealer/--sd-webui-ar-plusplus

### Additional information

_No response_
Repository: pytorch
Issue: [AOTI] Multiple arrayref_interface tests cause segfault on test runner exit
Labels: triaged,module: aotinductor

### 🐛 Describe the bug

How to repro:

comment out the lines below:

https://github.com/pytorch/pytorch/blob/57a9a64e10b84fa8d932482ae9417aa3fc3fbf44/test/inductor/test_aot_inductor.py#L2322-L2324

and run the following command:

```
$ python test/inductor/test_aot_inductor.py -k test_zero_grid_with_unbacked_symbols_abi_compatible_cpu_with_stack_allocation_and_minimal_arrayref_interface
```

While the test itself succeeds, the test runner segfaults before it exits.

Running it under gdb gives the following stack trace:

```
#0  0x00007fffb1caeb10 in ?? ()
#1  0x00007ffff68af896 in (anonymous namespace)::run (p=<optimized out>) at /opt/conda/conda-bld/gcc-compiler_1654084175708/work/gcc/libstdc++-v3/libsupc++/atexit_thread.cc:80
#2  (anonymous namespace)::run () at /opt/conda/conda-bld/gcc-compiler_1654084175708/work/gcc/libstdc++-v3/libsupc++/atexit_thread.cc:105
```

In particular, we are segfaulting when trying to run the destructor here: https://github.com/gcc-mirror/gcc/blob/releases/gcc-11/libstdc%2B%2B-v3/libsupc%2B%2B/atexit_thread.cc#L80

The destructor's address originally points to `~RAIIAtenTensorHandle()` within model.so, but by the time we try to run it, model.so has already been unloaded; hence the segfault. Not sure why this is only being triggered by the minimal arrayref interface though.

### Versions

PyTorch version: 2.4.0a0+git6890333
gcc used to build PyTorch: 11.4.1

cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @desertfire @chenyang78
Repository: pytorch
Issue: [DCP] Can we cache plan data?
Labels: oncall: distributed,triaged,needs design,module: distributed_checkpoint,oncall: distributed checkpointing

### 🚀 The feature, motivation and pitch

In a training script, we save checkpoints many times, they have the same dict structure. While when training on lots of nodes, communication overhead is large, can we get the saveplan(s) cached and only need to sync once?

### Alternatives

_No response_

### Additional context

looks the data structures are mutable (list, dict, ...), cannot directly use cache in functools

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k @LucasLLC @rohan-varma
Repository: ui
Issue: [bug]: Permission denied when trying to submit form
Labels: bug

### Describe the bug

When I click on submit on any form (shadcn examples) I receive this error on console:
![image](https://github.com/shadcn-ui/ui/assets/96212888/41b91b41-4fe0-4c4f-8c5b-0bc5da838ca8)



### Affected component/components

Forms

### How to reproduce

1. Go to shadcn example forms
2. Try to submit without filling up

( I click so many times on submit and eventually the page crashes)

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Manjaro last version with Firefox
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: ui
Issue: [bug]: Select not focus input
Labels: bug

### Describe the bug

When selecting an element of a select that is associated with the focus input action, the input does not get focus but focuses on that select

### Affected component/components

Select, Input

### How to reproduce

1: Create select
2: Create Input
3: Attach events related to focus input when change value select

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Browers
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: stable-diffusion-webui
Issue: [Feature Request]: Add VAE selection for HiresFix in txt2img
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 ?

i always use a sdxl model for t2i and sd1.5 model for hiresfix, it will take lower usage and fix some artifact(some sdxl model)

### Proposed workflow

1. Go to t2i
2. select a sdxl checkpoint at top
3. ![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/103174943/6ab15aa4-b743-43ac-a49f-4e775fb0dade)
4. open hiresfix sitting select a sd1.5 checkpoint, but can't select vae (will return full black img without --no-half-vae or some other complex work)
![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/103174943/5ebd7e1f-afd6-4d42-811c-f9fbc01e3b35)


### Additional information

_No response_
Repository: godot
Issue: RenderingServer multithreaded commands lock up multithreaded import plugins written in gdscript
Labels: bug,topic:rendering

### Tested versions

- Reproducible in Godot v4.3.dev5

### System information

Godot v4.3.dev5 - Ubuntu 22.04.4 LTS 22.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU () - 12th Gen Intel(R) Core(TM) i7-12700H (14 Threads)

### Issue description

When writing an import plugin for mesh resources it seems to lock up when I call ResourceSaver.save()

I traced it to `RS::get_singleton()->mesh_get_surface(mesh, i)` which calls, but never returns. It seems like the `FUNC1RC` wrapper macro in `servers/server_wrap_mt_common.h` _sometimes_ returns from command_queue.push_and_ret() but somehow still never completes the call.


```
Array ArrayMesh::_get_surfaces() const {
	if (mesh.is_null()) {
		return Array();
	}

	Array ret;
	for (int i = 0; i < surfaces.size(); i++) {
		RenderingServer::SurfaceData surface = RS::get_singleton()->mesh_get_surface(mesh, i);
```

### Steps to reproduce

Write an import plugin that creates a mesh, then add multiple of these resources to your project. This is affecting the govox project which uses the MagicaVoxel-Importer plugin to import `.vox` files as point cloud meshes

### Minimal reproduction project (MRP)

[govox-repro-lockup.zip](https://github.com/godotengine/godot/files/14926743/govox-repro-lockup.zip)
unzip the project and attempt to open it. It will lock up while importing vox files.

The code with issues is inside `addons/MagicaVoxel-Importer/plugin.gd`

If you set the variable `mutex_bug` inside the `_import` function to true it will work around the issue by using `call_deferred` to push the `ResourceSaver.save()` call to the main thread.