User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031015 Firebird/0.7 (MozJF) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031015 Firebird/0.7 (MozJF) It would be great if we can choose which headers we want to view and not only normal or all Reproducible: Always Steps to Reproduce: 1. 2. 3.
Summary: Choosing which Headers to view → Choosing which Headers to view
Specifically, I would greatly appreciate the ability to choose to use either a whitelist of headers to always show (making all others hidden), or a blacklist of headers to always hide (making all others visible). An additional enhancement would be to make the headers displayed newsgroup-specific.
*** Bug 264784 has been marked as a duplicate of this bug. ***
This is Seamonkey bug 61523.
The ability to choose headers to whitelist or blacklist should also allow wildcards. i.e. I'd like to whitelist "X-*" to enable all extended custom headers.
*** Bug 291938 has been marked as a duplicate of this bug. ***
As noted at the dupe, the Mnenhy extension provides this capability.
Summary: Choosing which Headers to view → Choosing which Headers to view (custom)
see bug 353193 for some backend work that allows the user to set a pref controlling what extra headers to display - it doesn't support wild-cards, however, though if there's interest, I could add that ability.
Component: Mail Window Front End → Message Reader UI
OS: Windows XP → All
QA Contact: front-end → message-reader
This RFE needs updating to reflect TB3 behaviors due to the new header panel within the message pane. TB3 dropped the Twisty that activated a compact header display, leaving just the View menu options of Normal or Full headers. There are hidden prefs for a few additional headers, referenced in Comment 7, that can be edited through Config Edit. A near term solution could be reworking the View options to offer Brief, Normal, and Full options. 1) Brief providing current normal content while blocking use of hidden prefs. 2) Normal would include existing hidden prefs and some extended content. 3) All to be same as current All content. Our code base should facilitate extensions that could deliver wild card header selections.
While I don't expect that this is utterly trivial to do right now, I wouldn't expect it to be particularly difficult either. Is there reason to believe that our existing extension points are insufficient?
You need to log in before you can comment on or make changes to this bug.