User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20131226030203 Steps to reproduce: 1. Use Nightly and install Firebug 1.12.5 from AMO [1] 2. Follow the instructions of this page: https://getfirebug.com/tests/head/console/5033/issue5033.html |=> Note: don't press "Continue", but the "Step Over" button (F10) 4 times 3. Reload the page [1] https://addons.mozilla.org/en-US/firefox/addon/firebug/ Actual results: - You will notice that Firebug UI is broken at step 6 of the test case. - After the reload, the Firebug UI is still broken, and won't work anymore unless you restart the browser. Expected results: Everything should work as with Nightlies before 2013-11-14. Notes: - I have used mozregression and noticed that a commit made at 2013-11-14 [1] has introduced the bug (could that be f059a2f80c22 ?). - I couldn't bisect the commits (I got errors while compiling and it takes me long to build Firefox each time). - Related issue Firebug-side: http://code.google.com/p/fbug/issues/detail?id=7078 [1] http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7b014f0f3b03&tochange=b2fab608772f Florent

Quite likely, yes. Is Firebug ending up disabling script for the chrome global?

> Is Firebug ending up disabling script for the chrome global? I don't think so: in the Browser Console, I can evaluate |alert('test');|.

I think Honza should probably take a look at this.

I think bug 924905 comment 50 describes the same issue, and bug 924905 comment 54 is spot-on. The best way to disable script on a page is to use Components.utils.{un,}blockScriptForGlobal(global). This API has the nice property that it can be used by multiple consumers, so long as everyone balances their block and unblock calls properly. You can also disable it for the docshell, which lets you disable across navigations, but doesn't scale to multiple consumers.

(In reply to Bobby Holley (:bholley) from comment #4) > I think bug 924905 comment 50 describes the same issue, and bug 924905 > comment 54 is spot-on. Yes, that's correct. > The best way to disable script on a page is to use > Components.utils.{un,}blockScriptForGlobal(global). So, if I understand correctly: stoppedFrame.executionContext.scriptsEnabled = false; can be replaced by: Components.utils.blockScriptForGlobal(global); Note that 'stoppedFrame' is the frame Firebug stopped in. The value is coming from JSD backend and passed into JSD hooks, e.g. jsd.breakpointHook. Is that correct? Honza

Yes, that is the correct approach. And setting scriptsEnabled = true can be replaced with Cu.unblockScriptsForGlobal(global).

Looks to work, thanks! Florent

(In reply to Bobby Holley (:bholley) from comment #6) > Yes, that is the correct approach. And setting scriptsEnabled = true can be > replaced with Cu.unblockScriptsForGlobal(global). One more question, is Cu.blockScriptsForGlobal suppose to block scripts even in all inner iframes? (e.g. in case where the 'global' passed in is the top level window). If not, should I just (recursively) iterate all iframes and pass them into Cu.blockScriptsForGlobal? Honza

(In reply to Jan Honza Odvarko from comment #8) > One more question, is Cu.blockScriptsForGlobal suppose to block scripts even > in all inner iframes? > (e.g. in case where the 'global' passed in is the top level window). > > If not, should I just (recursively) iterate all iframes and pass them into > Cu.blockScriptsForGlobal? > > Honza No. If you want to block it for all inner frames, you should probably just set attribute on the docshell, which will do that automatically.

Could you clarify the WONTFIX status on this for us so we know whether maybe this was addressed elsewhere with a patch?

@bkerensa: The WONTFIX means that we (Firebug) have solved the bug thanks to the instructions of :bholley, and no patch is required from the platform. Does it answer your question? Note: I still have to test the changes brought in Firebug after comment 8. However, I keep the WONTFIX status, since I intend to tell that very soon (this week). Florent

Removing the tracking nominations then, as per comment 11, thanks for clarifying.

After a test, the bug looks fixed. http://code.google.com/p/fbug/issues/detail?id=7078#c21 Florent

(In reply to fayolle-florent from comment #13) > After a test, the bug looks fixed. > http://code.google.com/p/fbug/issues/detail?id=7078#c21 > > Florent We have already decided not to track this and our decision is the same. Thanks!