fix(mxClient) Fixes NO_FO (foreignObject support is not available) test #58
Conversation
There was a problem hiding this comment.
Nice catch.
The condition is taken from the original mxgraph code: https://github.com/jgraph/mxgraph/blob/v4.2.2/javascript/src/js/mxClient.js#L194
It seems that the condition about Opera is completely wrong, at least for the latest Opera versions.
Running Opera 81.0.4196.60 on Ubuntu 20.04.3. The navigator.userAgent value is
'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36 OPR/81.0.4196.60' so the condition is always false too. And foreignObject are used for htmlLabels and Opera displays the label without any issue.
Opera has been using Chromium from years (2013-07-02) and the userAgent value has been updated when switching to Chromium. See https://help.opera.com/en/opera-version-history/
So I also suggest we remove the Opera condition as well.
|
Fyi this is fixed in release https://www.npmjs.com/package/@aire-ux/mxgraph as of 4.2.6. aire-ux#2. Bit of a messy PR as it also integrates typed-mxgraph |
There was a problem hiding this comment.
Nice work, thanks for your contribution @Seebiscuit
About my comment about the Opera browser, I have created #67 and this will be managed later.
We test a global config variable
mxClient.NO_FOin one key area of the CellRenderer:maxGraph/packages/core/src/view/cell/CellRenderer.ts
Line 542 in 74b67a6
This variable is responsible for detecting if the current client supports the
<foreign-object />svg element. The<foreign-object />element is the substrate used by HTML labels. If theNO_FOvariable is set to false, the<foreign-object />element is not rendered in the SVG output and non-string labels are not rendered.Currently, the initialization test for
mxClient.NO_FOdoes the following comparison:But the output of
document.createElementNS(...)is anSVGElementwhich will always pass the condition above. This PR simply requests the stringified representation of thisSVGElementwhich will match the RHS.