376445 - (andré2) When the header view is collapsed and there is a notification, the notification bar takes up too much space

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[andré]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1

[I opened a separate bug from 360288 since it is already marked as fixed, and this problem is basicly a side effect of the fix - ]

Previously, if the preference to block images in email was selected, only images were blocked.  (Preferences > Email+Forums > Message_Display > second item)
(Alternately about:config mailnews.message_display.disable_remote_image = true)

Starting with Seamonkey 1.1, all remote content is blocked, according to fixes with bug 360288.  These fixes introduced a remote content bar, which blocks about 4 lines of the main message window, greatly restricting the viewable area.

A much better solution would be to instead display an icon in the status bar which, on being clicked, would display a menu such as appears in the introduced remote_content bar.  (One could use the same icon.)
This menu could also be displayed on clicking an image icon (or even an image if one wishes to block remote content).

The options displayed should be appropriate to the current settings.
I.e., if messages are already blocked, then clicking on an image icon should not propose blocking images from the current server - as is now the case when clicking an image under Seamonkey 1.1.1.
(Note that I updated directly from 1.0.7 to 1.1.1, so I haven't seen 1.1.0)

By the way, image icons appear in the place of blocked remote images.
It would be a nice enhancement if the height of blocked images were reduced to the height of the image icon, to allow reading more of the email in question without scrolling.

Note that the variables displayed in the remote_content bar are "remoteContentMessage.label" and loadRemoteContentButton.label" in messenger.dtd, and "alwaysLoadRemoteContentForSender" in messenger.properties.
The icon is messenger/icons/remote-blocked.png in classic.jar or modern.jar, according to the theme.  (It appears to be the same image in both files.)

Reproducible: Always

Steps to Reproduce:
1. Ensure that remote content is blocked.
  (about:config mailnews.message_display.disable_remote_image = true)

2. Open an email which contains a remote message.

Actual Results:  
You see the big ugly remote content bar.

Note that previously there was no remote content bar, the only effect was that images were replaced by icons.
(By the way, the new icons replacing the images are MUCH NICER LOOKING, THANK YOU.)

Expected Results:  
A nice friendly icon in the status bar, much like the one indicating a secure site or restricted cookies, etc.
(It should be half the height/width of the icon in the remote content bar.)

I use the classic theme, but it should be the same with modern.  (They both use exactly the same icon and variables.)
Comments in bug 360288 (mentioned above) indicated that the same code was to be ported to Thunderbird.

Comment 1

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 2

[andré]

Attachment: icon "image blocked" 32x62 px

Identical symptoms in v1.1.9.
Very simple to reproduce -- simply look at an email with remote images, while the global setting is to block remote content and the source email adresse is not set to permit remote content.  (You could always send yourself an image from another email adresse.)

The symptoms have not changed since reporting the problem, and I've installed (at least almost) all the updates.
(Although I use the ms-windows version, I usually assess Mozilla via Wine on Linux.  This ensures compatibility for email retrieved on either system.
It works identically on both operating systems, including the symptoms here.)

But I have an idea that might help -- in place of the images not downloaded, place an icon that says "image blocked", instead of the plain icon now displayed.  I'm sending a very rough sample of my idea.
The icon in the status line would still be useful, since the blocked content need not be visible, or could be in an obscure location.  (further down or to the right)

A context menu could be associated with these icons, to give access to the 2 options in the current bar : unblock remote content (mostly images) for the current email adresse -and- unblock all remote email content.

Hope these suggestions help.

Comment 3

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre SeaMonkey/2.1b2pre - Build ID: 20101207033857

IIRC, currently the "remote content blocked" warning is a horizontal banner, blocking none of the content (which can be scrolled if long), with a link to allow all remote content from this sender (by creating an appropriate address book entry) and a button to allow remote content in this message only.

André, please retest with a recent build (at the moment that would mean SeaMonkey 2.0.10 or later).

Comment 4

[andré]

I've been on Linux exclusively with Seamonkey since shortly after reporting this bug, and there are the same symptoms.

The problem is a very big horizontal banner which blocks a large part of the viewing area.  To let users know something that they should realize after seeing this warning once or twice, if they haven't already reviewed the configuration setting after installation.
A simple warning icon in the status bar would be just as useful, and much less intrusive.

Sure, one can scroll around the problem, but why require additional scrolling around something that adds nothing to user experience.  It's about the same size as those annoying banner adds - and just as annoying and useless.

I made a (very clumsy temporory) patch, to avoid the problem, which I reapply with each new version.
I've just downloaded 2.0.11 to replace the currently installed 2.0.10.
I'll test it later this evening.

Comment 5

[andré]

Attachment: Diff of comments added to mailWindowOverlay.js to deactive remote content bar

Diff of workaround to deactive remote content bar.
Just devactivates some routines in messenger.jar/content/messenger/mailWindowOverlay.js

This was done a long time ago.  Some routines were probably unnecessarily deactivated, and there may be side effects.

Comment 6

[andré]

Indeed, the problem is still there with sm 2.0.11.

In my configuration, the bar takes about 20% of the vertical space free for displaying an email.  (It is used in conjuction with other applications, so never in full screen mode.)

Since I can receive 100 emails in a day, blocking images saves a lot of disk space and time.
Many users may not be bothered by the banner-ad sized notice, but it does interfere with efficiently reviewing emails

Comment 7

[Phoenix]

Is this still reproducible in modern SeaMonkey versions?

Comment 8

[Philip Chee]

Also please provide a screenshot of the problem.

Comment 9

[andré]

@ Phoenix
Yes, it still applies to "modern" versions.

@Philip Chee
Can't provide a screenshot since I've patched my installed Seamonkey.
However it is easily reproduceable on unpatched Seamonkey by globally setting to block all remote content in emails, then viewing an email with remote content.
Note that on smaller window sizes, the space taken by this redundant message becomes much more significant.

Comment 10

[Phoenix]

(In reply to andré from comment #9)
> @Philip Chee
> Can't provide a screenshot since I've patched my installed Seamonkey.
You can download unpatched version, unpack it to separate folder, run and make a screenshot of the problem

Comment 11

[andré]

Attachment: screenshot of notice of blocked remote content

This shows the remote content notice.
Note that each blocked content is replace by an icon, so the notice is of little use to anyone familiar with Seamonkey.
The screenshot program added a bar under the window, and a heading above.
The screenshot covers the Seamonkey mail window, which is not full screen.

Comment 12

[andré]

@Philip Chee
The screenshot shows the typical email window size, since I'm usually working with other windows in relation to the email messages.
The third bar from the top ("Afficher ...") is usually disabled (not displayed), but the unpatched version that I used to produce the screenshot is not fully configured.

In the screenshot, you can see an icon that is displayed in place of the remote content.
(At top left under the Subject line.)

Comment 13

[Ian Neal]

Confirming, I would classify this as an enhancement. I would propose that when the header view is collapsed there is an icon to indicate there is a notification (similar to the way there is one for attachments present).

Comment 14

[andré]

I'm not sure that I would call that an enhancement.  It really increases the time used to read a lot of emails.
Note that attachment 2 [details] [diff] [review] is my cludge that disables the notification bar - so someone more familiar with the code could probably better solve the problem relatively quickly.

There used to be an icon for this in the bar at the bottom, towards the right -- I think maybe before the notification bar was implemented  - but certainly not in 2.0.14 or since

Comment 15

[Philip Chee]

We could get ewong to port his notification box patch from Thunderbird to SeaMonkey MailNews. Would that help?

Comment 16

[Tony Mechelynck [:tonymec]]

In reply to comment #14:
Depending on opinion, this bug can be regarded as an "enhancement" (would make the product better, but there's no loss of function), "trivial" (cosmetic) or at the very most "minor" (minor loss of function, or easy workaround is present). Certainly not higher. If Ian (a SeaMonkey MailNews peer) says it's an enhancement, it probably is, unless Karsten (SeaMonkey MailNews owner) overrides him.

See also https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity

Comment 17

[andré]

(In reply to Philip Chee from comment #15)
> We could get ewong to port his notification box patch from Thunderbird to
> SeaMonkey MailNews. Would that help?

Thanks.  I don't know what it looks like, but if it solves the problem, I would really appreciate it :)
Ideally, the notification bar would disappear (at least by an option).
But anything that would reduce its' size would help.

The suggestion to make the notification disappear when the header view is collapsed sounds would work well for me.


(In reply to Tony Mechelynck [:tonymec] from comment #16)
> In reply to comment #14:
> Depending on opinion, this bug can be regarded as an "enhancement" (would
> make the product better, but there's no loss of function), "trivial"
> (cosmetic) or at the very most "minor" (minor loss of function, or easy
> workaround is present). Certainly not higher. If Ian (a SeaMonkey MailNews
> peer) says it's an enhancement, it probably is, unless Karsten (SeaMonkey
> MailNews owner) overrides him.
> 
> See also https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity

This depends whether one considers the loss of space a loss of function.
Under my circonstances, I would definitely say yes, for many of my emails.
But whatever it is called, I would be very happy to see a solution.

I'm just trying to return to the previous state with 4 more lines available for displaying my emails with unwanted remote content.
My cludge works, in the sense that it totally prevents the notification bar from appearing.  (But it may cause some unintended loss of function that I don't see)
But it must be reapplied every time I upgrade, and with the new omni.ja format and very frequent upgrades, it is a lot trickier and more time-consuming to apply.

Comment 18

[Philip Chee]

> Confirming, I would classify this as an enhancement. I would propose that when the
> header view is collapsed there is an icon to indicate there is a notification
> (similar to the way there is one for attachments present).
Good idea but make that icon a doorhanger since we already have the code for it somewhere.

Comment 19

[andré]

This problem is still present in Seamonkey 2.25
It is also present in Thunderbird 24.5

Comment 20

[andré]

(In reply to Philip Chee from comment #18)
> > Confirming, I would classify this as an enhancement. I would propose that when the
> > header view is collapsed there is an icon to indicate there is a notification
> > (similar to the way there is one for attachments present).

That would work very well for me :)
Also then no need for an extra option for those not concerned about the space taken.

> Good idea but make that icon a doorhanger since we already have the code for
> it somewhere.

Is there any progress on this ?
Or any way I could help ?  (Although I'm a programmer, I have minimal knowledge of the Mozilla interface.)

Comment 21

[andré]

There has been an "x" added to the 5-line remote content warning banner, which makes the banner disappear (until the next time I view the message).
But I find that clicking the "x" many hundred of times a week is very time consuming for remote content that I never ever want to see.

I suggest a supplementary solution that should satisfy everyone, with minimal changes :
change the current boolean variable "mailnews.message_display.disable_remote_image"
to a numeric variable where
0 = always show remote content
1 = always ask to show remote content, and
2 = never show or ask to show remote content.
(Could abbreviate to "0=always show  1=ask  2=never show".)

"1" could remain the default, but users like myself who NEVER want to see external remote content could choose "2".

Then the remote content banner should also include the option "don't ask me again", which when clicked would change the value from "1" to "2".

This would be a lot simpler (and more evident) than adding an icon.

Hopefully this will come soon ?

Comment 22

[andré]

BTW, referring to SM 2.26.1