Closed Bug 1446679 Opened 6 years ago Closed 6 years ago

Download rest of message not working after fetch headers only or partial download (do not download messages larger than ...) - POP account (TB 60)

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(thunderbird60+ fixed, thunderbird61 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 61.0
Tracking Flags:
Tracking Status
thunderbird60 + fixed
thunderbird61 --- fixed

People

(Reporter: jorgk-bmo, Assigned: jorgk-bmo)

References

Details

(Keywords: regression)

Attachments

(1 file)

1446679-username.patch
3.22 KB, patch
aceman
: review+
jorgk-bmo
: approval-comm-beta+
Details | Diff | Splinter Review 
+++ This bug was initially created as a clone of Bug #1361020 +++

Have a POP account that fetches headers only. Download a message, click on "Download the rest of the message". Nothing happens.

Most likely due to content policy changes in M-C, see also bug 1406574.
OK, no, nothing to do with content policy, it's due to the recent URI changes. Debug shows:
[7396, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000
4002: file c:/mozilla-source/comm-central/mailnews/local/src/nsPop3Service.cpp,
line 409

And that line is:
    rv = NS_MutateURI(newUri).SetUsername(escapedUsername).Finalize(newUri);
    NS_ENSURE_SUCCESS(rv, rv);

So we need a SetUserNameInternal() here. Patch coming.
More URL fallout. This works. BuildPop3Url() registers a listener, so after that, we can't use mutate any more.
Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Attachment #8959870 - Flags: review?(acelists)
Attachment #8959870 - Flags: approval-comm-beta+
Comment on attachment 8959870 [details] [diff] [review]
1446679-username.patch

Review of attachment 8959870 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, it works for me.
Attachment #8959870 - Flags: review?(acelists) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/8cfc708a254f
use SetUsernameInternal() in nsPop3Service::NewURI(). r=aceman
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 61.0
Why is Thunderbird 61 the target milestone instead of Thunderbird 60 beta 2? This does not make any sense.
The bug occurred in 60 beta 1 and should be fixed in 60 beta 2 instead of waiting another cycle!
No worries, that is why the patch has the approval-comm-beta+ flag.
After successful build on the nightly (61), it will be pushed to 60 too.
Confirmed working on Tb60_beta1_build3. Thanks.
(In reply to Jorg K (GMT+1) from comment #0)
> +++ This bug was initially created as a clone of Bug #1361020 +++
> 
> Have a POP account that fetches headers only. Download a message, click on
> "Download the rest of the message". Nothing happens.
> 
> Most likely due to content policy changes in M-C

Bug 1407056 - Override page CSP for content injected by expanded principle ?
Flags: needinfo?(jorgk)
See Also: → 1406574
No, as I said, it's fallout from the URI changes, bug 1434687.
Flags: needinfo?(jorgk)
See Also: 1406574 → 
(In reply to Jorg K (GMT+1) from comment #10)
> No, as I said, it's fallout from the URI changes, bug 1434687.
Blocks: 1434687
(In reply to Aris from comment #5)
> Why is Thunderbird 61 the target milestone instead of Thunderbird 60 beta 2?
> This does not make any sense.
> The bug occurred in 60 beta 1 and should be fixed in 60 beta 2 instead of
> waiting another cycle!

Actually, this is a bug in 52.7.0 and was apparently never really fixed in 55.0 despite the assertion in bug #1361020.  Is there a pending Thunderbird version earlier than 60 where this can be fixed?
Works for me in TB 52.7, I've just tried. What does "never really fixed" mean?
(In reply to Jorg K (GMT+1) from comment #13)
> Works for me in TB 52.7, I've just tried. What does "never really fixed"
> mean?

While I do not always have this problem, I had it twice today.  When I do have this problem, I can view the source of the "blank" message.  It is always HTML-formatted and is truncated somewhere in the HTML <head> section.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: