Closed Bug 483672 Opened 15 years ago Closed 14 years ago

Permission denied for <http://localhost:7080> to call method UnnamedClass.handleEvent@XPCSafeJSObjectWrapper.cpp:445.0

Categories

(Core :: XPConnect, defect, P1)

1.9.2 Branch
x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta1+
status2.0 --- ?
blocking1.9.2 --- -
status1.9.2 --- unaffected
blocking1.9.1 --- -
status1.9.1 --- unaffected

People

(Reporter: johnjbarton, Assigned: mrbkap)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.9.1, regression, Whiteboard: [firebug-p1][need for 1.9.2])

Attachments

(5 files, 2 obsolete files)

I get this error message:

Permission denied for <http://localhost:7080> to call method UnnamedClass.handleEvent@XPCSafeJSObjectWrapper.cpp:445.0

The line number is incorrect, the method name makes no sense.

I believe the call is in here:

function onHTTPSpyReadyStateChange(spy, event)
{
    try
    {
        spy.context.onReadySpy = spy; // maybe the handler will eval(), we want the URL.
        if (spy.onreadystatechange)
            spy.onreadystatechange.handleEvent(event);
    }
    catch (exc)
    {
        if (FBTrace.DBG_ERROR)
            FBTrace.sysout("spy.onHTTPSpyReadyStateChange: EXCEPTION", exc);
    }
    finally
    {
        delete spy.context.onReadySpy;
    }

    if (spy.xhrRequest.readyState == 4)
        onHTTPSpyLoad(spy);
}
Either the error is spurious, in which case this problem blocks Firebug or the error is real and the message is inadequate.  I marked the bug BLOCKS for both cases for now.
Blocks: 435025, 453978
This is examples/exampleNetTest.js running on FF 3.1b3. It never gets to testDone.

I think that what is happening is the readyStateChange event is firing and spy.js onHTTPSpyReadyStateChange() is being called by Firefox, but it is incorrectly being run under the web page principle. The call stack has only  
chrome://firebug/content/spy.js (512)
chrome://firebug/content/spy.js (334)

So my first guess is that this is a bug in 3.1, not a new security feature.
Whiteboard: [firebug-p1]
I've seen error messages similar to that, and in the console the linkified view-source url points to http://www.{some-.cpp-file}.com, with some-.cpp-file being whatever the exception passes through. It's very interesting that errors are reported to the console with the uri being some source cpp file...
Isn't this a dup of the "Chrome now gets XPCNativeWrapper for XHR" thing?
Whiteboard: [firebug-p1] → [firebug-p1]DUPEME
Not sure about the severity of this, marking sensitive.
Group: core-security
fwiw, I don't think this is a security issue.
If, contrary to my assumption, the web principal is correct, then Firebug 1.3 exposes Firefox 3.0 users. I don't know.
exposes in what way though? Based on this it looks like something (the web principal?) is preventing an event's listener from running. This would feel more securityish if we were running arbitrary javascript in an unprotected way.

Seeking further consults from the SG gurus.
I'm looking for the test case mentioned above, and can't find it in http://code.google.com/p/fbug/source/browse/#svn/examples/firebug1.4.
For what it's worth, the bug I was thinking of was bug 471395.
So presumably not a duplicate, but caused by the same thing.

Peter, mind looking into this?
Attached file Test Case
I am attaching a simple test extension that can be used to reproduce the problem.

Steps to reproduce:

1) Install the extension and enable dump() so, you can see the final exception in the system console.

2) Start Firefox 3.1b3 and load http://www.janodvarko.cz/firebug/tests/601/Issue601.htm page

3) Press the "POST" button on the page (it generates a XHR)

4) See the system console there is following exception.
XHRTest: EXCEPTION Error: Permission denied for <http://www.janodvarko.cz> to ca
ll method UnnamedClass.handleEvent


The test-case is replacing onreadystatechange property of the XHR object by  own function. The original handler is called within this function using handleEvent. 

The exception is fired when the original handler is called so, the handler implemented on the page is never executed. You can see that the green text (on the test page) saying "{response must be displayed here}" is never replaced with the actual response.

This works as expected in Firefox 3.0.7
(In reply to comment #10)
> For what it's worth, the bug I was thinking of was bug 471395.

It's not dup, since the problem in #471395 is that the exception was fired when the onreadystatechange property was just accessed. 
This has been fixed and works now.

In this case, the exception is fired when the onreadystatechange property is used to call the original handler.

Honza
Taking the liberty to move this to the right product.  Can someone check whether this also broke with bug 457022?  I expect it did...
Component: Security → XPConnect
Product: Firefox → Core
QA Contact: firefox → xpconnect
Whiteboard: [firebug-p1]DUPEME → [firebug-p1]
Version: 3.1 Branch → Trunk
Flags: blocking1.9.1?
(In reply to comment #9)
> I'm looking for the test case mentioned above, and can't find it in
> http://code.google.com/p/fbug/source/browse/#svn/examples/firebug1.4.

Sorry, I was thinking relative to the test directory:
http://code.google.com/p/fbug/source/browse/tests/content/examples/exampleNetTest.html
Blocks Firebug, blocks product on resolution.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Assignee: nobody → mrbkap
(In reply to comment #14)
> whether this also broke with bug 457022?  I expect it did...

Not that bug, checked 08-11-13 and 08-11-14 builds, both of which did not reproduce the bug (following str from comment 12). Still looking for a regression range.
That's not a useful range, sadly.  See comment 13.  The testcase as written is just meaningless before bug 471395 is fixed; it throws before we get to the code we're trying to test here.
Which suggests to me that we might need a better testcase, and that the issue is still bug 457022 originally.
honza, is there anything you can do to improve this testcase? Boris, anything you'd like to see in it in particular?
Group: core-security
The only reason to try improving the testcase is if we think there's a relevant regression range to be found.

Frankly, I think what this bug needs at this point is just debugging.
This testcase completes successfully (the date appears in green) prior to the regression range date, so I'm not sure what I'm doing wrong. Granted, I see the errors in the console, however the str in comment 12 are _not_ reproducible until the regression date...
> The testcase as written is just meaningless before bug 471395 is fixed; it 
> throws before we get to the code we're trying to test here.
True. Unfortunately I don't know how to provide better test case that isn't dependent on 471395. The onreadystatechange property must be accessed before the original handler is called.
(In reply to comment #23)
> This testcase completes successfully (the date appears in green) prior to the
> regression range date, so I'm not sure what I'm doing wrong. Granted, I see the
> errors in the console, however the str in comment 12 are _not_ reproducible
> until the regression date...
I am able to reproduce the problem consistently with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
How can I help here?
Honza
(In reply to comment #25)
> I am able to reproduce the problem consistently with: Mozilla/5.0 (Windows; U;
> Windows NT 6.0; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
> How can I help here?
> Honza

I think as Boris suggests in c#22, we just need to get someone who understands this part of the code stepping through the test case in a debugger. Any volunteers? I will totally reward successful patches with coffee and pie (or a beverage and dessert of your choice) at the AllHands.
For what it's worth, I'm trying to get to this bug -- it's on my todo list behind a couple of other things though.
ok Blake. Thanks for the update.
So, I looked into this today, and it's very tricky. The short of it is that |someXHRobject.onreadystatechange| is a double-wrapped JS object (that is, it's an XPCWrappedNative around an XPCWrappedJS). Because of this, calling the event handler through the double wrapped JSObject ends up in XPCWrappedNative::CallMethod. This does a security check to make sure we're allowed to call the method.

Now, because we're calling this through XPCSafeJSObjectWrapper, the subject principal is the web page. This *shouldn't* be a problem because the target object here is from the web page, however, we run into these lines in nsScriptSecurityManager.cpp:
        if (!aCallContext || classInfoData.IsDOMClass())
            securityLevel.level = SCRIPT_SECURITY_SAME_ORIGIN_ACCESS;
        else
            securityLevel.level = SCRIPT_SECURITY_NO_ACCESS;
in this case, we're called from CallMethod, we we have a context, and there is no classinfo, since we're asking if we have access to touch a regular Function. So we set securityLevel.level to be noAccess and throw.

This problem is actually visible from content without any XPCSafeJSObjectWrapper involvement: the testcase:

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){};
alert(xhr.onreadystatechange);

throws:

JavaScript error: http://localhost/~mrbkap/temp.html, line 7: Permission denied for <http://localhost> to create wrapper for object of class UnnamedClass

for the same underlying reason (we're creating the XPCWrappedNative around the Function in that case).

Fixing this for Firefox 3.5 now is scary. jst and I talked about assuming same-origin for double-wrapped objects in the security manager, but that's a *really* scary change.

Boris, any additional thoughts?
>var xhr = new XMLHttpRequest();
>xhr.onreadystatechange = function(){};
>alert(xhr.onreadystatechange);

Did this never work?  Or did we regress it with one of our changes?

Could we give classinfo to double-wrapped functions?
In 3.0.8 the code gives
Permission denied to create wrapper for object of class UnnamedClass
from the alert() call.  I'm not sure what this proves since Firebug spy works in 3.0.8 but not in 3.55.

(attempting to suppress urge to insert comment about the error message...partial failure)
(In reply to comment #30)
> Did this never work?  Or did we regress it with one of our changes?

This appears to have never worked. I tested back to Firefox 1.0.8 before giving up.

> Could we give classinfo to double-wrapped functions?

Yeah, that might work... Alternatively, we could implement nsISecurityCheckedComponent for double-wrapped, non-chrome JS objects and return "sameOrigin" for everything.
(In reply to comment #31)
> I'm not sure what this proves since Firebug spy works
> in 3.0.8 but not in 3.55.

This particular bug is fallout from the wrapper changes. However, fixing it correctly requires understanding of what broke what, exactly. The reason that wrappers broke this is that before, we were running into the "chrome can do anything" codepath and SJOWs prevent that.
Hmm.  nsISecurityCheckedComponent might be simpler to do...
Attached patch patch v1 (obsolete) — Splinter Review
So, this works except for the testcase in comment 29. The comment in the patch in SameOriginCheckeComponent::CanCreateWrapper says why.

What do you think?
Attachment #370765 - Flags: superreview?(jst)
Attachment #370765 - Flags: review?(bzbarsky)
Please use NS_strdup?

> If it isn't a double-wrapped object, then it definitely will
> +    // not have classinfo (and therefore won't be a DOM object). 

That should be "is a double-wrapped object", no?
Or do you mean that our JSObject is not a double-wrapped object?  I really can't tell what the double-wrapped part of this is trying to say.
Attached patch Updated comment (obsolete) — Splinter Review
Boris, does this make more sense?
Attachment #370765 - Attachment is obsolete: true
Attachment #370997 - Flags: superreview?(jst)
Attachment #370997 - Flags: review?(bzbarsky)
Attachment #370765 - Flags: superreview?(jst)
Attachment #370765 - Flags: review?(bzbarsky)
Yeah, that comment is a lot clearer.  Still need NS_strdup.
Attached patch OopsSplinter Review
Sorry, didn't see that in your first comment.
Attachment #370997 - Attachment is obsolete: true
Attachment #371344 - Flags: superreview?(jst)
Attachment #371344 - Flags: review?(bzbarsky)
Attachment #370997 - Flags: superreview?(jst)
Attachment #370997 - Flags: review?(bzbarsky)
Attachment #371344 - Flags: review?(bzbarsky) → review+
Comment on attachment 371344 [details] [diff] [review]
Oops

This is somewhat scary, but let's get it in for beta4...
Attachment #371344 - Flags: superreview?(jst) → superreview+
moz_bug_r_a4, can you poke at this to see if we're opening a gaping hole here?
I applied that patch and tested.  That patch does not fix this bug.  It seems
that CanCallMethod() returning "sameOrigin" does not work due to the same
reason as CanCreateWrapper().

http://mxr.mozilla.org/mozilla-central/source/caps/src/nsScriptSecurityManager.cpp#794
794             case nsIXPCSecurityManager::ACCESS_CALL_METHOD:
795                 checkedComponent->CanCallMethod(objIID,
796                                                 JSValIDToString(cx, aProperty),
797                                                 getter_Copies(objectSecurityLevel));
798             }
799         }
800     }
801     rv = CheckXPCPermissions(aObj, objectSecurityLevel);
Whiteboard: [firebug-p1] → [firebug-p1][firebug can work around, no longer blocks?]
I don't know of any workaround for this problem, other than disabling the Firebug features that trip on it.
(In reply to comment #44)
> I don't know of any workaround for this problem, other than disabling the
> Firebug features that trip on it.

that is the work-around.
Whiteboard: [firebug-p1][firebug can work around, no longer blocks?] → [firebug-p1][firebug can work around, no longer blocks, but would like to have]
But the purpose of disabling the feature is to allow us to find other FF3.5 problems. We need this bug to block 1.9.1.
(In reply to comment #46)
> But the purpose of disabling the feature is to allow us to find other FF3.5
> problems. We need this bug to block 1.9.1.

We're disabling the feature so we can find other bugs in FF3.5, yes. Also this allows us to be not completely broken on FF3.5. Not having a version of Firebug that works on 3.5 is not an option, even if that means disabling a few nice-to-have features like XHR responses in the Console.

This bug's still blocking 1.9.1, it's just not going to block beta 4. There is still a possibility that we won't have a fix for 3.5 final, so we have to keep that in mind and come up with fixes in firebug side if necessary.
Whiteboard: [firebug-p1][firebug can work around, no longer blocks, but would like to have] → [firebug-p1][firebug can work around temporarily, no longer blocks, but need for 1.9.1]
As a web developer, and a user of Firefox and Firebug, not having XHR responses anymore is a critical regression from past versions of Firefox. Fixing this issue is important for us to continue to develop modern JS websites in Firefox.

Developers that use firefox 3.5, firebug, and have the console tab enabled will suddenly have their ajax calls return nothing. No answer, no error message nothing; hopefully most of them will be able to trace it back here, and realize sooner than later that it's not a problem in their code, but a problem in firefox.
we will still have XHR responses in the Net panel.
I was also able to work around this by adding .wrappedJSObject to a couple of places in the example plugin. It wasn't pretty, but it seemed to work. I've lost exactly what I did, but I'll look into it again in a couple of days for you to try out.
thanks Blake. Keep us posted. Hopefully we can come up with something that isn't hideous and doesn't force us to drop features.
So what's our resolution for B4? The goal is to have Firebug be compatible - should we be taking this off the P1 blocker list and asking FB to employ the workaround?
beltzner: My interpretation and hope for what we were going to do to maintain compatibility and still allow b4 to ship was to employ a workaround in Firebug for the time-being. We'd like this to remain on the blocker list for 1.9.1 final.
--> P2 in order to block final release.
Priority: P1 → P2
The weekly summary says for this bug:
— Won’t block on a fix here, Firebug workaround on hand instead of taking this fix. 

What we have is a disabled feature that many users expect and use.
+1 for blocking. I use console XHR daily :(
Attached patch Fix for thatSplinter Review
This builds on top of attachment 371344 [details] [diff] [review] -- it makes caps understand "sameOrigin" from nsISecurityCheckedComponent. See also the comments in nsScriptSecurityManager.h.
Attachment #374960 - Flags: superreview?(bzbarsky)
Attachment #374960 - Flags: review?(jst)
Comment on attachment 374960 [details] [diff] [review]
Fix for that

I'd just do s/subject has greater than or equal privileges to the object/subject subsumes the object/

Other than that, looks good.
Attachment #374960 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 374960 [details] [diff] [review]
Fix for that

- In nsScriptSecurityManager::CheckXPCPermissions():

+            if (!aJSObject)
+            {
+                nsCOMPtr<nsIXPConnectWrappedJS> xpcwrappedjs =
+                    do_QueryInterface(aObj);
+                if (xpcwrappedjs)
+                {
+                    rv = xpcwrappedjs->GetJSObject(&aJSObject);
+                    NS_ENSURE_SUCCESS(rv, rv);
+                }
+            }
+
+            if (!aSubjectPrincipal)
+            {
+                // No subject principal passed in. Compute it.
+                aSubjectPrincipal = GetSubjectPrincipal(cx, &rv);
+                NS_ENSURE_SUCCESS(rv, rv);
+            }
+            if (aSubjectPrincipal)
+            {
+                nsIPrincipal* objectPrincipal = doGetObjectPrincipal(aJSObject);

If aJSObject comes in as null here, and the QI of aObj to nsIXPConnectWrappedJS fails, aJSObject will still be null here. A null check here seems like the right thing to do.

r=jst with that.
Attachment #374960 - Flags: review?(jst) → review+
Attached patch For checkinSplinter Review
Attachment #377057 - Flags: superreview+
Attachment #377057 - Flags: review+
Keywords: checkin-needed
if (!aSubjectPrincipal)

6 lines below:
if (aSubjectPrincipal)

Does this kind of language don't understand the }else{ ?
(In reply to comment #61)
> Does this kind of language don't understand the }else{ ?

            if (!aSubjectPrincipal)
                aSubjectPrincipal = GetSubjectPrincipal(cx, &rv);
            else

is not the same as

            if (!aSubjectPrincipal)
                aSubjectPrincipal = GetSubjectPrincipal(cx, &rv);
            if (aSubjectPrincipal)
ah sorry, didn't see that 'aSubjectPrincipal' could be set in that first if statement.
dev-doc-needed? (it's not clear to me if this introduces a new public [scriptable?] api of some sort...)
http://hg.mozilla.org/mozilla-central/rev/42832a65a579
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Regression: DHTML NoChrome increase 1.07% on Vista Firefox:
http://graphs-new.mozilla.org/graph.html#tests=[{%22machine%22:70,%22test%22:19,%22branch%22:1}]&sel=1242168480,1242341280

Previous results: 740.265 from build 20090513144241 of revision 9c62b2169f76 at 2009-05-13 14:42:00 on qm-pvista-trunk04 run # 0

New results: 748.176 from build 20090513154844 of revision 42832a65a579 at 2009-05-13 15:48:00 on qm-pvista-trunk04 run # 0

Suspected checkin range: from revision 9c62b2169f76 to revision 42832a65a579:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9c62b2169f76&tochange=42832a65a579

.. implicates this checkin.
Blocks: 493074
I filed bug 493074 to track the performance regression. I'll try to get the patch in that bug in today to see if it helps, if not. I'll back the whole thing out.
Blake, since you aren't working on COW now, this one should be your priority.
To be clear, we should be doing whatever we can to find a fix to the perf regression.
attachment 371344 [details] [diff] [review] backed out for mrbkap to see if that's the part that's causing the performance regression.

http://hg.mozilla.org/mozilla-central/rev/ed1f93938bf5
And reopening, to make sure this doesn't get forgotten...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Is this in the whiteboard:

[firebug can work around temporarily, no longer blocks, but need for 1.9.1]

Still true?
We've disable the feature in Firebug to prevent the error message, allowing us to test the rest of Firebug on FF3.5.  We need this bug fixed so we can restore this important feature of Firebug.
Yes, we will fix this before shipping 3.5.
what they said.
Attached patch For 1.9.1.Splinter Review
This is a combination of the fix in this bug and the followup fix in bug 483672, which is what's been on the trunk the longest.
Fix checked in for 1.9.1. Per discussion on irc with shaver and beltzner, we decided to take the small perf hit on the trunk rather than risking taking any new attempts at fixing it there as well.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a1b78429e99d
Keywords: fixed1.9.1
Backed out part relanded, marking fixed again.

http://hg.mozilla.org/mozilla-central/rev/ba3b363f2ba1
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
I have tested this with Firebug using following test case:
http://www.janodvarko.cz/firebug/tests/1586/Issue1586.htm

* It fails with Firefox 3.5pre (Permission denied for  to call method
UnnamedClass.handleEvent, chrome://firebug/content/spy.js (514))
* But passes with Firefox 3.6a1pre

Does that mean that it isn't fixed in 3.5pre, but will be in 3.5?
According to the https://bugzilla.mozilla.org/show_bug.cgi?id=483672#c74

Honza
This should be working with current 1.9.1 nightlies...  (anything after 2009-05-22).  If it's not, please remove the "fixed1.9.1" keyword from this bug?
True, tested with 3.5pre (Gecko/20090526) and works.
Thanks!

Honza
also tested and verified working.
Status: RESOLVED → VERIFIED
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.19?
Flags: wanted1.9.0.x-
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.19?
Flags: blocking1.9.0.19-
I am reopening this one.

The test (from comment #79) 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)

Here is the test:
http://www.janodvarko.cz/firebug/tests/1586/Issue1586.htm
Follow instructions on the page.

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 in comment #0

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

Is this known issue? Should I report a new bug for this?

Honza
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I am marking as blocking since this breaks Firebug 1.6 compatibility with Fx 3.7.
Honza
Severity: normal → blocker
I am setting some other flags to get more attention to this bug. According to Firebug's test harness, this is so far the only problem with Firebug 1.6 + Firefox 3.7a4pre combo.

As mentioned in comment #83 you can use following test page:
http://www.janodvarko.cz/firebug/tests/1586/Issue1586.htm

..to see the problem - and the exception in Firebug tracing console if ERRORS options is checked (note that you need 'X' build of Firebug, can be downloaded here: http://getfirebug.com/releases/firebug/1.6X/)

Tested with:
- Firefox 3.7a4pre, Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4pre) Gecko/20100401 Minefield/3.7a4pre (.NET CLR 3.5.30729)
- Firebug 1.6a8

Could somebody please take a look at this?
I'll provide further info how to reproduce if needed, just ask me.

Thanks!
Honza





Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4pre) Gecko/20100401 Minefield/3.7a4pre (.NET CLR 3.5.30729)
Priority: P2 → P1
Whiteboard: [firebug-p1][firebug can work around temporarily, no longer blocks, but need for 1.9.1] → [firebug-p1][need for 1.9.2]
Version: Trunk → 1.9.2 Branch
(In reply to comment #85)
> I am setting some other flags to get more attention to this bug.

None of the changes you made would be noticed by drivers. If you want attention, you need to use the blocking1.9.x flags, which I have requested for you.
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.1: --- → ?
status1.9.2: --- → ?
status2.0: --- → ?
Please don't abuse the flags by requesting blocking for branches this doesn't even apply to (comment 83). Different people triage the trunk, but the flags really don't mean much until later in the process. if you need it track people down.

(In reply to comment #83)
> I am reopening this one.

I don't think that's particularly helpful in this case. The patches here were checked in and still work for the earlier versions. If the symptoms came back it's probably a different problem (or the same problem in a new place?). Please file a separate bug for the trunk, something like "bug xxxx regressed bug xxxx" if you like.
blocking1.9.1: ? → -
blocking1.9.2: ? → -
blocking2.0: ? → beta1+
I see, I have reported:
https://bugzilla.mozilla.org/show_bug.cgi?id=557791

Daniel, could you please take a look at the new bug and check whether all flags are correctly set so it reaches proper people?

This issue is blocking Firebug 1.6 for Firefox 3.7

I am changing status of this one back to FIXED.

Thanks!
Honza
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.