WebUI From address selected incorrectly.

[exander77]

From address should always contain address that received initial e-mail.

If I send message from thread and I am on my own mail, it will fallback to primary address.

[exander77]

A lot of the time you reply from your own e-mail, and that is currently broken.

[mjl-]

Let me see if I understand this correctly.
You've got a message thread. Perhaps from a mailing list, or just privately. If you reply to a later message, you expect the "From" address to be selected based on earlier message by any of your addresses in the thread. So the webmail should look at messages in the thread, from oldest to newest, and use the first address that belongs to your account as "From" address. Making your address sticky for the thread.

A lot of the time you reply from your own e-mail, and that is currently broken.

You're replying to your own message, and you're now getting the address you're logged in as, but you want the webmail to select the same address as in the "From" header of your own message you replied to. The mechanism described above (look for known address in thread) would also solve this case.

This seems like a reasonable and more helpful approach to address selection. May be worth checking how other mail clients are doing this. I think it may make sense to look through the thread messages from newest to oldest (not oldest to newest) for known addresses, so you can switch addresses if you want to.

[exander77]

Yes, that is basically how I encountered it elsewhere. As very common use case is that you respond to a message, and then you respond again to your message where you are adding some new information. It is so common, I got hit by it several times after single day use. I respond a lot to a message thread adding new information.

[mjl-]

Ok, let's implement it that way. The required information is available in the webmail in the browser (at least when threaded view is on, but that should be a prerequisite). May take a little while before I get to it. If you're interested in trying to implement it, I could give pointers.

[exander77]

Ok, let's implement it that way. The required information is available in the webmail in the browser (at least when threaded view is on, but that should be a prerequisite). May take a little while before I get to it. If you're interested in trying to implement it, I could give pointers.

I would be interested into looking at the code, but I would really need some pointers, seems like one huge file, went through it briefly. Is there an easy way to test UI on my existing mox install?

[mjl-]

I would be interested into looking at the code, but I would really need some pointers, seems like one huge file, went through it briefly. Is there an easy way to test UI on my existing mox install?

You could create files webmail/webmail.{html,js} in the working directory
where you start mox. If those files exist, they will be served when the
webmail endpoint is requested. If they don't exist (the normal case for
deployed mox), the builtin files will be served.

mox/webmail/webmail.go

Line 63 in 3d4cd00

//go:embed webmail.html

mox/webmail/webmail.go

Line 149 in 3d4cd00

var webmailFile = &mox.WebappFile{

mox/webmail/webmail.go

Line 232 in 3d4cd00

webmailFile.Serve(ctx, log, w, r)

mox/mox-/webappfile.go

Line 57 in 3d4cd00

func (a *WebappFile) Serve(ctx context.Context, log mlog.Log, w http.ResponseWriter, r *http.Request) {

But for development, I would suggest running "mox localserve". It runs
locally and looks like a regular mox, it has a full webmail at
http://localhost:1080/webmail/. You could run make tswatch (on Linux at
least), and any change to webmail/*.ts will compile a new webmail.js.
Reloading the webmail page then gets you the new code. You could import some
test messages for experimentation, or compose & send some to non-existent
addresses: everything is delivered to the mox account (part of the localserve
mode).

It is indeed one big file, the structure won't be as obvious as if it would be in separate files. Things to look for are the "View" types and new.*View functions. I think you'll need to look at MsglistView and MsgitemView, they should have (or at least reference) the addressee information you're looking for.

mox/webmail/webmail.ts

Line 3604 in 3d4cd00

// MsglistView holds the list of messages for a mailbox/search query. Zero or more

mox/webmail/webmail.ts

Line 2361 in 3d4cd00

// MsgitemView is a message-line in the list of messages. Selecting it loads and displays the message, a MsgView.

The addressees are in the Envelope field of a MessageItem (api.ts and its
types are generated from the Go code):

https://github.com/mjl-/mox/blob/3d4cd004309469fb1fddbf3f89afc5ab111823ac/webmail/api.ts#L295C12-L295C27

[John-S4]

You could create files webmail/webmail.{html,js} in the working directory
where you start mox. If those files exist, they will be served when the
webmail endpoint is requested. If they don't exist (the normal case for
deployed mox), the builtin files will be served.

Sorry, I know this is an aside and not actually the point being discussed here, but this just caught my eye...

Just to clarify, this works kind of like a template override?
If that is the case does it work with the web admin and accounts pages as well, or only for webmail?

I just gave it a try by creating a /webmail/webmail.html file and restarting mox but didn't get my new file, but if that is how it is supposed to work then I will give it another go.