IE11 compatibility via Babel?

[lemmy]

edotor is great and we successfully prototyped its integration into the TLA+ Toolbox. The integration works fine on Linux and macOS and frees our users from (manually) installing GraphViz/dot. However, it fails miserably on Windows: Eclipse - for who knows why - cannot be convinced to use a modern browser such as chrome-based Edge or Firefox. It insists on IE11, which lacks support for almost everything, i.e. ES2015. I tried to manually backport edotor to ES5. After a while I discovered Babel, but I really don't know what I'm doing. Is there a chance that support for IE11 could be added?

By the way, launching Edge or Firefox on Windows from Eclipse as a standalone process fails because the URL is too long with the (encoded) graph appended.

[nikeee]

Do you need the editing capability or just the rendered graph?

edotor uses viz.js to render the graph. Maybe it it would work for you to just take this library and rewrite some of the example pages to fit your needs.

If this does not work for you, we could take a closer look into IE11 support together.

btw: I think eclipse uses IE11 because that's what they are only able to use with the native WebView control on Windows. Recently, MS announced WebView2, which uses the engine of Chromium-based Edge. However, this could take its time to ship with eclipse.

[lemmy]

Editing is nice to have but indeed not the primary feature we are interested in. What's great about edotor's integration of viz.js compared to other web-based GraphViz viewers, is that zooming, panning, ... just work. Btw. does edotor gracefully handle input that is too large to either render (e.g. with "dot") or to draw?

May I assume that https://github.com/nikeee/edotor.net/issues/13 is difficult to implement because of browser security features? If #13 would be available s.t. the path to the .gv/.dot input gets passed as a URL parameter, the TLA+ Toolbox could open the modern Edge on Windows explicitly.

[nikeee]

One way to solve the issue with passing the graph data to the site may be to invoke JS. When I worked with the WebView control (in .NET, though), there was the ability to invoke JavaScript inside the web control. Maybe it is possible via the eclipse API to run a specified JS string inside the browser control (it looks promising). It would then be possible to declare a global function on the site like renderString that would just be called with that graph source. There should be no limit on the string size.

If that works I'd try to come up with a sub-page that has the ability to render a graph and display it in a zoom/pannable manner and doesn't offer the editing capability. When working with exremely large graphs, parsing the graph source (which is something what edotor does) might end in a performance bottleneck. These large graphs are also unlikely to be edited manually, if I get your use-case right. So it would probably be better to omit the editing capability.

May I assume that #13 is difficult to implement because of browser security features?

Essentially, yes. The browser does not have access to the local file system. #13 would just be a File Dialog (like the one you get when you upload something to a webpage) and the file would be processed locally. Passing a file path would not be possible.

Btw. does edotor gracefully handle input that is too large to either render (e.g. with "dot") or to draw?

Good querstion. AFAIK there is no timeout for the processing. But the actual computations are done on a separate thread. Maybe aborting the rendering would be possible in Viz.js, I don't know.

[nikeee]

Is this still an issue / a desirable feature?

[lemmy]

No, thanks for your effort!