-
-
Notifications
You must be signed in to change notification settings - Fork 361
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
WidgetBuffer creates wrap opportunity in chrome #989
Comments
I have a reproduction link without hedgedoc or remote cursors. |
I am aware of this, but haven't been able to find a good workaround. The zero-width space thing we had before caused a lot of trouble because, after the browser does its thing on some native edit action, it was had to distinguish the spaces that were inserted for this hack from spaces that should actually be in the document. Also I'm pretty sure (and a rough test confirms) that zero-width spaces are also used as wrap opportunities by browsers—are you sure the patch you linked made a difference here? What we need, basically, is a bit of DOM that is A) treated as a regular editable inline element by the browser so that it avoids the slew of browser bugs around having a cursor next to an uneditable element, B) is invisible, C) is easy to distinguish from content text, and D) does not create a wrap point. If you find some obscure element or style that lets us do this, do let me know! |
(Possibly unicode character 0x2060, "word joiner" can be useful here. But again, we will need to support such characters appearing in the document as well, and somehow tell leftovers from our widget buffers apart from inserted content.) |
As far as you've described you just need a dummy element whose only purpose is to exist and don't influence anything, right? |
Those won't be treated as significant inline text editing elements by browsers (or a |
then what about an empty span? edit: hmpf.. this is also likely to be ignored because you need actual content, right? |
yes.. that's really tricky o.ö |
Oh... FYI, I have just found that chrome devs also think that elements with "position: absolute" style should not introduce soft wrap opportunities (though they have left the crbug open for years). So I think this could be, theoretically, solved by "position: absolute", if only the crbug were fixed... 😢 |
Unfortunately even without the WidgetBuffer I think you'll probably find that any decoration which splits a word will cause a wrap opportunity. The only way I know of to resolve this is to draw the collaborator cursors in a separate layer, as CodeMirror does for the main cursor. |
Actually I had this problem while working on remote cursors and solved that using nbsp inside of the widget. |
I just had another idea (thanks bathtub 🛀). How about wrapping the whole text before and after the widget buffers into editable spans and let only them do the text wrapping? In the following example you would only allow wrapping on elements with class text.
|
This is a good point. This patch exports the logic used by Could you take a look and let me know if this feature would work for you? |
This looks interesting. I'll take a look later. |
Looks like it is working! Thank you! Here are a couple of ideas I got while writing it:
|
FEATURE: The static `RectangleMarker.forRange` method exposes the logic used by the editor to draw rectangles covering a selection range. Issue codemirror/dev#989
FEATURE: Layers can now provide a `destroy` function to be called when the layer is removed. Issue codemirror/dev#989
@tamo Could you take a look and see if attached patches would cover your requirements? |
I'm going to close this issue as wontfix, since adding content inline necessarily influences break points, and it seems really hard to control that in a way that doesn't cause more problems than it solves. |
Just to let you know: The layer method works fine so far. We use it right now to create a new cursor plugin that fits our use case. Thank you for your help ❤️ |
I've tagged @codemirror/view 6.7.0 |
Thank you all, I'm happy to know that hedgedoc works well now.
Thanks for the patch. Probably it's good enough. |
Describe the issue
Hello,
We're using CodeMirror 6 in the development of HedgeDoc 2. So far I'm very impressed by what you've done so far. Great piece of work ❤️
Anyway. There is one problem. As a collaborative editor we want to show the remote cursors. For this task we use a widget (hedgedoc/hedgedoc#2957 to be precise), which causes trouble in combination with
EditorView.lineWrapping
. To be precise: Chrome takes thewidgetBuffer
as wrap opportunity because it is animg
tag.hedgedoc-2022-11-04_22.03.14.mp4
It seems like this commit is causing the issue. While I understand that this solution is maybe solving some other problems, it's causing this one which makes it unusable for us.☹️
Quick solution idea
What about letting the widget itself choose if the buffer should be an img or a span?
Additional Context
hedgedoc/hedgedoc#2957
hedgedoc/react-client#2451
Browser and platform
Chrome
Reproduction link
No response
The text was updated successfully, but these errors were encountered: