This is based on some conversations we had in browse.html 1. I can't tell from current spec if canGoBack() and canGoForward() return booleans or promises as they do in mozbrowser. Promises make this API less ergonomic and are more prone to race conditions. Basically now we request canGoBack() and canGoForward() on location change in order to update the rendered UI and later on we get results. It would make a lot more sense to include those values along with location change event and actually make webView maintain the state of those values for user instead. Also as far as I can tell atom-shell's web view does return boolean instead of promise for it: https://github.com/atom/atom-shell/blob/master/docs/api/web-view-tag.md#webviewcangoback I personally think those should be just getters + attributes that get updated when state changes and have event to let user know. 2. Larger issues is that API is very imperative while from HTML one would expect more declarative approach.
The larger issue we've being discussing is that history graph is maintained by the web view and is kind of hidden away. Unsurprisingly history graph is also linear given that's how today browsers present a history graph. It is unfortunate as it makes it difficult to do things differently like present sessions in non linear graph think of something like vim gundo As a matter of fact this is the root of the issue that I think influences an API making it imperative instead of declarative. I would suggest to change API to make it more declarative and get rid of imperative knobs like goBack / goForward / reload etc.. All of that maybe expressed via src change assuming that user keeps the navigation history. Although if you do it right now you won't restore page from cache but would load it over. It would be great if API was adjusted to make it src based and have maybe an additional attribute cache or something along that line to allow restoring from cache vs reloading it. That attribute may also be used to enable / disable caching of the documents.
No longer blocks: 1198471
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 22 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.