If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Error: this._processor is null

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
RSS Discovery and Preview
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: Tomcat, Assigned: Ehsan)

Tracking

({fixed1.9.1})

Trunk
Firefox 3.6a1
x86
Windows XP
fixed1.9.1
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Steps to reproduce:
-> Go to http://www.syndic8.com/
-> Click on the "5 random syndicated feeds:" XML Button
-> Subscribe to this via Live Bookmarks
--> Check the Error Console

Error: this._processor is null
Source File: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsLivemarkService.js
Line: 934
Duplicate of this bug: 439474
(In reply to comment #0)
> Steps to reproduce:
> -> Go to http://www.syndic8.com/
> -> Click on the "5 random syndicated feeds:" XML Button
> -> Subscribe to this via Live Bookmarks
> --> Check the Error Console
> 

It works for me.
Can you install the latest trunk ( http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ) and test this bug in safe mode, or better with a blank profile? Disable also all plugins temporary.

If it works in this way, but not with your normal profile, probably it's a problem caused by an extension. So try to disable them one-by-one.

When you find the problematic extension(s), inform us and its author, and change the resolution of this bug to invalid.

Comment 3

9 years ago
This bug is annoying the buggery out of me. I'm a web designer and every minute , if not more frequently, Firebug is displaying this as an error. That means I have to repeatedly open Firebug and double check that's it's not an error with my code.

Extremely frustrating. Enough to boost the status above "normal" IMHO.

Can this please be fixed in the next security and stability update? I don't want to have to go alpha on my main development machine just to solve this issue since I need a reliable and predictable environment with to develop.
Duplicate of this bug: 468455

Comment 5

9 years ago
Simple filter for this notice (fix for nsLivemarkService.js)
 /**
   * See nsIStreamListener.idl
   */
  onDataAvailable: function LLL_onDataAvailable(aRequest, aContext, aInputStream, aSourceOffset, aCount) {
    if (this._processor != null)
       this._processor.onDataAvailable(aRequest, aContext, aInputStream,
                                       aSourceOffset, aCount);
  },
  /**
   * See nsIRequestObserver.idl
   */
Duplicate of this bug: 416517
Vladimir, would this fix the problem and populate the feed folder?
Summary: Error: this._processor is null → XML feed not populated after adding as livemark (Error: this._processor is null)
Bad job of morphing. This bug is about the "Error: this._processor is null" error, which happens when data is available after the processor has been nulled out. It's not about showing some items from not-well-formed feeds, or trying to turn malformed XML into something that can be parsed.
Summary: XML feed not populated after adding as livemark (Error: this._processor is null) → Error: this._processor is null
So, is this a dupe of bug 388275?  The patch from that bug adds the necessary null checks to onDataAvailable <http://hg.mozilla.org/mozilla-central/rev/7ebd8c4e8315>.
That fixed FeedConverter.js so previewing a malformed feed doesn't throw, but not nsLivemarkService.js, so adding a malformed feed as a livemark (or, I presume, having one which later becomes malformed) still throws.
Created attachment 374688 [details] [diff] [review]
Patch (v1)

OK, obvious patch.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Attachment #374688 - Flags: review?(dietrich)
Comment on attachment 374688 [details] [diff] [review]
Patch (v1)

>@@ -667,17 +668,18 @@ LivemarkLoadListener.prototype = {
>       this._setResourceTTL(ERROR_EXPIRATION);
>       this._isAborted = true;
>       MarkLivemarkLoadFailed(this._livemark.folderId);
>       this._livemark.locked = false;
>       return;
>     }
>     // Set an expiration on the livemark, for reloading the data
>     try {
>-      this._processor.onStopRequest(aRequest, aContext, aStatus);
>+      if (this._processor)
>+        this._processor.onStopRequest(aRequest, aContext, aStatus);
> 

trying to clarify what's going on here: onStopRequest is called after handleResult, with possible onDataAvailable calls in between?
(In reply to comment #12)
> trying to clarify what's going on here: onStopRequest is called after
> handleResult, with possible onDataAvailable calls in between?

Yes, that should be the case.
(In reply to comment #13)
> (In reply to comment #12)
> > trying to clarify what's going on here: onStopRequest is called after
> > handleResult, with possible onDataAvailable calls in between?
> 
> Yes, that should be the case.

what data is available after the processor decides that processing is complete?

(i just want to make sure this patch is not just a band-aid for a problem that exists somewhere else...)
(In reply to comment #14)
> what data is available after the processor decides that processing is complete?

I'm not really sure what causes this behavior.

> (i just want to make sure this patch is not just a band-aid for a problem that
> exists somewhere else...)

I don't know this code well, so yes this could in fact be a band-aid for another problem, I'm afraid.
(In reply to comment #8)
> Bad job of morphing. This bug is about the "Error: this._processor is null"
> error, which happens when data is available after the processor has been nulled
> out. It's not about showing some items from not-well-formed feeds, or trying to
> turn malformed XML into something that can be parsed.

I've never talked about an not-well-formed feed. My comment is based on the same feed Carsten mentioned in comment 0. It is well-formed but causes a Livebookmark not to fill up with it's content. Do the steps from comment 0 and see what is happening. You will see that I haven't morphed anything! The current summary doesn't tell anything if you wanna query for a specific issue.
Whether or not you knew that you were talking about a not-well-formed feed, at 16:30 on the 24th you *were* talking about a not-well-formed feed. At that time, one of the random titles had an unescaped HTML entity in it. Because the preview page code chose to display the items it gets before the parser hits a fatal error, it showed some items; because the livemark code chose to not display any items when the parser hits a fatal error, it did not show any items. The summary reflects *exactly* what this specific issue is about; if you want a bug about livemarks deciding to show the items parsed before a fatal error, you need a new bug.
sayrer's more likely to actually know, but I think it's wallpaper, but necessary wallpaper. I think what's happening is that you have an HTTP channel where you called asyncOpen, which is sending you onDataAvailable calls as it loads the file, and you pass that data to the parser, and the parser hits a fatal error and tells you about it, so you give up on parsing, but don't call cancel() on the loadgroup, so you keep getting onDataAvailable calls for the rest of the feed. However, if I add a |this._livemark.loadGroup.cancel(Components.results.NS_BINDING_ABORTED)| in before nulling out the _processor, I still get the same this._processor is null error, so I'd guess you can't actually say "cancel right this instant, and don't you dare give me any more data."
Comment on attachment 374688 [details] [diff] [review]
Patch (v1)

r=me, thanks for the patch. and thanks for the analysis philor.
Attachment #374688 - Flags: review?(dietrich) → review+
http://hg.mozilla.org/mozilla-central/rev/070bce07a827
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Attachment #374688 - Flags: approval1.9.1?

Updated

9 years ago
Attachment #374688 - Flags: approval1.9.1? → approval1.9.1+
Should we return from onStopRequest early if _processor is null?
(In reply to comment #21)
> Should we return from onStopRequest early if _processor is null?

I'm not sure.  The rest of the work performed by onStopRequest does not depend on _processor, but whether we should be doing that work is beyond me.  Dietrich?
Being not-well-formed isn't an invitation to ignore caching headers and check constantly, so the only way you would want to return early would be if you had code to set the TTL in handleResult for the _isAborted case, which is probably why it doesn't cancel the stream - it's easier just to let it finish. It might be reasonable, in another bug that's going to have lots of testcases, to get the caching info off the stream, set the TTL, and cancel the stream, so we don't load all of a huge feed that's malformed in the first few characters, but that would be another bug.
Ah, and we don't want to cancel the stream and thus doom the cache entry, since for all we know it's almost done and will give us an etag that will let us avoid refetching the same busted thing over and over again for days.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0332f1e3024f
Keywords: fixed1.9.1
Verified Fixed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090821 Namoroka/3.6a2pre (.NET CLR 3.5.30729) ID:20090821052443
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-testsuite?
You need to log in before you can comment on or make changes to this bug.