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

Status: VERIFIED DUPLICATE of bug 142043

(Core :: Networking: File, defect)

Description

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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/[e-mail]/INBOX.imapmbox/Emailing__processReq.mimeattach/processRequest.htm

which causes a failure due to the 37-character folder named
'[e-mail]'

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.

Comment 1

[Doug Turner (:dougt)]

-> mailnews

Comment 2

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Doug, this is happening in Browser via AppleEvents.  MailNews has nothing to do
with it.

Comment 3

[Bill McGonigle (not currently reading bugmail; please contact directly)]

undoing these changes:

         AssignedTo|[e-mail]          |[e-mail]
          Component|Networking: File            |Attachments
            Product|Browser                     |MailNews
          QAContact|[e-mail]           |[e-mail]

I'll have to do the Component in a second pass, since the Component menu isn't
updating.

Comment 4

[Doug Turner (:dougt)]

sorry about that.  over to [e-mail] 

Comment 5

[Conrad Carlen (not reading bugmail)]

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 "[e-mail]"
(2) Use BBEdit's "Preview With" on that file.

Comment 6

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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...)

Comment 7

[benc]

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?

Comment 8

[Conrad Carlen (not reading bugmail)]

Dup.

*** This bug has been marked as a duplicate of 142043 ***

Comment 9

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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.

Comment 10

[Conrad Carlen (not reading bugmail)]

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.

Comment 11

[benc]

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.

Comment 12

[Conrad Carlen (not reading bugmail)]

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.

Comment 13

[benc]

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. 

Comment 14

[Conrad Carlen (not reading bugmail)]

Yes, that's right - though the "link" is an attachment. I think Bill put it
pretty clearly in comment #2.

Comment 15

[benc]

(not sure how you would get that AppleEvent to fire...)

Comment 16

[benc]

V/dupe, removing depends to dupe.
Thanks for the clarifications...