sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Double clicking window fails to maximize
Labels: bug,upstream,linux,titlebar,upstream-issue-linked,chromium

Type: <b>Bug</b>

In Ubuntu 22.04, you can double-click a window title to maximize the window. This does not work with VSCode.

Workarounds:
- enable system title bar (yuck)
- triple click (works but is a bug)

Note: chromium also has this issue. See https://bugs.chromium.org/p/chromium/issues/detail?id=1439861 

VS Code version: Code 1.85.1 (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:47:11.635Z)
OS version: Linux x64 6.5.0-14-generic snap
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|12th Gen Intel(R) Core(TM) i7-1265U (12 x 4109)|
|GPU Status|2d_canvas: unavailable_software<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: disabled_software<br>multiple_raster_threads: enabled_on<br>opengl: disabled_off<br>rasterization: disabled_software<br>raw_draw: disabled_off_ok<br>video_decode: disabled_software<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: unavailable_software<br>webgl2: unavailable_software<br>webgpu: disabled_off|
|Load (avg)|1, 1, 0|
|Memory (System)|31.03GB (25.25GB free)|
|Process Argv|--no-sandbox --force-user-env --unity-launch --crash-reporter-id dcf92d24-91a1-4788-904c-9cf8b86e9da2|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|ubuntu|
|XDG_CURRENT_DESKTOP|Unity|
|XDG_SESSION_DESKTOP|ubuntu|
|XDG_SESSION_TYPE|wayland|
</details><details><summary>Extensions (21)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-zipfs|arc|3.0.0
openmatchingfiles|bca|0.5.4
vscode-eslint|dba|2.4.2
gitlens|eam|14.6.1
EditorConfig|Edi|0.16.4
gitlab-workflow|Git|3.99.0
vscode-todo-highlight|jgc|2.0.8
select-highlight-minimap|mde|0.1.0
remote-containers|ms-|0.327.0
remote-ssh|ms-|0.107.1
remote-ssh-edit|ms-|0.86.0
remote-wsl|ms-|0.81.8
vscode-remote-extensionpack|ms-|0.25.0
remote-explorer|ms-|0.4.1
remote-server|ms-|1.5.0
vsliveshare|ms-|1.0.5905
restart-ts-server-button|qcz|1.0.1
text-power-tools|qcz|1.45.0
language-stylus|sys|1.16.0
vscode-terminal-here|Tyr|0.2.4
toggle-eslint|zen|0.0.3


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
vsclangdf:30486550
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30933248
pythongtdpath:30769146
i26e3531:30792625
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:30885898
pythontbext0:30879054
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
dsvsc019acf:30933242

```

</details>

<!-- generated by issue reporter -->
Repository: next.js
Issue: Next 14 Build Performance on Windows (outputFileTracing)
Labels: Upstream,bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/hungry-bassi-hzgrzf?file=%2Fpages%2Findex.tsx

### To Reproduce

### `outputFileTracing: false`

1. Set `outputFileTracing: false` in `next.config.js`
2. Build the app
3. Total time for my app build is `15` seconds
4. Build again without any change so cache kicks in
5. Total time for my app build is `6.5` seconds

### `outputFileTracing: true`

1. Set `outputFileTracing: true` in `next.config.js`
2. Build the app
3. Total time for my app build is `35` seconds
4. Build again without any change so cache kicks in
5. Total time for my app build is `15` seconds

### Current vs. Expected behavior

Currently, it's possible to use `outputFileTracing: false` in your `next.config.js`.

Unfortunately, this option is gonna be removed in Next `15.x`, as mentioned when running the `build` command:
![image](https://github.com/vercel/next.js/assets/22915526/4c91ff7e-2282-48bd-b81e-a023185c0db8)

This is unacceptable. This option is essential to build fast on Windows, with or without WSL2. I've been running for 2 years with the option disabled without any problem, there is no reason to remove it.

An alternative solution would be to not output at all the file tracing for anyone. Given I spent 2 years without it, I guess it's not an essential part of the build process...

This workaround exists for more than 2 years now. The only reasons I'm opening a new issue is because NextJs is declaring they're gonna remove the workaround soon...

Actually, here's the original issue from 2 years ago and it's still opened: https://github.com/vercel/next.js/issues/31021

Please, either fix the issue on Windows or do not deprecate the option. There is no need for a code sandbox here, it's an OS issue.

### Verify canary release

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

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
Binaries:
  Node: 20.11.0
  npm: 10.2.4
  Yarn: 1.22.21
  pnpm: N/A
Relevant Packages:
  next: 14.0.4
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

Operating System (Windows, MacOS, Linux)

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

next build (local)

### Additional context

Please see the original issue https://github.com/vercel/next.js/issues/31021

The issue has been open since the launch of NextJs `12.x`, 2 years ago...
Repository: neovim
Issue: TUI corrupted in mosh after scrolling
Labels: bug,tui

### Problem

neovim started in mosh leaves stray symbols on the screen and/or corrupts whole terminal

Could be related to https://github.com/mobile-shell/mosh/issues/1041

### Steps to reproduce

wget https://raw.githubusercontent.com/LazyVim/LazyVim/main/lua/lazyvim/config/init.lua
nvim --clean init.lua

Go top-bottom several times (gg, G, gg, G, gg, G)

You'll have stray symbols left after a while:

![image](https://github.com/neovim/neovim/assets/82057/0548fc50-16c8-41a6-9ce8-a9706ebd3cc4)

If you try it with LazyVim default config it's even worse, it looks like the issue is triggered with unicode symbols:

<img width="714" alt="image" src="https://github.com/neovim/neovim/assets/82057/8342724f-181e-40e8-8163-d9629d865efd">


### Expected behavior

No stray characters left behind.

LazyVim should look like that:

<img width="669" alt="image" src="https://github.com/neovim/neovim/assets/82057/9a79300c-dd82-4ba9-8739-da21a59d8f04">


### Neovim version (nvim -v)

0.9.5, also tried v0.10.0-dev-2110+g2fce95ec43

### Vim (not Nvim) behaves the same?

vim 8.2 or 9.1 works fine

### Operating system/version

Linux (archlinux, centOS), macOS 14.2.1

### Terminal name/version

mosh-1.4.0

### $TERM environment variable

mosh-256color

### Installation

system package manager
Repository: stable-diffusion-webui
Issue: [Feature Request]: switch BLIP to LAVIS
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 ?

BLIP that the current project depends on has been abandoned and merged into LAVIS. Maybe switch BLIP to LAVIS?

- https://github.com/salesforce/BLIP
- https://github.com/salesforce/LAVIS

### Proposed workflow

1. Evaluate whether to switch
2. Switch, use new LAVIS to complete project initialization
3. Don't switch, install like CLIP, use ZIP or something else


### Additional information

![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/1500781/4f0be217-c428-4141-aa4b-b57508f13159)
Repository: stable-diffusion-webui
Issue: [Feature Request]: in img2img save resize to/by status when saving defaults
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 checked and this did not seem to crop up so probably it is a weird thing to ask but when saving the defaults could we please save if in img2img the resize **_by_** is chosen rather than the resize **_to_**?

It totally correctly saves the values, so i do not think that is a bug, it just does not save which one is chosen.

### Proposed workflow

1. Go to img2img
2. since resize **_to_** is the default, press resize **_by_**
3. go to settings
4. under "other: defaults"
5. press view changes
6. notice how the choice is not mentioned, but if you fiddled with the slider you might see how the new value of the slider is present
7. press apply
8. restart ui
9. go to img2img
10. resize **_to_** is still the default instead of resize **_by_**, though if you fiddled with the slider it does remember what the value you set it to was.

### Additional information

this is probably just a minor annoyance of mine i find it weird nobody noticed, but people seem to focus on other stuff when i tried to search "resize" here in the issue list, but it is useful when working with a batch of images.
Repository: terminal
Issue: Quake Mode Global Summon Gathers All Windows on All Virtual Desktops
Labels: Needs-Repro,Issue-Bug,Product-Terminal,Area-Windowing

### Windows Terminal version

1.18.3181.0

### Windows build number

10.0.22631.0

### Other Software

_No response_

### Steps to reproduce

1. Open up Terminal window on Desktop 1.
2. Open up Terminal window on Desktop 2.
3. Invoke the global quake mode summons ( `` start+` `` )
4. Exit the quake mode window (not close, exit the window by exiting the process inside the quake mode terminal)
5. Invoke the global quake mode summons again ( `` start+` ``)


### Expected Behavior

Only the quake mode window should be brought to the current virtual desktop and displayed, not all the MS Terminal windows.

### Actual Behavior

 All terminal windows from Desktop 1 and Desktop 2 is gathered and show on the current virtual desktop that is active.

![image](https://github.com/microsoft/terminal/assets/1827190/2c58b9ba-ac7c-4645-850e-49ff9b9f64d0)


Most likely related or caused by `dev/migrie/f/quake-toCurrent-desktop` on #8888
Repository: vscode
Issue: When using monospaced Chinese fonts, the auto line-wrapping in simple mode is incorrect.
Labels: bug,editor-wrapping

Type: <b>Bug</b>

When using monospaced Chinese fonts, the auto line-wrapping in simple mode is incorrect.


simple mode
![simple](https://github.com/microsoft/vscode/assets/17917604/86209124-9dcd-4cdd-b3e9-f5180d628905)

adavanced mode
![advanced](https://github.com/microsoft/vscode/assets/17917604/f520b010-b43d-4a65-9784-18f8c11e70a8)


Fonts used: Maple https://github.com/subframe7536/maple-font 

Other Description: The width of the characters in this font has been modified so that the width of a single Chinese character is strictly equal to two English characters.




VS Code version: Code 1.85.1 (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:49:37.021Z)
OS version: Windows_NT x64 10.0.22631
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD Ryzen 5 5600X 6-Core Processor              (12 x 4200)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|63.91GB (48.63GB free)|
|Process Argv|--crash-reporter-id 8ce0fd0c-4c7f-41c1-b736-1ff19fa43d09|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (16)</summary>

Extension|Author (truncated)|Version
---|---|---
codegeex|AMi|2.3.1
codesandbox-projects|Cod|0.2.122
gitlens|eam|14.6.1
EditorConfig|Edi|0.16.4
prettier-vscode|esb|10.1.0
code-runner|for|0.12.1
vscode-language-pack-zh-hans|MS-|1.85.2024011009
python|ms-|2023.22.1
vscode-pylance|ms-|2023.12.1
remote-wsl|ms-|0.81.8
powershell|ms-|2024.0.0
material-icon-theme|PKi|4.33.0
sonarlint-vscode|Son|4.2.2
uridecode|sry|0.3.6
vscode-icons|vsc|12.7.0
city-lights-icon-vsc|Yum|1.1.3

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
vsclangdf:30486550
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30933248
pythongtdpath:30769146
i26e3531:30792625
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
2e7ec940:30885897
pythontbext0:30879054
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
dsvsc019acf:30933242

```

</details>

<!-- generated by issue reporter -->
Repository: deno
Issue: Implementation of close event of MessagePort API
Labels: feat,web

### Proposal

There was no timely and reliable way to detect when a MessagePort becomes disentangled, which made it difficult to release resources associated with ports. 
We proposed to add a close event to MessagePort API. 
The close event has landed to the HTML spec. Chrome has already completed implementation and it’s close to ship.

Initial issue: https://github.com/whatwg/html/issues/1766
Explainer: https://github.com/fergald/explainer-messageport-close
HTML spec: https://html.spec.whatwg.org/multipage/web-messaging.html#disentangle
Chrome status: https://chromestatus.com/feature/5086799659794432
Mozilla standards position: https://github.com/mozilla/standards-positions/issues/914
WebKit standards position: https://github.com/WebKit/standards-positions/issues/271
HTML spec PR: https://github.com/whatwg/html/pull/9933

Primary contacts: @rakina, @mingyc, @nononokam
Repository: neovim
Issue: Dynamic (not same for every line) soft-wrap margin... and *without* disabling buffer-wide horizontal scrolling.
Labels: enhancement,complexity:high,display

### Problem

Possibly suboptimal combination of soft-wrap and lack of horizontal scrolling in some programming environments.

### Expected behavior

Hi, just wanted to gather people's thoughts on the following possible feature:

Soft-wrap (non destructive) is done not at window's boundary, nor at a fixed
amount for every line.

Instead, the said soft-wrap margin is a user-defined constant offset but it
does *not* count leading whitespace (e.g. indentation) for any given line.

So if a given line has first non-whitespace char starting at column 0 (i.e.
line is not indented), and the said margin value is 80, then the line will be
soft-wrapped between columns 0 and 80.

If, on the other hand, some line is shifted/indented to the right so that it's
first non-whitespace char starts at line 10, then the wrap margin for this line
will be at column 90 (i.e. 10 + 80)... e.g. one option would be to soft-wrap
between columns 10 and 90 :)

This way if one has multiple paragraphs (say one starting at column 0, no
indent; another paragraph is heavily indented to the right) -- then both
paragraphs would be of the same width.

At the same time though: *still* have horizontal scrolling enabled (thus enabling to 
move across text freely) in the whole buffer/window/editor.

If the above is to be considered in the context of programming where:

1) some code blocks have heavily-nested indentation (fact of life, since one
cannot control all the code out there :)

2) users have different monitor-widths, font-sizes, eyesight conditions (so
hard-wrapping, or even doing so manually at a time of writing code, to a given
'paragraph width' may not be equally optimal to all users).

... then we would be able to avoid having a lot of wasted space on the left
with very tall and narrow code at far right (wrap on); whilst at the same time
not having to scroll too much for very long lines (wrap off)...

... and without forcing hard-wrapping/-formatting on every user with
potentially different monitor resolutions and font sizes;

... or without forcing different users to 'hard reformat' code differently to
their own desires thereby leading to danger of confusing 'diffs' when such code
is committed to the shared repo, etc.
Repository: pytorch
Issue: torch.topk, when the input contains +nan and -nan, the result is not sure; sometimes -nan is treated greater than normal number, sometimes -nan is the least; 
Labels: needs reproduction,triaged,module: python frontend

### 🐛 Describe the bug

