1736208 - FileLink HTML template looks broken in Outlook 2016 (and maybe other clients) - download link appears twice

Status: RESOLVED FIXED

(Thunderbird :: FileLink, defect, P3)

Description

[Johannes Endres]

Attachment: In Outlook 2016 the download link appears twice

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

I sent an HTML message with a FileLink'ed attachment to a user of Outlook 2016.

Actual results:

The HTML template with the download link looked broken for the recipient.

Expected results:

The HTML template should have a clearer UX for as many receiving clients as possible.

Comment 1

[Johannes Endres]

In reply to Thomas D. (:thomas8) from https://bugzilla.mozilla.org/show_bug.cgi?id=1736150#c3 :
[...]

Tbh, I don't consider the current FileLink template to be problematic UX, and while FileLink has been around for long, this is the first report ever afasics. I think Alex and Ryan will be in a position to make the call.
(In reply to Johannes Endres from comment #0)

Steps to reproduce:
I attached a large attachment to a message, chose to use FileLink and had the download link inserted in the mail with the HTML template in my language. The inserted HTML part contained 3 links:

1. the actual download link

Due to the attachment icon, that looks pretty straightforward to click on and get the file, which should succeed.

Sorry, I made some mistakes in the description:

1. Thunderbird actually inserts 4 links because the download link is inserted twice with two different link texts: First with the file name and then again with the entire link as the link text. Those are the two links left and right of the *cloud logo in the screenshot.

2. the "service_url" from the FileLink provider Add-On
   In your screenshot attachment 9246305 [details], it would appear that something went wrong on the add-on side.
   The add-on is not supposed to add a very long text link right besides the attachment download link.

Very true and it doesn't. The Add-On just returns the download link to Thunderbird (see https://webextension-api.thunderbird.net/en/91/cloudFile.html#onfileupload)

This should be an iconic link to the cloud provider, placed on the right side of the box, which in turn makes the download link stand out more on its own.

2. The screenshot was made with an Add-On that does not have a "service_url", so the cloud provider logo has no link at all (and we're down to 3 links again ;-) The long link you are referring to is the second instance of the download link as inserted by Thunderbird into the template.

Comment 2

[Johannes Endres]

I think the problem is in the HTML of the template. It causes some renderers to produce output that doesn't look as intended. So far I saw this in Outlook 2016 and in Thunderbird with the "Simple HTML" setting.

Maybe they just ignore the inline styles?

Comment 3

[Thomas D. (:thomas8)]

Thanks Johannes for looking into this!
Let's confirm this based on your detailed report.

(In reply to Johannes Endres from comment #2)

I think the problem is in the HTML of the template. It causes some renderers to produce output that doesn't look as intended. So far I saw this in Outlook 2016 and in Thunderbird with the "Simple HTML" setting.

Maybe they just ignore the inline styles?

Richard, John, any insights? The addon feeds the URL into the template (https://webextension-api.thunderbird.net/en/91/cloudFile.html#onfileupload), then e.g. in Outlook 2016 or TB with "Simple HTML" view things fall apart...

Comment 4

[John Bieling (:TbSync)]

Can you attach the raw source of the email (change the email address before uploading it)?

Comment 5

[John Bieling (:TbSync)]

Attachment: link.png

Ok, I got it to work on my own. It looks nice in HTML view. The second link spells out the entire link instead of just the filename, but it is the same link.

The third link is going to the add-ons homepage.

If you simplify HTML, then the formatting is obviously lost.

What could be done is to remove the links behind the full URL (and just have it printed) and also remove the link to the add-on, if that could reduce confusion.

But tweaking the simplified view so that it looks better should not cause the html view to look worse. Do not know what we can do with the missing linebreak there. I will try something.

Comment 6

[John Bieling (:TbSync)]

For the time being, you could toggle

mail.cloud_files.inserted_urls.footer.link

to not include the app link.

Edit: This is not true, this just defines the link. But we agreed to remove it, which I will take care of in bug 1736150.

Comment 7

[Richard Marti (:Paenglab)]

(In reply to John Bieling (:TbSync) from comment #5)

What could be done is to remove the links behind the full URL (and just have it printed) and also remove the link to the add-on, if that could reduce confusion.

I think too this could be done.

Comment 8

[John Bieling (:TbSync)]

Attachment: Bug 1736208 - Improve simple HTML display of links to files uploaded by CloudFile API. r=mkmelin

Depends on D128881

Comment 9

[John Bieling (:TbSync)]

Attachment: Test.eml

This is not as easy as it seems. I was not able to remove the link from the https:// url as that gets auto created anyhow, even if not specified. So this patch tries to improve the display by adjusting the format by:

• adding line breaks
• adding spaces
• adding alternative text which is used instead of image in full simplification to plain/text

Can you try this email? How does it look in outlook?

I have not touched the provider display. I would even go one step further and completely remove the provider display from the link. For the receiving party, there is no gain to know which add-on (!) the sender used to upload the file.

To remove the superfluous download links, one has to remove the full spelled out link entirely. In the simplified view one would then get the filename and the link, in the original HTML view one would only get the filename and has to hover over the link to see its src. I do not like that. I would instead accept the inconvenience to have the link 2 times in the simplified view. Comments?

Comment 10

[Thomas D. (:thomas8)]

I propose to remove the duplicate full download link, which imho doesn't help much but makes the whole section look messy and complicated. Comments?

Looking at attachment 9246610 [details], I am failing to see the usefulness of duplicating the short file link to the cloud file by presenting the full cloud link to the same file in addition. The full download link doesn't even show the file name, just some cryptic cloud location - how is that important or helpful for downloading? I can stare at the download link for long without obtaining any security-relevant information what I'm going to get when I click that. If the file is with cloud provider X or Y doesn't matter. Plus, if the mail was forged, for using the short link (which is the more obvious click target), I would still have to check the underlying URL. Isn't this about trusting the sender rather than the link?

I'd also think that the average user may not even understand that the long link also points to the same file (for which there's no indication), which again will make them choose the short link. Knowing the cloud file domain imo also won't help much - I don't know all cloud providers out there, so it wouldn't help me much to determine from just looking at the link if the domain is good or bad, and even if the domain is good, the mail might be forged, so the file could still be bad.

Comment 11

[Johannes Endres]

(In reply to John Bieling (:TbSync) from comment #9)

I have not touched the provider display. I would even go one step further and completely remove the provider display from the link. For the receiving party, there is no gain to know which add-on (!) the sender used to upload the file.

I'd suggest to leave it as is. If the FileLink provider Add-On does not supply a "service_url" in manifest.json, the icon has no link.

Comment 12

[Johannes Endres]

(In reply to John Bieling (:TbSync) from comment #9 again)

I have not touched the provider display. I would even go one step further and completely remove the provider display from the link. For the receiving party, there is no gain to know which add-on (!) the sender used to upload the file.

The Add-On icon vs. service icon confusion results from the design of FileLink. Obviously the idea was to have one Add-On per service (see Dropbox and Box Add-Ons). IMHO the better solution for this problem is bug 1627497.

Comment 13

[John Bieling (:TbSync)]

@Thomas:

I am failing to see the usefulness of duplicating the short file link to the cloud file by presenting the full cloud link to the same file in addition

That is what I mean with

In the simplified view one would then get the filename and the link, in the original HTML view one would only get the filename and has to hover over the link to see its src. I do not like that. I would instead accept the inconvenience to have the link 2 times in the simplified view. Comments?

You do not see where the file is being downloaded from. By design, the link itself is cryptic, so it is hard to guess. But not showing it at all is dangerous and is what all those pishing mails are doing.

Maybe we should extract the domain from the link and add "hosted on cloud.something.net" instead of the full link. Magnus?

@Johannes:

I still see no point in listing *cloud there, as that is also confusing the reader. And it does link to your add-on page. So there is another confusing link in the picture. Lets get rid of that.

Comment 14

[Johannes Endres]

(In reply to John Bieling (:TbSync) from comment #13)

@Johannes:

I still see no point in listing *cloud there, as that is also confusing the reader. And it does link to your add-on page. So there is another confusing link in the picture. Lets get rid of that.

True, listing *cloud and linking to the Add-On page has no point. (The next release of *cloud will remove the link).

But it might make sense to mention the actual service, and optionally link to it? I'm not sure myself and I don't have good reasons for it.

Comment 15

[Johannes Endres]

Please look at the plain text version for a reason: It says "...hosted on *cloud...". This still doesn't make sense as it contains the Add-On name instead of the account name. But to make the account name editable in the API and insert it here would make sense. It could then say "... hosted on YMCA Bonn Cloud ..."

Comment 16

[John Bieling (:TbSync)]

I just found bug 1627497, let's use that for discussing what to do with the provider link/display. This bug will not touch it then.

So for this bug we need to decide if we should keep the full link or reduce it to the FQDN (cloud.something.net) - or better include the scheme to know if it is a secured connection or not. If there is no nay coming in I will do that.

It says "...hosted on *cloud...".

I could easily adjust the plain/text version to print "...hosted on cloud.something.net ..." in this bug to remove all the confusion and fully fix the provider link/display in bug 1627497. Good?

Do the other changes I made to the layout reduce the confusion? How does it look in outlook?

Comment 17

[Alessandro Castellani [:aleca]]

Even tho I agree that visually have 2 links, one short and one long, is not super clear, I think it's very important we keep both for these reasons:

• Showing the source of the downloadable file. Which provider has been used and where users are clicking. It's an important information for users that are concerned about safety and want to be sure what they're clicking on.
• Ability to copy and paste the full link in the browser. This is fairly important as we should keep the ability to copy/paste the full URL for users that don't want to click on a link from an email, or if the link is not clickable (maybe disabled by the user or some add-ons, is that possible?)

Maybe we should extract the domain from the link and add "hosted on cloud.something.net" instead of the full link

This might be a good addition, but it's still something that can be faked, so showing the full URL still seems like the safer solution here.

It already looks better from the screenshot on comment 5.
Maybe we could add some text to explain it, something like:

[attachment icon] Download link
or copy this URL in the browser: [full url]

Comment 18

[Richard Marti (:Paenglab)]

Adding new strings would make it not possible to uplift this patch to ESR. I propose to do this additional text in bug 1627497.

Comment 19

[John Bieling (:TbSync)]

Attachment: test2.png

Mockup: Includes original and simplified HTML. Deliberately not touching the provider link/display in this bug.

Comment 20

[Thomas D. (:thomas8)]

Sorry, but I'm still refusing to accept that adding the full download link or even "hosted on..." has any substantial safety gain.

• I think we all agree that forging the entire FileLink insert is dead-simple, right? I can just copy the HTML, tweak according to my evil purposes, and re-inject into my own message, which will look exactly like TB's original insert, but can have any links of my liking.

• As long as you keep two links, the short link (in a forged mail) can be different from the long link. So there's still 50% evil, and it's more risky than before, because you are giving users a false security that if there's a correct long link below, they don't have to verify the short link above.

• ...hosted on... looks nicer, but actually makes that security fallacy worse - now we're training users to rely on a plain-text explanation below the actual link. That's even easier to forge, and a high-risk behaviour!

• Iow, the only place to verify what the the short link will really give me is the short link itself (by checking the status bar, or copying the URL).

@aleca:

• Short link URL shows up in status bar on hover, so users concerned about safety can look at that. Which actually increases the overall safety as it avoids the long-link-to-explain-short-link fallacy described above.
• Do you know how hard it is to copy a linkified long link from message reader as text using mouse selection? The only easy way is right-click on long link > Copy link location. So you could just do that right-click on the short link, which is exactly the same, only safer.

Comment 21

[Thomas D. (:thomas8)]

(In reply to John Bieling (:TbSync) from comment #19)

Created attachment 9246681 [details]
test2.png

Mockup: Includes original and simplified HTML. Deliberately not touching the provider link/display in this bug.

If we want to keep the full link (see my caveats in comment 20), this looks great, less cramped, and the intended relationship is much clearer than before. Great job, John!

Comment 22

[Johannes Endres]

The FileLink account name is stored in mail.cloud_files.accounts.account\d+.displayName. Does it make more sense to show that instead of the Add-On name?

It defaults to the Add-On name. So most users will not see a difference because it's not obvious how to change that pref. It will start making a difference if bug 1627497 is implemented.

Comment 23

[John Bieling (:TbSync)]

Attachment: owncloud.png

I moved the new string into a dedicated bug (Bug 1736787), as that cannot be uplifted to ESR, but we should try to uplift as much as possible to improve ESR as well.

In this bug we could still try to improve the used Provider String/Icon without touching the API (which Bug 1627497 is for). In my setup screen I see the OwnCloud string and the OnwCloud icon, which seem to be autodetected. Does this reliably work? Could you try with different ownCloud/NextCloud providers?

We could use that and fallback to the current behavior.

Comment 24

[John Bieling (:TbSync)]

Oh, you are doing that in your management script, this information is not yet available to the API. I am a fool.

Comment 25

[John Bieling (:TbSync)]

I updated the patch to include the suggestion of Comment 22. The user is already able to change the account name by double-clicking on it in the management screen, no preference hack needed.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/29e6ac4158c0
Improve simple HTML display of links to files uploaded by CloudFile API. r=mkmelin

Comment 27

[John Bieling (:TbSync)]

Comment on attachment 9246653 [details]
Bug 1736208 - Improve simple HTML display of links to files uploaded by CloudFile API. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
The main feature of this patch is to use the individual account name instead of the provider name in the FileLink summary, which improves multi-type-provider add-ons (or self-hosted provides). It also improves the summary in non-html emails.

Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky):
I do not see any risks.

Comment 28

[Wayne Mery (:wsmwk)]

Comment on attachment 9246653 [details]
Bug 1736208 - Improve simple HTML display of links to files uploaded by CloudFile API. r=mkmelin

[Triage Comment]
Approved for esr91

Comment 29

[John Bieling (:TbSync)]

I found a small inconvenience introduced by this bug documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1740664#c0

I suggest to delay uplift until we found a way how to solve this.

My suggestion would be to create an ESR only version of this patch, which removes the bullet point from the final string. Would that be ok?

Comment 30

[Magnus Melin [:mkmelin]]

Sounds good.

Comment 31

[John Bieling (:TbSync)]

Slight change of course: We have to wait with uplifting this to ESR until bug 1740664 is ready for uplift as well.

Comment 32

[Wayne Mery (:wsmwk)]

Comment on attachment 9246653 [details]
Bug 1736208 - Improve simple HTML display of links to files uploaded by CloudFile API. r=mkmelin

[Approval Request Comment]
Changing back to not approved - depends on bug 1740664

Comment 33

[Wayne Mery (:wsmwk)]

Changing back to not approved - depends on bug 1740664

bug 1740664 isn't yet on beta. Is there risk or folly to taking the package on esr without it having gone through beta. Or, is it unimportant to just wait until 91.4.0 (because 91.3.1 is this week, the last planned point release before 91.4.0).

Comment 34

[John Bieling (:TbSync)]

I am torn.

I have added a couple of regressions lately, even in bugs which I thought to be "low risk". So I guess it would be good to see this baking on beta before the entire thing moves to ESR. On the other hand, bug 1740664 really seems to have no risk.

Your call. :-)

Comment 35

[Wayne Mery (:wsmwk)]

Your call. :-)

Bringing bug severity into the picture - it is marked S4, so there is no serious user impact. Therefore, we can ignore "risk" and say let's take the safer course of getting bug 1740664 on beta, and then uplift for 91.4.0.

Comment 36

[Wayne Mery (:wsmwk)]

Comment on attachment 9246653 [details]
Bug 1736208 - Improve simple HTML display of links to files uploaded by CloudFile API. r=mkmelin

[Triage Comment]
Approved for esr91

Comment 37

[Rob Lemley [:rjl]]

Thunderbird 91.4.0:
https://hg.mozilla.org/releases/comm-esr91/rev/e40fd8df0d6b