Closed Bug 361231 Opened 18 years ago Closed 18 years ago

can't download truncated messages.

Categories

(MailNews Core :: Networking, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: john.sharples, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: version 3 alpha 1 (20061119) I have set the disk space the truncate messages greater the 500kb. any message greater than this size displays the correct info but will not download the remainder of the message. This function was working correctly up to a few nightly builds ago. Unfortunately I can't tell you exactly when it stopped working. Reproducible: Always Steps to Reproduce: 1.limit download size 2.download any message, with or without attachments greater than the set size 3.click the "truncated" button Actual Results: A file of 50 or so bytes appears in the download directory with the name of the file in question if it is an attachment. If part of the original message, nothing happens. Expected Results: should have downloaded the rest of the file/s If I disable the download size restriction the full file is downloaded normally.
Version: unspecified → Trunk
Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061120 Thunderbird/3.0a1 ID:2006112003 Error Console output: Error: uncaught exception: Load of pop://foo@bar:110/?uidl=UID250-1118255161 denied.
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Status: UNCONFIRMED → NEW
Ever confirmed: true
yes, I think this is because we're trying to run a pop3 url from a mailbox: url document and nsScriptSecurityManager::CheckLoadURIWithPrincipal is rejecting that.
So what we used to have is: { "pop", AllowProtocol }, { "pop3", DenyProtocol }, Now the pop protocol handler does: 290 *result = URI_NORELATIVE | URI_DANGEROUS_TO_LOAD | ALLOWS_PROXY; so it's equivalent to DenyProtocol. So the real question is who "we" is. Is this another case of Mailnews putting part of its UI into an untrusted context (the message itself)? If chrome were doing the URI load there shouldn't have been a problem... How do I go about nominating a bug to block Thunderbird 3?
Severity: normal → major
yes, exactly, we're adding the link to the html we generate when the message is truncated. I suppose we could add a button to the notification bar (e.g., where we put the not junk and show images buttons) and add a note telling the user to click the button. That would look a lot nicer...What do you think, Scott?
You could also have the chrome detect the click and do the actual load if you want, I suppose...
Presumably the same issue applies to the "expire news articles" error?
probably, though there it's probably a case of news-messages: vs news: schemes...
Blocks: 361279
*** Bug 362398 has been marked as a duplicate of this bug. ***
I was just going to file a bug on this too, but it figured that someone else already ran into it. It seems there really ought to be an exception to allow "internal" URLs to keep working.
Over to a product in which I can request the right blocking flags... David, Scott, I'd really like to get this resolved, but I would like input from you on what you feel the right security model is. Howard, the problem is that the "page" loading this internal URI is not an "internal page" as far as the security system is concerned. It's untrusted content.
Component: General → MailNews: Networking
Product: Thunderbird → Core
Attached patch possible fix (deleted) — Splinter Review
This is one possible fix for the mailbox/pop3 problem. When we generate the download now link for a partial message, we generate a mailbox url, and convert it to a pop3 url in nsMailboxService::NewUri. This runs afoul of the doc shell's policy checks. If we move this conversion to NewChannel, these links work again, from my quick tests. One downside is that we're lying a little about the url when the user mouses over the link. I'd still prefer a whole different UI for this where there's a button in chrome the user can click on. But I don't have time to do that now - a lot of users are also probably pretty used to the link.
Assignee: mscott → bienvenu
Status: NEW → ASSIGNED
David, doing that sort of thing in newChannel sounds perfect! Sounds excellent!
Comment on attachment 256478 [details] [diff] [review] possible fix ok, cool, requesting review. News links will probably need a similar trick...
Attachment #256478 - Flags: superreview?(mscott)
The patch works for me too.
Comment on attachment 256478 [details] [diff] [review] possible fix can we just lose this line: +// else and the statement braces that follow it?
Attachment #256478 - Flags: superreview?(mscott) → superreview+
oh, d'uh, yes, I'll fix that
fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Blocks: 120373
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: