Closed Bug 411814 Opened 17 years ago Closed 17 years ago

Firebug addon not available/working for Firefox 3

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: chofmann, Assigned: Dolske)

References

(
URL
)

Details

(Whiteboard: [external dependency][gecko/firefox part is done])

Attachments

(3 files, 1 obsolete file)

CrashReporter dump
59.79 KB, text/plain
Details
Firebug misrendering its panels since it was broken
54.90 KB, image/png
Details
test patch 2
4.53 KB, patch
Details | Diff | Splinter Review
Blocks: 364745
There is a working beta of this that works on FF3 (I'm running it), but it took me forever to find it. Version 1.1b10 is available at http://fireclipse.xucia.com/#Downloads Not sure why it's not on addons unless it's because it's "not official" or just because it's still "beta".
Hmm, Joe, are you working on this as well?
Whiteboard: eta:?
I think John Barton is running the Firebug work these days. John, would it be worth making mention of the FF3beta-compatible Firebug beta in the AMO page for Firebug? I know of at least one bug that prevents Firebug from working well on FF3, which I've marked as a dependency here.
Depends on: 391280
Information about firebug versions is available in the FAQ: http://groups.google.com/group/firebug/web/faq-about-firebug That would be a good link for AMO. The 391280 bug means I am not testing firebug 1.2 on FF3.
update: Bug 391280 went away. FF3.0b4 works well for firebug/chromebug. Unfortunately FF3.0b5pre nightly does not work at all with chromebug so I am no longer following the nightly builds. I'll try again in a week.
Can you elaborate on what doesn't work, and what nightly you were using? It'll be easier to fix that way...
Something good happened since last week, I can now run Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre I have 421583 and one unreported problem that I also have on B4: Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: :: line 644" data: no] Source File: chrome://global/content/bindings/browser.xml Line: 650 I also have one new one: Permission denied to create wrapper for object of class UnnamedClass that is all the message says, no filename, no linenumber
I take it back: after a few minutes I hit another on of these errors and cannot proceed. This one I can track down a bit: debugger.onError: uncaught exception: Permission denied to create wrapper for object of class UnnamedClass <top> (0)chrome://global/content/consoleBindings.xml:83-84@83 <bottom> debugger.onError: sees object with typeof: 'object'; object contains: [message]=uncaught exception: Permission denied to create wrapper for object of class UnnamedClass; [fileName]=null; [lineNo]=0; [pos]=0; [flags]=2; [errnum]=147; [exc]=null; So the file and line number are null but I get a stack from onError, if it is correct. (This is still better than last week)
I hate that error, and its locationlessness. Is there a bug on file for its lameness, or could you file for it? Also: when you say "cannot proceed", what do you mean? The browser locks up? Script aborts?
No, sorry, I just can't fix or workaround the problem so I have to go back to b4. More of the UnnamedClass thing: debugger.onError: uncaught exception: Permission denied to create wrapper for object of class UnnamedClass <top> (0)chrome://firebug/content/errors.js:98-233@100 <bottom> debugger.onError: sees object with typeof: 'object'; object contains: [message]=uncaught exception: Permission denied to create wrapper for object of class UnnamedClass; [fileName]=null; [lineNo]=0; [pos]=0; [flags]=2; [errnum]=147; [exc]=null; The function on the stack is at least in firebug, but the line is: var context = FirebugContext; so I don't know what to make of the message. These messages are content free as far as I am concerned.
Attached file CrashReporter dump —
So with Firebug 1.1b12 in my Addons list already, but disabled, things are fine. When I click Enable on it, the click Restart, I get a crash in Firefox after it restarts and displays all the windows. The crash report submitted by Breakpad is almost useless (bp-dd759630-ef07-11dc-b2e2-001a4bd43e5c). Attached is the CrashReporter dump from OS X. The crash only happens on the automatic restart when you click the "Restart" button in the addons dialog (and also on every nightly update restart if Firebug is enabled) for the last week or so (coincidentally also when b4 changed to b5pre in the nightlies, roughly). If you restart Firefox by quitting the app and running it again (or clicking Restart on the Breakpad dialog after the crash) then it starts up fine, with all sessions intact. Not sure if this is quite related, but I figured I'd add it to this bug as a data point.
Depends on: 422137
John: the entry in the console is not the problem, and you haven't said what actually _is_. If you didn't get _anything_ in the error console, how would you know what's wrong? What are you doing when you hit it? Examples: "when I open the Net panel, I get that error, and then I get that every time I try to do anything (inspect, set a breakpoint, filter messages)"; "I get that error when a page is loaded with Firebug active sometimes, and then I can't interact with Firebug for that tab/page/at all". Or: what are the steps you're using to reproduce that bug? Imagine someone posted such a report to the firebug list, and you asked them to report it in the issue tracker with details; what details would you want to see there to know where the problem was? :) The crappy error message is bug 246699, there's a patch that should land today.
Yes, I know that my report is crappy. That's why I put it here rather than opening a separate report. I just don't know what to do to make a better report. Normally I would just say nothing but I know FF is trying to converge on 3.0. I can tell you how to reproduce it, but the first step will be "svn checkout chromebug" so I imagine that is too much to ask. I get the error in several places including chromebug's main window selection menu. I was hoping someone would say "Oh that message, I fixed it yesterday" or "Oh that happens when you do X".
Can you try with the latest Firebug package? If it only happens with chromebug, it's likely not as high a priority (and there are principals involved, so it's possible). Else, can you package up whatever you're running so someone can try to reproduce it? I want to get these bugs fixed if they hurt Firebug, but I don't have the svn setup, and so I'm hoping you'll be able to package it so that we can get to work on it. If it's that hard to package up somewhere, I fear that getting a reliable setup to reproduce it from first principles will be pretty challenging too. :/ Maybe we could track chromebug-only issues separately?
If we had the call stack and line number for the error message or if we knew why this message comes out be having this meta discussion. From my perspective my report has already had the right effect: I know about bug 246699. I'll point to Mosedale's foresight in https://bugzilla.mozilla.org/show_bug.cgi?id=246699#c0: "Most XUL developers are likely to give up before they get to that point." We can track chromebug separate or not at all, but I'd rather not explain that I'm running FF2 to work on chromebug because FF3 is too buggy. I'll see if getfirebug.com will host a chromebug xpi.
getfirebug has versions of chromebug & firebug1.2 http://getfirebug.com/releases
(In reply to comment #16) > getfirebug has versions of chromebug & firebug1.2 > http://getfirebug.com/releases > Great! When do you think it will be added to AMO? Thanks for all the work getting it up to date!
Alex, sorry I was not clear. Firebug 1.1 works with FF3 for the most part. No further dev plans, so if it does not work well with FF3 we have a problem. Firebug 1.2 is the current dev path, I want to have it in late stage beta when FF3 is released. I am pushing on this and chromebug is to challenge FF3 while its still in beta. With luck we will have FF3+Firebug 1.2 in good shape together. But right now the getfirebug.com versions are just for testing FF3. Remember FF3.0a1... I don't know of any plans for adding firebug to AMO. (I have nothing against AMO, it just that releases are up to someone else).
Blocks: 422767
Depends on: 303821
Version: unspecified → Trunk
Depends on: 423890
Just FYI, I opened 422767 for chromebug-only issues to leave this one for firebug-only issues. Since I work on firebug with chromebug its not separate in my mind, but I can see it would be for others.
Depends on: 425139
Depends on: 425499
John J Barton: Mind giving me a rundown on what's still broken here?
I believe the Depends On list is correct. 425139 is a total show stopper. 423890 we can live with, if it is not indicative of other problems. 422167 I am still seeing out-of-memory on XPCSafeJSObjectWrapper.cpp. It is rarer, I used to get one every time I started, now I can't tell you how to reproduce. I need the call stack for that. 303821 is your call. Not on the list is 423796 423947 423949 421593 all of which I believe we can FIXED soon.
Depends on: 427164
Lazylinks:(In reply to comment #21) > I believe the Depends On list is correct. > bug 425139 is a total show stopper. > bug 423890 we can live with, if it is not indicative of other problems. > bug 422167 I am still seeing out-of-memory on XPCSafeJSObjectWrapper.cpp. It is > rarer, I used to get one every time I started, now I can't tell you how to > reproduce. I need the call stack for that. > bug 303821 is your call. > > Not on the list is > bug 423796 bug 423947 bug 423949 bug 421593 > all of which I believe we can FIXED soon. > Linking all bugs for easy referencing.
No longer depends on: 423890
I've added Bug 426131 as a blocker because I need know how to deal with it. If its working as it should then firebug/chromebug will have to be changed.
Depends on: 426131
No longer depends on: 303821, 391280, 425499
Is there something I can to do insure that the remaining FF3 issues that block Firebug are evaluated before FF3 ships? In my opinion Firebug can't run with some resolution on these issues, and FF3 wants Firebug to work, but they are not considered blockers, perhaps because my descriptions are not clear.
Nom'ing for blocking. Fx3 needs Firebug. Could we get a little love (either a fix or a work-around) for 426131 and 427164?
Flags: blocking-firefox3?
That might be the case; for example, it's unlikely that a bug that says it's about the clarity of out-of-memory errors is seen as a real blocker. If you think things should block FF3, please request blocking-1.9?, and make sure that the bug is actually clearly about the problem that keeps it from functioning. Attaching test case pages also helps immensely, since web sites change and have tons of moving parts. (In the "why OOM here?" case, you can break on js_ReportOutOfMemory and look at the native stack for clues; similarly for JS_ReportError and other cases of strange errors.) Of the deps marked on this bug, one is firebug-p3 (bug 426131), one has no firebug prioritization at all and is rated "minor" (bug 427164) and the last is about a lack of warning message detail (bug 422137, in which you say that the lack of error detail is somehow corrupting memory?). The latter was marked as being for a .x release, probably because it's just about the quality of an error message. We need bugs that describe the actual Firebug-blocking problem if they're going to get prioritized high enough to stop the release of FF3 -- we are not going to be holding the FF3 release in order to get more detail into OOM error messages as an example. Polvi: 427164 is us returning the wrong error code, and 426131 is firebug-p3 -- do they really need to be fixed before we can ship Firefox 3?
(In reply to comment #26) > Polvi: 427164 is us returning the wrong error code, and 426131 is firebug-p3 -- > do they really need to be fixed before we can ship Firefox 3? John seems to feel that these issues are blockers for creating a Firefox 3 compatible version of Firebug. John, could you elaborate on shaver's questions and requests?
(In reply to comment #26) > That might be the case; for example, it's unlikely that a bug that says it's > about the clarity of out-of-memory errors is seen as a real blocker. If you > think things should block FF3, please request blocking-1.9?, and make sure that > the bug is actually clearly about the problem that keeps it from functioning. > Attaching test case pages also helps immensely, since web sites change and have > tons of moving parts. Ok I change the title and I'll try to be clearer. > > (In the "why OOM here?" case, you can break on js_ReportOutOfMemory and look at > the native stack for clues; similarly for JS_ReportError and other cases of > strange errors.) > > Of the deps marked on this bug, one is firebug-p3 (bug 426131), one has no Ok I set it to firebug-p1. > firebug prioritization at all and is rated "minor" (bug 427164) and the last I set 427164 to firebug-p1, but the minor was some else's setting. is > about a lack of warning message detail (bug 422137, in which you say that the > lack of error detail is somehow corrupting memory?). The latter was marked as > being for a .x release, probably because it's just about the quality of an > error message. We need bugs that describe the actual Firebug-blocking problem > if they're going to get prioritized high enough to stop the release of FF3 -- > we are not going to be holding the FF3 release in order to get more detail into > OOM error messages as an example. I'd settle for the messages to stop ;-) > > Polvi: 427164 is us returning the wrong error code, and 426131 is firebug-p3 -- > do they really need to be fixed before we can ship Firefox 3? > Someone else changed 427164; without a usable jsdIScript firebug isn't helpful. My mistake on 426131 since at first I only thought it would prevent the viewing of one property. But I get the same message in other places.
I took 427164 off, because I believe it is a symptom not a cause.
No longer depends on: 425139, 427164
Assignee: joe → dolske
Flags: blocking-firefox3? → blocking-firefox3+
Whiteboard: eta:? → [external dependency]
Sometime between 4/15 and 4/18 FF3pre + Firebug 1.2 began to fail. I've tracked it down to browser2.loadURI(panelURL); where const panelURL = "chrome://firebug/content/panel.html";
What is "browser2"? A <browser> with type content, chrome, or content-primary? I'd sort of suspect bug 292789, but the regression range is wrong. To be hyper-clear: you're saying that with a given FB1.2 (which version? 1.2a19X?) loading some panel worked with the 4/15 nightly, but didn't work with the 4/18 nightly? I'll set up with the right version of FB and walk the nightlies after dinner, if you can help me out with confirmation of the versions involved, and some idiot-proof steps to reproduce. :)
Looks like it broke between the 041707 and 041807 nightlies. Checkins: http://tinyurl.com/5m4xcl browser2 is a <xul:browser anonid="browser" xbl:inherits="tooltip=paneltooltip,contextmenu=panelcontextmenu"/> inside a panelBar from bindings.xml, with id "fbPanelBar2". Need a debug build to figure out why loadURI is failing, I guess. Mine's building while I go to eat.
(In reply to comment #32) > Looks like it broke between the 041707 and 041807 nightlies. ... So I gather you don't need help reproducing this. Anyway based on the firebug newsgroup and the way it fails, all versions of Firebug should fail.
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1208508000&maxdate=1208514959 is the hourly-based regression range. I'm going to suspect smaug's patch here. smaug: what do you think? We're trying to load a chrome doc in a xul:browser, from the load event of another browser, and instead of getting the right content rendered in the browser, we get the HTML source or something? I'll upload someone's screenshot in a sec, but John may have more details. (My laptop is being very crashy right now, so I've been using a helpful volunteer.)
I want to fall asleep in my bed, and not at my desk, so I'm going to retire for the evening, but there will be builds with smaug's patch backed out for testing at https://build.mozilla.org/tryserver-builds/2008-04-19_19:25-shaver@mozilla.com-425814-backout/ . Mac's up now, win in another 90 mins or so. Reports about that build working or not would be much appreciated; I fear I'm going to have to reinstall my laptop or something :/
(In reply to comment #34) > http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1208508000&maxdate=1208514959 > is the hourly-based regression range. I'm going to suspect smaug's patch here. > > smaug: what do you think? We're trying to load a chrome doc in a xul:browser, > from the load event of another browser, and instead of getting the right > content rendered in the browser, we get the HTML source or something? we get about:blank in the browser's document
Hrm, wonder what's causing the behaviour in my attachment, then...
(In reply to comment #38) > Hrm, wonder what's causing the behaviour in my attachment, then... Firebug is looking for elements in the document. When they don't exist it stops initializing. It could fall over more gracefully. In fact I think this particular page may not be used in 1.2, its just loaded because of 1.0 logic but never shown in 1.2 because of the new activation. Is this loadURI thing not used much by others? The only other place Firebug uses is it in some workaround with a comment like: // We need to cancel this load and try again after a delay... this is used // mainly to prevent chaos while when the debugger is active when a page // is unloaded
(In reply to comment #39) > (In reply to comment #38) > > Hrm, wonder what's causing the behaviour in my attachment, then... > > Firebug is looking for elements in the document. When they don't exist it stops > initializing. It could fall over more gracefully. In fact I think this > particular page may not be used in 1.2... The body contents are not used, but the style sheet defines Firebug's UI panel, which explains why you see firebug-like content but without icons and everything shows rather than being hidden by CSS.
(In reply to comment #36) > the evening, but there will be builds with smaug's patch backed out for testing > at > https://build.mozilla.org/tryserver-builds/2008-04-19_19:25-shaver@mozilla.com-425814-backout/ The build from that URL, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041919 Minefield/3.0pre, Does NOT show the problem, the Firebug UI comes up fine.
Well, I guess that explains the console spewage I was getting yesterday: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file content/base/src/nsImageLoadingContent.cpp, line 486 I got as far as tracking it down to a Firebug requesting a load of "blank.gif" from a base uri of "about:blank", but hadn't noticed the rest was broken. :/
I found a possible workaround for Firebug 1.2 that seems to work on the latest nightly: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041907 Minefield/3.0pre Rather than load the HTML dynamically, I set src= on the browser element in the overlay.
What causes Firebug to call .loadURI? I guess it is done before 'DOMContentLoaded' (and before 'load') event.
But I think I have the fix. Will upload a patch to tryserver soon.
Attached patch test patch (obsolete) — — Splinter Review
I uploaded this patch to try server "frameloader_init" builds should become available soon https://build.mozilla.org/tryserver-builds/?C=M;O=D
(In reply to comment #47) > https://build.mozilla.org/tryserver-builds/2008-04-20_03:55-opettay@mozilla.com-frameloader_init/ > Anyone willing to try? Sorry that version, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042004 Minefield/3.0pre fails to load in my dev version with the workaround removed. Any version of firebug should show this problem, including: http://getfirebug.com/releases/firebug/1.2/firebug-1.2.0a20X.xpi I believe Firebug will be better off without loadURI so I am going to move the svn version to the workaround.
(In reply to comment #44) > What causes Firebug to call .loadURI? I guess it is done before > 'DOMContentLoaded' > (and before 'load') event. > .loadURI() is called twice, once from an XBL initializer (ctor) and once from the 'load' handler for the browser in the first use. The first call is actually delayed in a count-down loop with a comment from Joe Hewitt: // Wait until all panelBar bindings are ready before initializing if (--waitingPanelBarCount == 0) this.initialize(); where panelBar is the XBL object above. So: 1) browser.xul loads 2) bindings.xml loads processing XBL 3) some mystery countdown loop starts with waitingPanelBarCount = 2 4) this.initialize() finally triggers 5) addEventListener("load") set on browser1 inside of panelBar 6) loadURI() is called on a browser1 inside of panelBar 7) onload handler fires, loadURI() called on browser2 inside of panelBar. I believe that browser2 succeeds, but browser1 fails.
ah, hrm, browser.loadURI doesn't use frameloader's loadURI, but webnavigation::loadURI. I guess that is causing the trouble. Debugging...
Attached patch test patch 2 — — Splinter Review
This fixes the problem for me. TryServer builds coming https://build.mozilla.org/tryserver-builds/?C=M;O=D (They will be called XXX-frameloader_init2) The fix isn't perfect but perhaps enough for most common cases. There are too many ways to start dochshell load.
Attachment #316680 - Attachment is obsolete: true
No longer blocks: 425814
I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre and I'm not seeing any of the issues I marked as blockers so I took them off. Assuming nothing else breaks, I think we will be able to release Firebug 1.2b1 as soon as FF3 RC1 lands. At that time we can set this to FIXED
No longer depends on: 422137, 426131, 430050
If those bugs are fixed, let's mark them fixed. :) I am overjoyed to hear this. It'd be great to get some unit tests into the tree to cover the stuff you care about. Maybe you could help us get some of those up after we get clear of FF3 and FB1.2?
Indeed, instead of removing dependencies, we should be marking things fixed, if they're fixed. Or are you removing dependencies on things that are still platform issues, but simply no longer effect Firebug because of evolutions in firebug code?
> I think we will be able to release Firebug 1.2b1 as soon as FF3 RC1 lands Andrea and many others are going to be excited to hear this news! http://www.youtube.com/watch?v=eiA91JnRAWY
(In reply to comment #54) > Indeed, instead of removing dependencies, we should be marking things fixed, if > they're fixed. Or are you removing dependencies on things that are still > platform issues, but simply no longer effect Firebug because of evolutions in > firebug code? Hmm... I guess I don't quite understand the process here. It seems to me that marking the bugs FIXED is up to someone working on the bugs. 422137 has been marked FIXED. 427164 depends on 422137 so it could be resolved, but anyway I don't see it now. The third one was History.previous I think, it got marked INVALID. Next time I'll leave them alone.
(In reply to comment #53) > It'd be great to get some unit tests into the tree to cover the stuff you care > about. Maybe you could help us get some of those up after we get clear of FF3 > and FB1.2? > Firebug needs a test solution so we'll look into that after 1.2.
John, is this bug considered FIXED, then?
Whiteboard: [external dependency] → [external dependency][fixed?]
Whiteboard: [external dependency][fixed?] → [external dependency][fixed?][ETA 4/30?]
(In reply to comment #58) > John, is this bug considered FIXED, then? > Since the complaint include "available" as well as "working" I'd like to have a version that users can try before I say "FIXED". I have one issue from our 1.2 performance goals to complete before we are ready for Firebug 1.2 b1. Or we can change the title to "Ensure adequate platform support in FF3 for Firebug addon". That bit is fixed, thanks!
Nope, let's FIXED this when there's a version on AMO that people with FF3 can install.
Whiteboard: [external dependency][fixed?][ETA 4/30?] → [gecko/firefox part is done]
Whiteboard: [gecko/firefox part is done] → [gecko/firefox part is done][external dependency]
Whiteboard: [gecko/firefox part is done][external dependency] → [external dependency][gecko/firefox part is done]
john -- and updates or ETA on when we should expect something on AMO?
(we're in the middle of an email discussion on that topic right now :)
Update: We've hit one problem revealed in Firebug 1.2 testing: we can't get content that Firefox has downloaded (js, xhr, etc). Otherwise we are cleaning up and preparing for 1.2b1 when FF3RC1 hits. As Justin says, the AMO part is still unclear.
(In reply to comment #63) > Update: We've hit one problem revealed in Firebug 1.2 testing: we can't get > content that Firefox has downloaded (js, xhr, etc). Otherwise we are cleaning > up and preparing for 1.2b1 when FF3RC1 hits. If that's a Firefox bug, please make sure that a bug is filed and nominated for blocking ASAP.
(In reply to comment #64) > (In reply to comment #63) > > Update: We've hit one problem revealed in Firebug 1.2 testing: we can't get > > content that Firefox has downloaded (js, xhr, etc). Otherwise we are cleaning > > up and preparing for 1.2b1 when FF3RC1 hits. > > If that's a Firefox bug, please make sure that a bug is filed and nominated for > blocking ASAP. I think that's bug 430155.
(In reply to comment #64) I am inserting Jan 'Honza' Odvarko's excellent analysis of this issue, our conclusion based on his prototype is to ship #3 with Firebug 1.2b for FF3.0 and lobby for #2 as soon as practical. Therefore this does not need to block. ----- I have found three ways how to capture all response bodies and implement internal Firebug cache, which I believe is the way how to solve the double-load. #1) We can implement a new HTTP protocol handler and replace the existing one. I have made a prototype and it works. I am able to intercept all incoming data, however the implementation is quite heavy weight. A lot of interfaces has to be implemented and the entire XPCOM component I have did took about 400-500 lines of source code (!) There is even one unfrozen interface implemented. Only to register nsIStreamListner for each nsIHttpRequest. #2) There is a patch (waiting for review process) that would solve the problem with registering the nsIStreamListener. See bug: 430155. Jan Wrobel is proposing nsITraceableHttpChannel interface, that could be used to register the nsIStreamListener easily - when the http-on-examine-response event is reaised. If the patch could be reviewed and committed in reasonable time frame (I examined the patch, it's quite simple), it would be definitely the best solution. The implementation would be quite straightforward and bunch of extension developers would be happy as this is the logical and simple way how to observe response bodies. #3) The last possibility that I have found, is to implement a nsIStreamListenerTee listener and replace @mozilla.org/network/stream-listener-tee;1 component. This component listens to incoming data and stores it into the cache. However it's not used if memory cache is disabled (even if it's probably not that often). The *question* is if there are other cases where the "tee" component isn't used. Does anybody have an idea? Justin? This is crucial information for this solution. This would be much simpler than #1, but I don't like the way where some existing XPCOM components are replaced. Or do you thing that it's standard for FF extensions?
Depends on: 433711
We've hit a snag in using path #3 from comment 61, see bug 433711
(In reply to comment #66) Well it looks like we are back to path #1, as the other two did not pan out. Honza, can you commit that code and let's see if we can get it to work. > > #1) We can implement a new HTTP protocol handler and replace the existing > one. I have made a prototype and it works. I am able to intercept all > incoming data, however the implementation is quite heavy weight. A lot of > interfaces has to be implemented and the entire XPCOM component I have did > took about 400-500 lines of source code (!) There is even one unfrozen > interface implemented. Only to register nsIStreamListner for each > nsIHttpRequest. I guess you mean register nsIStreamListener for each nsIHttpChannel.
Another option to consider: XHR use responseText .js use onScriptCreated All others: don't show unless the user asks, then re-request (ie double load).
Depends on: 433977
Ok, we gave up on trying to get the source of content shown by Firefox for Firebug 1.2. We'll go back to the 1.1 level, source for XHR from responseText and everything else will be double loads.
No longer depends on: 433711
No longer depends on: 433977
Firebug 1.2.0a30X is the last alpha. Our current plan is to start Firebug 1.2 beta Monday May 19.
John, where I can download this version? I recognized an issue today with a Firebug 1.2 (somewhat) version I have installed on my Windows XP system. In conjunction with Session Restore and the Master Password Dialog on start-up Firefox consumes all cpu load and allocates around 600MB memory for two opened tabs. After I enter the MP the RAM usage goes down to normal. I'ld like to see if this issue can be also seen with the latest available version. So it would be nice if you could give me the download link. Further I could mail you the broken profile with test data. Sadly its a bit to large to add it as attachment.
The latest release of firebug are available here: http://getfirebug.com/releases
Thanks John. It looks like that the bug doesn't exist anymore with the latest alpha release of Firebug 1.2. There is no high cpu load and memory consumption anymore. If you are still interested in the broken profile you can send me a mail and I can prepare it for you.
Hello again John -- how has the beta been going? Getting close to an update on AMO?
We're just about to put out b2. It will be better but the b2-b1 delta means we will probably need another round before moving into bug fixes only. I don't know about AMO. Justin?
I have access to update Firebug on AMO. Once FB 1.2 is deemed ready for release, I'll push that version.
What do you think about the idea of putting up a FB 1.2 version on AMO and labling it as only compatible with 3.0. That way we would get a good population of the 2 million RC testers using it to help shake out any remaining bugs. If all goes well with this testing, and some backward testing with Fx2.x, compatibility could be extended back to 2.0. Is it possible to do something like that with AMO?
https://bugzilla.mozilla.org/show_bug.cgi?id=411809#c20 makes it sounds like the suggestion in comment 78 might be possible. But I guess, side effects that will mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=411809#c22 should be considered. fligtar and wil. any ideas on how we could expose firebug to mostly only firefox 3 RC1/2 users that are out there wanting to update to the beta version of Firebug?
Basil and I discussed that option earlier... The problem, which I think is a dealbreaker, is that FF2 users would be shown a page with the install button disabled (because the extension is only marked for newer Firefox releases), and they would have to login and trudge through the "older versions" list. This problem will be moot if we can decide that Firebug 1.2 Beta 2 is good enough, and just release it. :)
They can go to getfirebug.com/releases, and we could point them there from the developer comments or whatever. People using 1.0.5 are generally told to use FF3 and 1.2b2 if they have any problems at all, so I'd be comfortable flipping that switch for now.
(In reply to comment #79) >... any ideas on how we could expose firebug to mostly only > firefox 3 RC1/2 users that are out there wanting to update to the beta version > of Firebug? If AMO sent out a package called "Firebug 1.2" with min version 3 it would not affect FF2 users of 1.05.
I expect Firebug 1.2b3 to be out in a few days. We should be looking at Firebug 1.2 on FF2 soon thereafter.
Hey John, how's it looking? When should we see a final release of a compatible version of Firebug?
Version 1.2b3 fixed a number of major bugs. We are working on two issues, static scripts without javascript debugging and enable-always, that affect strings. Then we will ask for localization contributions. A third issue, profiling, is the only 1.0 capability that needs to be fixed up to allow updates for those users. And we still need to fix 1.2 for FF2. I'd guess the en-US version will be complete at b4 next week some time.
I have an issue with the tabfill not working in console. But to test this I'd like to get the latest Firebug. Where can I get it bewsides www.getfirebug.com which has been down for a very long time now?
hey -- since most Fx3 developers are already using the beta versions, can we just prepare what we have for AMO? From the feedback I have heard, the existing bugs are not bad enough to block us from shipping Firebug for Firefox 3.
Ok, I've pushed version 1.2 Beta 3 to AMO. [Note that this may take a few hours to work its way through our caches.] There will likely be a Beta 4 released soon, and a final version sometime after that, but there are currently no known major issues. The availability of Beta 3 means this bug can now be closed. [Also note that Firebug 1.2 isn't yet ready for Firefox *2*, so FF2 users will need to continue to use Firebug 1.05.]
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
OS: Windows XP → All
Hardware: PC → All
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: