A couple of points I've noticed...

flux::ViewTab.loadView() will always make / create a new View from scratch. Given this is called every time you load a Uri in the Frame / ViewTab, this seems a little wasteful. Particularly since the use of Frame.load() is advocated to retain web browser history in flux.

Which is a nice sedge-way into...

When you call WebBrowser.load(Uri)

• this calls the browser's onHyperlink event,
• which calls Frame.load()
• which creates a new Browser View,
• which calls the new browser's onHyperlink event (not sure how...),
• which calls Frame.load()
• which creates a new Browser view
• etc..
• which (on Windows) causes the JVM to error and exit.

A snippet of my code to prevent this is:

class BrowserView : View {
  private WebBrowser? browser

  override Void onLoad() {
    browser = WebBrowser() {
      it.onHyperlink.add |e| { this.onHyperlink(e) }  
    }
    ...
  }

  override Void onActive() {
    browser.load(resource.uri.plusQuery(["badHyperlink":"true"]))
    ...
  }

  private Void onHyperlink(Event event) {  
    if (resource.uri.query.containsKey("badHyperlink")) {
      return
    }
    ...
  }
}

I think what you said make sense ... but having worked recently with webbrowser (in camembert, fork of Brie) I've found the whole WebBrowser thing to be super buggy/unreliable, especially across platforms. In particular onHyperlink caused issues.

It's not a Fantom issue per say but more of SWT/native browser problem. In camembert I had to stick to only use load() for something that works on linux, mac, windows. Both loadStr() and onHyperlink() where inconsistent / buggy / not working.

So that might be why it's that way in Flux as well.

BTW: The SWT jars that ship with fantom are way old too, so using newer ones do help some but even then it's still buggy. Note: Brian updated the jars for the next release.

(Just bringing this up again cos I'm re-looking at some code.)

While the whole WebBrowser thing may well be buggy - it is Flux that causes the infinite recursion when you call WebBrowser.load(Uri), and this infinite recursion does cause JVM crashes.

If the Views were cached, the recursion would be broken, bringing in a bit more stability and little less resource overhead.

I was using it outside of flux (camembert) and there where still lots of issues like linux crashes, some features not working on windows like loadStr and so on.

Plain loading pages from a "real" server is almost te only thing that works, so I limited my usage to that.