Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layout bug when resizing main window #322

Closed
mgcrea opened this issue Apr 26, 2020 · 4 comments · Fixed by #439
Closed

Layout bug when resizing main window #322

mgcrea opened this issue Apr 26, 2020 · 4 comments · Fixed by #439

Comments

@mgcrea
Copy link

mgcrea commented Apr 26, 2020

I've been playing a bit with react-native-macos and I encountered a strange bug when resizing the main window, not sure where exactly the issue is. Here is the bug:

Looks like it is somehow triggered by long clipping text (tried available clipping options with no luck) and especially when you don't release the mousedown.

Screen Recording 2020-04-26 at 16 19 57

Has anyone encountered this?

▶ cat package.json| jq .dependencies | grep react
  "react": "16.13.1",
  "react-native": "0.62.2",
  "react-native-macos": "^0.60.0-microsoft.76",
@tom-un tom-un mentioned this issue Apr 27, 2020
@mayank-budhiraja
Copy link

@mgcrea can you help me reproduce to issue?

@elicwhite
Copy link
Collaborator

Ah, I may have created a duplicate of this here: #422

@mayank-budhiraja
Copy link

mayank-budhiraja commented Jun 2, 2020

@TheSavior Yes!
I tested with the sample project. It's a duplicate. Do you know how to resolve it?

@elicwhite
Copy link
Collaborator

I closed the duplicate.

I haven't investigated this issue beyond the report

christophpurrer pushed a commit to christophpurrer/react-native-macos that referenced this issue Aug 2, 2022
…crosoft#439)"

This change reverts microsoft#459 - but still tries to address the original issues:
- microsoft#422
- microsoft#322

This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread.
We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win.
The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.
christophpurrer pushed a commit to christophpurrer/react-native-macos that referenced this issue Aug 2, 2022
…crosoft#439)"

This change reverts microsoft#459 - but still tries to address the original issues:
- microsoft#422
- microsoft#322

This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread.
We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win.
The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.
christophpurrer added a commit to christophpurrer/react-native-macos that referenced this issue Aug 4, 2022
…crosoft#439)" (microsoft#1318)

This change reverts microsoft#459 - but still tries to address the original issues:
- microsoft#422
- microsoft#322

This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread.
We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win.
The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.

Co-authored-by: Scott Kyle <skyle@fb.com>
shwanton pushed a commit to shwanton/react-native-macos that referenced this issue Feb 13, 2023
…crosoft#439)" (microsoft#1318)

This change reverts microsoft#459 - but still tries to address the original issues:
- microsoft#422
- microsoft#322

This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread.
We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win.
The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.

Co-authored-by: Scott Kyle <skyle@fb.com>
shwanton pushed a commit to shwanton/react-native-macos that referenced this issue Mar 10, 2023
…crosoft#439)" (microsoft#1318)

This change reverts microsoft#459 - but still tries to address the original issues:
- microsoft#422
- microsoft#322

This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread.
We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win.
The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.

Co-authored-by: Scott Kyle <skyle@fb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants