sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Feature Request]: Support for left/right modifiers in accelerators
Labels: enhancement :sparkles:

### 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 feature request that matches the one I want to file, without success.

### Problem Description

It's possible to have left/right-aware shortcuts inside the app, things like `AltLeft+F`, `AltRight+F`, or even weird things like `CommandLeft+CommandRight`.

These shortcuts are not expressible in terms of Electron's accelerators though, so they can't be used freely everywhere throughout the app.	

### Proposed Solution

It'd be useful if they were supported, with Left/Right suffixes added for each supported modifier.

### Alternatives Considered

I could just not use left/right modifiers, though shortcuts in my app are customizable, including shortcuts for the app's menu, and the shortcuts library I'm using for the app supports these left/right modifiers, and I'd like to provide a unified interface for setting shortcuts, which means supporting these slightly more precise shortcuts everywhere. So really the only nice option is for Electron to add support for these.

### Additional Information

_No response_
Repository: electron
Issue: [Feature Request]: Support missing numpad keys for accelerators
Labels: enhancement :sparkles:

### 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 feature request that matches the one I want to file, without success.

### Problem Description

Some keys that are available in numpads are not currently supported, but they should be:

- NumpadComma
- NumpadEqual
- NumpadEnter

### Proposed Solution

Supporting them.

### Alternatives Considered

N/A

### Additional Information

_No response_
Repository: rust
Issue: unchecked region constraints for opaque types in dead code
Labels: P-medium,I-unsound,A-impl-trait,C-bug,T-types,S-needs-repro

*edit: while this tests currently results in an error, the underying issue still exists https://github.com/rust-lang/rust/issues/112417#issuecomment-2116444863*

```rust
trait CallMeMaybe<'a, 'b> {
    fn mk() -> Self;
    fn subtype<T>(self, x: &'b T) -> &'a T;
}

struct Foo<'a, 'b: 'a>(&'a (), &'b ());
impl<'a, 'b> CallMeMaybe<'a, 'b> for Foo<'a, 'b> {
    fn mk() -> Self {
        Foo(&(), &())
    }

    fn subtype<T>(self, x: &'b T) -> &'a T {
        x
    }
}

// `foo` must not compile but does.
fn foo<'a, 'b>() -> impl CallMeMaybe<'a, 'b> {
    panic!();
    Foo(&(), &())
}

// The rest is only to exploit that unsoundness.
trait Func {
    type RetTy;
}
impl<F: FnOnce() -> R, R> Func for F {
    type RetTy = R;
}

fn subtype<'a, 'b, F: FnOnce() -> R, R: CallMeMaybe<'a, 'b>, T>(_: F, x: &'b T) -> &'a T {
    let proof = R::mk();
    proof.subtype(x)
}

fn main() {
    let y = subtype(foo, &String::from("Hello World"));
    println!("{y}"); // use after free
}
```
With the current implementation `foo` only defines the opaque type during HIR typeck and not in MIR typeck as the defining use is in dead code. HIR typeck does not check regions so we use erased regions instead. This hidden type with erased regions is then used as the actual hidden type of the RPIT because there is no hidden type defined by MIR typeck.

We then never check that the RPIT is well-formed outside of HIR typeck itself, so we never check that the region constraints hold for the opaque type.
Repository: puppeteer
Issue: [Bug]: No requestfinished or requestfailed event for a network request (none-headless mode only)
Labels: bug,confirmed,P3

### Bug expectation

The reproducible example will monitor network requests when navigating to https://www.bing.com
Expected:
Each request should have a start and end record(requestfinished or requestfailed event).
Actually:
No requestfinished or requestfailed event fired for url  **https://login.microsoftonline.com/common/oauth2/authorize?client_id....**  

