sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Inconsistent locale detection in pages router with 2 locales in URL
Labels: bug,Navigation,Runtime

### Link to the code that reproduces this issue

https://github.com/DuckThom/nextjs-locale-detection-issue

### To Reproduce

1. Start application in dev
2. Go to: http://localhost:3000/nl/de   (rendering /pages/test1.tsx)
3. Check the process output and devtools JS console to see the page has rendered twice: first time the locale is 'nl', the second time 'de'
4. Observe the text rendered is incorrectly 'German page'
5. Go to: Go to: http://localhost:3000/nl/de?working    (rendering /pages/test2.tsx)
6. Check the process output and devtools JS console to see the page has rendered just once: the locale is 'nl'
7. Observe the text rendered is now correctly 'Dutch page'

### Current vs. Expected behavior

## Current behaviour:
When using 2 valid locales in the URL uses the first one on the initial render, but the second one on the second (client side?) render.

The reason  /pages/test2.tsx seems to be rendering correctly is because adding `getServerSideProps` makes the page only render once. Omitting it like in /pages/test1.tsx (or changing it to `getStaticProps`) will render the page twice, which can be observed in the process output and in the browser.

## Expected behaviour:
The first locale is always used. Using the example above, the locale should always be 'nl'.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
  Available memory (MB): 27756
  Available CPU cores: 16
Binaries:
  Node: 18.19.1
  npm: 10.2.4
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.0-canary.58 // Latest available version is detected (14.2.0-canary.58).
  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)

Middleware / Edge (API routes, runtime), Routing (next/router, next/navigation, next/link)

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

next dev (local)

### Additional context

This behaviour is also observed on stable NextJS 14.1.0
Repository: PowerToys
Issue: [Power Toys-Fancy zones>Image resizer]: Add new size button is not associated with its label.
Labels: Issue-Bug,Product-Settings,Product-Image Resizer,Priority-3,Area-Accessibility,A11yE+D,A11ySev3,A11yWCAG

### Microsoft PowerToys version

v0.79.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

Image Resizer

### Steps to reproduce

**Test environment:**
OS Build: Windows 11 Enterprise insider preview 23H2 (22631.3296)
Power toys version: v0.79.0
Screen reader: Narrator

**Repro Steps:**

1. Open the Power Toys app in the desktop.
2. Now select Image resizer from the left navigation pane.
3. Turn on the narrator using Win + Ctrl + Enter.
4. Now navigate to the Add new size button.
5. Observe the narrator's announcement.

**User Experience:**
Users may not understand the purpose of the "Add new size" button if it is not clearly labeled and associated with its label.

**Guideline reference:**
https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships

**Attachments:**
![image](https://github.com/microsoft/PowerToys/assets/117908911/79c0fed2-3acd-4731-baad-ff3b20a92193)


https://github.com/microsoft/PowerToys/assets/117908911/4fed5571-7284-4cff-85ef-5968c863efe6




### ✔️ Expected Behavior

The "Add new size" button should be clearly labeled and visually associated with its label 'Preset' to help users understand its function.

### ❌ Actual Behavior

The "Add new size" button is not clearly associated with its label, making it difficult for users to understand its purpose.

### Other Software

_No response_
Repository: vscode
Issue: Nested multi-workspaces
Labels: feature-request,workbench-multiroot

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

### Introduction
Often in a mono-repo, you want to both see your toplevel files but also be able to treat all your projects as separate workspaces. The current solution for this are these so called 'multi-root workspaces'. 

### Problem
Unfortunately, these multi-root workspaces have one big downside: you see your folders multiple times. This is because you want to see the files and folder structure in their root context, but vscode must list them separately below the root level as well.

They also require you to do a clumsy manual setup with having a file (which is not even generated right away) and the workspace isn't even automatically opened when opening the folder the workspace file is in.

![Current situation](https://github.com/microsoft/vscode/assets/7917821/89d6cda0-dff3-48e8-9229-c7c62e7f3f41)

### Solution
Allow embedded/sub workspaces to be visualised as such. This is the true solution for having a powerful versatile IDE that doesn't clutter your working experience.

It would also be very useful to have auto detection based on the existence of the `.vscode` folder and the option to run or enable/disable the tasks of a sub-workspace, so that you decide what you work on whenever you want to work on it. The need for a workspace dir on root level should not be necessary if we have this feature IMHO.

![sub-workspaces](https://github.com/microsoft/vscode/assets/7917821/bca09728-8d57-478a-90a6-3dad05b09d7c)
Repository: vscode
Issue: After reloading the window, the button in the taskbar has no text
Labels: electron,workbench-os-integration

Type: <b>Bug</b>

Run "Developer: Reload Window".

The taskbar button appears without text.

If I move the window to another monitor the text appears, and it remains when I return the window to the original monitor. However, when I don't have multiple monitors, I can't use this workaround.

I guess this is more of a bug in the taskbar, but it's probably triggered by some behavior of vscode (perhaps the window label is empty when it's created). It would be nice if you could forward this to the taskbar team, and find a workaround for users stuck with the current verson.

See screen capture:

https://github.com/microsoft/vscode/assets/1553464/e614f879-9b6c-482e-ab87-ad8187d33692



VS Code version: Code 1.84.2 (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, 2023-11-09T10:51:52.184Z)
OS version: Windows_NT x64 10.0.22631
Modes: Restricted
Connection to 'WSL: Ubuntu' could not be established  No remote extension installed to resolve wsl.

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|12th Gen Intel(R) Core(TM) i7-1255U (12 x 2611)|
|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)|31.64GB (13.29GB free)|
|Process Argv|--folder-uri=vscode-remote://wsl+Ubuntu/home/noamyr/sand/nix-pills --remote=wsl+Ubuntu --crash-reporter-id 6fdff34b-9540-42fb-bdf8-7f752d43c306|
|Screen Reader|no|
|VM|0%|

Connection to 'WSL: Ubuntu' could not be established  No remote extension installed to resolve wsl.
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
d34g3935:30971562
bg6jg535:30979843
ccp2r3:30993541
dsvsc020:30976470
pythonait:31006305
jchc7451:30973076
gee8j676:31009558
dsvsc021:30996838
g1icg217:30999571

```

</details>

<!-- generated by issue reporter -->
Repository: ollama
Issue: Ollama push got `retrieving manifest  Error: file does not exist`
Labels: bug,networking

### What is the issue?

When I run `ollama push [myusername]/modelthatexist` I got error 
```
retrieving manifest 
Error: file does not exist
```

### What did you expect to see?

I expected the model to be pushed.

### Steps to reproduce

- Download this gguf https://huggingface.co/pacozaa/TinyLlama-1.1B-intermediate-step-1431k-3T-GGUF
- Create Model file that link to the gguf
- Run a model
- Next, copy your model to your username's namespace: `ollama cp example <your username>/example`
- Push the model: `ollama push <your username>/example`

### Are there any recent changes that introduced the issue?

_No response_

### OS

_No response_

### Architecture

_No response_

### Platform

_No response_

### Ollama version

_No response_

### GPU

_No response_

### GPU info

_No response_

### CPU

_No response_

### Other software

_No response_
Repository: rust
Issue: build-std + link-dead-code=y cannot build custom target without sse
Labels: A-LLVM,O-x86_64,C-bug,requires-nightly,-Zbuild-std

Hi,
I  am trying to compile my Rust OS kernel for x86_64. As I don't want to implement SSE support for multiple reasons, I chose the `+soft-float` feature. This does not seem to work with build-std:
```
   Compiling compiler_builtins v0.1.108
   Compiling core v0.0.0 (/home/jzbor/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling mosk v0.1.0 (/home/jzbor/Programming/Rust/mosk)
   Compiling rustc-std-workspace-core v1.99.0 (/home/jzbor/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
rustc-LLVM ERROR: Do not know how to split this operator's operand!

error: could not compile `core` (lib)
warning: build failed, waiting for other jobs to finish...
```
For my features I currently use
```yaml
"features": "-mmx,-sse,+soft-float"
```
I have also tried adding `-sse2` and `-avx` with pretty much the same result.

Enabling SSE in the custom target works, but of course results in errors at runtime, as I don't actually implement SSE support.

I have found several related issues, but none of them seem to track this specific problem:
#63466 #92760 #62729 

#63466 seems to also be [referenced by official documentation as known issue](https://doc.rust-lang.org/rustc/targets/known-issues.html), although it is closed and does not seem to track actually fixing the issue.

I have tried the workaround suggested in #62729 without success. 

This is my full custom target:
```json
{
	"llvm-target": "x86_64-unknown-none",
	"data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128",
	"arch": "x86_64",
	"target-endian": "little",
	"target-pointer-width": "64",
	"target-c-int-width": "32",
	"os": "none",
	"executables": true,
	"linker-flavor": "ld.lld",
	"linker": "rust-lld",
	"panic-strategy": "abort",
	"disable-redzone": true,
	"features": "-mmx,-sse,+soft-float"
}
```

EDIT: Cargo version and rust version
```
cargo 1.79.0-nightly (499a61ce7 2024-03-26)
rustc 1.79.0-nightly (c9f8f3438 2024-03-27)
```

EDIT2: I found out this only happens with `-C link-dead-code=y`, which I require in order to link assembly code. If this option is not set the linker will remove some of the assembly sections.
Repository: PowerToys
Issue: [Power Toys-Image resizer]: The dimensions are not announced by the narrator of the sizes in the combo box.
Labels: Issue-Bug,Product-Image Resizer,Area-Accessibility,Needs-Triage,A11yE+D,A11ySev3,A11yWCAG

### Microsoft PowerToys version

v0.79.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

Image Resizer

### Steps to reproduce

**Test environment:**
OS Build: Windows 11 Enterprise insider preview 23H2 (22631.3296)
Power toys version: v0.79.0
Screen reader: Narrator

**Repro Steps:**

1. Open the Power Toys app in the desktop.
2. Now open the file explorer and now open menu of the image.
3. Now select the resize with image resizer.
4. Turn on the narrator using Win + Ctrl + Enter.
5. Now navigate Size combo box present on the dialogue.
6. Observe the narrator's announcement.

**User Experience:**
Lack of dimension announcements by the screen reader can create barriers for users who rely on assistive technologies to navigate the interface.

**Guideline reference:**
https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships

**Attachments:**

https://github.com/microsoft/PowerToys/assets/117908911/4d073772-14b7-4c8a-9156-3a9c7e4cbcf9

![image](https://github.com/microsoft/PowerToys/assets/117908911/d344dfd1-eac8-4f6e-b4fb-8761c063c026)


### ✔️ Expected Behavior

When selecting a size from the combo box, the screen reader should announce the dimensions associated with the selected option.

### ❌ Actual Behavior

The dimensions selected from the combo box are not announced by the screen reader only size name is announced.

### Other Software

_No response_
Repository: PowerToys
Issue: With FancyZones, the context menu of Visual Studio is drawn at the wrong location
Labels: Issue-Bug,Product-FancyZones,Needs-Triage

### Microsoft PowerToys version

0.80.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

FancyZones

### Steps to reproduce

With FancyZones, the context menu of Visual Studio is drawn at the wrong location, when the context menu is opened for the first time after starting Visual Studio.

### Prerequisites:
- Power Toys running with FancyZones enabled.
- In the FancyZones settings
    - Enabled: "Neu erstellte Fenster in ihre letzte bekannte Zone verschieben" (something like "Move created windows into their last known zone")
    - Disabled: "Andocken des untergeordneten Fensters zulassen" (something like "Allow docking of the child window")
- Visual Studio has been moved to a zone in order to automatically have it moved into that zone after restart.

### Steps:
- Start Visual Studio.
- Open any text file with Visual Studio.
- Perform a right-click in the text editor of Visual Studio to open the context menu.


### ✔️ Expected Behavior

The context menu is supposed to always open at the location of the mouse cursor.

![grafik](https://github.com/microsoft/PowerToys/assets/11920356/326cb096-11a1-4e84-9393-c7a7c85fd471)


### ❌ Actual Behavior

The context menu opens in the top left corner of the FancyZones zone.

![grafik](https://github.com/microsoft/PowerToys/assets/11920356/1d6523ac-2414-46d7-8178-0405fb081455)

### Other Software

Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
Version 17.9.5
Repository: vscode
Issue: Test Coverage Reading
Labels: bug,accessibility,testing,test-coverage

Type: <b>Feature Request</b>

Good morning!

I would like to suggest an improvement regarding reading test coverage with screen readers.

Since December, test coverage has been implemented in some extensions, such as the Japa Pak extension.

However, when running the tests, I cannot know with the screen reader (I did the test with nvda), which lines are not covered, what percentage of what is covered and what would need to be covered.

To play:

Open a java project that contains unit tests, run test coverage and try to verify the results using a screen reader.

VS Code version: Code - Insiders 1.89.0-insider (d6eba9b861e3ab7d1935cff61c3943e319f5c830, 2024-04-05T05:52:23.778Z)
OS version: Windows_NT x64 10.0.22631
Modes:
Remote OS version: Linux x64 5.15.146.1-microsoft-standard-WSL2


<!-- generated by issue reporter -->
Repository: godot
Issue: Compatibility renderer: lights seem brighter when their shadows are enabled
Labels: topic:rendering,documentation,topic:3d

### Tested versions

- Reproducible in: 4.2.0, 4.3.dev5

### System information

Godot v4.3.dev5 - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1060 6GB (NVIDIA; 31.0.15.3713) - Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (4 Threads)

### Issue description

When using the compatibility renderer, enabling shadows on a light will make lit surfaces brighter. This happens for directional (over the whole scene), omni and spotlights.

If the ambient light is made black, the problem goes away. If shadows are disabled for all lights, the problem also goes away. If multiple lights have shadows turned on, the problem is more pronounced than if a single light has shadows turned on. It looks like the ambient light might be applied one extra time for each light with shadows enabled.

This seems to have been introduced when compatibility renderer shadows were first added. Forward plus and mobile renderers are not affected.

Comparison of a scene with a default world environment lit by a single directional light with shadows disabled and enabled:

![Compatibility_ShadowsOff](https://github.com/godotengine/godot/assets/23417591/4cee3255-718c-48da-b3d5-be1b1e9eb2b7)
![Compatibility_ShadowsOn](https://github.com/godotengine/godot/assets/23417591/bb396fb0-1e1e-4a88-9bb0-d36a4f778c72)


### Steps to reproduce

Run the project with F5. Press 'S' to toggle shadows on the directional light on and off. Observe how surfaces get brighter when shadows are on.

### Minimal reproduction project (MRP)

[CompatShadowRepro.zip](https://github.com/godotengine/godot/files/14884361/CompatShadowRepro.zip)
Repository: vscode
Issue: Activity Bar Location: Title
Labels: feature-request,workbench-views

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.88.0
- OS Version: Linux x64 6.6.25-1-MANJARO

Steps to Reproduce:

1. Move the activity bar to the top.
2. Observe:
    
![1](https://github.com/microsoft/vscode/assets/20289055/fca41f1d-4dc8-4f44-baeb-a56f182b287d)

![2](https://github.com/microsoft/vscode/assets/20289055/f58bc6d7-f272-4f1f-b576-3b1b7c1cf14b)

This wastes some vertical space, and just doesn't look good to me. This is how it looked in 1.87:

![3](https://github.com/microsoft/vscode/assets/20289055/34eecc5b-4e67-4d52-8577-db8f2ced9abb)

I'd suggest using this separate panel only if there's not enough horizontal space, or adding a setting to toggle between the two.
Repository: go
Issue: proposal: x/sys/svc/mgr: Add "ConnectWithPermissions" and "OpenServiceWithPermissions" to allow for control on the windows permissions used
Labels: Proposal

### Proposal Details

Current the "Connect" method uses a fixed value of "windows.SC_MANAGER_ALL_ACCESS" when calling "windows.OpenSCManager". Similarly, the "OpenService" method uses a fixed value of "windows.SERVICE_ALL_ACCESS" when calling "windows.OpenService".

This proposal adds "ConnectWithPermissions" and "OpenServiceWithPermissions". These would both take an additional "uint32" value that is simply passed through to the underlying windows methods. The existing methods would delegate to these new methods passing the existing permissions values.

So you would have:

```
func Connect() (*Mgr, error) {
	return ConnectRemote("")
}

func ConnectWithPermissions(access uint32) (*Mgr, error) {
	return ConnectRemoteWithPermissions("", access)
}

func ConnectRemote(host string) (*Mgr, error) {
	return ConnectRemoteWithPermissions(host, windows.SC_MANAGER_ALL_ACCESS)
}

func ConnectRemoteWithPermissions(host string, access uint32) (*Mgr, error) {
...
h, err := windows.OpenSCManager(s, nil, access)
...
```

Then

```
func (m *Mgr) OpenService(name string) (*Service, error) {
	return m.OpenServiceWithPermissions(name, windows.SERVICE_ALL_ACCESS)
}

func (m *Mgr) OpenServiceWithPermissions(name string, access uint32) (*Service, error) {
	h, err := windows.OpenService(m.Handle, syscall.StringToUTF16Ptr(name), access)
...
```
Repository: puppeteer
Issue: [Bug]: Puppeteer click don't fail when actual element is overlapped
Labels: feature,confirmed,P3

### Minimal, reproducible example

```TypeScript
await this.page.waitForSelector('selector', { visible: true })
await this.page.click('selector')
```


### Error string

no error

### Bug behavior

- [] Flaky
- [ ] PDF

### Background

I'm trying to click an element on my page after performing some action.
Previous action renders a popup like element which covers the element. When I try to click the element before the overlapping popup closes, I expect puppeteer to fail. But, it don't throw any error.

I can add explicit timeout or wait for the overlapping element to be removed. But, why is puppeteer not throwing any error when element is not actually clicked?

I see puppeteer implementation of click is, just move the cursor to that x/y coordinate and do a mouse click. But, it's not actually validating it is clicking the element or some other element which is overlapping it.

```
async click(
    this: ElementHandle<Element>,
    options: Readonly<ClickOptions> = {}
  ): Promise<void> {
    await this.scrollIntoViewIfNeeded();
    const {x, y} = await this.clickablePoint(options.offset);
    await this.frame.page().mouse.click(x, y, options);
  }
```

WDIO has proper implementation of throwing an error for similar behaviour - https://webdriver.io/docs/api/element/click/

![image](https://github.com/puppeteer/puppeteer/assets/5052286/a33bfbb3-b475-4882-8baf-0ab6a096548d)


### Expectation

I would expect page.click fails if element is overlapped by any other element.

### Reality

Nothing happens. No error thrown by puppeteer.

### Puppeteer configuration file (if used)

_No response_

### Puppeteer version

22.6.2

### Node version

20.11.1

### Package manager

npm

### Package manager version

10.2.4

### Operating system

macOS
Repository: PowerToys
Issue: Recommendation, Please create a Tool that recognizes all software in your Windows PC using specific KEYS -or- Set of KEYS -or- Combination of KEYS
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

Please create a Tool that recognizes all software in your Windows PC using 
- Specific KEYS 
- Specific set of KEYS
- Combination of KEYS
It will help us to diagnose and see why a program is not behaving correctly 

I wonder if there is a way to build an index of these and have a lookup of these and have a tool management to interface with the software - Maybe a Change Keys, Suspend Keys (Temporarily) - DO not allow any other software to use these KEYS (combination)

Thanks much
 

### Scenario when this would be used?

Everyday Windows software management of keys

### Supporting information

Sometimes we do not see how a combination of KEYS is no longer working as expected