Myk Melez [:myk] [@mykmelez] Reporter
	Description • 8 years ago

In order for Positron to implement the Electron <webview> API, it needs to return the back/forward status of an <iframe mozbrowser> from the canGoBack/canGoForward methods of the <webview>.  So there should be some way to synchronously retrieve that status from the mozbrowser.

Currently, the only way to access that status is through the asynchronous methods getCanGoBack/getCanGoForward, which return a promise.  In Positron, I implemented a workaround that calls one of those methods and then spins the event loop while waiting for its promise to resolve.  But that's a hack that has negative side-effects (like hanging the UI process).

Perhaps the mozbrowser can pro-actively synchronize back/forward status from its child frame to its parent element, then make it available via properties on the element or synchronous canGoBack/canGoForward methods.

Alternatively, as suggested in bug 1198473 (which is similar but a bit more general), perhaps locationchange events can include the back/forward status of the mozbrowser, such that Positron can track the state itself.

	Andrew Overholt [:overholt]
	Comment 1 • 8 years ago

Kan-ru, wdyt?

	Kan-Ru Chen [:kanru] (UTC+9) Assignee
	Comment 2 • 8 years ago

I think the child can listen to the locationchange event and forward canGoBack/canGoForward information to the parent element. Then the canGoBack/canGoForward methods can be synchronous and retrieve the info from cache. But I'm not sure if canGoBack/canGoForward status can change without locationchange events.

Yes we could also expose them via properties but you will want the changes to the properties to be observable, maybe via new events.

	Andrew Overholt [:overholt]
	Comment 3 • 8 years ago

Myk, how does comment 2 sound?

	Myk Melez [:myk] [@mykmelez] Reporter
	Comment 4 • 8 years ago

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #2)
> I think the child can listen to the locationchange event and forward
> canGoBack/canGoForward information to the parent element. Then the
> canGoBack/canGoForward methods can be synchronous and retrieve the info from
> cache.

That's reasonable.  And it appears to be the way that Servo works, since https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowserlocationchange says that the "details" object associated with a mozbrowserlocationchange event includes canGoBack and canGoForward properties on Servo, which is effectively the same thing as you describe (although I'm not sure if you meant for this information to be part of that event or forwarded via a different mechanism).

	Kan-Ru Chen [:kanru] (UTC+9) Assignee
	Comment 5 • 8 years ago

(In reply to Myk Melez [:myk] [@mykmelez] from comment #4)
> (In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #2)
> > I think the child can listen to the locationchange event and forward
> > canGoBack/canGoForward information to the parent element. Then the
> > canGoBack/canGoForward methods can be synchronous and retrieve the info from
> > cache.
> 
> That's reasonable.  And it appears to be the way that Servo works, since
> https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowserlocationchange
> says that the "details" object associated with a mozbrowserlocationchange
> event includes canGoBack and canGoForward properties on Servo, which is
> effectively the same thing as you describe (although I'm not sure if you
> meant for this information to be part of that event or forwarded via a
> different mechanism).

Include the information as part of mozbrowserlocationchange event sounds good to me.

	Andrew Overholt [:overholt]
	Comment 6 • 8 years ago

P2 ~= "we aim to fix in the next few months" since this seems rather urgent.

Kan-Ru, can you take this?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 8 • 8 years ago
mozreview-review

Comment on attachment 8787578 [details]
Bug 1279635 - Change mozbrowserlocationchange event detail to match Servo.

https://reviewboard.mozilla.org/r/76302/#review74418

	Pulsebot
	Comment 9 • 8 years ago

Pushed by kchen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5cf6587f7f07
Change mozbrowserlocationchange event detail to match Servo. r=smaug

	Phil Ringnalda (:philor)
	Comment 10 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/5cf6587f7f07

	Myk Melez [:myk] [@mykmelez] Reporter
	Comment 11 • 8 years ago

Thanks for the fix!  It works exactly as expected after updating Positron to include it.

	Chris Mills [:cmills]
	Comment 12 • 8 years ago

It looks like this information has been included in the page already, in the following section:

https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowserlocationchange#detail_(Servo_only)

where it talks about the canGoBack and canGoforward properties, correct?

I've also added a note to the 51 release notes:

https://developer.mozilla.org/en-US/Firefox/Releases/51#Others

If I need to say something else, please let me know. Thanks!

	Myk Melez [:myk] [@mykmelez] Reporter
	Comment 13 • 8 years ago

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #12)
> It looks like this information has been included in the page already, in the
> following section:
> 
> https://developer.mozilla.org/en-US/docs/Web/Events/
> mozbrowserlocationchange#detail_(Servo_only)
> 
> where it talks about the canGoBack and canGoforward properties, correct?

Yes, but the page says that those properties are "Servo-only," whereas this bug exposes them on Gecko.  Basically, the references to Gecko and Servo on the page need to be coalesced, since Gecko and Servo now expose the same *detail* object.

	Chris Mills [:cmills]
	Comment 14 • 8 years ago

(In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> (In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #12)
> > It looks like this information has been included in the page already, in the
> > following section:
> > 
> > https://developer.mozilla.org/en-US/docs/Web/Events/
> > mozbrowserlocationchange#detail_(Servo_only)
> > 
> > where it talks about the canGoBack and canGoforward properties, correct?
> 
> Yes, but the page says that those properties are "Servo-only," whereas this
> bug exposes them on Gecko.  Basically, the references to Gecko and Servo on
> the page need to be coalesced, since Gecko and Servo now expose the same
> *detail* object.

Cool, thanks for the clarification Myk. I've updated the pages accordingly.