-
Notifications
You must be signed in to change notification settings - Fork 446
Scroll cursor back into view when it goes out of bounds #34
Conversation
Hey! Excellent job so far! Just a few glitches I noticed when giving it a run down --
I've illustrated both issues in this gif: Definitely better than it was before though! Thanks 👍 |
Should now be fixed. I modified the CSS file slightly and it seems to have done the trick. |
When recreating the bug, it seems that the cursor position ISN'T actually changing, it's just the offset of the view. If you scroll the view all the way down, you'll see the cursor is exactly where it should be. I just need to fix the change in scroll offset when doing the above. |
Aright, I think it's fixed...let me know if you find more bugs. Let the testing begin! |
var sel=window.getSelection(); | ||
if (sel.rangeCount) { | ||
var range = sel.getRangeAt(0); | ||
var needsWorkAround = (range.startContainer.nodeName.toLowerCase() == 'div' && range.startOffset == 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment or something about what this workaround is for and what it's doing?
Like, why is it needed? What is it returning instead of the normal case?
Oh I found another bug! Isn't this fun? lol 😸 If the cursor is out of view (below the cutoff) and you input something, it scrolls up when you input something -- that is good. However, if the cursor is out of bounds (above the cutoff) and you input something, it doesn't scroll into view. Also making newlines in that case is kind of weird too. |
good catch! right now the code just checks the caret position against the lower bounds, so my guess is I just need to check the caret position against the upper bounds as well and it'll be fixed. |
Really looking forward to seeing this get merged! |
var scrollView = editor.webView.scrollView | ||
|
||
var contentHeight: CGFloat? | ||
let htmlHeight = editor.runJS("document.getElementById('editor').clientHeight;") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally a good practice to wrap the JS implementation details with a public accessor method on the RE namespace IMHO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Even in this case, since document.getElementById('editor').clientHeight
is literally the same as RE.editor
, I might not be too opposed to just RE.editor.clientHeight
(I'm not sure how I'm doing it in other places.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did it that way to match: https://github.com/jesiegel1/RichEditorView/blob/master/RichEditorView/Classes/RichEditorView.swift#L176
@cjwirth I'd say it's best to keep things working consistently. Updating the example project isn't going to break anyone's code and it probably is good to mention such things in release notes as breaking changes. |
@mfrawley That's a good point. We should probably go with that then! @jesiegel1 Not trying to rush your or anything, but any progress with the issue of when the cursor is above the visible area? |
how could i use this branch. |
@cjwirth only just saw this notification. I'll try to work on it today if I can, or by the end of the week at least. |
@cjwirth Review and lemme know if you find any issues - this was a tricky one! |
Awesome! Yeah looking at the code it looks like something that might have taken a while to figure out. I'l take a look later today, probably tonight or something! But yeah, if it's all working, that's pretty exciting. |
@KKKiller Are you using CocoaPods? If so, you need to change the podfile to reference the in-development branch. Bascially, you will change pod 'RichEditorView' to pod 'RichEditorView', :git => 'git@github.com:jesiegel1/RichEditorView.git' and then re-run You can read more about podfile configuration here |
Cool! It seems to be working now! Let me take a look at the code and see how it looks :) |
RE.wrapTextNodes = function() { | ||
var contents = RE.editor.childNodes; | ||
for (var i = 0; i < contents.length; i++) { | ||
if (contents[i].nodeType === 3) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice to have an object or enum or something so we don't have magic numbers flying around. Maybe nodeType == 3
is obvious to JS devs, but i have no idea.
Maybe Node.TEXT_NODE
instead? https://developer.mozilla.org/en/docs/Web/API/Node/nodeType
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea that works, totally reasonable
Do you think you can fix some of the suggestions I had? Do you want me to just go and clean it up myself? It seems to be working pretty well, so just a little bit of cleanup and I'll merge it. |
@cjwirth yessir. hopefully should be able to do it later today/tomorrow. |
I have used this branch in my project and it is absolutely much better that the master. but today i got a bug,and i have no idea about how to fix it. when i set a HTMlL string to richEditor, it shown perfect .but when i click at any position of the text , and then i edit the text, it will scroll to the bottom . and after that ,it will work normal. this bug is not fatal ,but it feel bad.can you help me or give me some advice! thanks much! |
Have you used this branch with the most recent commits? |
yes i have update the latest commit. |
when i edit a HTMLstring, the latest cimmits add a mothed named as "wrapTextNodes", it will creat lots of div in my html, what is the function of this method? |
@KKKiller Without text nodes being wrapped in divs, it causes issues for calculating where the caret is. Why is creating lots of divs an issue? Generally you want your html content enclosed in some type of container. What is happening visually as a result of the divs being added? |
Hey, I've been away from Github for a while -- how is this going? Is the extra added div a problem? I understand that it's needed to calculate cursor position, but is it causing problems elsewhere? |
the divs will add lots of blank rows visually. i have remove the method "wrapTextNodes" in my project, it seems work normal. will there be any other bug if i remove it? |
did you actually try to see if it will add lots of blank rows? generally in html/css, if an explicit width/height isn't set for the div, the div takes up no space. |
beyond div and /div ,there is much of blank, i think it is the blank takes up the space. |
@KKKiller Maybe I'm not understanding what you're saying, but I'm not able to reproduce it in the sample app. Do you have some example code, or a screenshot or something? |
If not, I'll just merge this and we can open a new issue or something? |
OK,look forward to your merge. |
@jesiegel1 I'm not sure if you're interested or not, but I refactored it a little bit to make it simpler and more type safe. Thought you might like to take a look 😃 |
@cjwirth always interested. will definitely take a look. |
Fix #3