Can you share a JSFiddle (or similar) test case that reproduces the problem with the least amount of code necessary?

Thank you!

(Also, make sure you use the latest Chrome version - Chrome 47 is very old and will never get a fix)

Reporter@ could you please provide the sample URL/JSFiddle test case which would help us to triage the issue further.

Thanks..

sorry,
here's a link to the jsfiddle:

https://jsfiddle.net/mpwaw/xcx2e56L/

(chrome fully updated now!)

thanks

I cannot reproduce using BrowserStack Chrome 56 on macOS Sierra. See the attached screenshot.

Deleted: svg-foreign-content-input-no-leak.png 597 KB

	svg-foreign-content-input-no-leak.png 597 KB View Download

@matt347 - you can try exposing the user agent shadow DOM in the Developer Tools settings and see what happens there in terms of the internal elements that the <input> employs...

I believe what happens here is that when the input overflows, it gets a layer (probably for scrolling or similar), and then things break. Duping.

I am hitting the same issue. I really needed the foreignObject feature to include inputs in a diagram to allow users to edit values in place, but this overflow issue is a blocker. I could not yet find a work around for it. It works well on Edge, Firefox and Safari.

this bug also exists on windows.

There's a minimal code to reproduce this bug. It only occurs in Chrome. My Chrome version is 65. I use LinuxMint, but my colleages on Mac have this problem too.

There's only one <svg/> + <foreignObject/> + <input/> in the html file. If you'll open it in Chrome you'll see this input with its value as "1111". If you will write any another symbol to this input, then its font-size will be changed to very small. If you will push backspace (and return the value to "1111") the font-size will be recovered to its initial value.

So, if the text in the input is fit to input boundaries - okay, if the text is bigger - bug happens.

I tried to make minimal code to reproduce and have got this html. May be it's a bit strange, but I can't change any number or attribute in it without destroying the bug. 

Deleted: 1.html 362 bytes

1.html 362 bytes View Download

This issue is closed. Star/track  issue 771852  instead. No need for more reproduction cases, I believe, because it is a known issue.

I'm experimenting with it. I've found out some interesting facts:

1. `position: relative` and `transform: translate(0, 0)` on `<input/>` enforce the input gets its html-size igroring SVG coordinates model. In this file it means the input shrinks to half of its initial size.
2. After "1." the font-size bug doesn't work. No matter how long the input's value - font-size is constant.
3. When the value of the input isn't fit to its boundaries not only the font-size detracts, the real inner boundaries detracts too. But its border has a correct size and a position.

phistuck@gmail.com, ok, sorry :)