293783 - Regression: NNTP msgs with attachment, 2nd msg in series not loading from server

Status: RESOLVED DUPLICATE of bug 263724

(MailNews Core :: Networking: NNTP, defect)

Description

[Ronald Killmer]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Regression in TB 1.0.2 official win32 build.  This did work correctly in TB 0.4
and exists in Win ME and XP.

In a binary news group clicking on 1st msg with attachment gets the msg. 
Clicking on next msg. TB not clearing and opening msg. makes it dead.  Goto 3rd
msg and TB resets and d/l the msg w/attachment.  Try to go back to 2nd and it is
dead, TB not recognising the msg.  Will not for the rest of the current session.
 Requires close and restart to access 2nd msg.  This pattern of failure repeats
with alternating msgs not recognised and becoming dead in current session.

Reproducible: Always

Steps to Reproduce:
1.Click 1st msg to read w/attachment, it loads from server.
2.Click 2nd msg to read w/attachment, TB ignores it and makes is dead for this
session.
3.Click 3rd msg to read w/attachment, it loads from server.  Pattern repeats
during session.

Actual Results:  
Second msg selected is not d/l, read marker is toggled, status bar is not
cleared of 1st msg attachment data.  Remarking unread is no help.  Msg is
effectifly dead for remainder of session.  Requires close and restart of TB to
access 2nd msg.

Expected Results:  
TB will advance to next selected msg w/attachment and d/l it from NNTP server.

This is a regression in a function that is essential to efficient use of this
App to read NNTP msgs when retreval of binary attachments is the primary
activity and the text msg content is supplamental.

Wile this bug does not meet Bugzilla standards for a "Blocker" is is very close
and should be fixed ASAP to restore the broken funtionality.

This bug has been confirmed by other TB 1.0.2 users through discussion on
non-MoFo or related NNTP servers.

Comment 1

[idgreenwald]

My experience is a bit different.  If I click on a link in a newsgroup message
that takes me to a site in Firefox, when I return to TB the "N" or "Space" will
not open the next message.  Although focus is on the next message header, the
previous message remains in the display.

I can overcome this "hang" by marking the unread message unread, click on any
previous message and then type "N"

Comment 2

[Ronald Killmer]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
> Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
> 
> Regression in TB 1.0.2 official win32 build.  This did work correctly in TB 0.4
> and exists in Win ME and XP.
> 
> In a binary news group clicking on 1st msg with attachment gets the msg. 
> Clicking on next msg. TB not clearing and opening msg. makes it dead.  Goto 3rd
> msg and TB resets and d/l the msg w/attachment.  Try to go back to 2nd and it is
> dead, TB not recognising the msg.  Will not for the rest of the current session.
>  Requires close and restart to access 2nd msg.  This pattern of failure repeats
> with alternating msgs not recognised and becoming dead in current session.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1.Click 1st msg to read w/attachment, it loads from server.
> 2.Click 2nd msg to read w/attachment, TB ignores it and makes is dead for this
> session.
> 3.Click 3rd msg to read w/attachment, it loads from server.  Pattern repeats
> during session.
> 
> Actual Results:  
> Second msg selected is not d/l, read marker is toggled, status bar is not
> cleared of 1st msg attachment data.  Remarking unread is no help.  Msg is
> effectifly dead for remainder of session.  Requires close and restart of TB to
> access 2nd msg.
> 
> Expected Results:  
> TB will advance to next selected msg w/attachment and d/l it from NNTP server.
> 
> This is a regression in a function that is essential to efficient use of this
> App to read NNTP msgs when retreval of binary attachments is the primary
> activity and the text msg content is supplamental.
> 
> Wile this bug does not meet Bugzilla standards for a "Blocker" is is very close
> and should be fixed ASAP to restore the broken funtionality.
> 
> This bug has been confirmed by other TB 1.0.2 users through discussion on
> non-MoFo or related NNTP servers.

Ammendment: After a fresh startup four to six messages can be accessed before
the bug behavior kicks in. Once active even text only msgs are affected if they
are the next one accessed after one with an attachment.

Comment 3

[Chris Ilias [:cilias]]

I think this is a dup of bug 263724 .

Comment 4

[Ronald Killmer]

I tend to agree and see that the regression happened earier than TB1.0 as Bug
#253724 points to version 0.8 as the event horizon.

This bug #293783 has slightly different behavior tho the probable cause is likly
the same source as bug #263724.

Comment 5

[Ronald Killmer]

Lowering severity to normal based on improved behavior in TB 1.5 official build for Win32. Change Version to 1.5.

Now a user can click any message header and then back step to desired message header with attachement and it (msg) will get focus and begin to load.  Gone is the freezing of the msgs read status toggle to read and being made permanent for the remainder of current TB instance.

Behavior still does not match performance of stepping through text only message headers in NNTP reader mode.

Comment 6

[John Butler]

This behavior persists in Version 2.0.0.9.

Comment 7

[Ronald Killmer]

Updated version to 2.0 and OS to Windows Vista. This continues to plague Tb news reading of binary groups where files are attachments, not embedded inline. 

Comment 8

[Ronald Killmer]

Needs update of Assigned To: