365192 - Faulty newsblog.js logic with gNumPendingFeedDownloads kills ability to subscribe RSS

Status: RESOLVED WORKSFORME

(MailNews Core :: Feed Reader, defect)

Description

[alta88]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Tb2.0 beta 1 (20061226)


i've added a console message right after the debug in this code starting in line 114:

    if (gNumPendingFeedDownloads)
    {
      debug('Aborting RSS subscription. Feed downloads already in progress\n');
      return;
    }

and it is almost always the reason subscribing breaks, requiring a Tb restart.  using venkman, i notice the var is all over the place, like -5 just now.  clearly not being incremented/decremented/reset correctly.

Reproducible: Sometimes

Steps to Reproduce:
1.Frequent updating or subscribing to feeds, but no other errors or pattern
2.
3.
Actual Results:  
Once the error is thrown, Tb will not subscribe (due to the test on the var failing).

Expected Results:  
Var needs to be reset so subscribing can continue.

Comment 1

[alta88]

in looking at this in detail, it first seemed invalid feeds were the culprit:

1. an old feed had changed and no longer validated; updates would do the downloaded() function 2x and thus decrement the var twice, guaranteeing the test failed always.
2. new non-validating feed, though flagged as such, is still added; updates fail as above.

ok, so i removed bad feeds (even from trash, since Tb still updates them in that folder - which is a separate bug since this is neither user expected or appropriate behavior).  after a few update cycles, the var once again turned negative on double decrements.  design/logic here is not good.

effectively, Tb can only subscribe to new feeds if it's just been restarted.  this is always reproducible for me on about 45 feeds.

Comment 2

[Mike Cowperthwaite]

I'm confirming this based on the detailed analysis.

Comment 3

[Scott MacGregor]

tuukka might be able to help out here. 

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Marking as blocking do to the rotten user experience described.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

er, "due"

Comment 6

[Phil Ringnalda (:philor)]

alta88: do you still have a setup where you see this, or can you expand on "no longer validated"? I tried creating a minimal feed with one entry, subscribing to it, then adding a second entry with a <title> but no </title> so it would hit a parsing error, but after I right-click, Get Messages, I can still subscribe.

Comment 7

[alta88]

imo, it makes little sense to attack this bug before you (or someone) has finished what you started in bug 348450.  the failure i reported here is the result of [url=http://forums.mozillazine.org/viewtopic.php?f=9&t=480357]custom code[/url] to subscribe via a command line mechanism from Fx or external program, not via the Tb contextmenu Subscribe (i don't know if this bug affects the internal Tb Subscribe).

if you want to recreate it, first add several feeds and make sure they go through a few update cycles or Get Messages on busy feeds.  then issue the command line thunderbird.exe -mail feed:http://rssfeed.htm eg. to simulate an external subscribe.  there will not be either a successful subscribe message or any error message.

Comment 8

[Phil Ringnalda (:philor)]

Afraid I'm still unable to reproduce: I subscribed to 40 feeds, even lucking into one which became not-well-formed after I subscribed, got new items repeatedly, both manually and automatically, and subscribing from Firefox still works fine. The closest I could get was silent failure by triggering a manual update, then rushing over to Firefox to subscribe while the check was still going on, which as you'd expect from the code fails, foolishly and annoyingly, but doesn't seem to be what you're describing.

Comment 9

[alta88]

i have consistently reproduced this on Tb2 but have not tested with trunk.  though i think there have been almost no or very minor changes to feeds code (other than the external sub fix for win/nix).

it would be good to always log an external subscribe immediately when received by Tb, otherwise nothing can be known in the course of normal usage where a failure occurs, in the external app or Tb. silent failures here are very bad.

it seems you're testing via Fx feedconverter subscribe; perhaps simulating various subs via the commandline method (and creating malformed urls or other error conditions) may show something.  if not, well great.  i'll keep an eye out for it when 3 is out.

Comment 10

[Phil Ringnalda (:philor)]

I wasn't able to hit it from the commandline, either. Keeping an eye out when Tb3 ships is fine, but the reason I keep coming back to this bug is that it was marked as blocking Tb3, a difficult thing to do if the only person who has seen it isn't going to look until after.