Open Bug 543954 Opened 14 years ago Updated 2 years ago

Rewrite mail header pane in XHTML

Categories

(Thunderbird :: Message Reader UI, enhancement)

Product:
Thunderbird
Component:
Message Reader UI
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: BenB, Assigned: BenB)

References

Details

The current implementation of the mail header pane (the part of the main window which shows the header information of the email currently displayed - the part showing From: To:, CC:, Reply-To: etc.. *Not* the list of emails.) is currently implemented in XUL and I think is still the same implementation since the very beginning.

It has a number of problems:
* Subject didn't wrap (Bug 489609). That's now fixed, but fragile.
* From/To don't wrap (Bug 520249 - one of the reasons to fix this bug)
* From/To don't expand as desired. (Workarounds: bug 530239, bug 456596)

Other things to consider, which we want to do in the long term:
* Scroll header pane with message (Bug 9942)
* Conversation view ala GMail (Bug 241197)


dmose, who implemented the new style of the header pane, contemplated to rewrite it as XHTML on that occasion (end 2008/start 2009 IIRC), but didn't. He now regrets that he didn't, given how fragile it is, and agrees that the headerpane should be re-written in XHTML. When I implemented subjectwrap, I had lots of regressions, most of them due to bad or fragile older code. The code is simply a mess. So, a fresh start will be good.

One thing I'm not sure of, given that the current headerpane uses a lot of XBL, is whether I'll use XBL or just invent my own in pure JS.
Blocks: 520249
I wouldn't bother rewriting the header pane. I'd just dump it. Instead, I'd suggest improving the MIME emitter that we already use for print preview to handle all the features we need in the message header, such as linked email addresses (for use with an enhanced context menu).
Are you suggesting to put the header pane in content frame, running as untrusted page?
That's not going to work, because we need secure space. Not only for features like "Add to address book", which possibly indeed could be done by adding chrome features to content, but to securely show "signed", "spam", "phishing" icons etc.., otherwise a phishing mail could spoof the signed and hide the phishing indicator. That plus the button toolbar etc.pp.
Ah yes, I'd forgotton about those security icons (although SeaMonkey contains duplicates in the status bar, so it's not a complete loss), but the infobars and toolbars would of course have to remain where they are.
I'm wondering if and how customizing the toolbar for the header-pane buttons (pending as bug 519956) would be possible in XHMTL, including the palette.

> (comment #0) It has a number of problems:
> * Subject didn't wrap (Bug 489609). That's now fixed, but fragile.

This would benefit from XUL bug 492645 being fixed, or do you see another reason for considering this fragile?

> * From/To don't wrap (Bug 520249 - one of the reasons to fix this bug)
> * From/To don't expand as desired. (Workarounds: bug 530239, bug 456596)

I'm still having problems with tying bug 456596 to bug 530239, the need for configuration of the default view (i.e., number of addresses) is independent from the wrap/expand issue or an implementation in XHTML vs. XUL. Either way, that feature would have to be (re-)implemented to be available for the user.

> Other things to consider, which we want to do in the long term:
> * Scroll header pane with message (Bug 9942)

Don't forget its "competitors", i.e., bug 464309 and somehow related bug 325144 (where I'm still struggling to see the differences). Based on the discussions there, I don't see an agreement that this should be implemented (at least not as the only viewing mode or as the default).

> dmose, who implemented the new style of the header pane, contemplated to
> rewrite it as XHTML on that occasion (end 2008/start 2009 IIRC), but didn't. He
> now regrets that he didn't, given how fragile it is, and agrees that the
> headerpane should be re-written in XHTML.

So, what would you see as the time frame? There are various header-pane related bugs (all of which strictly speaking should block this rewrite bug), and some have patches ready to go for TB 3.1 or close to be finalized. It wouldn't be prudent to delay improvements of the current XUL-based header pane which still can make 3.1, just because of the argument that those features would have to be reimplemented in XHTML later then anyway...
> if and how customizing the toolbar for the header-pane buttons
> would be possible in XHMTL

