Closed Bug 557791 Opened 14 years ago Closed 14 years ago

Bug 483672 regression: Security Manager vetoed action

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: Honza, Assigned: mrbkap)

References

Details

(Keywords: regression, Whiteboard: [firebug-p1])

Attachments

(1 file)

Testcase described in comment 41
516 bytes, text/html
Details 
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
Keywords: regression
Whiteboard: [firebug-p1]
Requesting blocking as this bug prevents Firebug tests from passing for FF 3.7.
blocking2.0: --- → ?
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
Assignee: nobody → mrbkap
This is basically dogfood for me, can't develop my website on minefield.
I have most of a patch for this.
Blocking.
blocking2.0: ? → beta1+
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.
blocking2.0: beta1+ → beta2+
blocking2.0: beta2+ → beta3+
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+.
blocking2.0: beta3+ → 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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: