Closed Bug 1279635 Opened 4 years ago Closed 4 years ago

need a way to synchronously retrieve back/forward status of mozbrowser

Categories

(Core :: DOM: Core & HTML, enhancement, P2)

enhancement

Tracking

()

VERIFIED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: myk, Assigned: kanru)

References

Details

(Keywords: dev-doc-needed)

Attachments

(1 file)

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.
Kan-ru, wdyt?
Flags: needinfo?(kchen)
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.
Flags: needinfo?(kchen)
Myk, how does comment 2 sound?
Flags: needinfo?(myk)
(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).
Flags: needinfo?(myk)
(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.
P2 ~= "we aim to fix in the next few months" since this seems rather urgent.

Kan-Ru, can you take this?
Flags: needinfo?(kchen)
Priority: -- → P2
Assignee: nobody → kchen
Flags: needinfo?(kchen)
Comment on attachment 8787578 [details]
Bug 1279635 - Change mozbrowserlocationchange event detail to match Servo.

https://reviewboard.mozilla.org/r/76302/#review74418
Attachment #8787578 - Flags: review?(bugs) → review+
Pushed by kchen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5cf6587f7f07
Change mozbrowserlocationchange event detail to match Servo. r=smaug
https://hg.mozilla.org/mozilla-central/rev/5cf6587f7f07
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Keywords: dev-doc-needed
Thanks for the fix!  It works exactly as expected after updating Positron to include it.
Status: RESOLVED → VERIFIED
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!
(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.
(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.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.