1649710 - Fix EnvironmentFront

Status: RESOLVED FIXED

(DevTools :: Framework, defect, P1)

Description

[Nicolas Chevobbe [:nchevobbe]]

The constructor still has the signature of old fronts (I think?), expecting a client and a form.
But protocol.js calls it with a client, a targetFront and a parentFront, which means what it think is a form is in fact a target front.
It was somehow working because the targetFront has an actor method, but the work on Bug 1623283 revealed the issue.

This front should be fixed to behave like the other fronts, and the test that directly instantiate EnvironmentFront (devtools/server/tests/xpcshell/test_framebindings-07.js) needs to be updated.

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

TRY: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd9703f5ef8e88c1b3e8e7b91a4a82590e067bf2

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1649710 - Fix EnvironmentFront constructor. r=jdescottes.

The constructor signature was wrong, as protocol.js calls it with a targetFront
instead of the expected "form".
The self-management isn't making much sense, and there's no need for this front
to be different than others.
test_framebindings-07.js, which was directly instantiating EnvironmentFronts is
modified to not do this anymore.
This allow us remove the getBindings method from the front, as it was only used
from this test.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7220ff5029d0
Fix EnvironmentFront constructor. r=jdescottes.

Comment 4

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/7220ff5029d0