forked from facebook/react-native
-
Notifications
You must be signed in to change notification settings - Fork 146
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
Labels
Comments
Closed
@mgcrea can you help me reproduce to issue? |
Ah, I may have created a duplicate of this here: #422 |
@TheSavior Yes! |
I closed the duplicate. I haven't investigated this issue beyond the report |
4 tasks
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.
4 tasks
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
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.
Has anyone encountered this?
The text was updated successfully, but these errors were encountered: