insertHTML command still inserts spans when there's existing input on chrome about scribe HOT 13 OPEN

Hey Matthew. I can’t see how you’re calling Scribe.insertHTML in the video. Is it from the console?

from scribe.

haha, yah sorry about that. in this case, pressing "B" triggers it. But I think it should be reproducible with any trigger.

from scribe.

Sorry, I don’t think I understand. Pressing “B” to make something bold?

Also, what browser/version?

from scribe.

so it's just the trigger I chose to call Scribe.insertHTML. I could have went with a button but it was easier for me to do this at the time. it's unrelated to bold.

latest chrome (v. 33)

from scribe.

I can’t seem to reproduce this. Also, from your video it seems to be producing a B element, not a SPAN? It looks like the issue is that it’s erroneously adding inline styles for font-size/line-height?

Out of curiosity, do you have a line height somewhere on your page? We have seen similar issues in Chrome, which only occur when you do have an inherited line height.

Could you perhaps isolate the case even further, this time taking your custom trigger (Command+B) out of the equation and seeing what happens? If you could provide some steps to reproduce it from the console, that would be great. I tried focusing the editor (<p>foo|</p>; where | is my caret) and then calling scribe.insertHTML('<b>bar</b>'); to no avail.

from scribe.

Any updates? Let me know or I can close this.

from scribe.

Just wanted to note that the root cause of this was CSS in our code base.

It seems like if you have non-standard font-size on the editor div then that will cause Chrome to inline those styles on certain elements under some circumstances.

It would definitely be good to figure out when this comes in and strip those styles if possible.

from scribe.

@OliverJAsh We could add that to your list of browser inconsistencies ;)

from scribe.

ahh good to know!

from scribe.

I’m still unable to reproduce this issue. Do you have any steps to reproduce this? @TooTallNate @matthewmueller

from scribe.

This sounds very much like the issue we had to patch (in https://github.com/guardian/scribe/blob/master/src/plugins/core/patches/events.js). Could it be a regression, or an extended case? Would be good to be able to reproduce to see which one it may be.

Thanks

from scribe.

Not a Scribe user but I was hitting a similar issue with document.execCommand('insertHTML', ...) in general on Chrome and came across this bug report.

The issue with inline styles being inserted seems to occur when inserting html into a child div that is inside of a contenteditable div, when the child div has different styling than parent contenteditable div. For whatever reason, Chrome seems to want to force the inserted HTML to have the same styling as the parent contenteditable div, and does this by adding inline styles to tags and, if there is no wrapping element to style, wrapping inserted HTML in inline styling spans.

from scribe.

FYI, I did a bit of research for a similar issue in yabwe/medium-editor#543

A small reproducing example: https://jsfiddle.net/y4x3vu61/
A larger one with a workaround: https://jsfiddle.net/hsn9a6jo/4/

from scribe.