Help Extension broken again in Firefox Developer Edition & Nightly

Hi,

This month I got more and more reports that the “Turn Off the Lights” Firefox extension (XUL version) is not working in Firefox Developer and Nightly 48.0a1 (2016-03-23). When you click on the gray lamp button the lights go not off, but in the Firefox new tab page (chrome://) it dims the page.
In the stable Firefox version 45.0.1 do you see not the issue, and works everything very well.

In Nightly I get this error in the “browser console”:

unsafe CPOW usage main.js:490
[ERROR] Error: unsafe CPOW usage forbidden

Help. How can fix this issue or is this a bug in Firefox?
https://addons.mozilla.org/en-US/firefox/addon/turn-off-the-lights/

Kind Regards,
Stefan
https://www.turnoffthelights.com

I’m assuming this error is in your addon code? It shouldn’t be. It is only supposed to occur for non-addon code. However, passing CPOWs to browser code from an addon may cause it to happen. Also, it seems to happen in a few remaining cases inside browser code, which is just a bug.

dom.ipc.cpows.forbid-unsafe-from-browser is a preference that causes this to happen. It has recently been set default true, which is presumably what causes your problem. A quick fix is to turn it off again, but you really need to address the CPOW that you are using.

Thanks for your post!

I tried to solve this issue in my main.js XUL extension, but I don’t know how to fix this. Any idea how to solve this in code?
Need to get this back working for newer version of Firefox.

Also soon the “Turn Off the Lights” extension is available as a webextension, but there is bug with chrome.storage. So I can’t get this ready for Firefox v48 (nightly). Transition from xul to webextension

Thanks,
Stefan

You appear to be executing javascript directly in content using your own sandbox and manually created system principal, and you’re doing it from the chrome process through a compatibility shim. I’m amazed that ever worked at all in multiprocess mode, but it looks like the latest tightening of the screw has broken it. You have a quick-fix, but really this needs to be rewritten, possibly with frame scripts, possibly a different mechanism altogether. Although the recent change wasn’t intended to affect addons, you’re passing CPOWs into system functions all over and that is always going to be a problem.

In such a complex addon interacting so intimately with content, you should probably also take a look at all the other CPOW warnings you’re likely to have been getting. The intention is that those should be mostly fixed rather than ignored, then the addon can be declared officially e10s-compatible which improves performance and reduces memry use.

Hi Lithopsian.

Thanks to review the code and for your answer!
Long, long time ago, I was a beginner developer for my first Firefox add-on. And I didn’t know how creates this add-on to simply inject a javascript code on a website. I received from someone a very short and simple Firefox add-on that do this job. And then I build it further and further up…

Then when Google Chrome launches his extension support, the whole system is better and understandable for as developer. And they have a few basic samples. Even Microsoft use this now for the Edge browser.
I as small developer team and I can’t rebuild everything again for Firefox now. Even if Firefox stop the support of XUL. My hope is that Firefox get the chrome.storage fixed asap so I can move from the XUL to webextension.

Thanks,
Stefan

Is this idea that XUL is being deprecated a concerted conspiracy or simply a misunderstanding spread by social media? The whole Firefox interface is XUL. It isn’t going anywhere for a long long time. Read the blog and you will see that what is being deprecated, one day in the near future, is the method of creating extensions by overlays on XUL, as well as some other features used by extensions such as XPCOM. There is certainly the desire that addons be entirely sandboxed behind restrictive APIs, but for now they aren’t even going that far, if only because they are a long way from being able to support some very important addons without going outside those APIs.

So potentially, at some point in the next few years which has yet to be announced, you won’t be able to create an addon from the starting point of an overlay on browser.xul. However browser.xul or some similar file will still exist. Possibly one day they will even remove the ability to create dialogs and pages using XUL, although they have not announced this yet. You and other people really should stop repeating false claims such as that Mozilla will “stop the support of XUL”.

Hi Lithopsian,

The “stop the support of XUL” was not a good word. And yes I know this:
Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback. Add-ons that are built using the new WebExtension API will continue to work. We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.
Source: Firefox blog

Thanks,
Stefan

In fairness, there has been talk about deprecating XUL and replacing it in Firefox. However, that would be a massive undertaking and the available alternatives aren’t very clear. It would take years to do.

But yeah, we’re only talking about deprecating the current “anything goes” approach to add-on UI.

1 Like

Once the external access to XUL has been tied down, it would presumably be relatively “simple” to replace it internally with anything that did the job. Maybe port it all formally to GTK+ :slight_smile:

Coincidentally, today is the day that I got emails telling me that my life’s work is going to be deprecated very soon. No dates yet, and I guess it could be some time before things actually stop working once they’ve been formally deprecated.