Closed Bug 177480 Opened 22 years ago Closed 22 years ago

Can't handle attachments from Apple Mail w/ long host names

Categories

(Core :: Networking: File, defect)

Product:
Core
Component:
Networking: File
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED DUPLICATE of bug 142043
Milestone:
mozilla1.3beta

People

(Reporter: bill+mozilla-bugzilla, Assigned: ccarlen)

Details

This is a test case for bug 142043. 

Trying to open an HTML attachement from Apple Mail can fail due to the lack of
long filename handling.

Apple Mail stores the attachment in, e.g.:

file:///HardDrive/Users/johndoe/Library/Mail/IMAP-johndoe@mail.thejohndoegroup.com/INBOX.imapmbox/Emailing__processReq.mimeattach/processRequest.htm

which causes a failure due to the 37-character folder named
'IMAP-johndoe@mail.thejohndoegroup.com'

If the user has the right combination of a long-ish username and/or host name
this will fail every time.  If both are short it should always work.
-> mailnews
Assignee: dougt → mscott
Component: Networking: File → Attachments
Product: Browser → MailNews
QA Contact: benc → trix
Doug, this is happening in Browser via AppleEvents.  MailNews has nothing to do
with it.

undoing these changes:

         AssignedTo|dougt@netscape.com          |mscott@netscape.com
          Component|Networking: File            |Attachments
            Product|Browser                     |MailNews
          QAContact|benc@netscape.com           |trix@netscape.com

I'll have to do the Component in a second pass, since the Component menu isn't
updating.
Assignee: mscott → dougt
Component: Attachments → Networking: File
Product: MailNews → Browser
QA Contact: trix → benc
sorry about that.  over to ccarlen@netscape.com
Assignee: dougt → ccarlen
The Mach-0 build doesn't have any problem with long file names and Mach-0 is the
future. Just pointing that out because CFM-only bugs are going to get less
attention.

Also, there's an easier way to repro this that doesn't involve having a working
mail account with a long name. It does involve having BBEdit though. There are
probably lots of apps that could do this.
(1) Create an HTML file in a folder called "IMAP-johndoe@mail.thejohndoegroup.com"
(2) Use BBEdit's "Preview With" on that file.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
I'd be happy to mark this fixed when Mach-O is the 'shipping' nightly. Does the
target milestone of 1.3b mean that's when Mach-O will land? (yeah, I checked the
Mach.html page, and news, and irc...)

If this bug remains a depends on 142043, then shouldn't we send it to mailnews
so they know to test for this? If not, then isn't it a dupe?
Dup.

*** This bug has been marked as a duplicate of 142043 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Are separate bugs for test cases now disallowed?  I filed this per the request
of the owner of the depends on bug for separate test case bugs.

Sorry, don't mean to sound ungrateful for the test case, but the file impl on
CFM mozilla uses the old file APIs which limit it to 31 chars. Either we're
using the new APIs or we're not and don't really need a test case to know that.
If you don't have a placeholder bug for the component that is affected by the
bug, then you end up with a dupe in mail news that is resolved, so the next
person cannot see the bug when they query. That is how the compreg.dat bug got a
lot of dupes.

Also, when this is fixed, I'm not going to test every single entry point in the
product, that is the job of the black box qa per component. If you don't give
them a bug, they won't be reminded to test for this.
Ben, I'm not sure why you bring up mailnews. This bug talks about an attachment
in *Apple's* mail program not being able to be opened in mozilla through an
OpenURL event. Indeed, mailnews has nothing to do with it.
You mean?

STEPS:
1- set mozilla to default browser
2- click on link in applemail that has very long filename path segements.

If so, okay, you are right, I wish someone had said more plainly. 

Yes, that's right - though the "link" is an attachment. I think Bill put it
pretty clearly in comment #2.
(not sure how you would get that AppleEvent to fire...)
V/dupe, removing depends to dupe.
Thanks for the clarifications...
Status: RESOLVED → VERIFIED
No longer depends on: 142043
You need to log in before you can comment on or make changes to this bug.