Regression of bug 483672 Firebug test: http://www.janodvarko.cz/firebug/tests/1586/Issue1586.htm (follow instructions on the page) ...stops working with 3.7a4pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4pre) Gecko/20100322 Minefield/3.7a4pre (.NET CLR 3.5.30729) Tested in a new profile with Firebug 1.6Xa8 installed http://getfirebug.com/releases/firebug/1.6X/firebug-1.6X.0a8.xpi Throws following exception: onHTTPSpyReadyStateChange: EXCEPTION [Exception... "Security Manager vetoed action arg 0 [nsIDOMEventListener.handleEvent]" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] Related to the Firebug code mentioned here: https://bugzilla.mozilla.org/show_bug.cgi?id=483672#c0 The same test works when I test with Fx 3.6.3pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3pre) Gecko/20100321 Namoroka/3.6.3pre (.NET CLR 3.5.30729) I think this could be also related to bug 519901 Related Firebug issue: http://code.google.com/p/fbug/issues/detail?id=2927 Please see also https://bugzilla.mozilla.org/show_bug.cgi?id=483672#c83 https://bugzilla.mozilla.org/show_bug.cgi?id=483672#c85 Honza

Requesting blocking as this bug prevents Firebug tests from passing for FF 3.7.

The symptom is different from bug 483672, and this is a regression from bug 533600 and bug 542428. |handleEvent| is a SJOW and |event| is a chrome object, thus XPC_SJOW_Call wraps |event| in a COW. And then when XPCWrappedNative::CallMethod converts the JS argument to a native, XPCConvert::JSObject2NativeInterface tries to unwrap the COW, but the security check in UnwrapCOW fails since the subject principal is the content principal given by the SJOW.

Any progress on this? It's still blocking Firebug on 3.7 Honza

This bug seems to be present in FF 3.6.3 as well (using Firebug 1.5.3). Front-end developers are likely to switch to Chrome as their main debugging platform for as long as this bug is present.

Nevermind my last comment, the firebug problem i referred to seems to be unrelated to this bug.

Just to note that the official Firebug issue list is here: http://code.google.com/p/fbug/issues/entry Please create a report if you see a problem (and you can provide a test case for us to reproduce it and fix). Honza

This is basically dogfood for me, can't develop my website on minefield.

I have most of a patch for this.

Blocking.

Any progress on this one? It's an important Firebug 1.6 & Fx 3.7 combo blocker. Honza

Indeed.Any news?

Every update I'm hoping to get this finally fixed. Anyone found a way to have this temporary working until it gets fixed?

The temporary workaround is to use FF 3.6.

Blake, is this going to make Monday, Aug 2 code freeze? jst: re-triage?

I doubt we'll get this in in time for beta3, marking betaN+.

This is still in todays nightly build. Is a patch in the works? Blocking for me, cant develop in Minefield (FF 4b4pre)

this issue trouble me for a long period, waiting for solution.

hey guys, are you gonna fix that??? this is essential for developing XHR applications!

I voted to get it fixed.

Guys, please let's use Bugzilla for discussing relevant facts the bug and associated actions. Complaining or saying it's urgent [1] usually doesn't help much: there is a lot going on in the scope of Firefox 4 and I'm sure most Mozilla developers are already overflown. Voting in this bug and motivating others who are suffering from the issue to vote as well *is* the proper way to flag this issue as important. ;-) (In reply to comment #19) > this is essential for developing XHR applications! In a quick check, apparently you can enable the Net panel as a workaround (but I haven't deeply checked if it's a proper workaround, as it is not documented in the known issues [2]). [1] http://catb.org/~esr/faqs/smart-questions.html#urgent [2] http://getfirebug.com/knownissues

A couple of corrections to comment 21: This issue is the first on listed on http://getfirebug.com/knownissues. As stated on that page, the correct workaround is to turn off Firebug > Console > Show XMLHttpRequests, or use Firefox 3.6.

Sorry for the long silence here. We're working on some fairly large architectural changes that are going to fix this. They should hopefully be landing in a week or so.

Sounds great, thanks for the update! Honza

Can we expect those changes in beta6?

beta 6 seems to also have the bug

And this makes me doubt that we'll see any difference in beta7 https://wiki.mozilla.org/Releases/Firefox_4.0b7#Release_Tracking_.26_Schedule Am I wrong?

Mozilla has committed to fix this bug before FF4.0 final release. It's marked as blocking and it's on the list of knownissues that need to be fixed. Commenting here won't make it happen faster. You can ask on the mozilla.dev.apps.firefox newsgroup if there is anyway to give this work priority, but I doubt it can make a difference. Firefox 3.6 works great for AJAX development with Firebug.

Not much use if you're debugging Fx 4 functionality that you want for release, unfortunately. Firebug is the most important tool in my arsenal for getting things ready for final release. Not being able to use Firebug will probably delay release of these tools until after they've had their brief window to show off Fx 4's features to those looking for them. Which is some ways would defeat their entire purpose - they're there to showcase Fx 4. I'm not stating this to speed things up, just stating it's not that simple a problem as to be dismissed with 'use 3.6'.

You're right that we could just use 3.6 for our work. That doesn't do a lot to help us beta test FF4 though. The issue isn't that we can't get our work done, it is that FF4 is losing a lot test time by the people most qualified to find and report bugs because they can't use it for the work that they are doing.

(In reply to comment #29) And I am not disputing anything you say, just where you are saying it. You can't convince anyone on this bug report to put more resources on this bug. You have to make that case to Firefox management. You're just wasting the time of the very people who need to work on this bug.

> Sorry for the long silence here. We're working on some fairly large > architectural changes that are going to fix this. They should hopefully be > landing in a week or so. Blake, just wondering where things are at with this, and if you have any QA or testing I could do to help speed this along?

This will stay blocking for sure. Blake's been busy with compartments.

Well, compartments fixed *this* bug, but I hear they broke the rest of Firebug; so pick your poison ;-).

Seems fixed on Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101029 Firefox/4.0b8pre.

Yeah. This was fixed by compartments.

Just downloaded nightly ( Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101028 Firefox/4.0b8pre ) and tried to console.log the data from a JSON request in Firebug. This kills my script, giving no console output. This is the same behavior I was seeing in Fx Beta 6. When I do not console.log the JSON data, the script carries on without any errors. Is Firebug broken, is this fixed?

It actually *works* when the firebug panel is opened after page finished loading. If you reload a page with the panel hidden but with firebug enabled it wont work.

The Firebug window.console is added to the Web page in two ways: 1. Just before the first JavaScript method runs in the page, 2. If the user clicks on the command line and #1 has not happened. At least up to 10/30/2010 the API Firebug uses for #1 is not functioning in Firefox 4. Therefore path #1 does not work, which explains comment 37 but path #2 works which explains comment 38.

(In reply to comment #38) > It actually *works* when the firebug panel is opened after page finished > loading. If you reload a page with the panel hidden but with firebug enabled it > wont work. I can't reproduce this, tested with: http://hg.mozilla.org/mozilla-central/rev/f4ea6992e1c6 Could you please provide the exact STR? For me, this bug seems to be fixed. Honza

Actually i can't reproduce ATM because firebug won't stay attached to the page on reload with actual nightbuild (rev f4ea6992e1c6). Since the issue can only be reproduced in this case (on page reload when firebug is active-attached but not shown) i can't reproduce. I'll still attach a test case reproducing the issue before today's build. 1) Press the button with firebug enabled and visible. You get the responseText of the XMLHTTPRequest 2) Reload the page with firebug enabled but hidden and click the button again. You should get the same result but the request never ends and you don't get the alert dialog.

I really think we should just let this set until the jsd story is sorted out. Until then anything having to do with the console can be broken.

(In reply to comment #41) > 1) Press the button with firebug enabled and visible. You get the responseText > of the XMLHTTPRequest > 2) Reload the page with firebug enabled but hidden and click the button again. > You should get the same result but the request never ends and you don't get the > alert dialog. Retested with 40b9 http://hg.mozilla.org/mozilla-central/rev/d2bd42931b03 and works for me. Honza

Works for me too.