Workflow/Recipe Page Does not Correctly Render Recipes on Pixel Dense Devices
seanadipose opened this issue · 2 comments
Greenlight Workflow Doesn't Render Correctly on Chromium-Based Browsers
Problem
Arrows and boxes used for the recipe page on Chromium Browser on Pixel Dense devices do not display correctly.
The current implementation of the workflow piece in Greenlight is dependent upon SVG rendering. A foreignObject selector in HTML is added by the dagreD3 library.
Cause
A chromium bug is causing these devices to ignore pixel density and set the zoom scaling to 1 by fixing height of the foreignObject selector to a specific size in the browser.
This means the size is set by the dynamically generated SVG at runtime and makes it so that the resulting HTML displayed to the user has the incorrect height for the foreignObject selectors that act as containers for the HTML that we inject into the SVG will have the incorrect height on them, causing the spacing of arrows and other things on the page to be rendered the wrong height.
There has been an open issue with dagreD3 since August 29th of 2018 for this issue.
This is well illustrated in the attached issue which doesn't have any solutions.
Resources
Chromium defect: Issue 738022 - chromium - An open-source project to help move the web forward. - Monorail
Blocker for this: Issue 976224 - chromium - An open-source project to help move the web forward. - Monorail
foreignObject: - SVG: Scalable Vector Graphics | MDN
Additional note from Sean and my response:
Good news and bad news on the recipe page rendering issue. I wrote a detailed description of the problem which includes references to all the open issues with the library and with chromium here: #247
The good news:
The good news is that I’ve identified the underlying issue with the page, library and browser, and that it has open tickets with both the library and the browser(chromium). This means that if you use any browser that’s not chromium it should work (oh, as long as it’s not IE which doesn’t support the foreignObject selector).
The bad news:
The underlying issue is with the browser, which means it would be relatively time-consuming (and probably not a good idea) for me to hack a solution together as a result.
What I’d like to do:
I’d like to take a step back from this one for the moment and re-examine the problem when/if we take on a Greenlight upgrade. The way we’re rendering the components in the DOM isn’t the “angular” way, and depending on the scale of an upgrade it’s possible the issue gets resolved by then (maybe..) or that we can come up with a different way to draw the diagrams that doesn’t require foreignObject and then therefore would not have this issue.
My guess is that the new Greenlight won't drive a change to this screen, but we should be open to a new approach that eliminates this problem anyway. The probability of this issue being seen is pretty high given screens and the use of Chrome, so I think it likely we should address it. A demo with a glaring hole like that is not good.
How about one last thing before we move on @seanadipose -- look for what other library/approach would you use for the general problem and gauge the effort. That effort is the same whether we fix it now or as part of a re-vamping of greenlight. Add any notes about what you find then please move this to the backlog and mark it unassigned.
Thanks!
Requirements
support n-rows
support n-connections
support custom splitting & elements
support n-items / row
support CSS styling
mxGraph 4.0.4
mxGraph is a library that forms the underpinnings for draw.io. We can draw the graphs in such a way that we avoid rendering HTML templates that are connected to the foreignObject selectors, which will resolve the main issue. This will also make the solution potentially portable and more modular if we can remove the dependency that it currently has on Angular as part of this.