You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create an email with a few lines separated by empty lines.
Inspect the DOM. It should look like this:
<div>my line 1</div><div><br></div><div>my line 2</div><div><br></div>
Select a line but putting the cursor at the beginning of a non-empty line, holding the shift key, and pressing the down key.
Markdown Toggle.
Look at the markdown-here-wrapper that was created -- its data-md-original attribute has an empty <div> at the end of it that wasn't present in the original DOM.
If you then revert and repeat, there will be two empty <div>s, and so on.
The problem is that the range of the original selection has an endContainer of the <div><br></div> (outer) element, and a endOffset of 0, which means that it ends before the <br>.
Then in getSelectedHtml(), when we call selectedRange.cloneContents(), the partial <div> turns into an empty <div> element, and the original stays on the page (or it might be a new one enclosing the original <br> -- same result).
Impact
It's hard to know how severe this bug is. If it's just creating empty <div>s, then it's pretty minor. But, in theory, it could introduce more significant elements.
Even with <div>s, it can still mess up the Markdown. For example, if you have two plaintext lines with no empty line between then, they will be treated as the same line when rendering. But if you convert and revert the first line, then there'll be an empty <div> between then. If you then try to convert both lines, they'll be rendered as two separate lines. It's not difficult to recover from the situation, but it could be confusing and annoying.
Solutions
A simple solution might be to remove empty <div>s at the end of the output of getSelectedHtml(). But this doesn't account for the possibility that this bug can affect other tag types.
Maybe there will always be an empty element at the end of the outerHTML when the endOffset is 0? If so, that might be a good general solution.
A more robust solution might be to shrink or grow the end of the range so there's no partial element. But I'm not sure that this will actually work. And ranges are still a bit mysterious to me. And I fear the potential for bad side-effects.
The text was updated successfully, but these errors were encountered:
Reproduction:
Create an email with a few lines separated by empty lines.
Inspect the DOM. It should look like this:
Select a line but putting the cursor at the beginning of a non-empty line, holding the shift key, and pressing the down key.
Markdown Toggle.
Look at the
markdown-here-wrapper
that was created -- itsdata-md-original
attribute has an empty<div>
at the end of it that wasn't present in the original DOM.If you then revert and repeat, there will be two empty
<div>
s, and so on.The problem is that the range of the original selection has an
endContainer
of the<div><br></div>
(outer) element, and aendOffset
of0
, which means that it ends before the<br>
.Then in
getSelectedHtml()
, when we callselectedRange.cloneContents()
, the partial<div>
turns into an empty<div>
element, and the original stays on the page (or it might be a new one enclosing the original<br>
-- same result).Impact
It's hard to know how severe this bug is. If it's just creating empty
<div>
s, then it's pretty minor. But, in theory, it could introduce more significant elements.Even with
<div>
s, it can still mess up the Markdown. For example, if you have two plaintext lines with no empty line between then, they will be treated as the same line when rendering. But if you convert and revert the first line, then there'll be an empty<div>
between then. If you then try to convert both lines, they'll be rendered as two separate lines. It's not difficult to recover from the situation, but it could be confusing and annoying.Solutions
A simple solution might be to remove empty
<div>
s at the end of the output ofgetSelectedHtml()
. But this doesn't account for the possibility that this bug can affect other tag types.Maybe there will always be an empty element at the end of the
outerHTML
when theendOffset
is0
? If so, that might be a good general solution.A more robust solution might be to shrink or grow the end of the range so there's no partial element. But I'm not sure that this will actually work. And ranges are still a bit mysterious to me. And I fear the potential for bad side-effects.
The text was updated successfully, but these errors were encountered: