sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Luminosity contrast ratio of keyboard focus indicator on Authorize button fails to meet the required ratio of 3:1: A11y_VS Code extension for API Center_Generate HTTP file_Authorize_Non Text Contrast.
Labels: bug,themes,accessibility

### GitHub Tags
#A11yTCS; #A11ySev2; #Win32; #WCAG1.4.11; #GH_VSCodeextensionforAPICenter_Win32_Apr2024; #DesktopApp; #Visual Studio Code Client; #A11yMAS; #NonText Contrast; #A11YWCAG2.1; 

### Environment Details:
Application Name: VS Code Extension for API Center
OS: Windows 11 Enterprise 23H2 (OS build 22631.3296)

### Repro Steps:

1. Create an API center in azure portal.
2. Open Visual studio Code.
3. Tab till API center extension in the left side panel and press enter.
4. Tab till definition under the Api name which you have created, and press enter.
5. The name which you have provided to the definition will appear for ex-"openapi4", right click on it.
6. Go to "Generate HTTP file" using the down arrow and press enter.
7. An HTTP file will appear.
8. Tab till Authorize button.
9. Verify whether the Luminosity contrast ratio of keyboard focus indicator on Authorize button meet the required ratio of 3:1 or not.

### Actual Result:
Luminosity contrast ratio of keyboard focus indicator on Authorize button fails to meet the required ratio of 3:1
Note: This issue is observed throughout the feature.

### Expected Result:
Luminosity contrast ratio of visual focus indicator on authorize button should be greater than or equal to required ratio of 3:1.

### User Impact:
People with low vision often have difficulty perceiving tab focus that have insufficient contrast if Luminosity contrast ratio of visual focus indicator fails to meet the required ratio of 3:1. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a lightness difference of 3:1 or greater can make these items more distinguishable when the person does not see a full range of colors

### Attachment:

![Image](https://github.com/user-attachments/assets/b9a042a6-3318-40cb-86e0-b74d7f1d772d)
Repository: vscode
Issue: extension get wrong resource in context key when right click a folder with subfolder
Labels: bug,file-explorer

For below  folder structure 'builtIn\res' , if you right click on the 'builtIn' not 'bulitIn\res', then you use the 'Inspect Context Key' command to show the context , the 'resource' in the context keys is always 'builtIn\res' not 'builtIn' .

<img width="111" alt="Image" src="https://github.com/user-attachments/assets/c4be7c28-e05a-4fdd-8469-998e560a4637" />

- VS Code Version: 
- OS Version: 
Version: 1.96.2 (user setup)
Commit: fabdb6a30b49f79a7aba0f2ad9df9b399473380f
Date: 2024-12-19T10:22:47.216Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.26100

Steps to Reproduce:


1. run 'Inspect Context Key' command 
2. right click on a folder which contains a subfolder in the same row in file explorer 
3. check the 'resource' in context keys
Repository: rust
Issue: Compilation of large project taking much longer after 1.84 (monomorphization)
Labels: I-compiletime,T-compiler,C-bug,I-prioritize,regression-untriaged

<!--
Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.

Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
-->

### Code

I have a big private project and we try to stay current on rust versions. Upon trying 1.84 I saw compilation times grow about 3 times. I already seen this behavior in other rust versions which made me have to skip it, for example 1.82.

I self-profiled the compile in 1.83 and 1.84 and diffed, so I got to this (https://gist.github.com/lsunsi/7d301c7e332f50a734647d3aff0efbdc).
I'm not sure how useful it is, but there we go. I can post the prof data as well if it's useful.

Further, I'll try to bisect and get back with more information.

### Version it worked on

<!--
Provide the most recent version this worked on, for example:

It most recently worked on: Rust 1.47
-->

It most recently worked on: 1.83

```
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1
```

### Version with regression

<!--
Provide the version you are using that has the regression.
-->

`rustc --version --verbose`:
```
rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.84.0
LLVM version: 19.1.5
```

<!--
Did the compiler crash? If so, please provide a backtrace.
-->

</p>
</details>

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-stable-regression-untriaged
-->

@rustbot modify labels: +regression-from-stable-to-stable-regression-untriaged
Repository: electron
Issue: setOverlayIcon blurry on scaled resolutions
Labels: platform/windows,bug :beetle:,blocked/need-repro,33-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

33.2.1

### What operating system(s) are you using?

Windows

### Operating System Version

Windows 10, Windows 11

### What arch are you using?

x64

### Last Known Working Electron version

-

### Expected Behavior

Overlay icon scales following desktop DPI when increasing scaling (like the app icon).

### Actual Behavior

Overlay icon looks blurry when OS resolution is scaled, looks like it always uses a 16x16 although a larger one is provided.

![Image](https://github.com/user-attachments/assets/8b7ab1ab-e2a7-49b1-81db-d14a42cb39a0)

### Testcase Gist URL

_No response_

### Additional Information

I would expect the overlay icon to automatically adapt to the desktop scaling, but it would be acceptable to specify multiple icons too, or different icons for each scale step.
Repository: transformers
Issue: use_liger_kernel requires much more GPU memory during evaluation than training
Labels: bug

### System Info

I found when enabling use_liger_kernel=True, it does reduce GPU memory for training. however, when dealing with evaluation, I found it requires much more GPU memory than training, even though the per_device_eval_batch_size is smaller than per_device_train_batch_size, and seq_lengths are similar.

![Image](https://github.com/user-attachments/assets/9042e485-daf3-4235-b389-c75595486e0c)

Architecture/Model: 
AutoModelForSequenceClassification - Qwen/Qwen2.5-1.5B (it happens on all qwen2.5 models, including 0.5b to 32b ones);

Specific Setting:
--per_device_train_batch_size 4 --gradient_accumulation_steps 4 --per_device_eval_batch_size 1 --bf16 --max_length 4096 --gradient_checkpointing True --group_by_length True --use_liger_kernel True --attn_implementation flash_attention_2

Unnecessary but things you might want to know:
I use deepspeed zero(1/2/3), yet I found this issue also exists when running with ddp.

People who could help:
@muellerzr @SunMarc

### Who can help?

@muellerzr @SunMarc

### Information

- [x] The official example scripts
- [ ] My own modified scripts

### Tasks

- [x] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

To reproduce:

Simply follow this trl [reward modeling example](https://github.com/huggingface/trl/blob/main/examples/scripts/reward_modeling.py).

### Expected behavior

I expect enabling use_liger_kernel=True does not occupy much more GPU memory for evaluation than training.
Repository: tauri
Issue: [bug] MSI installer uses HKCU despite being per-machine installation
Labels: type: bug,platform: Windows,status: needs triage

### Describe the bug

The installer performs what appears to be a per-machine installation:

- Installs to Program Files by default
- Requires admin privileges
- Creates shortcuts in Public Desktop and ProgramData Start Menu (accessible to all users)

However, InstallDir, Desktop Shortcut and other registry keys are created under HKCU

One issue caused by this is in the scenario:

- User A installs the program, registry keys are created in User A's HKCU
- If User B uninstalls the program, the files and public shortcuts are removed
- But User A's HKCU registry entries remain since User B's uninstaller can't access them
- This leaves orphaned registry entries for any user who installed but didn't **un**install the program themselves

Is this intended behavior or should the registry keys be in HKLM since this is a per-machine installation?

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
> tauri info


[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 131.0.2903.112
    ✔ MSVC: Visual Studio Build Tools 2022
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 22.9.0
    - npm: 10.9.0

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1 (outdated, latest: 2.2.0)
    - @tauri-apps/cli : 2.1.0 (outdated, latest: 2.2.4)

[-] Plugins
    - tauri-plugin-shell 🦀: 2.2.0
    - @tauri-apps/plugin-shell : 2.2.0
    - tauri-plugin-dialog 🦀: 2.2.0
    - @tauri-apps/plugin-dialog : 2.2.0
    - tauri-plugin-fs 🦀: 2.2.0
    - @tauri-apps/plugin-fs : not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../build
    - devUrl: http://localhost:1420/
    - framework: Svelte
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: ant-design
Issue: Segmented 组件在暗黑模式下的动画过渡效果不自然
Labels: improvement

### What problem does this feature solve?

![Image](https://github.com/user-attachments/assets/b4451ee6-fff8-4796-bbcf-a55fa5893f80)

如图，在暗黑模式下当相邻两个选项切换时会有这种与 hover 背景重叠的效果，默认浅色主题下就没这种问题

### What does the proposed API look like?

跟浅色模式一样动画过渡自然

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: kubernetes
Issue: kube-controller-manager restart when leaderelection lost
Labels: kind/bug,needs-sig,needs-triage

### What happened?

After the kube-controller-manager component fails to renew the contract, the kube-controller-manager component directly exits the process. Can the kube-controller-manager component be selected as the primary component without restarting the process?

### What did you expect to happen?

The kube-controller-manager process does not exit after the renewal fails.

### How can we reproduce it (as minimally and precisely as possible)?

Construct a network problem to make the renewal of the primary node fail.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```
1.31
</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: PowerToys
Issue: PowerToys Bug while it was in no use
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.86.0

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

No way I can find how to reproduce it, an error window just popped up, after some almost crashing state after changing programs windows (switching to another program in the computer), then my second monitor stopped being recognized and I needed to restart the PC.
I wasn't even using PowerToys directly... just running in the background.
Log archives attached.

[PowerToysReport_2025-01-14-09-15-46.zip](https://github.com/user-attachments/files/18410243/PowerToysReport_2025-01-14-09-15-46.zip)

### ✔️ Expected Behavior

At the moment none, the app was just running in the background.

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: deno
Issue: Next.js build sometimes fails with "Cannot find module" error
Labels: nextjs

The error looks like this:

```
Error: Cannot find module './chunks/264.js'
Require stack:
- /tmp/build/src/.next/server/webpack-runtime.js
- /tmp/build/src/.next/server/pages/_document.js
- /tmp/build/src/node_modules/.deno/next@15.2.0-canary.8/node_modules/next/dist/server/require.js
- /tmp/build/src/node_modules/.deno/next@15.2.0-canary.8/node_modules/next/dist/server/load-components.js
- /tmp/build/src/node_modules/.deno/next@15.2.0-canary.8/node_modules/next/dist/build/utils.js
- /tmp/build/src/node_modules/.deno/next@15.2.0-canary.8/node_modules/next/dist/build/worker.js
- /tmp/build/src/node_modules/.deno/next@15.2.0-canary.8/node_modules/next/dist/compiled/jest-worker/processChild.js
    at t.f.require (.next/server/webpack-runtime.js:1:1637)
    at <unknown> (.next/server/webpack-runtime.js:1:1110)
    at t.e (.next/server/webpack-runtime.js:1:1089) {
  code: "MODULE_NOT_FOUND",
  requireStack: [Array]
}
```

It usually gets fixed by cleaning `node_modules/` *and* removing the `DENO_DIR` (path can be found in `deno info`).

I have absolutely no idea what causes this, nor how to reproduce it reliably.
Repository: flutter
Issue: Incorrect position of Japanese predictive conversion popup in TextFormField using maxLines on the Web
Labels: a: text input,framework,a: internationalization,platform-web,has reproducible steps,P2,team-text-input,triaged-text-input,found in release: 3.27,found in release: 3.28

### Steps to reproduce

1. Prepare a Mac with macOS Sequoia 15.2 (Japanese).
2. Paste the code sample into [dartpad.dev](https://dartpad.dev/) and run it.
3. Type Japanese in TextFormField and display the predictive conversion popup.

### Expected results

The predictive conversion popup will appear without any redundant space under the text.

### Actual results

The predictive conversion popup is appeared with redundant space under the text.

### Code sample

<details open><summary>Code sample</summary>

```dart
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        colorSchemeSeed: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  final String title;

  const MyHomePage({
    super.key,
    required this.title,
  });

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: TextFormField(
        maxLines: 10,
      ),
    );
  }
}
```

</details>


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

<img src="https://github.com/user-attachments/assets/a769542a-c7a4-461f-8cd7-e3b36b63bd19" />

</details>


### Logs

<details open><summary>Logs</summary>

None.

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

None. (Run on dartpad.dev with Based on Dart SDK 3.6.0 and Flutter SDK 3.27.1.)

</details>
Repository: ollama
Issue: Windows Installer hangs at the end of install
Labels: bug

### What is the issue?

Hi,

I've encountered a bug while upgrading ollama that also occurs when installing or trying to uninstall.
At the very end of the process, the windows will become disabled (can't move it, can't put in in foreground), witht he icon being higlighted in red on the taskbar, like if a modal was in the way.

Looking for the logs showned nothing. So I looked in the call stack of the install process, and found out that overwolf was causing the hang.
Killing overwolf  from the tray icon immediately finishes the install.

Looking at logs, the installation is actually finished, overwolf seems just to be preventing the auto closing of the installer window.

![Image](https://github.com/user-attachments/assets/9bc72579-7a42-417c-ab06-df6760aefffa)
```
2025-01-14 13:42:40.680   Deleting uninstall key left over from previous non administrative install.
2025-01-14 13:42:40.680   Creating new uninstall key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{44E83376-CE68-45EB-8FC1-393500EB558C}_is1
2025-01-14 13:42:40.680   Writing uninstall key values.
2025-01-14 13:42:40.680   Detected previous administrative 64-bit install? No
2025-01-14 13:42:40.680   Detected previous administrative 32-bit install? No
2025-01-14 13:42:40.684   Installation process succeeded.
```

I've had help on this on the discord, but as the problem is quite unusual, I've tough it could be interesting to report the issue (that might be on overwolf side) to at least propose the very simple solution on the FAQ.

Let me know if I can provide more logs or information, I'd be glad to help.

### OS

Windows

### GPU

Nvidia

### CPU

AMD

### Ollama version

0.5.5
Repository: stable-diffusion-webui
Issue: [Bug]: Bad API auth with certain passwords
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

```
Jan 14 13:14:03 roxanne.dragonfear stable-diffusion-webui[1682746]: ValueError: too many values to unpack (expected 2)
```
The routine in api.py is using auth.split(":")

It should be using auth.partition(":") to avoid double-splits.

### Steps to reproduce the problem

Just run the thing with an API password that contains colons.

### What should have happened?

Should start normally.

### What browsers do you use to access the UI ?

_No response_

### Sysinfo

Doesn't matter.  It's a code bug.

### Console logs

```Shell
Above.
```


### Additional information

_No response_
Repository: TypeScript
Issue: `builder.getDeclarationDiagnostics` performance regression since 5.6
Labels: Needs Investigation

### 🔎 Search Terms


Starting with version 5.6, the `builder.getDeclarationDiagnostics` method has become slower when invoked to retrieve diagnostics for a single `SourceFile`.

Here are the timing comparisons:

**TypeScript Version: 5.5.2**  
- `builder.getDeclarationDiagnostics()`: **2.247s**  
- `builder.getDeclarationDiagnostics(builder.getSourceFiles()[0])`: **0.19ms**  
- `builder.getSourceFiles().forEach(sf => builder.getDeclarationDiagnostics(sf))`: **1.655s**

**TypeScript Version: 5.7.2**  
- `builder.getDeclarationDiagnostics()`: **1.675s**  
- `builder.getDeclarationDiagnostics(builder.getSourceFiles()[0])`: **1.791s**  
- `builder.getSourceFiles().forEach(sf => builder.getDeclarationDiagnostics(sf))`: **2.824s**


### 🕗 Version & Regression Information

- This changed between versions 5.5 and 5.6
- This changed in commit or PR https://github.com/microsoft/TypeScript/pull/59065



### 💻 Code

https://github.com/alan-agius4/ts-getDeclarationDiagnostics

### 🙁 Actual behavior

Regression in performance

### 🙂 Expected behavior

Similar performance

### Additional information about the issue

_No response_
Repository: rust
Issue: Tracking issue for release notes of #133807: ci: Enable opt-dist for dist-aarch64-linux builds
Labels: T-compiler,relnotes,T-infra,relnotes-tracking-issue


This issue tracks the release notes text for #133807.

### Steps

- [x] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Internal Changes
- [ci: Enable opt-dist for dist-aarch64-linux builds](https://github.com/rust-lang/rust/pull/133807)
The ARM 64-bit compiler (AArch64) on Linux is now optimized with ThinLTO and PGO, similar to the optimizations we have already performed for the x86-64 compiler on Linux. This should make it up to 30% faster.
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @mrkajetanp, @Kobzol -- origin issue/PR authors and assignees for starting to draft text
Repository: vscode
Issue: VS Code workspaces on dynamic set of subfolders
Labels: feature-request,workbench-multiroot


Type: <b>Feature Request</b>

Hi,
I am developing in a big monorepo with hundreds of projects. I would like to create a code-workspace file that treats each folder of a subfolder as its own project.
Like

- packages/project1
- packages/project2
- ...
- packages/project500

Currently, code-workspace files need to list every project explicitly.
I would like to be able to specify a subfolder and have it dynamically added. So instead of
```
{
  "folders": [
     {
        "path": "packages/project1"
      },
      {
        "path": "packages/project500"
      },
  ]
}
```
I would like:
```
{
  "rootFolders": [
    {
      path: "packages"
     }
  ]
}
```
and VS Code should dynamically show each subfolder of packages as a project.

VS Code version: Code - Insiders 1.97.0-insider (c594d55bae90276d174cea4ddf2901694d4ebb3e, 2025-01-14T05:04:07.371Z)
OS version: Windows_NT x64 10.0.26120
Modes:
Remote OS version: Linux x64 6.5.0-1025-azure


<!-- generated by issue reporter -->