-
Notifications
You must be signed in to change notification settings - Fork 304
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
Tribute menu wrong position when body is scrolled on contenteditable elements #10
Comments
@dmail I can see where this would be problematic. What we need to do is create a scenario that reproduces this. Can you add an example of the issue to the |
After testing it appears that taking into account the scroll of ancestor elements is required when tributeMenu & inputElement have different scrollable ancestor. This is not the case in In conclusion
|
@dmail Thank you! You brought up a good point, it seems like |
Yeah the approch with buttons and javascript to force the scroll have strong chances to break as the Btw you are welcome I like what you did and your enclination for vanilla js so thank you too ;) |
@dmail From what I can tell, it looks like the current code positions correctly in your pull request, but when I scroll then I lose my position until I start typing again, at which point it repositions. Maybe we need to bind to the |
Do we agree that there is two issue ? Issue 1step to reproduce
Bug descriptionMenu is badly positionned Suggested fixCan be fixed as suggested in the first comment Issue 2step to reproduce
Bug descriptionmenu does not stick to the input and becomes badly positionned, menu is correctly repositionned as soon as you type in the field. Suggested fixCan be fixed as you suggest, by listening for the |
When this issue will be fixed? Can i help to solve this issue? |
I don't have much time atm but I can tell you without testing that adding the code below (this.menuContainer || window).addEventListener('scroll', function() {
if (this.tribute.isActive) {
this.tribute.showMenuFor(this.tribute.current.element)
}
}.bind(this), false) after line#256 should fix the scroll issue. @mrsweaters do you think you can add these two fix soon ? |
@dmail @joaolavoier Sorry guys, been crazy busy the past few days. I should have some time to test this out today. |
@dmail @joaolavoier Please test this pull request: #18 |
I had meet the similar problem, in the source code it use |
When the window is scrolled it's correctly taken into account by getTextAreaOrInputUnderlinePosition. However its contenteditable sibling getContentEditableCaretPosition does not consider window scroll
A quick fix I used was to add this block of at the bottom of getContentEditableCaretPosition
A better fix would take into account the scroll of every parent having a scroll, not only the window. (For instance if there is an overflow: auto on an ancestor element)
The text was updated successfully, but these errors were encountered: