sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Rewrite localized urls do not work consistently
Labels: bug

### 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: 16.18.1
      npm: 8.19.2
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.2.5-canary.14
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```


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

Internationalization (i18n)

### Link to the code that reproduces this issue

https://github.com/patriciomase/nextjs-localization-issue

### To Reproduce

Next version 10
go to localhost:3000/de/de --> it works
go to localhost:3000/de/de/no-slug-page --> it works
go to localhost:3000/de/de/page/1 --> it works

Next version 13
go to localhost:3000/de/de --> it works
go to localhost:3000/de/de/no-slug-page --> it works
go to localhost:3000/de/de/page/1 --> IT DOES NOT WORK

Next canary
go to localhost:3000/de/de -->  IT DOES NOT WORK
go to localhost:3000/de/de/no-slug-page -->  IT DOES NOT WORK
go to localhost:3000/de/de/page/1 --> IT DOES NOT WORK

### Describe the Bug

We use this kind of url for localization domain.com/de/de/page

As we can't set a locale containing a slash we were rewriting the url. (Example from de/de to de-de)

Example: rewriting from 'de/de/:path*' to 'de-de/:path*' used to work consistently in older versions

Around next 12 the pages containing dynamic slugs stopped working, the pages with a "static" url kept working just fine.
So, domain.com/de/de/my-page will work; domain.com/de/de/page/1 will FAIL

Now in the latest canary none of these works and it seems impossible to have a / (slash) in the localized path 

### Expected Behavior

Behaviour keeps consistent between next versions. Rewriting rules work as expected.

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

Not relevant. Server issue.

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

AWS. (but not relevant, issue happens locally too)
Repository: storybook
Issue: [Documentation]: Introduce the CLI's "add" option as the default way to install addons.
Labels: documentation

### Describe the problem

Currently, the documentation only features how to install Storybook addons via the known package managers (i.e., `yarn`, `npm`, `pnpm`), and sometimes, when a user tries to add an addon, he forgets to suffix the package with `next` tag, and with that it inadvertedly the stable version is added instead and leads to the addon not being able to work as it should with the alpha/beta/rc versions of Storybook. To address this, we should instead reference installing addons with our CLI using the `add` option as a first option (e.g., npx sb@next add @storybook/addon-a11y) and relegate using the package managers as alternatives.

For context, see this [discussion](https://github.com/storybookjs/storybook/issues/12622#issuecomment-1294510722) where the issue presented itself.

@shilman let me know when we're in the clear so I can make this change.

### Additional context

N/A
Repository: go
Issue: proposal: new option to configure internal packages from go.mod
Labels: Proposal,modules

I would like to propose a new feature for Go modules where `internal` package behavior can be managed centrally from the `go.mod` file.

I am proposing a new option enabling us to use directory names other than `internal` to indicate internal behavior and instead use a more centralized configuration at the module level.  When this statement block is used in the `go.mod` file, it would otherwise disable normal internal behavior in that the toolchain would not treat directories named `internal` as special.

This would be completely optional, like Go module replace directives, but if present would allow users to manage where internal "nodes" are located in their module with a declarative syntax for managing internal functionality:
```go.mod
internal (
  github.com/org/mod/package
  github.com/org/mod/otherpkg/subpkg
)
```
Or for the entire module
```go.mod
internal (
  github.com/org/mod
)
```
If the `go.mod` block is present, all directories are treated equally and there is no more special treatment of directories named `internal`.  This would be useful in development if an outside test module wanted to import/test internal code in a CI scenario.  For example, if I wanted to use the Go CLI to modify `go.mod` and add this `internal` block so that I can build my test module which imports/tests internal code without being denied by the toolchain.  That is a simpler and more practical solution than copying a package directory from its source module to the test module.  Of course, many would say to just keep the test code together in the `internal` directory but you may have outside tools that use have developed which makes things difficult.

Example scenarios where this might be useful:
1. Change management of internal functionality.  For example, I can put a package exactly where I want in a repo when I start working on it.  Then, I update `go.mod` to make that package internal so it's not exposed to anyone.  Finally, when it's ready I remove the entry from `go.mod` and the package is there.  At no point does that process involve new or changing directories, file move/renames, etc.  Plus, the entire history of these changes are captured centrally within the commit history of the `go.mod` file.

2. Eliminate useless nesting.  If I have a package called `services` and want everything in there to be internal.  Currently, I would have to rename this directory to `internal` to accomplish this.  Or worse, I could nest the `services` directory inside an `internal` directory, creating a `.../internal/services` structure where there are no Go files inside the `internal` directory.

3. Internal Modules.  Currently, this is not possible unless the root directory of the module is named `internal`.  This is not practical when many modules are at the repo root as it means a repo must be named `internal`.

The solution with the directory naming came before Go modules.  I think this is a more "Go modules" approach to internal functionality.
Repository: vscode
Issue: Dark+ default theme: Cannot tell highlighted from selected token
Labels: bug,themes

This is a follow-up on #152595:

With the current default VS Code Dark+ color theme, it's very hard to tell highlighted tokens from selected tokens when editing a PowerShell file:

![Cannot distinguish highlighted from selected token](https://user-images.githubusercontent.com/9283914/174493620-dfc156d0-8da7-435f-9b3b-1a230590b248.gif)

This leads to manifold maloperations and, thus, frustration when editing code using the keyboard for navigation.
<br/>

@aeschli's comment:
> Note: Users can customize the colors in the settings:
> 
> ```
>   "workbench.colorCustomizations":
>   {
>     "editor.selectionBackground": "#ff0000",
>     "editor.wordHighlightBackground": "#ff00ff",
>     "editor.selectionHighlightBackground": "#ffff00"
>   },
> ```

… doesn't change a thing, I'm afraid:

![Cannot recognize selected text](https://user-images.githubusercontent.com/9283914/227258313-b22c1843-1871-4d29-8631-fcbda1113eaf.png)
<br/>

Please improve contrast and, thus, accessibility and usability of the code editor.
<br/>
Repository: godot
Issue: [HTML5] Godot eats user gestures, preventing the use of certain browser APIs in Firefox
Labels: bug,platform:web,topic:porting,topic:thirdparty

### Godot version

3.5.1

### System information

Firefox on Linux

### Issue description

```
    var navigator = JavaScript.get_interface("navigator")
    var data_obj = JavaScript.create_object("Object")
    data_obj["title"] = "title"
    data_obj["text"] = "text"
    data_obj["url"] = "https://example.com"
    # need to call canShare first because otherwise some browsers will reject share()
    print(navigator.canShare(data_obj)) # True
    navigator.share(data_obj) # fails
