mykmelez
commented
8 years ago According to https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowserlocationchange, Servo includes the back/forward status in its mozbrowserlocationchange events. Making Gecko do the same would enable Positron to cache it in the parent process so it could return it synchronously from the canGoBack/canGoForward methods.
WebAPI/BrowserAPI/Common_Subset equates Google's and Microsoft's canGoBack/canGoForward methods with Mozilla's getCanGoBack/getCanGoForward methods. But Electron's equivalents (presumably based on those in Chromium) are synchronous, whereas Mozilla's are asynchronous, returning a promise that resolves to the result.
So our <webview> implementation, which uses an <iframe mozbrowser> internally, emulates them by calling getCanGo* on the mozbrowser and then spinning the event loop until they return. That works, but it's a hack, and it has undesirable side-effects (like hanging the main process). We should figure out a better implementation.
Perhaps a mozbrowser can pro-actively synchronize back/forward status from its child frame to its parent element, so Positron can call synchronous methods on the element or introspect properties that contain its current status. Or perhaps locationchange events can include information on the back/forward status of the mozbrowser, so Positron can keep track of the state itself, as suggested by bug 1198473.
That bug, and bug 1198479, address similar concerns, but they're a bit more general, and they're in FirefoxOS::Runtime, whereas this is probably a Core::DOM issue. So I filed bug 1279635 on it.