torch.topk

when the input contains +nan and -nan, the result is not sure; sometimes -nan is treated greater than normal number, sometimes -nan is the least; 

### Versions

torch 1.13 & torch 2.1 

cc @albanD
Repository: rust
Issue: Tracking Issue for `os_str_display`
Labels: T-libs-api,C-tracking-issue

<!--
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(os_str_display)]`

This is a tracking issue for the `OsStr::display` 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::ffi

pub mod os_str {
    pub struct Display<'a> { /* private fields */ }
}

impl OsStr {
    pub fn display(&self) -> os_str::Display<'_>;
}
```

### 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: https://github.com/rust-lang/libs-team/issues/326
- [x] Implementation: #120051
- [ ] 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.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: PowerToys
Issue: FancyZones: Select custom shortcut to span a window across multiple zones
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

Right now, we have the option to select the secondary mouse button to trigger the zoneactivation - which is awesome.
You can drag a window to a specific zone or right between them. But you can also hold "Ctrl" and span it across multiple zones.
For a maximum efficient usage of the feature i'd love to suggest the following enhancements:

Click secondary mousebutton = trigger the zoneactivation
Hold secondary mousebutton = trigger the zoneactivation and (simulate holding "Ctrl") to span it across multiple zones

If not possible, a custom shortcut for either would be awesome.

Thanks in advance for the effort.

### Scenario when this would be used?

I'd like to enhance the accessibility of this awesome tool.
By doing both functions with the mouse it feels much more natural in my opinion.

### Supporting information

_No response_
Repository: ant-design
Issue: antd v5 版本中 Table组件设置scroll属性后 与dnd-kit结合实现拖拽排序时，拖动行到表格底部会出现频繁闪动的问题
Labels: Inactive,unconfirmed

### Reproduction link

[https://stackblitz.com/edit/react-nfxyc7?file=demo.tsx](https://stackblitz.com/edit/react-nfxyc7?file=demo.tsx)

### Steps to reproduce

1、使用antd官网拖拽手柄列demo；
2、设置表格scroll属性为 y:300;
3、拖拽第二行数据往表格底部方向拉；
4、在第二行数据拉到表格底部位置时整个表格出现频繁闪动的问题

### What is expected?

期望第二行数据拉到表格底部位置时不会出现闪动问题

### What is actually happening?

第二行数据拉到表格底部位置频繁闪动

| Environment | Info |
| --- | --- |
| antd | 5.13.1 |
| React | react18.x |
| System | macOS 12.6 (21G115) |
| Browser | chrome 107.0.5304.110（正式版本） (arm64) |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: GPUParticles2D - editor crash if GPUParticles2D finished signal is connected to queue_free on a one shot system
Labels: bug,topic:editor,crash,topic:particles

### Tested versions

v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 Ti (NVIDIA; 31.0.15.3699) - AMD Ryzen 7 4800H with Radeon Graphics (16 Threads)

### Issue description

If you connect the `finished` signal of a one-shot `GPUParticles2D` to its `queue_free` function **and** the system is the root of the scene, triggering emit on the system in the editor will cause it to crash.

### Steps to reproduce

* Create a new scene, make GPUParticles2D into its root.
* Disable emitting, set the system to one shot, add a process material.
* Via the signals panel on the GPUParticles2D node, connect the `finished` signal to `queue_free` 
![image](https://github.com/godotengine/godot/assets/717574/b9b867df-9670-4c95-b116-e8ba1b1d906e)
* Toggle the `emitting` checkbox on the particle system. 
* Wait one second for the system to finish emitting.
* Editor crashes.

### Minimal reproduction project (MRP)

[MRP-ParticleCrash.zip](https://github.com/godotengine/godot/files/13961196/MRP-ParticleCrash.zip)