```

This code is activated by a button in my game.  When I press the button, I see in the console:
`Navigator.share: User activation was already consumed or share() was not activated by a user gesture.`

But of course, share() was activated by a user gesture: clicking on the button.  Somehow Godot is eating the gesture.  

It works fine in Chrome (I only tested Chrome on Android).

It's especially vexing since `canShare()` returns true, so I wrongly show the share button (unless I put in special-case code for Firefox, which I guess is what I'll have to do).

### Steps to reproduce

See above

### Minimal reproduction project

See above
Repository: opencv
Issue: Solidify (inpaint)
Labels: feature

### Descripe the feature and motivation

I found `solidify` in [freebies](http://flamingpear.com/free-trials.html#freebies) to be very useful, and it has similar functionality to `inpaint`, so I hope you can add it.

Input

![Solidify_0](https://user-images.githubusercontent.com/34391447/227262337-64ad9ca6-ea16-46d5-918d-3b773677e1ae.png)


OpenCV: INPAINT_NS

![INPAINT_NS](https://user-images.githubusercontent.com/34391447/227262988-2e9e168f-4d67-49e1-a0ca-133ce5fe27b0.png)


OpenCV: INPAINT_TELEA

![INPAINT_TELEA](https://user-images.githubusercontent.com/34391447/227263004-293d4ae9-5d57-4407-ba38-af6729b1f5fd.png)



Solidify_A

![Solidify_A](https://user-images.githubusercontent.com/34391447/227262350-77aba8a1-9e1e-4e95-9f37-c296ae1ec793.png)

Solidify_C

![Solidify_C](https://user-images.githubusercontent.com/34391447/227262567-815719c2-1fbd-42ad-b062-6c18a3978709.png)


### Additional context

_No response_
Repository: godot
Issue: Mesh Library "Apply MeshInstance Transforms" causes issues with raycasts on GridMap
Labels: bug,topic:physics,topic:3d

### Godot version

4.0.1

### System information

Windows 10, Vulkan, NVIDIA GeForce RTX 3060 Laptop GPU, Driver 528.24

### Issue description

Ray casts on certain GridMap objects need to be much longer in order to hit the object.  Recreating the issue seems to require:

1. A semi-complicated mesh (I was able to recreate the issue with a hemisphere mesh but not a cube)
2. The scale of the object to be set high (e.g. 100)
3. The "Apply MeshInstance Transforms" option to be selected when the mesh library is exported

When ray casts do hit, they appear to report the correct position, but need to be extremely long (e.g. 100m) in order to actually hit the object.  The colliders otherwise seems to work fine for physics purposes, so the issue seems isolated to ray casting.

In this photo, the 3 cylinders are showing the ray cast distance for a set of RayCast3D nodes.  They should all be hitting the object, but only the green one is:

![3-rays](https://user-images.githubusercontent.com/4873959/227264669-145935d7-b191-4893-9174-13fc258cfa9c.PNG)


### Steps to reproduce

To create a mesh library with this issue, add a MeshInstance to a scene, set the mesh to something non-trivial (e.g. a sphere), and set the scale set to (100, 100, 100).  Create a Trimesh Static Body on the mesh using the Mesh drop-down in the editor.  Export the scene as a mesh library and make sure "Apply MeshInstanace Transforms" is checked.  In a new scene, create a grid map with the exported mesh library and place one or more of the objects.  Then perform any ray cast activity involving the grid map, either with the RayCast3D node or direct space state `intersect_ray`.

### Minimal reproduction project

[grid-map-raycasts.zip](https://github.com/godotengine/godot/files/11052970/grid-map-raycasts.zip)
Repository: next.js
Issue: Incorrect warning for objects with null prototype passed from Server Components to Client Components
Labels: Upstream,bug

### 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 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.19.0
      npm: 9.4.1
      Yarn: 1.22.19
      pnpm: 7.14.2
    Relevant packages:
      next: 13.2.5-canary.14
      eslint-config-next: N/A
      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)

### Link to the code that reproduces this issue

https://github.com/charltoons/next-rsc-null-prototype-warning

### To Reproduce

Pass an object with a `null` prototype from a Server Component to a Client Component

Example server component:
```tsx
  const objectWithNullPrototype = Object.create(null);
  objectWithNullPrototype.foo = "bar";
  return <ClientComponent myObject={objectWithNullPrototype} />
