Closed Bug 366509 Opened 18 years ago Closed 16 years ago

[SessionStore] "Component is not available" in sss_saveState :: line 1688

Categories

(Firefox :: Session Restore, defect, P3)

Product:
Firefox
Component:
Session Restore
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dietrich, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: dataloss, helpwanted, Whiteboard: [fix: update to Firefox 3.5][known to happen with Firebug under Firefox 3.0])

Attachments

(5 files)

sessionstore.js to reproduce the error discussed here
61.62 KB, text/plain
Details
very simple sessionstore.js file that demonstrates the problem
499 bytes, text/plain
Details
minimal sessionstore.js
102 bytes, text/plain
Details
fix?
1.31 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
Another sessionstore.js
2.79 KB, application/x-javascript
Details 
from shaver:

my firefox2 is full of:
[Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: file:///Applications/Firefox2.app/Contents/MacOS/components/nsSessionStore.js :: sss_saveState :: line 1688" data: no]
nsSessionStore.js (line 1688)
this does not cause any functionality loss, as far as we can tell. session is properly saved and restored. session was set to always resume.

http://lxr.mozilla.org/mozilla1.8/source/browser/components/sessionstore/src/nsSessionStore.js#1687
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
I have Firefox 2.0.0.11 on Linux and these errors appear very often.
With previous version (2.0.0.9 or 2.0.0.10) these errors didn't appear.

This bug can be some regression. Can anybody look for a reason of this bug?
Flags: blocking1.8.1.12?
Flags: blocking-firefox3?
I don't see this on trunk, clearing nom unless there's someone seeing this on trunk.
Flags: blocking-firefox3?
Priority: -- → P3
Target Milestone: --- → Firefox 3 M11
Does this have any negative consequences besides spamming the Error Console? If yes, please provide steps to reproduce - otherwise this is mostly a polish issue which is unfortunate but won't block any release.

Besides: I've seen this occasionally on Windows as well, haven't however been able to figure out what kind of component this error refers to (the line referred is a pure JS statement with no XPCOM involved at all). Could probably use some help of a JS-core guru...
Flags: blocking1.8.1.12?
Keywords: helpwanted
OS: Mac OS X → All
Hardware: PC → All
I have this bug, and when FF crashed, the session that was restored was old
I can confirm comment 11: my sessionstore.js is not updated after this starts to appear, which means that new tabs and windows are not restored.  The message also appears every time I switch tabs, which is when sessionstore.js would be updated with the currently-selected tab.  This hasn't caused any critical dataloss yet, but it's certainly annoying when it does happen.

I can't duplicate the problem consciously, but it occurs at least once a week during regular use; if I happen to see the console messages I switch to Tab Mix Plus's session manager (which successfully saves the session) and restart the browser, then switch back to Firefox's session manager, which starts to function again.  (Simply disabling and re-enabling Firefox's session manager doesn't work; the same messages appear in the console window when it's re-enabled, and sessionstore.js is not updated.)  It doesn't appear to be related to the amount of time the browser has been running or how much I've used it: I can have Firefox open for two weeks with no problem, and then have it appear after 3 hours of relative inactivity the next time I restart.
Does anybody of the people observing this issue use Firebug? If so, please try disabling/uninstalling Firebug for the time being and see whether the problem persists.
(In reply to comment #14)
> Does anybody of the people observing this issue use Firebug? If so, please try
> disabling/uninstalling Firebug for the time being and see whether the problem
> persists.
> 

I'm testing Firebug disabled.
I had roughly 10-14 days whereby this bug was a pain. Not just error messages
spamming console - after hundreds of exceptions in each tab (for many tabs) the
browser would fall over, repeatedly - and remain unstable after restart.
Sporadic but persistant issue with no common (or easy to identify cause). After
lots of preying problem has not re-appeared since. Another user reported bug
was only showing with restored sessions - and my feelings are that it probably
was the case. My plugins at time of bug were : Firebug, Flashblock, GoogleGears
and YSlow. I still use these plugins - but the problems (for me) have
mysteriously gone. For me it was all ok before GoogleGears (and problems came
after that), and I am not sure if GoogleGears updated itself (sorry very busy)
- and the problem went away - I am not sure.
Seems like all of us use FireBug. That would make it the likely cause. As to testing, that is, as stated, hard to do, as the bug only appears sporadically.
I can confirm that I have Firebug installed (and YSlow, Flashblock and Live HTTP Headers).

I still see this issue sporadically and I need to restart Firefox when it happens.  Will try to uninstall Firebug for a while.

I receive this on every page load when I restore the previous session after a crash. (Which happens at least twice a day on my ubuntu edgy)
I too have firebug installed, but it still happens with firebug disabled.
I'm running Firefox 2.0.13 freshly installed, and with Firebug enabled or disabled (not uninstalled, I use it all the time for my work and can't imagine living without it!) I'm getting this error:

Error: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///usr/local/firefox-2.0/components/nsSessionStore.js :: sss_saveState :: line 1753"  data: no]
Source File: file:///usr/local/firefox-2.0/components/nsSessionStore.js
Line: 1753

Basically, it's not crashing any more, but it's throwing a ton of errors as I'm working on Javascript on a page.  If I get a chance to uninstall Firebug I will but as said, too necessary for work.
Addendum: Didn't show in Firefox 2.0.10 on Fedora Core 2, showed in FF 2.0.11 and caused crashes until FF 2.0.13.  Firebug is installed but disabling makes no difference.
Depends on: 429414
I see this error today in my console using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042104 Minefield/3.0pre. This profile does not have Firebug installed.
I get this consistently ever since FF upgraded to v2.0.0.14 (running on Windows Server 2003 sp2).  It did not happen with prior versions of FF.

If I disable Firebug, it doesn't happen.
If I disable or remove all other add-ons and extensions but leave Firebug active, it happens.


5/20/08: I installed the latest version of Firebug, and the problem disappeared.
(In reply to comment #24)
> 5/20/08: I installed the latest version of Firebug, and the problem
> disappeared.
> 

Which version is that? I have 1.1.0b12 and I'm still receiving these error messages.
I've got 0.4.1
(In reply to comment #26)
> I've got 0.4.1
> 

Are we talking about the same thing?
When I click on the "Tools" menu and select "Add-ons" it says "Firebug 0.4.1".
(In reply to comment #28)
> When I click on the "Tools" menu and select "Add-ons" it says "Firebug 0.4.1".
> 

That must be an ancient version. Where did you get it from?

See http://www.getfirebug.com/releases/index.html
(In reply to comment #29)
> (In reply to comment #28)
> > When I click on the "Tools" menu and select "Add-ons" it says "Firebug 0.4.1".
> > 
> 
> That must be an ancient version. Where did you get it from?
> 
> See http://www.getfirebug.com/releases/index.html
> 
I installed v1.05 and the bug returned.  I then installed v1.2 beta, and it still happens.

This error is now present in Firefox 3 with the release of Firebug 1.2.0b2 (or maybe it was b1). I don't remember noticing it in previous releases.

Would like to have nominated this as wanted‑firefox3 or at least wanted‑firefox3.1, but that doesn't appear to be possible at this time. (?)
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

This does happen in Firefox 3 RC2 with Firebug 1.2 beta 1 through beta 3.  This is actually a dataloss issue.  Every time I start Firefox 3, the error appears consistently on the console, and the sessionstore.js file does not get written at all (its last modified timestamp does not change).

If during this time Firefox crashes (or there is a power outage), when Firefox starts again, it resumes with the same windows and tabs as were opened the last time I had opened Firefox, which causes me to lose any work that I had done during the past session.

If, however, I activate the "Show my windows and tabs from the last time" option and close the browser, the sessionstore.js file gets updated, and next time Firefox starts, the session is correctly resumed.  If during this session the browser crashes, next time the session store does not prompt the user if he wishes to resume, and just resumes (as if the browser was shut down using File -> Quit) the old session.

I see this consistently, and everyday.  I think this is worth blocking 3.0.1, so I'm marking it as such.
Flags: blocking1.9.0.1?
Keywords: dataloss
Target Milestone: Firefox 3 beta3 → ---
Version: 2.0 Branch → Trunk
For what its worth, Firebug does not use sessionstore.

John.
Someone posted about the same exact problem in my thread for Session Manager.  His list of extensions does not include Firebug and he said the problem went away when he disabled "Tree Style Tab 0.6.2008050601".  He said the problem started after upgrading to FF3.

See http://forums.mozillazine.org/viewtopic.php?p=3406829#3406829

I could not reproduce the problem with "Tree Style Tab 0.6.2008050601" installed.  My guess is that there is a combination of extensions causing the problem.  It wouldn't be the first time different combinations of extensions caused mysterious problems.  Usually it's triggered by calling components when the browser is starting up.
I get the same problem with << location: "JS frame :: [..]/Minefield/components/nsSessionStore.js :: sss_saveState :: line 1896" data: no >> in 2008061803, FireBug enabled.
Similar with FF3.0 release:

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.host]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox%203/components/nsSessionStore.js :: sss_saveState :: line 1896"  data: no]
Source File: XPCSafeJSObjectWrapper.cpp
Line: 445

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
I can't block the branch on this if the best we know about it is "caused by some extensions, some of the time", though comment 34 seems informative. John, maybe there's a race condition in Firebug?

Eshan: does this only happen with Firebug, even final release, on a new profile?

Please renominate if/when more information comes up.
Flags: blocking1.9.0.1? → blocking1.9.0.1-
(In reply to comment #37)
> Eshan: does this only happen with Firebug, even final release, on a new
> profile?

I have only seen this on "real-world" profiles (ones which have a number of extensions installed) and they all included Firebug.  It does happen on final release, however, not on a clean profile.  I will try to watch my error consoles and wait for this to happen again, and I'll give a shot at debugging it using Venkman.  I'll update here with more information as soon as I do that.
(In reply to comment #37)
> I can't block the branch on this if the best we know about it is "caused by
> some extensions, some of the time", though comment 34 seems informative. John,
> maybe there's a race condition in Firebug?

Does this always occur on startup (not later)? 

I almost always run with browser.sessionstore.resume_from_crash false, so we need to take know of these values, maybe they affect the variability. 

I do think there is a race condition, but not in Firebug. My bet would on the code to accelerate Firefox start up time, which extension loading is shifting around. That is why Firebug comes up often but not always: its is a common large extension.  This also explains why it can't be reproduced and needs "real-world". 

I doubt you will learn anything from Venkman, I run with Firebug set to dump all the info in exceptions, not much in this case. If I'm right a better bet would be windbg to trap during the startup phase. 


I can't get Venkman to load nsSessionStore.js.  Does anyone know how I can set a breakpoint in that file in Venkman?
John J. Barton: I have browser.sessionstore.resume_from_crash set to "true". And yes, the error always occurs on startup, not later.

Is it possible to produce a modified (debug) version of nsSessionStore.js that dumps additional data somewhere? Since I can reproduce the bug easily on my profile, I'd be able to help.
If the error always occurs at startup the problem is probably caused by an add-on calling one of nsSessionStore's API's before the nsSessionStore component has been initialized.

In the case of this bug, the line that throws the exception is:

  this._writeFile(this._sessionFile, oState.toSource());


this._sessionFile is undefined until it is set in the init() function in nsSessionStore.  So if the _writeFile() function is called before the init() function is called, an excepetion will be thrown because _writeFile() would be trying to open a stream to "undefined".

nsSessionStore is initialized by the call to it's init() function in the delayedStartup() function in browser.js.  I have found that extension's who listen for the "load" event can run before the delayedStartup() function and therefore run before nsSessionStore is initialized.  This should only be a one time occurrence at startup though and shouldn't cause any problem (other than the exception in the error console).  I got around that in my own extension by manually calling nsSessionStore's init function to initialize it before I use it.

If the exception is popping up at other times (not on browser startup), that means that the nsSessionStore function never initialized.  This will occur if the nsSessionStore component is disabled by setting the "browser.sessionstore.enabled" preference to false.

For both cases, it might make sense to check if nsSessionStore has been initialized when any of it's API calls are made and either initialize itself then (if sessionstore is enabled) or ignore the API call (or throw it's own exception).  Overall there should probably be exception handling code added to nsSessionStore.  See bug 345898 for another example of this.

Also bug 356432 is a dupe of this bug (or vice-versa).

to Michael Kraft:

Thanks for the detailed explanation!
However, there are similar bugs (bug 427193, bug 428283) that point to the same line in nsSessionStore.js but with a different error:

too much recursion: this._writeFile(this._sessionFile,
oState.toSource());

Unlike the error we're discussing here, this kind of error (too much recursion) freezes firefox for 3-7 seconds. Do you have any ideas why this may happen? Both errors often appear simultaneously (at least for me). Can this be caused by extensions, too, or is it a separate problem? Even if the "Component is not available" error can be safely ignored, this one ("too much recursion") cannot because it freezes the browser. Do you have any ideas?
3-7 seconds? You're lucky! Mine freezes for at least a minute.
When I get this error, it's either only during startup, or persisting throughout the whole session (but more often the latter is the case).  So, I've modified my nsSessionStore.js file to include a simple check at the beginning of sss_saveState, like below:

    // XXXehsan: ignore premature calls
    if (!("_sessionFile" in this) ||
        !this._sessionFile)
      return;

I'll run with this modified version for a while and will watch sessionstore.js in my profile to make sure it's being updated during the session for a while, and will let you guys know what comes up.
(In reply to comment #44)
> Thanks for the detailed explanation!
> However, there are similar bugs (bug 427193, bug 428283) that point to the same
> line in nsSessionStore.js but with a different error:
> 
> too much recursion: this._writeFile(this._sessionFile,
> oState.toSource());
> 

That sounds like a different problem (which is probably why it's under a different bug).  Firefox 3.0 has functionality to check for for recursion (a function calling itself) too many time which is usually the sign of an infinite loop.  The only function on that line is the .toSource() function which shouldn't trigger an infinite recursion. Firebug must be doing something weird for that to happen.

As for why it takes 3-7 seconds for the "too much recursion" error to come up.  That partially my fault for filing bug 420869.  :)
Actually check that about Firebug, looking at the attachment from comment #17 in bug 427193 it looks like somehow the _closedtab data got corrupted.  I'm assuming the data was bad before the errors occurred since otherwise the sessionstore.js file wouldn't be written.  I'm guessing the toSource() javascript function doesn't like when data gets bad.  Why the session data would be bad though I have no idea.

In any case that's a different bug.
(In reply to comment #42)
> nsSessionStore.  So if the _writeFile() function is called before the init()
> function is called, an excepetion will be thrown because _writeFile() would be
> trying to open a stream to "undefined".

Who calls _writeFile() then?  Is it possible that the 'autosave' operation is being triggered by an extension indirectly, without an explicit intent to do so?
I think I have a reproducible test case now.

I copied my sessionstore.js file (see attachment) and tried to reproduce an error on a fresh clean installation of FF3 + Firebug 1.2b3. I am still not sure if Firebug causes these errors, but running w/o Firebug didn't invoke an error.

Steps to reproduce:
1. Do a fresh installation of FF3
2. Set "Show my windows and tabs from last time" under Tools/Options/Main/Startup
3. Install Firebug 1.2b3 from https://addons.mozilla.org/firefox/addon/1843 and restart Firefox as prompted by the installation process
4. Close Firefox after it gets restarted
5. Replace the sessionstore.js in your profile with my copy (attached)
6. Start Firefox again. Your first 3 tabs are guaranteed to be the built-in browser error pages, since they reference a local site available only on my local machine.
7. Switch between these first 3 tabs several times (7-8 switches should be enough).
8. Open Error Console and enjoy the errors.

When testing on a clean install + firebug 1.2b3, I am able to reproduce only this:

Error: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox%20TEST2/components/nsSessionStore.js :: sss_saveState :: line 1896"  data: no]
Source File: file:///C:/Program%20Files/Mozilla%20Firefox%20TEST2/components/nsSessionStore.js
Line: 1896

When testing on my "real" browser profile, with more extensions installed, I also got a plenty of "too much recursion" errors (mentioned in my comment 44) each time I switched to those 3 tabs with error pages, which also freezed the browser for more than 10 seconds.

Note to Ehsan Akhgari: the fix for nsSessionStore.js you proposed does not work, as I got the same errors with your fix applied.
Attachment #327051 - Attachment mime type: text/x-c++ → text/plain
First off ignore my last comment about the sessionstore.js file being corrupt.  The editor I was using couldn't handle the line lengths that were used and displayed garbage.  notepad.exe displayed it fine.


Second I managed to recreate the "Component is not available" without any extensions installed in a fresh profile by analyzing the previously attached sessionstore.js file and determining that the problem occurs when there is one valid and one invalid page "loaded" in the browser. In this case this._sessionFile is fine so that's not the problem in this case.  Apparently there is bad data in the oState.window[0].tab[0] object that causes toSource() function to croak.  I created a extremely simplistic (499 bytes) sessionstore.js that demonstrates this problem with no add-ons installed.


I also managed to recreate the "too much recursion" problem with the following both of the following two combination of extensions: 
Firebug 1.2b3 and GreaseMonkey 0.8.20080609.0
and AI Roboform Toolbar 6.9.90 and GreaseMonkey 0.8.20080609.0

I'll report my findings of that in bug 427193.

I think there is an issue with the toSource() function since I don't think "Component is not available" is a valid exception no matter what you give it, but it's definitely being triggered by data give to it by SessionStore.
Steps to reproduce:

1. Create a new profile
2. Load it and change settings to load windows/tabs from last time.
3. Close browser and copy sessionstore.js file into profile folder.
4. Run browser and wait.
That's nice, thanks Michael. This one's even simpler and makes the issue obvious: We try to set the history index to a non-existing entry. We really shouldn't...
Attached patch fix? — — Splinter Review 
So, let's validate our input somewhat better. Not sure how we get into the bad state to start with, though. Anyway, this patch might fix the worst issues as reported in this bug and maybe even as reported in bug 427193 as well.
Attachment #327156 - Flags: review?(gavin.sharp)
That fixes the case of my artificially created sessionstore.js file, but since I manufactured that sessionstore.js file by hand I'm not sure it was valid to begin with.

I can still reproduce the problem with this one that wasn't artificially created, but only if Firebug is installed.  My guess is Firebug is doing something weird to the session data, but since Firebug makes no calls to SessionStore I don't see how exactly.  It must be manipulating the window (maybe because of the load error?) and SessionStore is saving it.
Any idea how using the wrong index ends up causing the exception?
(In reply to comment #56)
Not without diving into the sessionHistory code to see what consequences/side-effects setting a wrong index could have (BTW: not setting an index at all seems to leave sessionHistory in a somewhat broken state as well). And how the error manages to get from sessionHistory all the way around to toSource is really a question for one of our Core gurus.
To Simon Bünzli:

Even with your fix applied to nsSessionStore.js, I still get the same errors when restoring a session:

Error: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox%203/components/nsSessionStore.js :: sss_saveState :: line 1898"  data: no]
Source File: file:///C:/Program%20Files/Mozilla%20Firefox%203/components/nsSessionStore.js
Line: 1898

and also:

Error: too much recursion
Source File: file:///C:/Program%20Files/Mozilla%20Firefox%203/components/nsSessionStore.js
Line: 1898

This happens on my working FF3 installation which has a bunch of extensions installed (including Firebug and Greasemonkey) and about 17 tabs open. However, this time none of the tabs contain a built-in browser error page.
FWIW, I've seen this (and bug 427193) without Firebug installed, although I can't reproduce it consistently.  It seems to be related to having chrome: URLs (f.e. about:config, or a chrome: page loaded by an extension) loaded into a browser tab.

I have a browser session open which has this problem.  I tried running the below code in Error Console:

Components.classes["@mozilla.org/browser/sessionstore;1"].getService(Components.interfaces.nsISessionStore).getBrowserState()

And to my surprise, it dumped out the browser state in JSON format.  Inspecting the nsSessionStore.js file shows that the getBrowserState method is implemented using the _toJSONString function, which seems to handle the task correctly.  I noticed that the only place which calls toSource() in nsSessionStore.js is the offending line.

So, the question I have here is: does toSource() have any special characteristics which can't be replaced by _toJSONString()?  If not, then I think this could lead to a fix for this bug.  Simon: do you have any idea?
(In reply to comment #60)
> does toSource() have any special characteristics which can't be replaced by
> _toJSONString()?  If not, then I think this could lead to a fix for this bug.

toSource is significantly faster than _toJSONString. Once we've got a complete native JSON implementation, we could switch over to using JSON exclusively (cf. bug 387859 and bug 407110). Then again, that wouldn't really fix the core issue being observed here - just the symptom.
Attachment #327156 - Flags: review?(gavin.sharp) → review+
Flags: wanted-firefox3.1?
Whiteboard: [firebug-p2]
Blocks: 429414
No longer depends on: 429414
(In reply to comment #50)
> Created an attachment (id=327051) [details]
> sessionstore.js to reproduce the error discussed here
> 
> I think I have a reproducible test case now.
> ...

If you read through all of the reports under 429414, you'll see several different error messages.  This particular one, in comment #50, comes out with FF3 + Firebug 1.2. I believe I have figured out how to fix it. The key was the comment #59 by myk. The error comes out two times in Firebug; Firebug has two browser XUL elements set to chrome: urls.

Using Firebug FBTrace with ERRORS on, I found a stack trace that pointed to chrome://browser/content/browser.xul. Using Chromebug I set a breakpoint on line 637 and watch the exception being taken at browser start up but not on tab start up.  After a bit, the code on line 637 hit me and I set the browser element in Firebug to have 
disablehistory="true"
So far I've not had the messages; I won't miss seeing these 20 times a day.

 try {
637 if (!this.hasAttribute("disablehistory")) {
638 var os = Components.classes["@mozilla.org/observer-service;1"]
639 .getService(Components.interfaces.nsIObserverService);
640 os.addObserver(this, "browser:purge-session-history", false);
641 // wire up session history
642 this.webNavigation.sessionHistory =
643 Components.classes["@mozilla.org/browser/shistory;1"]
644 .createInstance(Components.interfaces.nsISHistory);
645 // enable global history
646 this.docShell.QueryInterface(Components.interfaces.nsIDocShellHistory).useGlobalHistory = true;
647 }
648 }
649 catch (e) {
650 Components.utils.reportError(e);
651 }
652
Is it true that except for the "main content" browser for any XUL application (including Firefox), all other <browser> elements should have disablehistory="true"?  This attribute only affects the session history glue code, so I think it would be safe to swap it with an enablehistory attribute as John suggested above.  Of course I don't think such a solution would be accepted on branch...
(In reply to comment #63)
> Is it true that except for the "main content" browser for any XUL application
> (including Firefox), all other <browser> elements should have
> disablehistory="true"?  
> 

Yes, see bug 408668 comment 1
This is also submitted to fbug's issue tracking system: <http://code.google.com/p/fbug/issues/detail?can=1&q=502&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&id=502>, and was recently fixed: <http://code.google.com/p/fbug/source/detail?r=967>.

Also, marking this dependent on bug 408668, because once that bug is fixed, then this problem won't happen in any extension.
Depends on: 408668
Using today's nightly build on Mac Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081103 Minefield/3.1b2pre, my Error Console is filled with this message. I have to clear it every few minutes.
Are you still able to reproduce this issue with a 20081106 nightly build? If not, this bug was fixed by bug 407110.
Fixed in Firebug http://code.google.com/p/fbug/issues/detail?id=502
I believe the fix was to disable history on our internal browser.
Whiteboard: [firebug-p2] → 
(In reply to comment #69)
> Are you still able to reproduce this issue with a 20081106 nightly build? If
> not, this bug was fixed by bug 407110.

Marcia, can you please test again? Would be nice to see if it still happens to you.
I have not seen this error lately either on Tiger or Leopard nightlies.

(In reply to comment #73)
> (In reply to comment #69)
> > Are you still able to reproduce this issue with a 20081106 nightly build? If
> > not, this bug was fixed by bug 407110.
> 
> Marcia, can you please test again? Would be nice to see if it still happens to
> you.
Resolving as WORKSFORME per comment #69 and comment #74.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
I'm encountering this bug frequently in Fx 3.0.11 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729))

I have Firebug enabled, if that matters.
Whiteboard: → [fix: update to Firefox 3.5][known to happen with Firebug under Firefox 3.0]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: