Lexical version: Latest

## Steps To Reproduce

1. Open [Lexical playground](https://playground.lexical.dev/)
2. Replace text with "foo.bar"
3. Set cursor to beginning of text
4. Type OPTION + right arrow

Here is a Replay of the bug: https://app.replay.io/recording/2d509a52-e59b-40bd-83a9-ba17e89c90b8

## The current behavior
In Firefox, the cursor is now after the dot

## The expected behavior
Cursor should move before dot

all-platforms-bug

core

lexical

Bug: Option + Right arrow cursor bug (Firefox)

We do a search if app.replay.io/recording exists in the issue, but only capture if it is included in the description. We could also pull in comments to capture replays posted there so all rows have a link.

replayable

Capture replay links from comments

I tried to buy a hoverboard but it failed with an error :(

overboard

I can’t buy a board :(

Hey hey, just wanted to let you know this counter doesn't increment.

broken-counter

Counter doesn't increment

![image](https://user-images.githubusercontent.com/87003751/222906320-80bb96fe-626f-471f-b21e-3092b798e6f8.png)


Protocol-Examples

react mount detection demo error

We made a Replay of this behavior 😛: https://app.replay.io/recording/dc020aef-64e2-4a4b-9a0d-1475ea12aebf you can click through to see a video.

I made an attempt to figure it out, and you can see my thought process in the replay. Afaict it's happening in the call to `sort` in `mergeObjectUpdates`, but I can't tell why.

https://github.com/tilt-dev/tilt/blob/master/web/src/HUD.tsx#L388

tilt

Resources reordering rapidly in sidebar

Thread:

- https://twitter.com/k_woodhouse93/status/1585713986569637888
- https://twitter.com/k_woodhouse93/status/1585921284902252545
- Repro: https://twitter.com/k_woodhouse93/status/1586308416871489537
  - https://github.com/kwoodhouse93/ink-redux-repro
  - Replay (possibly crashing): https://app.replay.io/recording/replay-of-distclijs--797ca851-8c51-44c5-ba2f-ece05da30960

react-redux

Possible issue with either RTKQ or React-Redux with Ink

This does not seem to cause any problems while recording, but we crash when attempting to replay it. Personally, I think it would be reasonable to just disable the print dialog from Replay because that doesn't feel like a feature that people will run into much (if anything they are likely to accidentally bring up the dialog like me and accidentally mess up their recording), but we could also fix it  for full marks 😄 

Recording: https://app.replay.io/recording/please-consider-the-environment-before-printing-this-replay--aacb2af2-2107-492d-82ab-69dd4ca2d4c7?point=60684969543474293057435418937531463&time=60857&hasFrames=false (crash happens between 30 and 40 seconds I think)

limitation

linear

gecko-dev

Opening the Print Dialog cannot be replayed

### 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 Pro
    Binaries:
      Node: 18.15.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.3.0
      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)

Middleware / Edge (API routes, runtime), Operating System (Windows, MacOS, Linux)

### Link to the code that reproduces this issue or a replay of the bug

https://app.replay.io/recording/untitled--a2870323-63de-40a4-876e-7f0eb5ebec5e

### To Reproduce

- error ./node_modules/.pnpm/next-auth@4.22.1_next@13.4.4_nodemailer@6.9.2_react-dom@18.2.0_react@18.2.0/node_modules/next-auth/next/middleware.js
Module parse failed: Identifier 'NextResponse' has already been declared (3:6)
| "use strict";
| const NextResponse = require("next/dist/server/web/spec-extension/response").NextResponse;
> const NextResponse = require("next/dist/server/web/spec-extension/response").NextResponse;
| var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");
| Object.defineProperty(exports, "__esModule", {

Import trace for requested module:
./node_modules/.pnpm/next-auth@4.22.1_next@13.4.4_nodemailer@6.9.2_react-dom@18.2.0_react@18.2.0/node_modules/next-auth/next/middleware.js
./node_modules/.pnpm/next-auth@4.22.1_next@13.4.4_nodemailer@6.9.2_react-dom@18.2.0_react@18.2.0/node_modules/next-auth/middleware.js

### Describe the Bug

after updating to next 13.4.4 have this bug, when downgrading everything works fine.

### Expected Behavior

no bug, normal dev

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

please add a complete reproduction

template: bug

area: Edge

type: needs triage

area: OS

next.js

Nodemailer issue on next 13.4.4

### Version

v14.17.6

### Platform

Darwin Nates-MacBook-Air.local 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:36:53 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T8101 x86_64

### Subsystem

_No response_

### What steps will reproduce the bug?

As a possible workaround for https://github.com/RecordReplay/node/issues/28 I used process.exit to exit my script as a desirable point. The command I used to run the recording is `replay-node --exec ts-node ./src/index.ts `. 

### How often does it reproduce? Is there a required condition?

Seemingly every time 

### What is the expected behavior?

Replay should pause at the specified breakpoint

### What do you see instead?

Replay seems to be pausing at an unrelated breakpoint

### Additional information

The replay I'm experiencing this bug on is https://app.replay.io/recording/replay-of-ts-node--2833115f-26fd-4160-8b1d-ec19f86d8d16

Replay of the bug occurring is at https://app.replay.io/recording/replay-misidentifying-where-to-pause-for-breakpoint--3668d82a-b2e6-49cd-a1cb-0ba103cdcd85 

Reported on Discord at https://discord.com/channels/779097926135054346/798693728999047203/980889833998282792

Screen recording uploaded to Discord at https://discord.com/channels/779097926135054346/798693728999047203/980890518898753566 

node

Replay not pausing at correct position in call stack for breakpoint

### Verify canary release

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

### Provide environment information

```bash
I am running this on vercel.
```


### 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://app.replay.io/recording/lusio-or-discover-new-games-or-track-your-gaming-portfolio-or-connect-with-other-gamers--4eed141a-022b-414e-82b5-77086de448b0

### To Reproduce

In the replay video below, please open the network terminal and look for 'signout' request.
Here, I have navigated through two environments, 
1. First one does not contain any reverse proxy from vercel and is directly hitting our API server.
2. Second one is being routed through a reverse proxy of vercel which I have configured in next.config.js.
Both these environments are actually deployed to vercel right now.

In the first `signout` request, please find that the headers 'st-access-token' and 'st-refresh-token' in the response are received by the browser as empty headers or with a value of ' '.

In the second instance where the 'signout' request goes through next's rewrite method's reverse proxy, these headers are not being received on the browser. 

### Describe the Bug

Bug here is that empty headers in response are being removed by the reverse proxy enabled through 'rewrite' method in next config. This is unexpected behaviour.

### Expected Behavior

The empty headers should be sent to browser as-is and should not be removed.

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

Version 113.0.5672.63 (Official Build) (arm64)

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

Vercel

Empty headers in response of request proxied through `rewrites` get automatically removed. 

### Description

When using Stately Studio on Windows 11 (22H2) with either Chrome (107.0.5304.63) or Firefox (106.0.1), zoom in and zoom out actions (by pressing Ctrl + Mouse Wheel Up or Down) are zooming in or zooming out way too much.

### Expected result

When pressing Ctrl button and scrolling mouse wheel button, on every tick the zoom should change by a reasonable distance, that's roughly equal between ticks.

### Actual result

When zooming in, zoom percentage seems to double on every tick. When zooming out, zoom percentage always goes to 10%.

### Which browsers are you seeing the problem on?

Firefox, Chrome

### Additional details

Here's a link to a Replay recording: https://app.replay.io/recording/search-box-or-search-box-or-stately-studio--c6f61ac4-f6b7-4d67-80fe-f52635cb8a5d

studio-issues

Bug: unexpected zoom behavior on Windows 11

Hi there,

With small size images, I get an issue like below:

![image](https://user-images.githubusercontent.com/94069932/150785560-7ba16f05-367d-4db8-bcf5-4fe4066034f2.png)

Can anybody help me?
Thanks in advance.

masonry

Issue with small size images

Probably a bug in visibility detection. 

Steps to repro:

1. https://excalidraw.com/#json=5236195592241152,nBFUdjjvd2rZyqpNHBMKUg
2. zoom on the ~center of the rectangle to 1000%

excalidraw

zooming on a shape stops rendering it

I'm debugging this recording:
https://app.replay.io/recording/21594023-f9ae-4787-912c-c391a68304aa

and I've noticed that sometimes I'm not able to step into certain functions. Take a look at this loom:
https://www.loom.com/share/9628264e684a4d0eb66e5176296972e5

Notice how I've wanted to step into `reportImplicitAny` but I was taken out of this frame, to the point after the call to the `reportImplicitAny`'s caller.

One additional thing I've noticed here is that 0 hits are reported on the line containing that `reportImplicitAny`
<img width="953" alt="Screenshot 2021-09-21 at 13 24 01" src="https://user-images.githubusercontent.com/9800850/134162769-40a1f617-a18e-4586-a954-1229a043f322.png">

This is clearly incorrect as I was paused at this line of code.

0 hits reported incorrectly

**Description**
Want to create Code Highlighting block with changing code language on every block. But got an error: 
`Error: Cannot resolve a Slate point from DOM point: [object Text],1`

**Recording**


https://user-images.githubusercontent.com/49220993/175454278-56800975-01bc-4d7d-89d3-31a51a8ef84b.mov



**Sandbox**
https://codesandbox.io/s/slate-reproductions-forked-rzgecw

**Steps**
To reproduce the behavior:
1. Click on custom block
2. Type something
3. See error (And also can't delete typed text)

**Expectation**
Edit text inside block without errors

**Environment**
- Slate Version: 0.80
- Operating System: Mac OS 12.1
- Browser: Safari 15.2

**Context**
Created custom block with code highlighting feature. 
Main difference with Slate Code Highlighting Example (https://github.com/ianstormtaylor/slate/blob/main/site/examples/code-highlighting.tsx) that I want to blocks with different languages in each custom block.


slate

Error: Cannot resolve a Slate point from DOM point: [object Text],1

### 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.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.20.0
      npm: 8.19.4
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.4.4-canary.0
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.3
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue or a replay of the bug

https://app.replay.io/recording/untitled--a18f4a73-07a1-49a7-94ec-6400bf8094ae

### To Reproduce

Issue is not reproducible locally or in Node.js environments, where `caches` is always present

Issue happens only inside Vercel Edge Middleware

Can be reproduced by deploying app with following `middleware.ts`:

```typescript
import type { NextRequest } from "next/server";
import { NextResponse } from "next/server";

export async function middleware(request: NextRequest) {
  console.log({
    typeofCaches: typeof caches, // "undefined"
    globalTypeofCaches: typeof global.caches, // "undefined"
  });
  return NextResponse.next();
}

export const config = {
  matcher: ["/", "/((?!_next/static|favicon.ico).*)"],
};
```

### Describe the Bug

Global `caches` property is `undefined` when trying to access it from `middleware.ts/js` inside Vercel Edge Middleware runtime.

Here are logs from Edge Middleware. `typeof caches` and `typeof global.caches` yields `undefined`

<img width="560" alt="Screenshot 2023-05-20 at 20 18 17" src="https://github.com/vercel/next.js/assets/12574743/f3f4eb1e-5f8d-4c03-87b3-5087a41d75af">

When running locally or inside remote Node.js environment, `caches` is present and middleware works fine

And here are logs from Next.js Serverless Function, where `caches` are present:

<img width="550" alt="Screenshot 2023-05-20 at 20 19 32" src="https://github.com/vercel/next.js/assets/12574743/0bbfe7e2-20e7-415f-a7e8-d5db5065da57">



### Expected Behavior

`caches` and `global.caches` inside Vercel Edge Middleware runtime is present and exposes [Web APIs CacheStorage](https://developer.mozilla.org/en-US/docs/Web/API/Cache)



### Which browser are you using? (if relevant)

Version 113.0.5672.126 (Official Build) (arm64)

### How are you deploying your application? (if relevant)

Vercel

area: app

Web APIs Cache not working in Vercel Edge Middleware – typeof `caches` is `undefined`

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
codesandbox on next@13.4.1-canary.2
```

### Which area(s) of Next.js are affected? (leave empty if unsure)

Routing (next/router, next/navigation, next/link)

### Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/hopeful-taussig-uvq5g1

### To Reproduce

Click around to different pages, which are all handled by the same /app/[path]/page.tsx route.

### Describe the Bug

Note that scroll position is preserved when navigating.

### Expected Behavior

You wouldn't expect it to be.


<sub>[NEXT-1130](https://linear.app/vercel/issue/NEXT-1130/app-router-scroll-position-not-reset-when-dynamic-segment-changes)</sub>

area: Routing

[NEXT-1130] app router: Scroll position not reset when dynamic segment changes

### What version of React, ReactDOM/React Native, Redux, and React Redux are you using?

- React: 0.0.0-experimental-e7d0053e6-20220325
- ReactDOM: 0.0.0-experimental-e7d0053e6-20220325
- Redux: 4.2.0
- React Redux: 8.0.2

Here is a Replay recording of this bug with some annotations from me:
http://app.replay.io/recording/replay-failing-reactdevtools-e2e-repro--3351989d-95d4-4035-80af-07d813a623aa

Here is a Loom (it's long) where I use Replay to investigate the problem:
https://www.loom.com/share/3d60c14466184b03acc9af7b80e9eff8

Also note that this issue is specific to an experimental React API, `Offscreen`. The React team has [published some early documentation](https://github.com/reactwg/react-18/discussions/19) about this API but it has not been released in a stable form yet.

### What is the current behavior?

A _connected_ component misses updates that are fired while it is inside of a hidden `Offscreen` component.

I believe this is because the component unsubscribes when it is _unmounting_ and does not check for missed updates when it is later remounted. (The selectors passed tot he map-state-to-props function were not executed.)

### What is the expected behavior?

The _expected_ behavior is perhaps up for debate. Should the component process Store updates (at a lower priority) while hidden or should it wait to render them only if it's later re-shown? In a sense, this question isn't worth debating _yet_ because I don't think React currently provides an API (even an experimental one) to _stay subscribed_ while in a hidden state.

That being said, I think the currently expected behavior is that when then `Offscreen` tree is later _re-shown_, React Redux `connect` should check the Store for the latest values and re-render if they have changed since the component was last rendered.

### Which browser and OS are affected by this issue?

Presumably all of them

### Did this work in previous versions of React Redux?

- [ ] Yes

Connect HOC misses store changes when "offscreen"

It seems that pressing shift key while scrolling the mouse wheel has no effect on Windows, contents of the canvas move up or down, instead of left or right. On Mac it works as expected.

I was able to reproduce this with the latest versions of Chrome and Edge on Windows 10.