sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: editor.find.cursorMoveOnType Non-Functional in Notebooks
Labels: feature-request,notebook-find

Type: <b>Bug</b>

Open a Jupyter Notebook file and run Ctrl+F (or similar shortcut for Find). Even with editor.find.cursorMoveOnType enabled, typing will not move the cursor or the view until hitting Enter - this has the frustrating effect of meaning that the second search result is the one displayed on search completion, not the first. Occurs even with extensions disabled.

VS Code version: Code 1.81.1 (Universal) (6c3e3dba23e8fadc360aed75ce363ba185c49794, 2023-08-09T22:20:33.924Z)
OS version: Darwin arm64 22.6.0
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Apple M1 (8 x 24)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>metal: disabled_off<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)|3, 2, 2|
|Memory (System)|16.00GB (0.33GB free)|
|Process Argv|--crash-reporter-id 52f21196-41fe-460c-9a9f-aae4845bd8e8|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (19)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-markdownlint|Dav|0.51.0
githistory|don|0.6.20
python-environment-manager|don|1.0.4
vsc-python-indent|Kev|1.18.0
dotenv|mik|1.0.1
black-formatter|ms-|2023.4.1
isort|ms-|2023.10.1
python|ms-|2023.14.0
vscode-pylance|ms-|2023.8.40
jupyter|ms-|2023.7.1002162226
jupyter-keymap|ms-|1.1.2
jupyter-renderers|ms-|1.0.17
vscode-jupyter-cell-tags|ms-|0.1.8
vscode-jupyter-slideshow|ms-|0.1.5
autodocstring|njp|0.6.1
indent-rainbow|ode|8.3.1
vscode-yaml|red|1.14.0
intellicode-api-usage-examples|Vis|0.2.7
vscodeintellicode|Vis|1.2.30


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30792226
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
vscccc:30803845
2e4cg342:30602488
f6dab269:30613381
showlangstatbar:30737416
03d35959:30757346
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
gsofb:30804716
pythonnosmt12:30797651
pythonidxpt:30805730
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
diffeditorv1:30812748

```

</details>

<!-- generated by issue reporter -->
Repository: next.js
Issue: searchParams object is empty in production build on Vercel 
Labels: bug,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.1.0: Sun Oct  9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000
  Binaries:
      Node: 18.15.0
      npm: 9.8.1
      Yarn: N/A
      pnpm: 8.1.1
  Relevant Packages:
      next: 13.4.20-canary.4
      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) of Next.js are affected? (leave empty if unsure)

_No response_

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

https://github.com/andrewgolovanov/reproduction-app

### To Reproduce

**Steps for testing:**
1. Deploy the [reproduction-app repository](https://github.com/andrewgolovanov/reproduction-app) to Vercel.
**Note**: _This issue doesn't manifest locally or with the Vercel CLI._
2. Navigate to `https://<your-vercel-domain>/user/1?test=1`
3. Inspect the Vercel logs to verify the presence of `searchParams`.
4. Navigate to `https://<your-vercel-domain>/blog/1?test=1`
5. Recheck the Vercel logs. This time, `searchParams` should be absent.

### Describe the Bug

The crux of the issue is that the `searchParams` object returns empty unless directly interacted with within the function body. For instance, passing it as a parameter for GraphQL operations results in an error due to its emptiness.

Below is a snapshot from Vercel logs highlighting the problem:
<img width="2040" alt="image" src="https://github.com/andrewgolovanov/reproduction-app/assets/17677196/e333dbd2-2d6b-4027-afe5-fcd435ae349a">

For a more illustrative example, refer to this [detailed use-case of searchParams](https://github.com/neondatabase/website/blob/main/src/app/blog/wp-draft-post-preview-page/page.jsx#L40). Here, utilizing `searchParams` becomes unfeasible as it's devoid of content.

Similar closed issue [[NEXT-601] search params object is empty in production with next 13 app dir](https://github.com/vercel/next.js/issues/43077) where unfortunately the reproduction does not show the real problem

**Related PR**: It seems to me that the changes in [this pull request](https://github.com/vercel/next.js/pull/46205/files) are related to described issue

### Expected Behavior

Developers should be able to rely on the `searchParams` object. It should consistently provide necessary query parameters without workarounds or dependency on a particular way it is utilized within the code.

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

_No response_

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

Vercel

<sub>[NEXT-1563](https://linear.app/vercel/issue/NEXT-1563/searchparams-object-is-empty-in-production-build-on-vercel)</sub>
Repository: godot
Issue: Control Nodes suffer from jittering when resized using non default anchoring
Labels: bug,confirmed,topic:gui

### Godot version

4.1.1.stable ( and  mono ) , 4.2 dev3 ( and mono ) , 4.0 have been tested.

### System information

Fedora Linux 38 (Workstation Edition)

### Issue description

When a Control node is not left in its default anchor state ( that being anchored to top left ), It will "jitter" when "Custom minimum size" is used to resize it.

Which is an issue since for some reason using the regular "size" will not expand a control node from its centre if using centre anchoring, will not expand leftwards when using top right anchoring, etc.. if intentional i cannot grasp the reason for this, although i'm sure there might be a valid reason to do so. Using custom minimum size is also inconvenient as it messes with animations.

Demo video (zoomed in for clarity ) 


https://github.com/godotengine/godot/assets/74463310/0c3ee954-d14d-4547-870c-4e709c056900



### Steps to reproduce

The minimal reproduction project is as slim as possible and straightforward as possible, to use it simply play the animation player in the only provided scene and the "jitter" can be clearly seen along with labels pointing to its exact location

### Minimal reproduction project

[Control_Jitter_min_rep_project.zip](https://github.com/godotengine/godot/files/12430148/Control_Jitter_min_rep_project.zip)
Repository: material-ui
Issue: [joy-ui] Add Sidebar component
Labels: new feature,waiting for 👍,package: joy-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

In https://github.com/mui/material-ui/pull/38169 we started a discussion of adding a Sidebar (left navigation, permanent drawer) component. Although it can be built using CSS grid or flexbox relatively easy, the value of it is to bring consistency and great DX. In addition to this, the component is often used together with the `Drawer` component, depending on the screen size, for e.g. https://mui.com/material-ui/react-drawer/#responsive-drawer.

In terms of the name for the component we can choose from the following:
- PermanentDrawer (following Material UI's nomenclature)
- Sidebar (similar to Chakra UI, I also feel this is the most common used term describing this component)
- Sidenav (indicating it is a navigation)
- AppShell

### Examples 🌈

Mantine - https://mantine.dev/core/app-shell/
Material UI - https://mui.com/material-ui/react-drawer/#permanent-drawer
Chakra UI (pro) - https://pro.chakra-ui.com/components/application/sidebars
Ant design - https://ant.design/components/layout#components-layout-demo-side

### Motivation 🔦

Bringing consistency and feature parity with other react UI libraries.
Repository: next.js
Issue: Docking client not rendering on drag since 13.4.9-canary.3
Labels: bug

### Verify canary release

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

### Provide environment information

```bash
next-js-server-rc-dock]$ npx --no-install next info

    Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Sat Jun 10 12:24:53 UTC 2023
    Binaries:
      Node: 18.9.1
      npm: 9.5.0
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.20-canary.4
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A
```


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

App Router

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

https://github.com/aranselmo/next-js-server-rc-dock/tree/nonworking-with-v13.4.20-canary.4

### To Reproduce

Use an app like the above link with latest rc-dock  and latest next.js to run it. In the non-working branch you will not see drag snap to buttons on dragging a panel, whereas in the main working branch, you will see snap to buttons on dragging. The only difference is the  version of next.js used so this was introduced in the last few months of changes.

Really, all you theoretically need for this example is an import {DockLayout} from 'rc-dock' and page returning DockLayout object with one of the examples from https://ticlo.github.io/rc-dock/examples/.

This is just a realistic simplification of a docking with state stored in a context provider.

### Describe the Bug

Fundamentally the bug is the latest next.js isn't allowing a third-party client component to trigger a rerender of its root element on dragging.

On the above main branch using next.js **13.4.8** (which works as it used to work), the rc-dock allows dragging one tab panel over another panel and it will render a snap-to pop up in the center that lets you snap the panel above/below/etc. in relation to the drag target.

On the above branch using latest next.js, the rc-dock no longer renders the DockLayout root component on drag and so never shows the dock snaps and prevents rc-dock from working.

I tracked this down to a change in **13.4.9-canary.3** which mentions not rerendering the root element unnecessarily, but this was a breaking change for my apps at least and the only difference is updating next.js version.

### Expected Behavior

I think there needs to be more thought put into the change made in 13.4.9-canary.3 that prevents root rerendering and either make it some sort of flag that can be disabled/enabled or something.

Otherwise, I'd like a suggested workaround for how to wrap my DockLayout component that would allow it to work with the latest next.js.

As is, I've had to lock my application to version 13.4.9-canary.2 as that is the last working version for this combination.

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

Latest Chrome, but shouldn't matter

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

npm run dev
Repository: flutter
Issue: Consider removing the author requirement on the no-response bot
Labels: team-infra,P3,triaged-infra

Currently the no-response bot only removes the label if the original author comments. This isn't always desirable:
- Sometimes we ask for information in an old issue to see if it's still happening, and the author never replies, but someone else replies to say that they can reproduce it in a current version; even though we've received exactly the information we want, the issue is auto-closed anyway.
- https://github.com/flutter/flutter/issues/131319 is an example where one person filed an issue and then a colleague took over responding, so the label never got removed, and a critical issue's triage to the correct team was delayed by more than a week.

I think we should strongly consider changing it to remove the label if there is any comment, regardless of author. This isn't configurable in the upstream bot, but we are already using a fork, so we could change this in our fork (and send a PR upstream in case they are interested).

The downside is that things like "me too" comments that don't answer the question would remove the label. If that happens a lot, then we would spend more time re-adding the label. That seems likely to be low cost though (especially since if any given issue is getting a lot of me-too comments in a short time that's probably a signal that we should take a closer look at whether it needs accelerated triage), and this change should be easy to make, so we could try it and see if it's a significant issue in practice.

/cc @helinanever
Repository: material-ui
Issue: [Modal] Normalize the component & usage across all products
Labels: umbrella,component: modal

This issue will serve as an umbrella for all issues (inconsistencies) found around the modal vs non-modal features noticed on all different products.

- Material UI - we are missing a non-modal dialog demo. We technically have the `hideBackdrop` prop that makes this possible, but we are not educating people about this. The docs states "A Dialog is a type of [modal](https://mui.com/material-ui/react-modal/) window that appears in front of app content to provide critical information or ask for a decision. Dialogs disable all app functionality when they appear, and remain on screen until confirmed, dismissed, or a required action has been taken.", but there are also non-modal dialogs scenarios, that should likely support, for e.g. check https://accessuse.eu/en/non-modal-dialogs.html#:~:text=A%20non%2Dmodal%20dialog%20pops,partly%20covered%20by%20the%20dialog. This page has great examples of both use-cases https://www.nngroup.com/articles/modal-nonmodal-dialog/
- Joy UI - we are missing a page for the Dialog, the only demo we have lives on the modal's page, it may not be straight forward to find it - https://mui.com/joy-ui/react-modal/#modal-dialog. The modal should be treated as a utility component, used in different components, we should not educate people to use it directly, but have components for the most common use-cases it is associated with, like dialogs, drawers etc.
- Inconsistencies between using modal vs non-modal popups in some components. For e.g. on the Select component, Material UI uses a modal element for the options list - this means that when the select is open, users cannot directly take different action by clicking on an element outside of the list. For example try this demo - https://cml5vj.csb.app/ (open the select and try clicking on the button while it is opened). While this works great for mobile, the behavior is a bit odd on desktop, as you can likely find a spot to click in order to close the select without taking unintended action. On the contrast Base UI (and Joy UI) offer only the non-modal option, which works great on desktop, but could be problematic on mobile devices, where you may not have an available space to tab in order to close the select without taking an action. In my opinion we should support both of these scenarios in all libraries.

### Issues

- https://github.com/mui/material-ui/issues/38756
Repository: flutter
Issue: Minimum height/Width for RenderIntrinsic
Labels: c: new feature,framework,c: proposal,P2,team-framework,triaged-framework

- [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

It would be nice if `RenderIntrinsic` had a minimum value in a case that we don't want the children to have a too small height/width.



### Proposal

The constructor will look like:
```dart
  RenderIntrinsicHeight({
    RenderBox? child,
   double? minHeight,
  }) : super(child);
```
Then the `computeMinIntrinsicHeight` will be calculated depending on whether there is a `minHeight` or not.
Repository: deno
Issue: Add support to redirect a Worker's `console.log`
Labels: suggestion,runtime

I need the parent thread to transform whatever the worker logs on the console, e.g. 
```ts
// parent.ts
console.log("hey there, I'm the parent.");

// worker.ts
console.log("hey there, I'm a child!");

// terminal when running
[LOG] hey there, I'm the parent.
[Worker 42] [LOG] hey there, I'm a child!

```
I got it working with pipes for child processes. However I cannot see any method to do that with workers.
I've also tried to temporarily override `console.log` into a wrapper in the parent before creating the worker, in vain.
Is there a theoretical reason I could not do that, or is it merely a missing feature?
Thanks
Repository: pytorch
Issue: [BE] Consolidation of SymNode methods constant_int, maybe_as_int, etc
Labels: triaged,oncall: pt2,module: dynamic shapes

This is something of a preexisting problem, but I wonder why I didn't just have `maybe_as_int` take care of everything...

_Originally posted by @ezyang in https://github.com/pytorch/pytorch/pull/107089#discussion_r1294920333_
            


cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @wconstab
Repository: TypeScript
Issue: Incorrect error reported when using `class extends null` and re-opening interface
Labels: Bug,Fix Available,Rescheduled

### 🔎 Search Terms

class extends null interface

### 🕗 Version & Regression Information

- This is the behavior in every version I tried (at least up until 3.3, which is the oldest build in the playground).


### ⏯ Playground Link

https://www.typescriptlang.org/play?lib=true&ts=5.1.6#code/JYOwLgpgTgZghgYwgAgEJwM4oN4CgC+uuCANphsgMLIQAekIAJhSAK4knJ7I-IID2IDGCisEYflAAUASi65eyQoVCRYiFNToNmaTDnxA

### 💻 Code

```ts
interface Base {
}

class C extends null {
    constructor() {
    }
}
interface C extends Base {}
```

### 🙁 Actual behavior

Reports the following error:

```
Class static side 'typeof C' incorrectly extends base class static side 'null'.
```

### 🙂 Expected behavior

No error. `inteface Base` does not describe the static side of anything, and reopening a class using something like `interface C extends Base {}` is common practice for shims.

### Additional information about the issue

I ran into this when implementing a class that utilizes `return` override in a constructor when combined with `class extends null` while experimenting with the Shared Structs origin trial (whose constructors produce objects with a `null` prototype). Though native `extends null` has some issues in ES2015+, it still works fine with explicit `return` override in a constructor in any engine:

```js
class C extends null {
  constructor() {
    return {};
  }
}
new C(); // works just fine.
```
Repository: PowerToys
Issue: Always on top - Ability to set different display orders/priority levels
Labels: Needs-Triage

### Description of the new feature / enhancement

When activating Always On Top, I can specify different z-orders on windows so that an "always on top" window is **_more_** on top than others.

This could be introduced as a new setting under "Appearance and behavior" that enables the user to set or cycle through more than one level. Perhaps having different colored borders for the different levels would be nice.

### Scenario when this would be used?

When a user has multiple "always on top" windows and some windows should _always_ be above other "always on top" windows. Similar to how Task Manager's always on top has a higher priority.


### Supporting information

[Defining Window z-order blog post](https://blog.adeltax.com/window-z-order-in-windows-10/)
Repository: flutter
Issue: [Impeller] Move `toImageSync` off raster thread.
Labels: engine,c: proposal,P3,e: impeller,team-engine,triaged-engine

<img width="1289" alt="Screenshot 2023-08-24 at 8 12 09 AM" src="https://github.com/flutter/flutter/assets/30870216/872d61c4-c4ed-4da2-bbb9-841d9bb1e291">

`toImageSync` currently is executed on the raster thread because of historical limitations of OpenGL.  I suspect we'll get better performance if we just execute it on the ui thread with vulkan.

As seen in the screenshot above, `toImageSync` can occupy time that could be used for encoding frames on the raster thread.  In the example above the raster thread gets backed up, then fires many frames in quick succession which means there isn't a drawable available for the next frame.

It's hard to estimate the impact of this change.  At a bare minimum, executing `toImageSync` on the ui thread will remove the overhead of synchronizing the ui thread with the raster thread.  And it means the building of one thread on the ui thread cannot interfere with the encoding of the previous frame on the raster thread.

If switching `toImageSync` would switch the order of operations to `Snapshot->Submit Frame->Snapshot->Submit Frame` versus `Snapshot->Snapshot->Submit Frame->Submit Frame` that would be preferable since it would give more time for the gpu to render the first frame.  I'm not sure if the Snapshots are both associated with the first frame or not though.

---

Jonah has suggested experimenting with https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/page_transitions_theme.dart#L226 and disabling the snapshotted page transition.
Repository: flutter
Issue: DartPluginRegistrant test flakes on mac_host_engine
Labels: P2,team-engine,triaged-engine

https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20Production%20Engine%20Drone/129959/overview

from https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20mac_host_engine/5796/overview

```
[0;32m[ RUN      ] [mDartIsolateTest.DartPluginRegistrantFromBackgroundIsolate
[ERROR:flutter/testing/elf_loader.cc(26)] App AOT file does not exist for this fixture. Attempts to launch the Dart VM with these AOT symbols will fail.
[FATAL:flutter/runtime/dart_vm_initializer.cc(89)] Error while initializing the Dart VM: Precompiled runtime requires a precompiled snapshot
[1/8] DartIsolateTest.DartPluginRegistrantFromBackgroundIsolate returned/aborted with exit code -6 (21 ms)
[2/8] DartIsolateTest.DartPluginRegistrantIsPresent (21 ms)
```
Repository: flutter
Issue: [Impeller] Support rendering in engine lib UI tests
Labels: P2,c: tech-debt,e: impeller,team-engine,triaged-engine

For example, imagine I wanted to write a test that shows the following bug: https://github.com/flutter/flutter/issues/126673.

I'd (as far as I understand it) _have_ to write this in the framework layer (`flutter/flutter`) in order to get full tooling support, and in the case of validating that we're drawing the "right kind of lines", probably golden-file tests. Within `flutter/engine`, there are two other kinds of tests that don't seem to meet my needs:

1. [`aiks_unittests.cc`](https://github.com/flutter/engine/blob/d3172a072366408e622a7ce0f1ac75999e986e26/impeller/aiks/aiks_unittests.cc#L453-L478), which runs on the Impeller backend with a custom harness, but doesn't let me reuse existing tests and will be harder to catch Skia <> Impeller fidelity issues.
2. [`canvas_test.dart`](https://github.com/flutter/engine/blob/9fc3246bff1849864f2aaeff973029fbf560a6a8/testing/dart/canvas_test.dart#L327-L367), which only runs on the software backend (which Impeller doesn't support if I understand correctly).

Related issues:

- https://github.com/flutter/flutter/issues/53784
- https://github.com/flutter/flutter/issues/76565