sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Can not disable `reference-types` feature for wasm32 target with `-C linker-plugin-lto` flag
Labels: P-medium,T-compiler,O-wasm,C-bug,regression-untriaged

### Code

@alexcrichton

Code is minimized as much as possible and here is a demo repository: https://github.com/StackOverflowExcept1on/wasm-builder-regression/
- `wasm-checker` - simple CLI tool that passes wasm to parity-wasm parser (it does not support reference-types)
- `wasm-program` - this is smart contract that panics and terminates with an error
- `wasm-project` - some intermediate directory that is generated by our utility
- [check.sh source code](https://github.com/StackOverflowExcept1on/wasm-builder-regression/blob/master/wasm-project/check.sh)

```bash
git clone https://github.com/StackOverflowExcept1on/wasm-builder-regression.git
cd wasm-builder-regression/wasm-project
./check.sh
```
```
    Finished `release` profile [optimized] target(s) in 8.30s

   Compiling gear-wasm v0.45.1
   Compiling wasm-checker v0.1.0 (/mnt/tmpfs/wasm-builder-regression/wasm-checker)
    Finished `release` profile [optimized] target(s) in 1.68s
     Running `/mnt/tmpfs/wasm-builder-regression/wasm-checker/target/release/wasm-checker ./target/wasm32-unknown-unknown/release/wasm_program.wasm`

Error: InvalidTableReference(128)
```

If I remove flag `-C linker-plugin-lto`, it works as described in #128511

I expected to see this happen: *I can disable `reference-types` via `-Ctarget-cpu=mvp` and `-Zbuild-std`*

Instead, this happened: *there is some kind of conflict between compiler flags?*

### Version it worked on

It most recently worked on: `nightly-2024-07-31`

### Version with regression

`rustc +nightly-2024-08-01 --version --verbose`:
```
rustc 1.82.0-nightly (28a58f2fa 2024-07-31)
binary: rustc
commit-hash: 28a58f2fa7f0c46b8fab8237c02471a915924fe5
commit-date: 2024-07-31
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0
```
Repository: react-native
Issue: Single-line TextInput sized as multiline on Fabric ShadowNode
Labels: Issue: Author Provided Repro,Resolution: PR Submitted,Component: TextInput,Type: New Architecture

### Description

Having a non-multiline `TextInput` component on new arch will be sized by the layout engine/shadow node as if it were multiline unless one explicitly sets `numberOfLines={1}`. 

### Steps to reproduce

1. With new architecture enabled on Android
2. Type text into a non-multiline `TextInput`
3. Observe the height keep increasing as you type longer and longer without text breaking lines

### React Native Version

0.75.3

### Affected Platforms

Runtime - Android

### Areas

Fabric - The New Renderer

### Output of `npx react-native info`

```text
System:
  OS: macOS 15.0
  CPU: (10) arm64 Apple M1 Pro
  Memory: 91.72 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.11.0
    path: ~/.asdf/installs/nodejs/20.11.0/bin/node
  Yarn:
    version: 3.6.4
    path: ~/.asdf/installs/nodejs/20.11.0/bin/yarn
  npm:
    version: 10.2.4
    path: ~/.asdf/plugins/nodejs/shims/npm
  Watchman:
    version: 2023.03.27.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.12.1
    path: /Users/joel/.asdf/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.0
      - iOS 18.0
      - macOS 15.0
      - tvOS 18.0
      - visionOS 2.0
      - watchOS 11.0
  Android SDK:
    API Levels:
      - "28"
      - "30"
      - "31"
      - "32"
      - "33"
      - "34"
    Build Tools:
      - 29.0.2
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 32.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
    System Images:
      - android-32 | Google APIs ARM 64 v8a
      - android-33 | Google Play ARM 64 v8a
      - android-34 | Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2411.12071903
  Xcode:
    version: 16.0/16A242d
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.11
    path: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/javac
  Ruby:
    version: 3.0.3
    path: /Users/joel/.asdf/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.75.3
    wanted: 0.75.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: false
```


### Stacktrace or Logs

```text
See screenshots.
```


### Reproducer

https://github.com/oblador/react-native-textinput-height-issue

### Screenshots and Videos

| Fabric | Paper |
|--------|--------|
| ![Screenshot_1726823427](https://github.com/user-attachments/assets/9f5e5ff4-d9d2-4a5c-9a37-f9e31c74b7fe) | ![Screenshot_1726823447](https://github.com/user-attachments/assets/1bcfdc18-fb36-477d-8f9d-0dd42baf3949) |
Repository: opencv
Issue: Charuco board is only detected if I set the size + 2 larger than the actual board
Labels: wontfix,category: objdetect

### System Information

OpenCV 4.9/Python 3.11.9 on NixOS

### Detailed description

I have the following image:

![image](https://github.com/user-attachments/assets/3e5b49fb-8ee8-4a59-8912-78fbdbe88d85)

I am running this on the following code:

```python
import cv2 as cv
from cv2 import aruco

image = cv.imread('calibration-plate.png')
image = cv.resize(image, (3450, 2850), interpolation=cv.INTER_NEAREST)

dictionary = aruco.getPredefinedDictionary(aruco.DICT_7X7_1000)

board = aruco.CharucoBoard((23, 19), 0.015, 0.009, dictionary)
print(board.getChessboardCorners().shape, board.getIds().shape)
detector = cv.aruco.CharucoDetector(board)
corners, ids, markers, markerIds = detector.detectBoard(image)

if markers is not None:
    image = cv.aruco.drawDetectedMarkers(image, markers, markerIds)

if corners is not None:
    image = cv.aruco.drawDetectedCornersCharuco(image, corners, ids)

cv.imwrite('res.png', image)
```

This produces the following `res.png`:

![image](https://github.com/user-attachments/assets/f27b3463-2721-47a5-b9e0-777e6881e9c7)

Notice that markers are found, but chessboard intersections are not.

If I make the following change

```diff
-board = aruco.CharucoBoard((23, 19), 0.015, 0.009, dictionary)
+board = aruco.CharucoBoard((25, 21), 0.015, 0.009, dictionary)
```

Then I get the following new `res.png`:

![image](https://github.com/user-attachments/assets/42937c8e-48bd-4b5b-abf4-4ee892a98781)

Note that I now do have chessboard intersections, but their ids are wrong. This board is not 25x21, so it makes sense that the ids would be wrong. What I don't understand is why chessboard intersections are only detected with this (incorrect) board configuration.

### Steps to reproduce

See description above.

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: rust
Issue: Should `#[expect(warnings)]` at some point warn that there are no warnings in the annotated code?
Labels: A-lints,A-diagnostics,T-compiler,C-bug,F-lint_reasons

### Code

```rust
#[expect(warnings)]
pub fn foo() {}
```

### Current output

`rustc` is happy with an expect annotation on code, that does not trigger a warning

### Desired output

probably this should ask to remove the expect annotation?

### Rationale and extra context

`expect(warnings)` is probably not the most idiomatic thing to do, but I found it in my code. And I would think that this behaves like other `expect` annotations.

### Other cases

_No response_

### Rust Version

```
rustc 1.83.0-nightly (f79a912d9 2024-09-18)
binary: rustc
commit-hash: f79a912d9edc3ad4db910c0e93672ed5c65133fa
commit-date: 2024-09-18
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0
```

### Anything else?

_No response_
Repository: langchain
Issue: Anthropic's prompt caching in langchain does not work with ChatPromptTemplate.
Labels: 🤖:docs,investigate

### URL

https://python.langchain.com/docs/how_to/llm_caching/

### Checklist

- [X] I added a very descriptive title to this issue.
- [X] I included a link to the documentation page I am referring to (if applicable).

### Issue with current documentation:

I have not found any documentation for prompt caching in the langchain documentation. There seems to be only one post on twitter regarding prompt caching in langchain. I am trying to implement prompt caching in my rag system. I am using history aware retriever. 

I have instantiated the model like this:

llm_claude = ChatAnthropic(
    model="claude-3-5-sonnet-20240620",
    temperature=0.1,
    extra_headers={"anthropic-beta": "prompt-caching-2024-07-31"}
)


And using the ChatPromptTemplate like this:

contextualize_q_prompt = ChatPromptTemplate.from_messages(
                [
                    ("system", contextualize_q_system_prompt),
                    ("human", "{input}"),
                ]
            )
            
I am not able to find a way to include prompt caching with this. 
I tried making the prompt like this, but still doesnt work.

prompt = ChatPromptTemplate.from_messages([
        SystemMessage(content=contextualize_q_system_prompt, additional_kwargs={"cache_control": {"type": "ephemeral"}}),
        HumanMessage(content= "{input}")
    ])

Please help me with how I should enable prompt caching in langchain.




### Idea or request for content:

Langchain documentation should be updated with how to use prompt caching with different prompt templates. And especially with a RAG system.
Repository: ant-design
Issue: Tour component with navigation
Labels: Inactive,improvement

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/gracious-dijkstra-krystw)

### Steps to reproduce

1. Create a provider that will store refs
2. Add the Tour component to it
3. In nextButtonProps, add navigation between targets
4. Sometimes they will have time to be highlighted, but this does not always work

### What is expected?

Highlight target after navigate to another page

<img width="300" alt="Снимок экрана 2024-09-20 в 13 35 23" src="https://github.com/user-attachments/assets/9d33e474-f17f-4ef7-8bc7-b28c486cbf80">
<img width="300" alt="Снимок экрана 2024-09-20 в 13 35 28" src="https://github.com/user-attachments/assets/7a7f9b8f-ceb3-491c-9dd9-2ba1fdf95f78">


### What is actually happening?

The target is not highlighted

<img width="300" alt="Снимок экрана 2024-09-20 в 13 35 39" src="https://github.com/user-attachments/assets/a58eb09d-0067-4638-a14b-1ae9ecbcb51f">
<img width="300" alt="Снимок экрана 2024-09-20 в 13 35 45" src="https://github.com/user-attachments/assets/616730fe-05e7-42fa-9c06-1e6bb9e38dc3">

| Environment | Info |
| --- | --- |
| antd | 5.20.6 |
| React | 18.2.0 |
| System | MacOS 14.5 |
| Browser | Google Chrome 128 |

---
Maybe I don't fully understand how refs work, I tried many different options, but ideally it would work out of the box

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Could not resolve SDK "Godot.NEt.Sdk"
Labels: topic:buildsystem,needs testing,topic:dotnet

### Tested versions

Godot v4.3.0.stable

### System information

Windows 10 - Godot v4.3.0.stable

### Issue description

I recently decided to try out C# in godot and installed dotnet along with setting godot's network mode to online, But when I try and build a C# script I get the following errors
`MSB4236: The SDK 'Godot.NET.Sdk/4.3.0' specified could not be found. C:\Users\Mike\Desktop\c#test\test\Test.csproj(0,0)`
![image](https://github.com/user-attachments/assets/a1427688-4580-436a-9f57-2f54ade7828f)


This is what my .csproj file looks like

### Steps to reproduce

Install godot mono, Install dotnet, Make a project and try building a C# script

### Minimal reproduction project (MRP)

[c#test.zip](https://github.com/user-attachments/files/17074095/c.test.zip)
Repository: deno
Issue: Should `deno cache` ignore specifiers it does not understand?
Labels: needs discussion

Vite projects (and other frontend ones) typically contain non-standard imports like importing `.svg` files. Deno errors when it encounters such a file upon calling `deno cache`.

## Steps to reproduce

1. Run `npm create vite`
2. Pick the "Vanilla" -> "TypeScript" preset
3. `cd` into the project folder and run `deno cache src/App.tsx`

Output:

```sh
error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
  Specifier: file:///workspaces/deno2_test/src/assets/react.svg
    at file:///workspaces/deno2_test/src/App.tsx:3:23
```

Version: Deno 2.0.0-rc.4+66fb81e
Repository: godot
Issue: Building with mono can't handle special characters in file path
Labels: enhancement,discussion,topic:editor,topic:dotnet

### Tested versions

- Reproducible in v4.3.stable.mono.official [77dcf97d8] and v4.4.dev2.mono.official [97ef3c837]

### System information

Godot v4.3.stable.mono - Ubuntu 20.04.6 LTS (Focal Fossa) - X11 - OpenGL 3 (Compatibility) - Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2) - Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (4 Threads)

### Issue description

When trying to compile a C# project using Godot Mono It fails and returns the error:

```
MSB4019: The imported project "/path/to/project/Zombie BurgerZ: Oh No Edition/.godot/mono/temp/obj/Zombie BurgerZ- Oh No Edition.csproj.*.props" was not found. Confirm that the expression in the Import declaration "/path/to/project/Zombie BurgerZ: Oh No Edition/.godot/mono/temp/obj/Zombie BurgerZ- Oh No Edition.csproj.*.props" is correct, and that the file exists on disk. /usr/share/dotnet/sdk/8.0.401/Current/Microsoft.Common.props(74,3)
```

Removing special characters from the project directory name and `assembly_name` (located in `project.godot`) fixes the issue.

My project was created in an older version of Godot where it didn't enforce having no special characters in project directory names. Godot should warn users when opening a project that has special characters in its name or warn users when migrating their projects that have special characters to newer versions.

### Steps to reproduce

- Create and import a project with special characters in the directory name (e.g `:`) using an older version of Godot
- Open the project in a newer version
- Create a C# script and try to compile

### Minimal reproduction project (MRP)

[minimal reproduction project](https://github.com/user-attachments/files/17074558/mvp.test.zip)
Repository: pytorch
Issue: torch.func.vjp and sparse tensors: "Sparse CSR tensors do not have strides"
Labels: module: sparse,triaged,module: functorch

Sparse tensors seem not to work with torch.func :
```python
import torch

x=torch.rand(10)
dense=torch.rand(1,10)
sparse=dense.to_sparse_csr()

def test_dense(x):
  return (dense@x)[0]

def test_sparse(x):
  return (sparse@x)[0]

torch.func.grad(test_dense)(x) # works
test_sparse(x) # works
torch.func.grad(test_sparse)(x) # fails
#RuntimeError: Sparse CSR tensors do not have strides


def test_dense_minimal():
  return dense

def test_sparse_minimal():
  return sparse.to_dense()

torch.func.vjp(test_dense_minimal)[1](x) # works
test_sparse_minimal() # works
torch.func.vjp(test_sparse_minimal)[1](x) # fails
#RuntimeError: Sparse CSR tensors do not have strides
```



### Versions

pytorch 2.4.1+cu121


I haven't found an open issue about here. Are there any plans to fix this incompatibility?

Cheers, Felix

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jcaip @zou3519 @Chillee @samdow @kshitij12345
Repository: vscode
Issue: Enabling the `issueReporter.experimental.auxWindow` setting prevents Issue Reporter window from being focused
Labels: bug,issue-reporter

<!-- ⚠️⚠️ 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.93.0
- OS Version: MacOS Sonoma 14.7 (23H124)

Steps to Reproduce:

1. With `issueReporter.experimental.auxWindow` enabled, open the Issue Reporter through the "Help: Report Issue..." command
2. Move the Issue Reporter window behind another window and call "Help: Report Issue..." again -- the behavior I observe is the Issue Reporter window stays hidden behind the other window
3. Disable `issueReporter.experimental.auxWindow` and run "Help: Report Issue..." again -- the window should now pop back into the foreground and into focus

Seen as part of https://github.com/microsoft/vscode/issues/229107

Able to reproduce in the current 1.94 VS Code Insiders build as well.
Repository: vscode
Issue: Window size becomes the size of the monitor when transferring maximized window across differently scaled monitors
Labels: upstream,electron,workbench-window

Start by opening the window, restoring it (unmaximize), move to 1x scale monitor and size is smallist

![Image](https://github.com/user-attachments/assets/c6551e05-7cd2-4f1a-9c74-086eefca9f7e)

Drag to second 2x monitor and maximize by dragging it to the top of the window

![Image](https://github.com/user-attachments/assets/ce20867a-b5f1-47d0-bfbd-5545cdcefb4e)

Exit VS Code

Start VS Code

Win+shift+left to transfer to 1x scale monitor

Drag down to unmaximize

![Image](https://github.com/user-attachments/assets/92e4d9c9-7bff-4595-adf7-efccde10dc75)

🐛 the window is the size of the first monitor. At some point it looks like we're saving the maximized dimensions of the window to the non-maximized size. This requires manually resizing the window in order to make it usable again. I would expect us to keep track of the unmaximized size even when transferring maximized windows across monitors
Repository: go
Issue: mime: ParseMediaType should not return an error if mediatype is empty
Labels: NeedsInvestigation

### Go version

go version 1.23.0

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/alden/Library/Caches/go-build'
GOENV='/Users/alden/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/alden/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/alden/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.1/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.1/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/alden/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/_h/_w_mjtt91s1dws8zlxnnjpzm0000gn/T/go-build1772735711=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

I have a file server that returns `Content-Disposition` headers like this: `;filename*=UTF-8''hello-world.pdf`

Example: https://go.dev/play/p/rxRNVZGDOQu



### What did you see happen?

`mime.ParseMediaType` fails with the error "mime: no media type" ([from here in code](https://github.com/golang/go/blob/165bf241f2f7c72cffd83e278d674ae3ddbd72a1/src/mime/mediatype.go#L105-L107))

### What did you expect to see?

- `mime.ParseMediaType` succeeds, returning mediatype `""` and `params["filename"]` `hello-world.pdf`
- Note that all modern browsers and email clients parse a blank mediatype correctly
- [rfc6266](https://www.rfc-editor.org/rfc/rfc6266#page-5) and [rfc2183](https://www.rfc-editor.org/rfc/rfc2183.html#section-2.8) both say `Unknown or unhandled disposition types SHOULD be handled by
   recipients the same way as "attachment"`, and presumably an empty string disposition type fits into that
Repository: godot
Issue: Unable to vertical scroll animation bezier editor with mousewheel
Labels: bug,topic:editor,needs testing,topic:animation

### Tested versions

Reproducible in:
- v4.3.stable.official [77dcf97d8]
- v4.2.1.stable.official [b09f793f5]

Not reproducible in:
- v4.1.4.stable.official [fe0e8e557]

### System information

Godot v4.3.stable - Debian GNU/Linux trixie/sid trixie - Wayland - Vulkan (Mobile) - dedicated AMD Radeon RX 7600 (RADV NAVI33) - AMD Ryzen 5 7600 6-Core Processor (12 Threads)

### Issue description

I'm unable to scroll or scale vertically in the Animation dock's bezier editor.

In v4.3 / v4.2:
- Plain `Mousewheel` = no effect
- `Ctrl + Mousewheel` = horizontal zoom
- `Alt + Mousewheel` = no effect
- `Shift + Mousewheel` = no effect
- `Ctrl + Shift + Mousewheel` = horizontal zoom
- `Ctrl + Alt + Mousewheel` = no effect
- `Alt + Shift + Mousewheel` = no effect
- `Ctrl + Alt + Shift + Mousewheel` = vertical zoom

In v4.1 / v4.0:
- Plain `Mousewheel` = **vertical scroll**
- `Ctrl + Mousewheel` = horizontal zoom
- `Alt + Mousewheel` = **vertical scroll**
- `Shift + Mousewheel` = no effect
- `Ctrl + Shift + Mousewheel` = horizontal zoom
- `Ctrl + Alt + Mousewheel` = no effect
- `Alt + Shift + Mousewheel` = no effect
- `Ctrl + Alt + Shift + Mousewheel` = vertical zoom


Further, the vertical zoom part is confounding because the [documentation](https://docs.godotengine.org/en/stable/tutorials/animation/animation_track_types.html#bezier-curve-track), in a note added with 4.3, states that:

> zoom in and out on the time axis ... with `Ctrl + Shift + Mouse wheel`. Using **`Ctrl + Alt + Mouse wheel`** will zoom in and out on the Y axis

And to add to the confusion, there is at least one [previous report](https://github.com/godotengine/godot/issues/75476) which indicates that just `Alt+Mousewheel` would zoom vertically as of 4.0.1, but even if I try that exact version I get the same result as 4.1, above! :confused: 

So it might be a platform (Win/Linux+Wayland) difference? Or perhaps with all my version swapping my editor settings have got messed up somehow? Though I didn't think you could change mousewheel binds? :confused: 


### Steps to reproduce

1. Create a bezier track in an animation
2. Switch to bezier editor
3. Try to scroll vertically

### Minimal reproduction project (MRP)

n/a
Repository: vscode
Issue: Devtools error: No registered selector for ID: ms-vscode.npm-command
Labels: bug,debt

Starting up code-oss I see this:

![Image](https://github.com/user-attachments/assets/76a692cc-6afa-4cf5-9ff3-fabff3e5a01b)