(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #2) > Although the caret is positioned at odd coordinates, this should be fixed in `nsFrameSelection` or layout code because this should occur is the caret browsing mode too and in that case, we cannot insert `<br>` element (anyway, I don't like to do it in editable element too). > Thanks, Masayuki. > On Chrome, I see caret at right of the table, and typing text is inserted after the table (i.e., appeared in the next new line) without paragraph. Perhaps, this is the only way to guarantee that we allow user to move caret outside the table and showing caret since the parent block of the table may have border or background and caret shouldn't be put outside of it. :jfkthame: what do you think about the proposal? Moreover, if you support following Chrome's behavior, can you please point to the code areas which need to adaptation?
Bug 1674359 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #2) > Although the caret is positioned at odd coordinates, this should be fixed in `nsFrameSelection` or layout code because this should occur is the caret browsing mode too and in that case, we cannot insert `<br>` element (anyway, I don't like to do it in editable element too). > Thanks, Masayuki. > On Chrome, I see caret at right of the table, and typing text is inserted after the table (i.e., appeared in the next new line) without paragraph. Perhaps, this is the only way to guarantee that we allow user to move caret outside the table and showing caret since the parent block of the table may have border or background and caret shouldn't be put outside of it. :jfkthame: what do you think about the proposal? Moreover, if you support following Chrome's behavior, can you please point to the code areas which need adaptation?