I'll probably continue to use the XUL toolbar / buttons, so it should be the same.
Based on discussion with Mnyromyr, author of the Mnenhy extension:
* I want to create an API where extensions can subscribe to certain message headers or all of them, in a subscribe/observer pattern style. That would remove the need to replace messageHeaderSink.processHeaders() and similar hacks.
* Independently, I also want to add a UI place where extensions can add headers and another place for icons / additional UI.
(In reply to comment #5)
> It wouldn't be prudent to delay improvements of the current XUL-based header
> pane which still can make 3.1, just because of the argument that those
> features would have to be reimplemented in XHTML later then anyway...

Agreed.  I don't expect 3.1 to be able to accommodate this level of change.  

On a slightly bigger picture front, one of our takeaways from the 3.0 cycle, and the header changes in particular, were that it's often better for non-trivial feature changes to start and iterate as extensions and only later decide if and how they should land in the core.  Bryan and Blake already have more than one such extension underway, and this feels very much like it wants to fall into that category.

My suggestion here, therefore, would be to write this new header pane _entirely_ as an extension, filing Bugzilla bugs about extension points that you need along the way.  This also means you can move much faster since you won't need to wait for advice and reviews from core developers along the way.
Yes, I agree this is not 3.1 fudder.

Yes, I have already created a repo for this as extension
<https://hg.mozilla.org/users/mozilla.BenB_bucksch.org/mail-headerpane-ext/>
and started a stub extension. For me, branch vs. extension is purely a technical choice, though, and has only little effect on the way I work. Specifically, the goal and timeline for it remains the same, and so does involvement and reviews of other developers.
(In reply to comment #9)
> Yes, I have already created a repo for this as extension
> <https://hg.mozilla.org/users/mozilla.BenB_bucksch.org/mail-headerpane-ext/>
> and started a stub extension.

Great!

> Specifically, the goal and timeline for it remains the same

Skimming this bug, it's not clear to me what exactly you mean by this.  What do you perceive both the goal and the timeline to be?

> and so does involvement and reviews of other developers.

In a world with infinite development and design resources, sure.  We don't live in that world, however, and other devs need to opt their time in here...
> What do you perceive both the goal and the timeline to be?

The goal is to get this into 3.2, and have it land (checked into comm-central) within a few weeks after the development finished.
When and if I finish development depends on a lot on my other projects.
Due to the long time it too land bug 525238, I have no more (paid) time left to work on this, unfortunately. I may do it on my own, but I don't know.
I mentioned this in bug 667384, but I really don't think this bug is valuable, at least not as stated. There's nothing intrinsic about XHTML that makes it better than XUL; far from it, since we'll lose nice things like toolbar customization (via document.persist, which only works from XUL documents as I recall) and context/popup menus, which can't be set in HTML (you can set a single context menu on the containing <browser> and dynamically show/hide elements based on what you clicked on, but that gets obnoxious quickly).

It sounds like there are basically three issues that prompted this bug:

1) XUL's box model is painful for doing certain kinds of layouting.
2) There's no good way to scroll the headers with the message.
3) Conversation view

(1) is a non-issue, since you can use the HTML layout model from XUL just by setting display:block or display:inline (or any of the other HTML display types). Judicious use of this should resolve most of the funkiness in terms of text wrapping. As far as I know, everything with this should Just Work, so it shouldn't be a significant effort to maintain.

(2) is just as much of an issue from XHTML as it is from XUL. Currently, the only workable way to handle this would be to emit the message header from libmime, which is not a task I'd wish on anyone (emitting inline attachments is bad enough). If Firefox devs implement seamless iframes, we can do this easily in XUL or XHTML (barring any strange complications).

Protz's Thunderbird Conversations shows that we don't really need to fix this to make (3) work either. Even then, Conversations could be implemented in XUL.

That said, a "clean up the message header" bug would be totally welcome. I just don't think XHTML is going to give us anything we don't already have, save for using a more familiar set of tags.
Here is an add-on which implements the header with HTML:
https://addons.mozilla.org/en-US/thunderbird/addon/totalmessage/

Otherwise just my € .02 as author of the CompactHeader adddon:
I don't really see any advantages in using HTML. And a lot of problems, e.g. for the toolbar in the header.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.