1227787 - Clicking wide images which have links zooms image rather than open link destination

Status: RESOLVED INVALID

(Thunderbird :: Message Reader UI, defect)

Description

[elic]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151030083932

Steps to reproduce:

1. Receive an email with an embedded image which is a link that is wider than the message window area.
e.g. assuming the message reader area is 800px wide, if the body of the received email contains
<a href="http://www.example.com"><img src="http://lorempixel.com/1000/800" width="1000"></a>
2. Attempt to follow the hyperlink by clicking on the image



Actual results:

The cursor turned into a magnifying glass with a plus/minus icon and the image toggled between full size and fitting into the width of the window each time I clicked on it


Expected results:

Clicking the link should have opened the link destination

Comment 1

[elic]

NB This problem exists at least on Ubuntu and Windows 7.

Comment 2

[aleth [:aleth]]

This came up on #maildev.

Is this a bug or the expected behaviour? i.e. should the shrinktofit attribute not be added to imgs inside <a> tags?

Comment 3

[elic]

Well, I would have expected that the image does shrink to fit but that clicking on it would follow the link rather than zoom the image.

If I wanted to zoom the image I would right click on it, so maybe for this case the default "click" action could be to follow the hyperlink and if someone wants to zoom the image it could be added to the right click menu?

Comment 4

[:Dossy Shiobara]

One of the problems with passing through the "click" event to an image that is in the shrunken state is that client-side imagemaps (MAP and AREA elements) coordinates aren't scaled accordingly, so the (x,y) where the click occurs on the visual representation of the image may not line up with the imagemap AREA that was supposed to correspond with the area of the image that was clicked.

Comment 5

[Magnus Melin [:mkmelin]]

I don't think shrinktofit was ever supposed to affect anything but attached imaged showed inline. That is affects pictures elsewhere is just  a bug.

Comment 6

[alta88]

Shrinktofit is working exactly as designed. It's an important design point to very much avoid horizontal scroll, and there isn't and shouldn't be any difference between shrinktofit for attachments/feed enclosures rendered inline, and any image (link or not) contained within the message body.

Since the image is altered (shrunktofit) it is important to give a visual feedback and ability to restore to original, which is done with the cursor indication and left click toggle. This takes precedence, correctly, over left click link following, for shrunk images only; links are opened with right click contextmenu for shrunk images.

People who really want to do the Wrong Thing and provide a bad horizontal scrolled image experience can defeat shrinktofit with some combination of div layers and css so the overflow isn't caught on the image itself.

Shrinktofit for images was ui-r+ by bwinton and this bug should be closed invalid.

Comment 7

[:Dossy Shiobara]

> People who really want to do the Wrong Thing and provide a bad horizontal scrolled image experience can defeat shrinktofit with some combination of div layers and css so the overflow isn't caught on the image itself.

This is absolutely untrue as of TB 38.5.1 on OSX where I have tested extensively: shrinktofit only looks at the message pane width and the image's native width regardless of how it's been styled or its parent element overflow attribute.  I can provide a very simple test case demonstrating this.

Also, I discovered another bug: if the IMG is wrapped in an A element, the right-click context menu doesn't provide the "Open Link in Browser" for the A HREF, at least if the IMG has client-side imagemap defined ("USEMAP").  It will give the "Open Link in Browser" for the imagemap-defined areas, but the rest of the image that isn't covered by the imagemap should open the A HREF link, which TB doesn't give the option for when right-clicking on the shrinktofit image.

If shrinktofit is working as designed, then go ahead and close this bug as invalid, so we can raise a bug that shrinktofit's design is bad and should be removed.  It's a feature that's looking for a problem: it's not solving a problem that needs this as a solution.

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to alta88 from comment #6)
> Shrinktofit is working exactly as designed. It's an important design point
> to very much avoid horizontal scroll, and there isn't and shouldn't be any
> difference between shrinktofit for attachments/feed enclosures rendered
> inline, and any image (link or not) contained within the message body.

For an image in a html mail, surely it's displaying the way the author intended. I don't know why anyone would put gigantic images in there though? This is in great contrast to "just attached an image" which got rendered inline.

Comment 9

[:Dossy Shiobara]

(In reply to Magnus Melin from comment #8)
> For an image in a html mail, surely it's displaying the way the author
> intended. I don't know why anyone would put gigantic images in there though?
> This is in great contrast to "just attached an image" which got rendered
> inline.

Define "gigantic."  Since the sender of the message does NOT control the width of the message pane of the receiver, a 400px wide image could trigger shrinktofit if the message pane is narrow enough - I use TB in the 3-pane layout (View > Layout > Vertical View, +Folder Pane, +Message Pane) and my message pane is ~700px wide, just wide enough for 80-character fixed width text Courier 14px.  Images that might normally not exceed other people's message panes at 1600x1200 full-screen will certainly be "gigantic" for me.

Really, the whole shrinktofit idea is a terrible user experience.  Plus, the implementation gives the end user reading the mail no control (no way to turn it off in any preference setting) nor the sender any control (CSS/style to turn it off).

Comment 10

[alta88]

(In reply to Magnus Melin from comment #8)
> (In reply to alta88 from comment #6)
> > Shrinktofit is working exactly as designed. It's an important design point
> > to very much avoid horizontal scroll, and there isn't and shouldn't be any
> > difference between shrinktofit for attachments/feed enclosures rendered
> > inline, and any image (link or not) contained within the message body.
> 
> For an image in a html mail, surely it's displaying the way the author
> intended. I don't know why anyone would put gigantic images in there though?
> This is in great contrast to "just attached an image" which got rendered
> inline.

I couldn't disagree more strongly. Authors may or may not know what they're doing; they may be email spammers tricking for clicks; and they *absolutely* do not know the preferred viewport size of the recipient. I do not believe you will find any user who prefers a gigantic horizontally scrolled image to one that fits the viewport. Nor is it clear how this is in great contrast to inline attachments, in any way. A gigantic image is completely unfriendly and a sign of bad/nonexistent design - almost as though the enormous effort to size/layout pages comfortably without horizontal scroll for differing device sizes were completely unknown.

Tb's obligation here is to the user, not the author. And all it takes is - one click - to see the original.

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin from comment #5)
> I don't think shrinktofit was ever supposed to affect anything but attached
> imaged showed inline. That is affects pictures elsewhere is just  a bug.

https://mzl.la/2xVBXeH(In reply to alta88 from comment #6)
> Shrinktofit is working exactly as designed. It's an important design point
> to very much avoid horizontal scroll, and there isn't and shouldn't be any
> difference between shrinktofit for attachments/feed enclosures rendered
> inline, and any image (link or not) contained within the message body.
> ...
> Shrinktofit for images was ui-r+ by bwinton and this bug should be closed
> invalid.

That was bug 534083