Note: This problem is reproducible only when **headless is set to false**.  The behavior is not consistent between headless and non-headless mode.
![Capture](https://github.com/puppeteer/puppeteer/assets/8121062/cf71d18a-38ac-4ecf-ac9c-346c0fa68abf)


### Bug behavior

- [ ] Flaky
- [ ] PDF

### Minimal, reproducible example

```TypeScript
import puppeteer from 'puppeteer';

const pendingRequests = [];

async function delay(time) {
    return new Promise(resolve => setTimeout(() => resolve(), time));
}

function monitor(page) {
    function onRequestStart(request) {
        if (request.resourceType() === 'document') {
            pendingRequests.push(request);
            //console.log("onRequestStart " + request.url());
        }
    }

    function onRequestEnd(request) {
        if (request.resourceType() === 'document') {
            const index = pendingRequests.indexOf(request);
            if (index !== -1) {
                pendingRequests.splice(index, 1);
            }
            //console.log("onRequestEnd " + request.url());
        }
    }

    page.on('request', onRequestStart);
    page.on('requestfailed', onRequestEnd);
    page.on('requestfinished', onRequestEnd);
}

async function monitorNetwork(browser) {
    const page = await browser.newPage();
    monitor(page);
    await page.goto('https://www.bing.com', {waitUntil: 'networkidle0'});
    await delay(1000);
    if (pendingRequests.length > 0) {
        // In non-headless mode, no requestfinished or requestfailed event fired for url https://login.microsoftonline.com/common/oauth2/authorize?client_id...
        throw new Error('Pending request found after network idle.');
    }
}

(async () => {
    const browser = await puppeteer.launch({headless: false});
    await monitorNetwork(browser);
    await browser.close();
})();


```


### Error string

Error: Pending request found after network idle.

### Puppeteer configuration

_No response_

### Puppeteer version

20.5.0

### Node version

18.12.1

### Package manager

npm

### Package manager version

8.19.2

### Operating system

Windows
Repository: flutter
Issue: [Material 3] Support dividers in DropdownMenu
Labels: c: new feature,framework,f: material design,c: proposal,P3,team-design,triaged-design

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

The Material 3 specification has a section about Dividers in DropdownMenus.

See item 6 in the spec: https://m3.material.io/components/menus/specs

However, the `DropdownMenu` API currently only allows a list of `DropdownMenuEntry`items, which each require a value and a label. This prevents using a Divider, as the divider has no real value.

### Proposal

Implement a new `DropdownMenuEntry` subclass, DropdownMenuDivider,  which has no value or label and just inserts a `Divider` per the Material 3 example (using the M3 divider specs). No selection change should happen when a Divider is tapped.
Repository: TypeScript
Issue: Using `"allowJs": true` and `"module": "commonjs"` to transform `.mjs` files should emit `.cjs` files
Labels: Possible Improvement

# Bug Report

### 🔎 Search Terms

CommonJS, allowJS, ESM, CJS, file extensions

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about output "file extensions for CommonJS modules".

### ⏯ Playground Link

[Sandbox link with relevant code](https://codesandbox.io/p/sandbox/tsc-mjs-extension-bug-rhsczj) (I couldn't use the playground, since this involves using an .mjs file).

### 💻 Code

```json5
// package.json
{
  "name": "tsc-mjs-extension-bug",
  "version": "0.1.0",
  "type": "commonjs",
  "main": "dist/javascript.mjs",
  "scripts": {
    "build": "tsc",
    "test": "node ."
  },
  "dependencies": {
    "typescript": "5.1.3"
  }
}

```

```json5
// tsconfig.json
{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "nodenext",
    "allowJs": true,
    "outDir": "dist"
  }
  "include": ["src"]
}
```

```js
// src/javascript.mjs
export const where = "javascript";
console.log(`Hello ${where}`);
```

```ts
// src/typescript.ts
export const where = "typescript";
console.log(`Hello ${where}`);
```

### 🙁 Actual behavior

The `javascript.mjs` is transformed to CommonJS (as expected), but the file extension of the emitted file is still `.mjs`.
This breaks the package, since `.mjs` is supposed to be use exclusively for JavaScript using ESM and the emitted file now uses CommonJS.

### 🙂 Expected behavior

I would expect `tsc` to transform  the `src/javascript.mjs` to CommonJS and either:
1. emit it as `dist/javascript.cjs` or alternatively
2. take into account the `"type": "commonjs"` in the package.json and emit the file as `.js` as it does with the `src/typescript.ts` file.
Repository: next.js
Issue: Response not gzipped if middleware returns NextResponse
Labels: bug,Runtime,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Mon Apr 24 20:52:24 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.14.1
      npm: 9.3.1
      Yarn: N/A
      pnpm: 8.1.0
    Relevant packages:
      next: 13.4.5-canary.7
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.4
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/gazs/content-encoding-middleware

### To Reproduce

- Use `next@13.2.5-canary.28` or above
- have a middleware.ts file that returns a NextResponse

#### In the attached repo:

While the server is running - either with `next dev` or `next start`, request a page with curl:

```
curl http://localhost:3000 -I -X GET -H 'Accept-Encoding: gzip'
```

<table>
<tr>
<th>
with middleware.ts 
</th>
<th>
without  middleware.ts
</th>
</tr>
<tr>
<td>
<pre>
HTTP/1.1 200 OK
date: Mon, 06 Nov 2023 15:27:38 GMT
cache-control: no-store, must-revalidate
x-powered-by: Next.js
etag: "kax1clllnq10g"
content-type: text/html; charset=utf-8
vary: Accept-Encoding
connection: close
transfer-encoding: chunked
</pre>
</td><td>
<pre>
HTTP/1.1 200 OK
cache-control: no-store, must-revalidate
x-powered-by: Next.js
etag: "o7szhipal610g"
content-type: text/html; charset=utf-8
vary: Accept-Encoding
date: Mon, 06 Nov 2023 15:27:54 GMT
<b>content-encoding: gzip</b>
connection: close
transfer-encoding: chunked
</pre>
</td>
</table>


### Describe the Bug

Responses are not gzipped when a NextResponse is returned from the middleware function. If the middleware function returns _without_ a NextResponse, the response is gzipped.

The issue is first seen in next@13.2.5-canary.28.

### Expected Behavior

Responses should have the same content-encoding whether or not we use a NextResponse to generate the response

### Which browser are you using? (if relevant)

n/a

### How are you deploying your application? (if relevant)

- run the application using `next start`

<sub>[NEXT-1698](https://linear.app/vercel/issue/NEXT-1698/response-not-gzipped-if-middleware-returns-nextresponse)</sub>
Repository: material-ui
Issue: No colorPrimary or success properties on OutlinedInputClasses
Labels: component: text field,package: material-ui

If I want to get the MUI class of a success input element I have to code it via props in the logic, but I'd like to know if there is a similar way when, for example, we get the `error` class, or the `colorSecondary`.
https://github.com/mui/material-ui/blob/a33eb7cba66a5c5631ba77c96d2fafaa12ed9f32/packages/mui-material/src/OutlinedInput/outlinedInputClasses.ts#L5-L9
We have `colorSecondary` or even `error` here
https://github.com/mui/material-ui/blob/0d3aba1c9433dc5dd79dd9af6821c25b48d6f4f7/packages/mui-material-next/src/Input/inputClasses.ts#L14
I wonder why we don't have a `colorPrimary` or `success`

## Example of use
For example, in a theme, we can custom set a color if the input has error state as follow:
 ```typescript
[`&.${outlinedInputClasses.error}`]: {
   color: "red"
  }
```
But we can't set it if the input has success state because there is no `outlinedInputClasses.success` or `outlinedInputClasses.colorPrimary`
Repository: TypeScript
Issue: Mapped Type `[Lhs of Rhs]` Syntax for Array and Tuple Types
Labels: Suggestion,In Discussion

# Suggestion

## 🔍 Search Terms

mapped type, of, array, tuple

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

A new `[Lhs of Rhs]` syntax in mapped type to map over values of array and tuple types:
```ts
type ResultType = {
    [V of SourceType]: DoSomethingWith<V>
}
```
Rhs does not need to be a type parameter.
Rhs must extend `readonly unknown[]` or a type error is raised.

## 📃 Motivating Example

```ts
type Foo = ['hello', 'world']

type Bar = {
    [V of Foo]: V[]
}
// Bar = ['hello'[], 'world'[]]
```

## 💻 Use Cases

Currently, to do the same as in motivating example, one might intuitively write:
```ts
type Bar = {
    [K in keyof Foo]: Foo[K][]
}
```
However this is incorrect and is a mistake that's potentially difficult to spot.

Instead one must either introduce a generic intermediate type:
```ts
type Transform<T> = {
    [K in keyof T]: T[K][]
}

type Bar = Transform<Foo>
```
Or use the `infer` workaround:
```ts
type Bar = Foo extends infer T ? {
    [K in keyof T]: T[K][]
} : never
```

Both workarounds are not immediately obvious to inexperienced developers, less ergonomic, and will silently break when `Foo` is no longer an array or tuple type without putting extra constraints.
Repository: vscode
Issue: Switching profiles is removing the color theme setting
Labels: bug,themes

Steps to Reproduce:

1.  Have a profile with following settings
```json
{
    "window.autoDetectColorScheme": true,
    "workbench.preferredDarkColorTheme": "Abyss",
    "workbench.colorTheme": "Abyss",
    "workbench.preferredHighContrastColorTheme": "Abyss",
}
```
2. From this profile, create a Doc Writer Profile - Settings > Profile > Create Profile... > Doc Writer
🐛 Theme of Doc Writer profile was reset to Abyss

CC @joaomoreno
Repository: next.js
Issue: notFound() in layout.tsx file hooks not-found.tsx file in the parent directory rather than in the same directory.
Labels: Navigation

### Verify canary release

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

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64
Binaries:
  Node: 18.16.0
  npm: 9.5.1
  Yarn: 1.22.17
  pnpm: N/A
Relevant packages:
  next: 13.4.1
  eslint-config-next: 13.2.4
  react: 18.2.0
  react-dom: 18.2.0
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Routing (next/router, next/navigation, next/link)

### Link to the code that reproduces this issue or a replay of the bug

/

### To Reproduce

File structure is as below. We have 2 `not-found.tsx` files here. `[league_code]/not-found.tsx` and `[league_code]/[team_code]/not-found.tsx`
![screenshot](https://i.ibb.co/6v99JK0/Screen-Shot-2023-06-08-at-8-52-55-AM.png)

`notFound()` is called in `[league_code]/[team_code]/layout.tsx` file.
![screenshot](https://i.ibb.co/SmYqfxt/Screen-Shot-2023-06-08-at-9-05-01-AM.png)


### Describe the Bug

This call hooks `[league_code]/not-found.tsx`, not `[league_code]/[team_code]/not-found.tsx`.

### Expected Behavior

It should hook `[league_code]/[team_code]/not-found.tsx` file in the same directory.

### Which browser are you using? (if relevant)

Chrome 114.0.5735.106

### How are you deploying your application? (if relevant)

_No response_
Repository: godot
Issue: Outline around objects in transparent `Viewport` when using Vulkan
Labels: bug,topic:rendering,confirmed

### Godot version

4.0.dev [2985a9a]

### System information

Kubuntu GNU/Linux 23.04

### Issue description

If you use a `Viewport` with `transparent_bg` enabled, and you also happen to use Vulkan for the rendering, and dark outline will be visible around the stuff inside:

|**Vulkan**|**OpenGL**|
|---|---|
|![Screenshot_20230608_101505](https://github.com/godotengine/godot/assets/30739239/7f994f27-bd1f-4d64-b0e3-daa37a871196)|![Screenshot_20230608_101412](https://github.com/godotengine/godot/assets/30739239/0c18f237-5931-4345-b685-e773b315cb93)|


### Steps to reproduce

- Create something with a `Viewport` (either a `Window`, or a `SubViewportContainer`).
- Enable `transparent_bg` for it.
- Now inside the `Viewport` create something that can have the same color with what is behind it.

### Minimal reproduction project

[ViewTransparentBug.zip](https://github.com/godotengine/godot/files/11689462/ViewTransparentBug.zip)
Repository: kubernetes
Issue: Server-side Apply can cause additional calls to webhooks
Labels: priority/important-soon,lifecycle/rotten,wg/api-expression,needs-triage

When compared to client-side apply that doesn't send empty `{}` patches, server-side apply always sends the manifest.
When no-op apply is sent, it triggers the full mutation/admission which can cause a lot of stress on webhooks.

It might be useful to not call the validating webhooks if the resource hasn't changed.

/wg api-expression
/priority important-soon
/triage accepted
Repository: deno
Issue: Deno.copyFile triggers the file watcher infinitely
Labels: needs info

I have the following code:

```ts
const watcher = Deno.watchFs("./src");

for await (const event of watcher) {
    console.log(event);

    event.paths.forEach((path) => {
        Deno.copyFileSync(path, get_destination(path));
    });
}
```

Every time a file is modified, the watcher detects the change, so the file is copied to the destination folder. But seems like `Deno.copyFileSync` somehow triggers a new "modify" event to the original file in the watcher, so it's an infinite loop.

As a workaround, I can read and write the file content

```ts
const watcher = Deno.watchFs("./src");

for await (const event of watcher) {
    console.log(event);

    event.paths.forEach((path) => {
        Deno.writeFileSync(get_destination(path), Deno.readFileSync(path));
    });
}
```

I think this is a bug, because `copyFile` shouldn't modify the original file.

My Deno version:
```
deno 1.34.1 (release, x86_64-apple-darwin)
v8 11.5.150.2
typescript 5.0.4
```
Repository: next.js
Issue: Vercel is unable to retrieve files when CMS example is connected with a Wordpress with 167 posts
Labels: examples

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home Single Language
    Binaries:
      Node: 18.0.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.4
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5
```


### Which example does this report relate to?

cms-wordpress

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

Vercel

### Describe the Bug

When I create a Headless Wordpress connected with a wordpress with over 150+ posts and host it in vercel, vercel is not able to retrieve all requisitions, I also deployed directly from the cms-wordpress example and the same problem occurred
![image](https://github.com/vercel/next.js/assets/81180853/9c1bdec2-5cac-4ec9-869e-3997b12d2730)
This is a print from vercel logs, and as can see it, there are several errors. it's also importante to note that are not all files that vercel is not able to retrieve, for example some images works totally fine, and some don't, some page load fast, and others don't, maybe is connected with the build order.

### Expected Behavior

Vercel should be able to retrieve all static files and not having to wait for about 10 seconds for a image.

### To Reproduce

Clone and deploy the cms-wordpress connected with a wordpress with 150+ posts
Repository: kubernetes
Issue: HTTP Connection to webhooks is not always re-used
Labels: priority/important-soon,lifecycle/rotten,wg/api-expression,needs-triage

This is speculative and needs to be investigated, but it looks like in some situations the connection to webhooks is not re-used, causing connections to leak and all sorts of snowballing effect.

We should look for an existing test and stress-test it to see if we can further investigate the issue.

/wg api-expression
/priority important-soon
/triage accepted
/cc @justinsb
Repository: pytorch
Issue: Warn / deprecate / remove ProcessGroupNCCL._group_start(), _group_end() APIs
Labels: oncall: distributed,triaged

### 🐛 Describe the bug

As reported by @lw, these APIs are error prone and can easily result in correctness issues if the appropriate synchronization is not done by the user. As a result, we should discuss whether to remove these APIs (and just use the `coalescing_manager`), or add a warning saying users have to do explicit sync.

### Versions

main

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: stable-diffusion-webui
Issue: [Feature Request]: Cancel button for Batch Upscale 
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 ?

Would be nice to be able to cancel batch upscale jobs.

### Proposed workflow

1. Go to extras
2. Press press cancel button
3. Batch upscale job canceled


### Additional information

_No response_