-
Notifications
You must be signed in to change notification settings - Fork 194
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
backspace at start of line gives strange results in Webkit #40
Comments
I have started looking at this issue. It seems to be at least in part related to #41 and actually happend both in Webkit (all the time) and Firefox (sometimes). Basically when inside two inserts that are inside oneanother (in a paragraph that has been emptied), it seems to get confused as which direction it should move (up or down). There is also an issue where the carety moved this way:
and if one now clicks backspace once, one would expect for the caret to end up at the end of the second line, however, it ends up at the start instead:
I think a general policy has to be figured out about whether inserts can be nested or not. Currently it can, and this may make sense some time and at other times not. Take the following example
In the above example it may make sense that the second insert is nested in the first insert. The document owner will first be asked whether he accepts the insert 1, and only if he confirms will he be presented with delete 2 and insert 2. However, imagine this case:
Where | is the caret. If user 2 has the caret there, hits retrun and writes another paragraph, the following code is produced:
This second example does not look right. User 1 has nothign to do with the paragraph, so why would an insert for user 1 be connected to it. Additionally, this nesting gives problems with this error, in both main browsers, both with and without TinyMCE. One alternative could be to not accept inserts inside inserts ever. Another possibility could be to only accept them if user 2 writes inside a paragraph by user 1, but not when creating an entirely new paragraph. The first solutiuon would probably give cleaner results altogether. @delambo what is your preference? |
fixed for Webkit in johanneswilm@b62ecc6 The behavior in Firefox is more sane than it was before, but not entirely fixed still. |
@johanneswilm - with my changes to master today (and my update to the ice demo), I think the problem you described in comment 1 is fixed. Can you verify please? Let me know what you have cooking. I'm trying to get ice fixed up, especially in webkit. I was busy on a lot of projects last year, but will have more time to devote to ice this year. |
@delambo Hey, I've merged your changes, this particular issue has not been fixed in the ICE demo you have running, but is working in my current master branch. There is still something wrong with selection deletion of the content a user has created himself, both in my version and in yours, though somewhat differently: In your version, if you select a longer part of text, which includes some subelements that the current user has authored, and click 'backspace' these subelements are deleted. However, if you select only parts or an entire paragraph the current user has written, and hit 'backspace', then it is only crossed out. |
the above error exists both in Webkit and in Firefox. |
In my version there is something more serious happening when deleting a paragraph written b7y the current user + some additional contents. I will look at that tomorrow. |
@johanneswilm - I'm still not able to replicate in the online demo. Can you break down step (3). For instance, where is the cursor when you start creating new paragraphs (hit enter/return) and what do you enter into the paragraphs. Thanks. |
ah, you're right. the cursor does not move strangely any more. But a new bug has come out of this -- the paragraph before it ends with three times |
I would prefer to handle/prevent tags from getting split into new paragraphs by attacking the problem upstream in the _handleEnter: function() {
var range = this.getCurrentRange();
if (!range.collapsed) this.deleteContents();
// If the cursor is at the end of an insert, then move the cursor
// outside so that the browser doesn't split the insert into the
// new paragraph that is created.
var insert = this.getIceNode(range.startContainer, 'insertType');
while (insert && range.startContainer.data.length === range.startOffset) {
range.setStartAfter(insert);
insert = this.getIceNode(range.startContainer, 'insertType');
this.selection.addRange(range);
}
return true;
} I'm going to try to massage it for Chrome - may even submit a bug request because Chrome doesn't have this behavior for What do you think? |
I completely agree. This is a much cleaner way of doing it. If you do that,
|
This is proving to be really hard in Webkit. Still working on getting this right. |
Since the first problem is fixed, I'm going to open a new issue with the second problem. |
Try the following (using a Webkit browser):
Expected results: The cursor should delete the now empty paragraph and move to the paragraph above it where it should be placed at the very last position.
What happens: Instead the "B" of the paragraph below it is deleted (the one that goes: "But in reality...").
In Firefox this works fine.
The text was updated successfully, but these errors were encountered: