Closed Bug 1132983 Opened 6 years ago Closed 6 years ago

Menu entry for "Firebug" disappears at every restart

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.32 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: mapsym, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32
Build ID: 2015011400

Steps to reproduce:

Install Firebug
Restart Seamonkey

OS: OpenSuse 13.2 (KDE)


Actual results:

The following menu entry is present after installation of Firebug but disappeared after a restart: 
Tools->Web Development->Firebug

It appears again if Firebug is disabled and enabled again from Add-ons Manager (or reinstalled completely), but gets lost after each new start of Seamonkey.
Nevetheless Firebug could be started by F12 even if the menu entry is lost.

This does not depend on whether the old Venkman debugger is installed or removed.

Not sure whether this is a problem in Seamonkey or in Firebug.


Expected results:

Menu entry "Firebug" should be there all the time (as long as Firebug is installed).
Confirmed.
Firebug 2.0.8.

Should it mean anything:

> 1423856478515	addons.xpi	WARN	Exception running bootstrap method startup on firebug@software.joehewitt.com: TypeError: FirebugGCLICommands is undefined
> (resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/21.dumy/extensions/firebug@software.joehewitt.com.xpi!/bootstrap.js:78:4)
> JS Stack trace: startup@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/21.dumy/extensions/firebug@bootstrap.js:78:5
> < XPI_callBootstrapMethod@XPIProvider.jsm:4436:9 < XPI_startup@XPIProvider.jsm:2159:13
> < callProvider@AddonManager.jsm:208:12 < _startProvider@AddonManager.jsm:667:5
> < AMI_startup@AddonManager.jsm:824:9 < AMP_startup@AddonManager.jsm:2402:5
> < AMC_observe@addonManager.js:55:7
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's probably a Firebug bug. Perhaps you should also file a bug with their issue tracker.
Ok, I filed a corresponding bug in Firebug's issue tracker:
https://code.google.com/p/fbug/issues/detail?id=7764
As that is a Firebug issue, I close this report. (It may be fixed by bug 574955, though.)
Note that Firebug is not officially supported in SeaMonkey.

Sebastian
Status: NEW → RESOLVED
Closed: 6 years ago
Depends on: 574955
Resolution: --- → WONTFIX
This is not a bug at all and should probably be marked RESOLVED INVALID.  Firebug doesn't officially support SeaMonkey and versions after 2.0.4 just don't happen to work OOB anymore.
The problem is they use window.gBrowser in a couple places where if they were to support SeaMonkey they would need to use

window.gBrowser || window.getBrowser()


The following patch applied to Firebug will fix it:

diff -r ./firebug-2.0.7-fx/content/firebug/firefox/browserOverlay.js ./firebug-2.0.7.1/content/firebug/firefox/browserOverlay.js
583c583
<         var browser = win.gBrowser;
---
>         var browser = win.gBrowser || win.getBrowser();
638c638,639
<         if (this.win.gBrowser.isRemoteBrowser)
---
>         let wingb = this.win.gBrowser || this.win.getBrowser();
>         if (wingb.isRemoteBrowser)
(In reply to kevink9876543 from comment #5)
> The problem is they use window.gBrowser in a couple places where if they
> were to support SeaMonkey they would need to use
> 
> window.gBrowser || window.getBrowser()

Applied the patch in https://github.com/firebug/firebug/commit/53bb5bda15.

Sebastian
Resolution: WONTFIX → INVALID
Oh wow, didn't expect that, thanks a lot sebo! :D
Thanks for applying the patch! I have build the xpi from the latest revision at gitgub and Firebug works again in SeaMonkey.

BTW, I am a little perplexed - why is "window.gBrowser || window.getBrowser()" needed for SM? From my observations window.gBrowser is also available in SM and the statement "window.gBrowser === window.getBrowser()" returns true when I run it in SM. What is the difference then?
(In reply to lemon_juice from comment #8)
> BTW, I am a little perplexed - why is "window.gBrowser ||
> window.getBrowser()" needed for SM? From my observations window.gBrowser is
> also available in SM and the statement "window.gBrowser ===
> window.getBrowser()" returns true when I run it in SM. What is the
> difference then?

In Firefox window.gBrowser is a getter and window.getBrowser() is deprecated; in SeaMonkey window.gBrowser is a normal variable that is set by calling window.getBrowser() (which also returns the value it sets for window.gBrowser), so in SeaMonkey you want to try to use window.gBrowser when possible but you can't assume that window.gBrowser isn't null..
Nasty little differences... Thanks for explaining.
In Firefox gBrowser is a "smart" getter. In SeaMonkey gBrowser is a normal global variable set by calling getBrowser(). Firefox does have a getBrower() that is aliased to gBrowser mostly for backward compatibility with older extensions.
You need to log in before you can comment on or make changes to this bug.