```

Example client component:
```tsx
"use client";

export const ClientComponent = (myObjectProp: any) => {
  return <pre>{JSON.stringify(myObjectProp)}</pre>;
};
```

### Describe the Bug

Observe in the server logs the following warning:
```
Warning: Only plain objects can be passed to Client Components from Server Components. Classes or other objects with methods are not supported.
  <... myObject={{foo: "bar"}}>
                ^^^^^^^^^^^^^^
```

While this is only a warning and does not inhibit runtime behavior, large objects will print this warning for each object instance. We discovered this issue when trying to pass an extracted cache from an Apollo client (which uses null prototype) to a client component. In this case, it results in hundreds of lines of warning logs for each request.

I'm not sure if this a a Next.js bug or a React bug. The issue can be attributed to this function: https://github.com/vercel/next.js/blob/canary/packages/next/src/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-server.browser.development.js#L1154

### Expected Behavior

No warning is emitted since objects with `null` prototype are serializable.

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

_No response_

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

Vercel (the issue appears during local dev)
Repository: stable-diffusion-webui
Issue: [Bug]: Picture previews are slow to load since update
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

In one of the more recent commits, something changed that significantly slowed down loading the grid and picture previews for a completed session.

And additional issue is that some of the previews will not load in the display at all. If you use your arrow keys to progress through the images you will get the preview window lingering forever on the previous image. Directly clicking the problem image doesn't do anything.

I rolled back to an earlier commit on Feb 19 (014e7323f6f54a38183f8de52dc83f2248eee251) and the problem went away.



### Steps to reproduce the problem

1. Create a prompt and have it generate 2 or more batches of 100 pictures
2. Watch how long it takes to show the preview image.
3. Arrow key through images and note long load times.
4. Minimize browser window, do something else, then go back to the GUI and note how long it takes to reload the images.




### What should have happened?

Fast loading of images is not occuring.

### Commit where the problem happens

a9fed7c364061ae6efb37f797b6b522cb3cf7aa2

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

Windows

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

Google Chrome

### Command Line Arguments

```Shell
--xformers
```


### List of extensions

openpose-editor	https://github.com/fkunn1326/openpose-editor.git	42ba3d5d (Sat Mar 18 23:09:12 2023)	unknown
sd-dynamic-prompts	https://github.com/adieyal/sd-dynamic-prompts.git	1596f556 (Mon Mar 6 04:49:07 2023)	unknown
sd-webui-controlnet	https://github.com/Mikubill/sd-webui-controlnet.git	2f0e6732 (Tue Mar 21 17:37:51 2023)	unknown
stable-diffusion-webui-tokenizer	https://github.com/AUTOMATIC1111/stable-diffusion-webui-tokenizer.git	ac6d541c (Sat Dec 10 12:58:31 2022)	unknown
ultimate-upscale-for-automatic1111	https://github.com/Coyote-A/ultimate-upscale-for-automatic1111.git	0a3d03a4 (Tue Feb 7 06:07:23 2023)	unknown
LDSR	[built-in](http://127.0.0.1:7860/)		
Lora	[built-in](http://127.0.0.1:7860/)		
ScuNET	[built-in](http://127.0.0.1:7860/)		
SwinIR	[built-in](http://127.0.0.1:7860/)		
prompt-bracket-checker	[built-in](http://127.0.0.1:7860/)







### Console logs

```Shell
not relevant
```


### Additional information

_No response_
Repository: next.js
Issue: [NEXT-892] Re-export of client components needs to be marked as use client as well
Labels: Webpack

### 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 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.14.0
      npm: 9.3.1
      Yarn: 1.22.10
      pnpm: N/A
    Relevant packages:
      next: 13.2.5-canary.14
      eslint-config-next: 13.1.6
      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)

### Link to the code that reproduces this issue

https://stackblitz.com/edit/vercel-next-js-tlwzjp?file=src/layout.jsx

### To Reproduce

1. Create pages/layouts in separate folder (not `app/`)
2. Mark those as client components (`'use client'`)
3. Reexport those in `app/` directory without marking that file as client component

### Describe the Bug

The build process fails while trying to generate pages with following error:
```
Error occurred prerendering page "<page>". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Cannot access .then on the server. You cannot dot into a client module from a server component. You can only pass the imported name through.
    at Object.get (<project-folder>/.next/server/chunks/256.js:31807:15)
    at async createComponentTree (<project-folder>/node_modules/next/dist/server/app-render/index.js:501:29)
    at async <project-folder>/node_modules/next/dist/server/app-render/index.js:419:56
    at async Promise.all (index 0)
    at async createComponentTree (<project-folder>/node_modules/next/dist/server/app-render/index.js:383:38)
    at async <project-folder>/node_modules/next/dist/server/app-render/index.js:419:56
    at async Promise.all (index 0)
    at async createComponentTree (<project-folder>/node_modules/next/dist/server/app-render/index.js:383:38)
    at async <project-folder>/node_modules/next/dist/server/app-render/index.js:419:56
    at async Promise.all (index 0)
