373481 - ability to allow javascript in individual Tb messages

Status: UNCONFIRMED

(Thunderbird :: Mail Window Front End, enhancement)

Description

[alta88]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: 


With the javascript.allow.mailnews pref well hidden (correctly), there however needs to be a way to allow it on an individual message basis.  It would be wrong to have multimedia or other features enabled by js DOA in Tb.

This should work exactly the way the Block Remote Images notifier does:
1)allow one time load of images [js] for that message
2)allow whitelist of trusted senders or sites(rss/newsgroups)
3)immediate reload of message for pref change to take effect
4)warning message is important

Bugs 312110 and 278744 are ok, but imo too broad.  Js is likely sometimes desired in mail and mostly in rss, but this is certainly not always true for either.  CAPS policies are beyond average users.

Thanks.

Reproducible: Always

Comment 1

[chrizilla]

I fully agree with the description above.
At least there should be way to enable js for RSS accounts via an account based approach.

Comment 2

[Ronald Killmer]

The addition of a field to the Abooks to flag trusted/untrusted senders would complement the notifier being proposed. I get lots of Opt-In HTML format newsletters and advertising circulars which could include JS and for which I may want JS disabled. Such flags in collected Abook should enable an override of javascript.allow.mailnews true in Prefs.js if the Abooks are used as a whitelist source.

  

Comment 3

[alta88]

the whitelist needs to be for both 1)senders and 2)websites.  addressbook is fine for the former, but if rss and newsgroups are to be supported, then the latter is required also - it would make more sense to store that in the same way Fx does.

Comment 4

[Ronald Killmer]

Reference:
http://kb.mozillazine.org/Allowing_only_certain_sites_to_use_JavaScript

The method presented at mozillaZine KB may be OK for an enterprise with an IM staff, but sucks for General Public Users. I see two flaws with current policy.

1.) No clues to users choice to use CAPS to create user.js loaded CAPS modifications.
2.) No clues that the referenced article exists as a guide to drafting a User CAPS policy.

For years I turned on JS globally just to have the functionality for multimedia testing. While the highly restrictive Tb CAPS prohibit more JS than Fx, there are legitimate uses that We are not now allowing on any basis when JS is globally set to off. 

alta88 presented a good starting implementation framework. I think we should do a full top down review of CAPS, but that is for m.d.a.t discussion.