<foreignObject> doesn't seem to have the same result in Safari/Firefox as it does in Chrome browsers

[francisngo]

For foreignObject in Safari browsers, nodes are given additional width and height and the tree links are not positioned in the correct place as they are in Chrome browsers. Similar with Firefox, styling from foreignObjectWrappers are not applied.

Are you reporting a bug, or opening a feature request?

Bug

What is the actual behavior/output?

foreignObject's width/height and positions in Safari are not equal to Chrome.

What is the behavior/output you expect?

foreignObject's and tree link's positions are off and not accurate.

Can you consistently reproduce the issue/create a reproduction case (e.g. on https://codesandbox.io)?

View link in chrome then in safari and firefox to see the difference: https://codesandbox.io/s/0362k66m0n

What version of react-d3-tree are you using?

latest version

[francisngo]

For Safari Browsers, I found out that in ForeignObjectElement.jsx, the width and height set in <foreignObject width={nodeSize.x - BASE_MARGIN} height={nodeSize.y - BASE_MARGIN} {...foreignObjectWrapper} /> overwrites the prop's foreignObjectWrapper.style.width and ...height. Is there a way to override the width and height set in <foreignObject> for safari browsers to use the one from props?

[Nilanth]

For Safari Browsers, I found out that in ForeignObjectElement.jsx, the width and height set in <foreignObject width={nodeSize.x - BASE_MARGIN} height={nodeSize.y - BASE_MARGIN} {...foreignObjectWrapper} /> overwrites the prop's foreignObjectWrapper.style.width and ...height. Is there a way to override the width and height set in <foreignObject> for safari browsers to use the one from props?

@francisngo Have you fixed this issue

[bkrem]

For Safari Browsers, I found out that in ForeignObjectElement.jsx, the width and height set in <foreignObject width={nodeSize.x - BASE_MARGIN} height={nodeSize.y - BASE_MARGIN} {...foreignObjectWrapper} /> overwrites the prop's foreignObjectWrapper.style.width and ...height.

Ah man, sorry about this (and my very delayed response); I had no idea that the way that expression evaluates would be subject to browser compat :/

I'm currently cleaning up the repo & committing myself to shipping a v2 in the coming weeks, which I will make this a part of, since I think the wisest move here is to remove that implicit base margin (breaking change -> v2) which is confusing anyways.

Thank you for reporting this issue, I'll update here when it's fixed!

[bkrem]

Please note that #284 may be related to this. I'm still going to remove the base margins for v2, but if you're seeing odd behaviour in Safari it may also be related to this upstream issue in the browser itself.

Will report back here once I've done my own investigation into cross-browser issues in v1 and how they can (hopefully) be mitigated for v2.