```

### Expected Behavior

The build doesn't fail without the need of marking those components manually. This was the behaviour on `next@13.1.6`

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

_No response_

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

_No response_

<sub>[NEXT-892](https://linear.app/vercel/issue/NEXT-892/re-export-of-client-components-needs-to-be-marked-as-use-client-as)</sub>
Repository: excalidraw
Issue: Allow for adaptive colors in SVG exports
Labels: enhancement

Excalidraw SVG outputs have the option of a transparent background.

Where excalidraw is being used to produce images for a site with light & dark modes, it'd be nice if the images themselves were color-adaptive. Reference stackoverflow: https://stackoverflow.com/questions/67187091/creating-svg-that-appears-black-in-light-mode-and-light-in-dark-mode

UX wise, maybe the export tool could expose a "dark mode" checkbox, which, when clicked, replaces the preview box with a side-by-side that shows the original and a generated inverted color scheme.
Repository: godot
Issue: Game crashes immediately without error message
Labels: bug,topic:gdscript,crash

### Godot version

4.0.1.stable.official [cacf49999]

### System information

Windows 10

### Issue description

When I attach a PackedScene to my script, the game crashes immediately upon opening with no messages. Without the scene attached, it works as normal.

![Screenshot (4)](https://user-images.githubusercontent.com/29776687/227319094-c0658790-bc79-4e5e-9441-17e528c3d18d.png)
![Screenshot (5)](https://user-images.githubusercontent.com/29776687/227319121-7dee0e36-357f-4b59-ab3d-49cfbc612a68.png)


### Steps to reproduce

Play Game1 scene with Linked Scene attached

### Minimal reproduction project

[Project.zip](https://github.com/godotengine/godot/files/11054953/Project.zip)
Repository: vscode
Issue: Git - pre-push and pre-commit git hooks are handled differently when errors occur
Labels: bug,git

<!-- ⚠️⚠️ 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. -->
Version: 1.76.2 (user setup)
Commit: ee2b180d582a7f601fa6ecfdad8d9fd269ab1884
Date: 2023-03-14T17:55:54.936Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Windows_NT x64 10.0.19044
Sandboxed: No

Issue:

`pre-commit` and `pre-push` git hooks are not handled consistently when errors occur.

`pre-commit`:
![commit error](https://user-images.githubusercontent.com/99204238/227335641-a5c458a4-5383-490e-9bdd-98d618af4dbf.png)

`pre-push`: 
![push error](https://user-images.githubusercontent.com/99204238/227335749-0c2cd047-85fd-4ea8-8416-01e49177cda8.png)

Steps to Reproduce:

1. Create a fresh directory
1. `git init`
1. Create `pre-commit` and `pre-push` files in the git hooks directory with the following contents:
   ```shell
   #!/bin/sh
   
   echo "Failure message"
   exit 1
   ```
1. Try to commit from VSCode Source Control Tab
1. Error message says "Git: Failure message"
1. Disable the `pre-commit` hook
1. Make a successful commit
1. Configure a remote and attempt to run `git push`
1. Error message says "Can't push refs to remote.  Try running "Pull" first to integrate your changes"

`pre-commit` seems to use the first line of output in the error dialog, whereas `pre-push` uses the last one.  It'd be nice if these were consistent.  Furthermore, it seems that I just can't control the dialog message for `pre-push` failures, it's always the same.