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

Fix positioning error #57

Merged
merged 5 commits into from
May 28, 2024
Merged

Fix positioning error #57

merged 5 commits into from
May 28, 2024

Conversation

iansan5653
Copy link
Member

@iansan5653 iansan5653 commented May 22, 2024

Fixes a bug where the menu position would be calculated incorrectly because dom-input-range gives absolute exact positions and we were still offsetting by the position/scroll of the input.

This approach calculates where the menu is and where it isn't, then adjusts the top and left values based on the difference between the two. This relative approach is a little more complicated than just setting top and left directly but avoids have to make any special consideration for fixed/relative/absolute/top-layer positioning. It's also still very fast as all the computations involved are fairly cheap.

Also adds a floating menu to the demo so we can see this in action.

@iansan5653 iansan5653 requested a review from a team as a code owner May 22, 2024 20:45
@keithamus
Copy link
Member

Does this account for scroll containers? It's dropping the scrollx code which tells me it might not work properly if scrolled.

@iansan5653
Copy link
Member Author

iansan5653 commented May 23, 2024

Sorry, didn't intend to mark this ready for review yet. I need to figure out a way to test this locally in dotcom.

Does this account for scroll containers? It's dropping the scrollx code which tells me it might not work properly if # scrolled.

Theoretically scrolling should work as expected: DomInputRange is already accounting for scroll. When getBoundingClientRect is called on the range, the result is exactly where we want the menu to be relative to the document, so it's just a matter of making sure that's where the menu ends up.

@iansan5653 iansan5653 marked this pull request as draft May 23, 2024 14:19
@iansan5653 iansan5653 force-pushed the fix-positioning-error branch from e7948d0 to 912db2b Compare May 23, 2024 19:28
@iansan5653 iansan5653 marked this pull request as ready for review May 23, 2024 19:30
@iansan5653
Copy link
Member Author

Okay, now we're ready for review. Tested in dotcom by manually copying in the changes and it's working great. I updated the approach to only have to set top and left once (fewer repaints!) and extracted a positionMenu function.

Copy link
Member

@keithamus keithamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 LGTM

@silverwind
Copy link
Contributor

silverwind commented May 27, 2024

Also noticed that the positioning in @github/text-expander-element@2.7.0 is rather broken compared to 2.6.1, e.g. too far in both the x and y axis. I hope this fixes that.

image

@iansan5653
Copy link
Member Author

Also noticed that the positioning in @github/text-expander-element@2.7.0 is rather broken compared to 2.6.1, e.g. too far in both the x and y axis. I hope this fixes that.

Yes, this should fix that! Will merge today and release as 2.7.1; please file a bug if you continue to see problems after that release

@iansan5653 iansan5653 merged commit fc7f9b6 into main May 28, 2024
1 check passed
@silverwind
Copy link
Contributor

Thanks, I can confirm 2.7.1 fixed that issue for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants