The default bug view has changed. See this FAQ.

Extra link inserted into Filelink emails on receiver's end

RESOLVED FIXED in Thunderbird 15.0

Status

Thunderbird
Message Compose Window
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mconley, Assigned: Bienvenu)

Tracking

Trunk
Thunderbird 15.0

Thunderbird Tracking Flags

(thunderbird13 fixed, thunderbird14 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

Created attachment 618287 [details]
Screenshot showing the inserted URL

When sending a Filelink email, receivers still see a URL attachment, distinct from the Filelink URL in the body of the message.

See screenshot.

David:  is this on purpose?
(Assignee)

Comment 1

5 years ago
yes, it's on purpose. We need a mimepart to store all the stuff that lets us edit drafts correctly in the mime headers. I decided to put the url in the body of the mime part because I thought it might be more useful than an empty mime part.
David:

Ok, so we'll mark this one WONTFIX?

-Mike
(Assignee)

Comment 3

5 years ago
(In reply to Mike Conley (:mconley) from comment #2)
> David:
> 
> Ok, so we'll mark this one WONTFIX?
> 
> -Mike

Well, I'm open to suggestions - we could simply not put the link in and have an empty part, but I thought it might come in handy, perhaps for extensions.

Comment 4

5 years ago
(In reply to David :Bienvenu from comment #3)
> (In reply to Mike Conley (:mconley) from comment #2)
> > David:
> > 
> > Ok, so we'll mark this one WONTFIX?
> > 
> > -Mike
> 
> Well, I'm open to suggestions - we could simply not put the link in and have
> an empty part, but I thought it might come in handy, perhaps for extensions.

I think having this extra duplicated link is confusing. I understand the reason we need this mime but I'd suggest we leave it empty.
I'm curious of what you have in mind for extensions. This sounds interesting as well so we need to balance user experience and developer provisions...
Could we leave the link in, but make it a type of mime part we don't show by default?

Could we remove it before sending?
(Assignee)

Comment 6

5 years ago
(In reply to Jb Piacentino from comment #4)
> I think having this extra duplicated link is confusing. I understand the
> reason we need this mime but I'd suggest we leave it empty.
> I'm curious of what you have in mind for extensions. This sounds interesting
> as well so we need to balance user experience and developer provisions...

things like prefetching the cloud files, indexing them in gloda, etc. But we could do that by putting the link information in a mime header instead of in the body.

Re using some type we don't display, I'm open to suggestions. We'd need something that won't cause interoperability problems with other clients. We could use application/octet-stream, as long as not having a file in the content-type doesn't confuse other apps.

Comment 7

5 years ago
(In reply to David :Bienvenu from comment #6)
> (In reply to Jb Piacentino from comment #4)
> > I think having this extra duplicated link is confusing. I understand the
> > reason we need this mime but I'd suggest we leave it empty.
> > I'm curious of what you have in mind for extensions. This sounds interesting
> > as well so we need to balance user experience and developer provisions...
> 
> things like prefetching the cloud files, indexing them in gloda, etc. But we
> could do that by putting the link information in a mime header instead of in
> the body.
If this is a way of hidding the information while maintaining useful information for extensions, that seems a good solution.
> 
> Re using some type we don't display, I'm open to suggestions. We'd need
> something that won't cause interoperability problems with other clients. We
> could use application/octet-stream, as long as not having a file in the
> content-type doesn't confuse other apps.
(Assignee)

Comment 8

5 years ago
Created attachment 618799 [details] [diff] [review]
proposed fix
Assignee: nobody → dbienvenu
Attachment #618799 - Flags: review?(mconley)

Comment 9

5 years ago
Could we just make the attachment an internet shortcut? (.url file)
Mime type could perhaps be application/internet-shortcut? Would be pretty nice to just be able to drag'n'drop cloud attachments to the desktop and be able to open directly.
Comment on attachment 618799 [details] [diff] [review]
proposed fix

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

Hm - so this seems to introduce a bug.  STR:

1)  Open a compose window, and attach a large Filelink - > 1MB, to fully experience the effects.  (I noticed it with a 10MB file)
2)  Send the message.

What happens?

When sending, the progress bar chugs along, as if the attachment is being sent along with the message.

What's expected?

Sending should be instantaneous.

I should point out that this does fix the other bug - we no longer insert the extra link into the body of the message.
Attachment #618799 - Flags: review?(mconley) → review-

Comment 11

5 years ago
(In reply to Magnus Melin from comment #9)
> Could we just make the attachment an internet shortcut? (.url file)
> Mime type could perhaps be application/internet-shortcut? Would be pretty
> nice to just be able to drag'n'drop cloud attachments to the desktop and be
> able to open directly.
 
We would of course then name the attachment, like <realfilename>.url.
Firefox creates .url files like so: http://mxr.mozilla.org/comm-central/source/mozilla/widget/windows/nsDataObj.cpp#1156 though i think even a file containing just the url works in practice.
(Assignee)

Comment 12

5 years ago
(In reply to Mike Conley (:mconley) from comment #10)

> When sending, the progress bar chugs along, as if the attachment is being
> sent along with the message.
ugh, probably the content type change. I'll try to look at this after tb 12.01.

Re internet shortcut, the urls that we get from file link providers usually point at a web page, not the actual file.
(Assignee)

Comment 13

5 years ago
oh yeah, I remember now - nsMsgSendPart::Write() will write out what's in m_buffer, if it's set; otherwise, it writes out the file in m_file. When I removed the link code, that left m_buffer null... working on a fix.
(Assignee)

Comment 14

5 years ago
Created attachment 619207 [details] [diff] [review]
don't snarf attachment...
Attachment #618799 - Attachment is obsolete: true
Attachment #619207 - Flags: review?(mconley)

Comment 15

5 years ago
Created attachment 619331 [details] [diff] [review]
make filelink attachments interet-shortcut

Yes, it may not be a direct link. However, my making it a shortcut you can get to it with a click or two. 

This also have the advantages like
 - attachment icon will be shown in thread pane
 - save all for multiple attachments would do more of what the user expects
 - sending a mail with cloud attachments AND normal attachments is confusing to the receiver as is (also somewhat with several cloud attachments)
Attachment #619331 - Flags: review?(dbienvenu)
(Assignee)

Comment 16

5 years ago
(In reply to Magnus Melin from comment #15)
> Created attachment 619331 [details] [diff] [review]
> make filelink attachments interet-shortcut
> 
> Yes, it may not be a direct link. However, my making it a shortcut you can
> get to it with a click or two. 
> 
> This also have the advantages like
>  - attachment icon will be shown in thread pane
>  - save all for multiple attachments would do more of what the user expects
>  - sending a mail with cloud attachments AND normal attachments is confusing
> to the receiver as is (also somewhat with several cloud attachments)

I believe JB and Blake don't want to see the attachment icon, or attachments in the attachment pane of the message viewer, so they would see all these as disadvantages. But I might be confused, and they should speak for themselves.
Ideally, I don't want to see the attachment icon or attachments in the attachment pane.  If we absolutely have to have something there, making it an "internet shortcut" seems like the least bad option.
(Assignee)

Comment 18

5 years ago
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #17)
> Ideally, I don't want to see the attachment icon or attachments in the
> attachment pane. 

That's what my patch that mconley is going to review accomplishes.

Comment 19

5 years ago
I have to say i'm surprised you don't want an attachment icon for mails that contain attachments (though the actual file is elsewhere). 
More often than not i'm searching old mails that i know had some document attached, and finding which mail that would be in a conversation is a lot easier if there's an icon.
Hardware: x86 → All
Comment on attachment 619207 [details] [diff] [review]
don't snarf attachment...

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

This looks good to me, and works as advertised.

Thanks David.
Attachment #619207 - Flags: review?(mconley) → review+
(Assignee)

Comment 21

5 years ago
fixed on trunk - http://hg.mozilla.org/comm-central/rev/c2fc01604fdc
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 15.0
Is this something we wanted for TB 13/14?
(Assignee)

Comment 23

5 years ago
Comment on attachment 619331 [details] [diff] [review]
make filelink attachments interet-shortcut

I don't disagree with you, Magnus, but I guess I can see the argument that until we treat these more like attachments, we shouldn't show them as attachments.
Attachment #619331 - Flags: review?(dbienvenu) → review-
(Assignee)

Comment 24

5 years ago
Comment on attachment 619207 [details] [diff] [review]
don't snarf attachment...

[Triage Comment]
we want this for tb 13 and 14, I believe.
Attachment #619207 - Flags: approval-comm-beta+
Attachment #619207 - Flags: approval-comm-aurora+
comm-aurora: http://hg.mozilla.org/releases/comm-aurora/rev/b88d0663488d
comm-beta: http://hg.mozilla.org/releases/comm-beta/rev/834a6df4263e
status-thunderbird13: --- → fixed
status-thunderbird14: --- → fixed
You need to log in before you can comment on or make changes to this bug.