Stop calling TargetFront.attach from options panel to know if JS is enabled

Categories

(DevTools :: Framework, enhancement)

For bugs in Firefox DevTools, the developer tools within the Firefox web browser. This includes issues about the user interface of the toolbox, special pages such as about:debugging and about:devtools, and developer-related APIs.

Here is an handy test document:
data:text/html,<script>document.write("JS");</script><br/>xxxxx
Note that this code looks antique!
You would expect the checkbox in options panel to always be updated to the right state, but it is not with/without this patch.
Here is the controvertial STR:
* open the test doc
* open toolbox on the options panel
* toggle JS to *disabled*
* close the toolbox ===> the BrowsingContextTargetActor will reset docShell flag on destroy, but not reload the document
* reopen the toolbox
=> options panel says the JS is *enabled*. Well that's kind of true, docShell's flag allows JS to run, but you have to reload to see that.
At the end, we might as well just consider the JS always enabled from the options panel, it would behave the same as today and the code would be simplier...
But here is a patch to stop calling attach and rely on the state stored on the front.
I added a preliminary revision, to switch a test for JS disabling to async test.

For now, the options panel was calling `attach` to know if the javascript was disabled
on the debugged document. But this property is already cached during the `attach`
request done by the toolbox.
MozReview-Commit-ID: JcDT6vxCUzN
Depends on D8847

For now, the options panel was calling `attach` to know if the javascript was disabled
on the debugged document. But this property is already cached during the `attach`
request done by the toolbox.
MozReview-Commit-ID: JcDT6vxCUzN
Depends on D8851