Open Bug 725589 Opened 10 years ago Updated 5 years ago
Error: 'Component is not available' when calling method: [ns
IHttp Channel::get Response Header] in Page Thumbs Protocol .js
I've been seeing the following error in the error console recently (today, and right before I went on holiday ~6 days ago): Error: 'Component is not available' when calling method: [nsIHttpChannel::getResponseHeader] = NS_ERROR_NOT_AVAILABLE Source file: resource://app/components/PageThumbsProtocol.js Line: 212 Haven't had time to investigate causes or correlations. I seems to get it in bursts, ~10 errors around the same time then some period of time between the next burst (I haven't seen them appear - that's just based on other things logged to the error console).
I can confirm this error using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a2) Gecko/20120212 Firefox/12.0a2. For me it is generated by the New Tab Page (about:newtab) that is now enabled by default. The observed error is that no thumbnails are shown in the New Tab Page. The error message is generated once for each thumbnail that should be displayed.
That's very strange. There even is a try/catch block wrapping the call: http://mxr.mozilla.org/mozilla-central/source/browser/components/thumbnails/PageThumbsProtocol.js#212 Can you please try with safe-mode? I'd like to know if there's any add-on interfering here.
I still see the error message in safe-mode.
(In reply to Stefan Sitter from comment #3) > I still see the error message in safe-mode. Same. Even right after startup: open new tab, see error. Oddly enough, I just counted the errors... there's exactly 10 of them each time. Not 9 as I'd expect.
Per spec , nsIHttpChannel.getResponseHeader() throws NS_ERROR_NOT_AVAILABLE if the header is not set. Maybe there's some caller that doesn't do a try/catch? Would be great to find the caller... And I have no idea why even with safe-mode you're seeing this and I'm not.  https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIHttpChannel#getResponseHeader%28%29
I bet the people seeing this have dom.report_all_js_exceptions set to true. I do!
Hm, yes. And flipping that does indeed result in no such errors in the error console. But that method is *meant* to throw.
report_all_js_exceptions was kind of a workaround to address the fact that XPConnect heuristics for determining whether something should be reported are difficult to get right in certain cases (involving calls back and forth across JS<->C++, particularly in "expected to throw" cases - I forget the exact details but they should be in bug 415498). I'm not sure there's much to do here. I don't think we want to change the PageThumbsProtocol.js code just to work around this issue if it's otherwise working fine. There may be some XPConnect changes worth making to help address this, but I really have no idea about that.
Turning off the preference doesn't change anything about the missing thumbnails in the New Tab page for me. The error message is gone but the real error still exists.
That's probably unrelated to this exception (IIRC there are other bugs covering missing thumbnails).
FWIW, I'm also getting along with with the Line: 212 error this: Error: 'Component is not available' when calling method: [nsIHttpChannel::getResponseHeader] = NS_ERROR_NOT_AVAILABLE Source file: resource://app/components/PageThumbsProtocol.js Line: 226
You need to log in before you can comment on or make changes to this bug.