1395813 - Investigate whether we can remove the browser-element-api:call JS sync IPC

Status: NEW

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

Description

[(no longer active)]

This is called from <https://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/dom/browser-element/BrowserElementChildPreload.js#59>

According to telemetry, it's mean time right now is 17.94ms on trunk.  It looks like this is used for the contextmenu event.

Andrea, are you familiar with this?  It looks like this is a remnant from the b2g days (it was added in bug 864382).  Is it still needed?

Comment 1

[Kan-Ru Chen [:kanru] (UTC+9)]

All browser-element-api message shouldn't appear in normal browsing since we don't instantiate mozbrowser. Only place this could happen is devtools responsive design mode and maybe other non-firefox front-end.

Comment 2

[(no longer active)]

Yes, AFAIK the only place this appears in is the devtools UI.  The telemetry submission rate was quite low which I think corroborate that.

Comment 3

[Andrea Marchesini [:baku]]

I keep the NI. I'll work on this as soon as possible.

Comment 4

[Andrea Marchesini [:baku]]

BrowserElement API is still used by devtools if I remember correctly. Would be great if somebody from that team can check the priority of this bug and fix/resolve it somehow. Honza, can you help here?

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Patrick, another thing related to the current RDM implementation, can you please have a look?

Here is quick search for BrowserElement API
https://searchfox.org/mozilla-central/search?q=BrowserElement+API&path=

Honza

Comment 6

[Patrick Brosset <:pbro>]

Yes RDM is the sole consumer of this API (in fact of the <iframe mozbrowser> element).
Its current architecture depends on this entirely and removing it would break RDM which is a very important tool in light of our GeckoView efforts (since many (all?) web developers building for mobile do need RDM to test on desktop first).

The current plan is to investigate how feasible it would be to get rid of this by merging the RDM UI into browser.xul instead and using the content <browser remote> as the viewport area that RDM displays, instead of the <iframe mozbrowser>.
This is something we are investigating in bug 1549775 right now. And our plan is to have enough of this figured out before the start of H2 so we can jump into implementation phase then.