serv/mox
1
0
Fork 0
mirror of https://github.com/mjl-/mox.git synced 2024-12-27 08:53:48 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions
mox/webmail/lib.ts

513 lines
21 KiB
TypeScript
Raw Normal View History

add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
// Javascript is generated from typescript, do not modify generated javascript because changes will be overwritten.
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
// We build CSS rules in JS. For several reasons:
// - To keep the style definitions closer to their use.
// - To make it easier to provide both light/regular and dark mode colors.
// - To use class names for styling, instead of the the many inline styles.
// Makes it easier to look through a DOM, and easier to change the style of all
// instances of a class.
// We keep the default/regular styles and dark-mode styles in separate stylesheets.
const cssStyle = dom.style(attr.type('text/css'))
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
document.head.prepend(cssStyle)
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
const styleSheet = cssStyle.sheet!
const cssStyleDark = dom.style(attr.type('text/css'))
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
document.head.prepend(cssStyleDark)
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
const styleSheetDark = cssStyleDark.sheet!
styleSheetDark.insertRule('@media (prefers-color-scheme: dark) {}')
const darkModeRule = styleSheetDark.cssRules[0] as CSSMediaRule
let cssRules: { [selector: string]: string} = {} // For ensuring a selector has a single definition.
// Ensure a selector has the given style properties. If a style value is an array,
// it must have 2 elements. The first is the default value, the second used for a
// rule for dark mode.
const ensureCSS = (selector: string, styles: { [prop: string]: string | number | string[] }, important?: boolean) => {
// Check that a selector isn't added again with different styling. Only during development.
const checkConsistency = location.hostname === 'localhost'
if (cssRules[selector]) {
if (checkConsistency) {
const exp = JSON.stringify(styles)
if (cssRules[selector] !== exp) {
throw new Error('duplicate css rule for selector '+selector+', had '+cssRules[selector] + ', next '+exp)
}
}
return
}
cssRules[selector] = checkConsistency ? JSON.stringify(styles) : 'x'
const index = styleSheet.cssRules.length
styleSheet.insertRule(selector + ' {}', index)
const st = (styleSheet.cssRules[index] as CSSStyleRule).style
let darkst: CSSStyleDeclaration | undefined
for (let [k, v] of Object.entries(styles)) {
// We've kept the camel-case in our code which we had from when we did "st[prop] =
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
// value". It is more convenient as object keys. So convert to kebab-case, but only
// if this is not a css property.
if (!k.startsWith('--')) {
k = k.replace(/[A-Z]/g, s => '-'+s.toLowerCase())
}
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
if (Array.isArray(v)) {
if (v.length !== 2) {
throw new Error('2 elements required for light/dark mode style, got '+v.length)
}
if (!darkst) {
const darkIndex = darkModeRule.cssRules.length
darkModeRule.insertRule(selector + ' {}', darkIndex)
darkst = (darkModeRule.cssRules[darkIndex] as CSSStyleRule).style
}
st.setProperty(k, ''+v[0], important ? 'important' : '')
darkst.setProperty(k, ''+v[1], important ? 'important' : '')
} else {
st.setProperty(k, ''+v, important ? 'important' : '')
}
}
}
// Ensure CSS styling exists for a class, returning the same kind of object
// returned by dom._class, for use with dom.*-building functions.
const css = (className: string, styles: { [prop: string]: string | number | string[] }, important?: boolean): { _class: string[] } => {
ensureCSS('.'+className, styles, important)
return dom._class(className)
}
// todo: reduce number of colors. hopefully we can derive some colors from a few base colors (making them brighter/darker, or shifting hue, etc). then make them configurable through settings.
// todo: add the standard padding and border-radius, perhaps more.
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
// We define css variables, making them easy to override.
ensureCSS(':root', {
'--color': ['black', '#ddd'],
'--colorMild': ['#555', '#bbb'],
'--colorMilder': ['#666', '#aaa'],
'--backgroundColor': ['white', '#222'],
'--backgroundColorMild': ['#f8f8f8', '#080808'],
'--backgroundColorMilder': ['#999', '#777'],
'--borderColor': ['#ccc', '#333'],
'--mailboxesTopBackgroundColor': ['#fdfdf1', '#1a1200'],
'--msglistBackgroundColor': ['#f5ffff', '#04130d'],
'--boxShadow': ['0 0 20px rgba(0, 0, 0, 0.1)', '0px 0px 20px #000'],
'--buttonBackground': ['#eee', '#222'],
'--buttonBorderColor': ['#888', '#666'],
'--buttonHoverBackground': ['#ddd', '#333'],
'--overlayOpaqueBackgroundColor': ['#eee', '#011'],
'--overlayBackgroundColor': ['rgba(0, 0, 0, 0.2)', 'rgba(0, 0, 0, 0.5)'],
'--popupColor': ['black', 'white'],
'--popupBackgroundColor': ['white', '#313233'],
'--popupBorderColor': ['#ccc', '#555'],
'--highlightBackground': ['gold', '#a70167'],
'--highlightBorderColor': ['#8c7600', '#fd1fa7'],
'--highlightBackgroundHover': ['#ffbd21', '#710447'],
'--mailboxActiveBackground': ['linear-gradient(135deg, #ffc7ab 0%, #ffdeab 100%)', 'linear-gradient(135deg, #b63d00 0%, #8c5a0d 100%)'],
'--mailboxHoverBackgroundColor': ['#eee', '#421f15'],
'--msgItemActiveBackground': ['linear-gradient(135deg, #8bc8ff 0%, #8ee5ff 100%)', 'linear-gradient(135deg, #045cac 0%, #027ba0 100%)'],
'--msgItemHoverBackgroundColor': ['#eee', '#073348'],
'--msgItemFocusBorderColor': ['#2685ff', '#2685ff'],
'--buttonTristateOnBackground': ['#c4ffa9', '#277e00'],
'--buttonTristateOffBackground': ['#ffb192', '#bf410f'],
'--warningBackgroundColor': ['#ffca91', '#a85700'],
'--successBackground': ['#d2f791', '#1fa204'],
'--emphasisBackground': ['#666', '#aaa'],
// For authentication/security results.
'--underlineGreen': '#50c40f',
'--underlineRed': '#e15d1c',
'--underlineBlue': '#09f',
'--underlineGrey': '#888',
'--quoted1Color': ['#03828f', '#71f2ff'], // red
'--quoted2Color': ['#c7445c', '#ec4c4c'], // green
'--quoted3Color': ['#417c10', '#73e614'], // blue
'--scriptSwitchUnderlineColor': ['#dca053', '#e88f1e'],
'--linkColor': ['#096bc2', '#63b6ff'],
'--linkVisitedColor': ['#0704c1', '#c763ff'],
})
// Typed way to reference a css variables. Kept from before used variables.
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
const styles = {
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
color: 'var(--color)',
colorMild: 'var(--colorMild)',
colorMilder: 'var(--colorMilder)',
backgroundColor: 'var(--backgroundColor)',
backgroundColorMild: 'var(--backgroundColorMild)',
backgroundColorMilder: 'var(--backgroundColorMilder)',
borderColor: 'var(--borderColor)',
mailboxesTopBackgroundColor: 'var(--mailboxesTopBackgroundColor)',
msglistBackgroundColor: 'var(--msglistBackgroundColor)',
boxShadow: 'var(--boxShadow)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
buttonBackground: 'var(--buttonBackground)',
buttonBorderColor: 'var(--buttonBorderColor)',
buttonHoverBackground: 'var(--buttonHoverBackground)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
overlayOpaqueBackgroundColor: 'var(--overlayOpaqueBackgroundColor)',
overlayBackgroundColor: 'var(--overlayBackgroundColor)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
popupColor: 'var(--popupColor)',
popupBackgroundColor: 'var(--popupBackgroundColor)',
popupBorderColor: 'var(--popupBorderColor)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
highlightBackground: 'var(--highlightBackground)',
highlightBorderColor: 'var(--highlightBorderColor)',
highlightBackgroundHover: 'var(--highlightBackgroundHover)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
mailboxActiveBackground: 'var(--mailboxActiveBackground)',
mailboxHoverBackgroundColor: 'var(--mailboxHoverBackgroundColor)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
msgItemActiveBackground: 'var(--msgItemActiveBackground)',
msgItemHoverBackgroundColor: 'var(--msgItemHoverBackgroundColor)',
msgItemFocusBorderColor: 'var(--msgItemFocusBorderColor)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
buttonTristateOnBackground: 'var(--buttonTristateOnBackground)',
buttonTristateOffBackground: 'var(--buttonTristateOffBackground)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
warningBackgroundColor: 'var(--warningBackgroundColor)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
successBackground: 'var(--successBackground)',
emphasisBackground: 'var(--emphasisBackground)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
// For authentication/security results.
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
underlineGreen: 'var(--underlineGreen)',
underlineRed: 'var(--underlineRed)',
underlineBlue: 'var(--underlineBlue)',
underlineGrey: 'var(--underlineGrey)',
quoted1Color: 'var(--quoted1Color)',
quoted2Color: 'var(--quoted2Color)',
quoted3Color: 'var(--quoted3Color)',
scriptSwitchUnderlineColor: 'var(--scriptSwitchUnderlineColor)',
linkColor: 'var(--linkColor)',
linkVisitedColor: 'var(--linkVisitedColor)',
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
}
const styleClasses = {
// For quoted text, with multiple levels of indentations.
quoted: [
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
css('quoted1', {color: styles.quoted1Color}),
css('quoted2', {color: styles.quoted2Color}),
css('quoted3', {color: styles.quoted3Color}),
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
],
// When text switches between unicode scripts.
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
scriptswitch: css('scriptswitch', {textDecoration: 'underline 2px', textDecorationColor: styles.scriptSwitchUnderlineColor}),
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
textMild: css('textMild', {color: styles.colorMild}),
// For keywords (also known as flags/labels/tags) on messages.
keyword: css('keyword', {padding: '0 .15em', borderRadius: '.15em', fontWeight: 'normal', fontSize: '.9em', margin: '0 .15em', whiteSpace: 'nowrap', background: styles.highlightBackground, color: styles.color, border: '1px solid', borderColor: styles.highlightBorderColor}),
msgHeaders: css('msgHeaders', {marginBottom: '1ex', width: '100%'}),
}
ensureCSS('.msgHeaders td', {wordBreak: 'break-word'}) // Prevent horizontal scroll bar for long header values.
ensureCSS('.keyword.keywordCollapsed', {opacity: .75}),
// Generic styling.
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
ensureCSS('html', {backgroundColor: 'var(--backgroundColor)', color: 'var(--color)'})
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
ensureCSS('*', {fontSize: 'inherit', fontFamily: "'ubuntu', 'lato', sans-serif", margin: 0, padding: 0, boxSizing: 'border-box'})
webmail: ensure white background when viewing attachments, for the black text of plain text attachments otherwise, in dark mode, the plain text iframe content would be black text on the white background of the iframe as set by webmail. i can't find a way to set the content text on the iframe that contains it.
2024-06-10 21:11:26 +03:00
ensureCSS('.mono, .mono *', {fontFamily: "'ubuntu mono', monospace"})
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
ensureCSS('table td, table th', {padding: '.15em .25em'})
ensureCSS('.pad', {padding: '.5em'})
ensureCSS('iframe', {border: 0})
ensureCSS('img, embed, video, iframe', {backgroundColor: 'white', color: 'black'})
add ability to include custom css & js in web interface (webmail, webaccount, webadmin), and use css variables in webmail for easier customization if files {webmail,webaccount,webadmin}.{css,js} exist in the configdir (where the mox.conf file lives), their contents are included in the web apps. the webmail now uses css variables, mostly for colors. so you can write a custom webmail.css that changes the variables, e.g.: :root { --color: blue } you can also look at css class names and override their styles. in the future, we may want to make some css variables configurable in the per-user settings in the webmail. should reduce the number of variables first. any custom javascript is loaded first. if it defines a global function "moxBeforeDisplay", that is called each time a page loads (after authentication) with the DOM element of the page content as parameter. the webmail is a single persistent page. this can be used to make some changes to the DOM, e.g. inserting some elements. we'll have to see how well this works in practice. perhaps some patterns emerge (e.g. adding a logo), and we can make those use-cases easier to achieve. helps partially with issue #114, and based on questions from laura-lilly on matrix.
2024-11-29 12:17:07 +03:00
ensureCSS('a', {color: styles.linkColor})
ensureCSS('a:visited', {color: styles.linkVisitedColor})
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
// For message view with multiple inline elements (often a single text and multiple messages).
ensureCSS('.textmulti > *:nth-child(even)', {backgroundColor: ['#f4f4f4', '#141414']})
ensureCSS('.textmulti > *', {padding: '2ex .5em', margin: '-.5em' /* compensate pad */ })
ensureCSS('.textmulti > *:first-child', {padding: '.5em'})
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
// join elements in l with the results of calls to efn. efn can return
// HTMLElements, which cannot be inserted into the dom multiple times, hence the
// function.
const join = (l: any, efn: () => any): any[] => {
const r: any[] = []
const n = l.length
for (let i = 0; i < n; i++) {
r.push(l[i])
if (i < n-1) {
r.push(efn())
}
}
return r
}
webmail: show all images (inline and attachment) below the text part (for the text view, not for html view) the attachment buttons for images get some opacity for the text view, to indicate you don't have to open them explicitly.
2024-04-20 20:36:14 +03:00
// From https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types
const imageTypes = [
'image/avif',
'image/webp',
'image/gif',
'image/png',
'image/jpeg',
'image/apng',
'image/svg+xml',
]
const isImage = (a: api.Attachment) => imageTypes.includes((a.Part.MediaType + '/' + a.Part.MediaSubType).toLowerCase())
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
// addLinks turns a line of text into alternating strings and links. Links that
// would end with interpunction followed by whitespace are returned with that
// interpunction moved to the next string instead.
const addLinks = (text: string): (HTMLAnchorElement | string)[] => {
// todo: look at ../rfc/3986 and fix up regexp. we should probably accept utf-8.
webmail: implement registering and handling "mailto:" links to start composing a message. the help popup now has a button to register the "mailto:" links with the mox webmail (typically only works over https, not all browsers support it). the mailto links are specified in 6068. we support the to/cc/bcc/subject/body parameters. other parameters should be seen as custom headers, but we don't support messages with custom headers at all at the moment, so we ignore them. we now also turn text of the form "mailto:user@host" into a clickable link (will not be too common). we could be recognizing any "x@x.x" as email address and make them clickable in the future. thanks to Hans-Jörg for explaining this functionality.
2024-02-09 13:21:33 +03:00
const re = RegExp('(?:(http|https):\/\/|mailto:)([:%0-9a-zA-Z._~!$&\'/()*+,;=-]+@)?([\\[\\]0-9a-zA-Z.-]+)(:[0-9]+)?([:@%0-9a-zA-Z._~!$&\'/()*+,;=-]*)(\\?[:@%0-9a-zA-Z._~!$&\'/()*+,;=?-]*)?(#[:@%0-9a-zA-Z._~!$&\'/()*+,;=?-]*)?')
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
const r = []
while (text.length > 0) {
const l = re.exec(text)
if (!l) {
r.push(text)
break
}
let s = text.substring(0, l.index)
let url = l[0]
text = text.substring(l.index+url.length)
r.push(s)
// If URL ends with interpunction, and next character is whitespace or end, don't
// include the interpunction in the URL.
webmail: better recognize URLs in text wrapped in () or <> if it follows interpunction e.g. "text... (https://localhost)." would keep ) as part of the url before, but not anymore.
2023-09-21 12:09:27 +03:00
if (!text || /^[ \t\r\n]/.test(text)) {
if (/[)>][!,.:;?]$/.test(url)) {
text = url.substring(url.length-2)+text
url = url.substring(0, url.length-2)
} else if (/[)>!,.:;?]$/.test(url)) {
text = url.substring(url.length-1)+text
url = url.substring(0, url.length-1)
}
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}
webmail: implement registering and handling "mailto:" links to start composing a message. the help popup now has a button to register the "mailto:" links with the mox webmail (typically only works over https, not all browsers support it). the mailto links are specified in 6068. we support the to/cc/bcc/subject/body parameters. other parameters should be seen as custom headers, but we don't support messages with custom headers at all at the moment, so we ignore them. we now also turn text of the form "mailto:user@host" into a clickable link (will not be too common). we could be recognizing any "x@x.x" as email address and make them clickable in the future. thanks to Hans-Jörg for explaining this functionality.
2024-02-09 13:21:33 +03:00
r.push(dom.a(url, attr.href(url), url.startsWith('mailto:') ? [] : [attr.target('_blank'), attr.rel('noopener noreferrer')]))
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}
return r
}
// renderText turns text into a renderable element with ">" interpreted as quoted
// text (with different levels), and URLs replaced by links.
const renderText = (text: string): HTMLElement => {
return dom.div(text.split('\n').map(line => {
let q = 0
for (const c of line) {
if (c == '>') {
q++
} else if (c !== ' ') {
break
}
}
if (q == 0) {
return [addLinks(line), '\n']
}
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
return dom.div(styleClasses.quoted[q%styleClasses.quoted.length], addLinks(line))
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}))
}
const displayName = (s: string) => {
// ../rfc/5322:1216
// ../rfc/5322:1270
// todo: need support for group addresses (eg "undisclosed recipients").
// ../rfc/5322:697
const specials = /[()<>\[\]:;@\\,."]/
if (specials.test(s)) {
return '"' + s.replace('\\', '\\\\').replace('"', '\\"') + '"'
}
return s
}
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
const formatDomain = (dom: api.Domain) => dom.Unicode || dom.ASCII
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
// format an address with both name and email address.
const formatAddress = (a: api.MessageAddress): string => {
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
let s = '<' + a.User + '@' + formatDomain(a.Domain) + '>'
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
if (a.Name) {
s = displayName(a.Name) + ' ' + s
}
return s
}
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
// Like formatAddress, but returns an element with a title (for hover) with the ASCII domain, in case of IDN.
const formatAddressElem = (a: api.MessageAddress): string | HTMLElement => {
if (!a.Domain.Unicode) {
return formatAddress(a)
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
return dom.span(a.Name ? [displayName(a.Name), ' '] : '', '<', a.User, '@', dom.span(attr.title(a.Domain.ASCII), formatDomain(a.Domain)), '>')
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
// like formatAddress, but underline domain with dmarc-like validation if appropriate.
const formatAddressValidated = (a: api.MessageAddress, m: api.Message, use: boolean): (string | HTMLElement)[] => {
const domainText = (domstr: string, ascii: string): HTMLElement | string => {
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
if (!use) {
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
return domstr
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
}
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
const extra = domstr === ascii ? '' : '; domain '+ascii
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
// We want to show how "approved" this message is given the message From's domain.
// We have MsgFromValidation available. It's not the greatest, being a mix of
// potential strict validations, actual DMARC policy validation, potential relaxed
// validation, but no explicit fail or (temporary) errors. We also don't know if
// historic messages were from a mailing list. We could add a heuristic based on
// List-Id headers, but it would be unreliable...
// todo: add field to Message with the exact results.
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
let name = ''
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
let color = ''
let title = ''
switch (m.MsgFromValidation) {
case api.Validation.ValidationStrict:
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
name = 'Strict'
color = styles.underlineGreen
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
title = 'Message would have matched a strict DMARC policy.'
break
case api.Validation.ValidationDMARC:
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
name = 'DMARC'
color = styles.underlineGreen
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
title = 'Message matched DMARC policy of domain.'
break
case api.Validation.ValidationRelaxed:
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
name = 'Relaxed'
color = styles.underlineGreen
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
title = 'Domain did not have a DMARC policy, but message would match a relaxed policy if it had existed.'
break;
case api.Validation.ValidationNone:
if (m.IsForward || m.IsMailingList) {
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
name = 'Forwardlist'
color = styles.underlineBlue
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
title = 'Message would not pass DMARC policy, but came in through a configured mailing list or forwarding address.'
} else {
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
name = 'Bad'
color = styles.underlineRed
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
title = 'Either domain did not have a DMARC policy, or message did not adhere to it.'
}
break;
default:
// Also for zero value, when unknown. E.g. for sent messages added with IMAP.
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
name = 'Unknown'
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
title = 'Unknown DMARC verification result.'
return dom.span(attr.title(title+extra), domstr)
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
}
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
return dom.span(attr.title(title+extra), css('addressValidation'+name, {borderBottom: '1.5px solid', borderBottomColor: color, textDecoration: 'none'}), domstr)
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
}
let l: (string | HTMLElement)[] = []
if (a.Name) {
l.push(a.Name + ' ')
}
l.push('<' + a.User + '@')
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
l.push(domainText(formatDomain(a.Domain), a.Domain.ASCII))
webmail: for domain in From address, show if domain is dmarc(-like) validated i'm not sure this is good enough. this is based on field MsgFromValidation, but it doesn't hold the full DMARC information. we also don't know mailing list-status for all historic messages. so the red underline can occur too often.
2023-11-27 14:11:05 +03:00
l.push('>')
return l
}
webmail: show email address instead of display name of "from" header in message listing if display name contains chars from "<@>" it could be an attempt to confuse the reader with an email address. a classic.
2023-11-01 21:12:52 +03:00
// format just the name if present and it doesn't look like an address, or otherwise just the email address.
webmail: for junk/rejects messages, show sender address instead of name in list
2024-03-05 11:04:59 +03:00
const formatAddressShort = (a: api.MessageAddress, junk: boolean): string => {
webmail: show email address instead of display name of "from" header in message listing if display name contains chars from "<@>" it could be an attempt to confuse the reader with an email address. a classic.
2023-11-01 21:12:52 +03:00
const n = a.Name
webmail: for junk/rejects messages, show sender address instead of name in list
2024-03-05 11:04:59 +03:00
if (!junk && n && !n.includes('<') && !n.includes('@') && !n.includes('>')) {
webmail: show email address instead of display name of "from" header in message listing if display name contains chars from "<@>" it could be an attempt to confuse the reader with an email address. a classic.
2023-11-01 21:12:52 +03:00
return n
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
return '<' + a.User + '@' + formatDomain(a.Domain) + '>'
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
}
// return just the email address.
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
const formatEmail = (a: api.MessageAddress) => a.User + '@' + formatDomain(a.Domain)
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
const equalAddress = (a: api.MessageAddress, b: api.MessageAddress) => {
return (!a.User || !b.User || a.User === b.User) && a.Domain.ASCII === b.Domain.ASCII
}
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
const addressList = (allAddrs: boolean, l: api.MessageAddress[]) => {
if (l.length <= 5 || allAddrs) {
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
return dom.span(join(l.map(a => formatAddressElem(a)), () => ', '))
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
}
let elem = dom.span(
join(
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
l.slice(0, 4).map(a => formatAddressElem(a)),
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
() => ', '
),
' ',
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
dom.clickbutton('More...', attr.title('More addresses:\n'+l.slice(4).map(a => formatAddress(a)).join(',\n')), function click() {
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
const nelem = dom.span(
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
join(l.map(a => formatAddressElem(a)), () => ', '),
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
' ',
dom.clickbutton('Less...', function click() {
elem.replaceWith(addressList(allAddrs, l))
}),
)
elem.replaceWith(nelem)
elem = nelem
})
)
return elem
}
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
// loadMsgheaderView loads the common message headers into msgheaderelem.
// if refineKeyword is set, labels are shown and a click causes a call to
// refineKeyword.
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
const loadMsgheaderView = (msgheaderelem: HTMLElement, mi: api.MessageItem, moreHeaders: string[], refineKeyword: null | ((kw: string) => Promise<void>), allAddrs: boolean) => {
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
const msgenv = mi.Envelope
const received = mi.Message.Received
webmail: fix received date shown on message we were trying to offset the timezone, but that makes no sense: we already created a date in the local timezone based on (milli)seconds passed. so we can just use that date instead of calculating a wrong date.
2023-11-05 01:35:44 +03:00
const receivedlocal = new Date(received.getTime())
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
const msgHeaderFieldStyle = css('msgHeaderField', {textAlign: 'right', color: styles.colorMild, whiteSpace: 'nowrap'})
const msgAttrStyle = css('msgAttr', {padding: '0px 0.15em', fontSize: '.9em'})
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
dom._kids(msgheaderelem,
// todo: make addresses clickable, start search (keep current mailbox if any)
dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td('From:', msgHeaderFieldStyle),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
dom.td(
style({width: '100%'}),
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.div(css('msgFromReceivedSpread', {display: 'flex', justifyContent: 'space-between'}),
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
dom.div(join((msgenv.From || []).map(a => formatAddressValidated(a, mi.Message, !!msgenv.From && msgenv.From.length === 1)), () => ', ')),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
dom.div(
attr.title('Received: ' + received.toString() + ';\nDate header in message: ' + (msgenv.Date ? msgenv.Date.toString() : '(missing/invalid)')),
receivedlocal.toDateString() + ' ' + receivedlocal.toTimeString().split(' ')[0],
),
)
),
),
(msgenv.ReplyTo || []).length === 0 ? [] : dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td('Reply-To:', msgHeaderFieldStyle),
webmail: show unicode for internationalized email addresses by default before, we showed the xn-- ascii names, along with the unicode name. but users of internationalized email don't want to see any xn-- names. we now put those in an html title attribute for some cases, so you can still see them if you really want to, by hovering. after talking to arnt at fosdem.
2024-02-08 20:03:48 +03:00
dom.td(join((msgenv.ReplyTo || []).map(a => formatAddressElem(a)), () => ', ')),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
),
dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td('To:', msgHeaderFieldStyle),
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
dom.td(addressList(allAddrs, msgenv.To || [])),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
),
(msgenv.CC || []).length === 0 ? [] : dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td('Cc:', msgHeaderFieldStyle),
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
dom.td(addressList(allAddrs, msgenv.CC || [])),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
),
(msgenv.BCC || []).length === 0 ? [] : dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td('Bcc:', msgHeaderFieldStyle),
webmail: for long to/cc/bcc address list (>5) show the first 4 and a button to show the rest for issue #98 by mattfbacon, thanks
2023-11-20 23:36:40 +03:00
dom.td(addressList(allAddrs, msgenv.BCC || [])),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
),
dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td('Subject:', msgHeaderFieldStyle),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
dom.td(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.div(css('msgSubjectAttrsSpread', {display: 'flex', justifyContent: 'space-between'}),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
dom.div(msgenv.Subject || ''),
dom.div(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
mi.Message.IsForward ? dom.span(msgAttrStyle, 'Forwarded', attr.title('Message came in from a forwarded address. Some message authentication policies, like DMARC, were not evaluated.')) : [],
mi.Message.IsMailingList ? dom.span(msgAttrStyle, 'Mailing list', attr.title('Message was received from a mailing list. Some message authentication policies, like DMARC, were not evaluated.')) : [],
mi.Message.ReceivedTLSVersion === 1 ? dom.span(msgAttrStyle, css('msgAttrNoTLS', {borderBottom: '1.5px solid', borderBottomColor: styles.underlineRed}), 'Without TLS', attr.title('Message received (last hop) without TLS.')) : [],
mi.Message.ReceivedTLSVersion > 1 && !mi.Message.ReceivedRequireTLS ? dom.span(msgAttrStyle, css('msgAttrTLS', {borderBottom: '1.5px solid', borderBottomColor: styles.underlineGreen}), 'With TLS', attr.title('Message received (last hop) with TLS.')) : [],
mi.Message.ReceivedRequireTLS ? dom.span(css('msgAttrRequireTLS', {padding: '.1em .3em', fontSize: '.9em', backgroundColor: styles.successBackground, border: '1px solid', borderColor: styles.borderColor, borderRadius: '3px'}), 'With RequireTLS', attr.title('Transported with RequireTLS, ensuring TLS along the entire delivery path from sender to recipient, with TLS certificate verification through MTA-STS and/or DANE.')) : [],
webmail: tweak color for label about encrypted/signed messages it wasn't very readable, probably since the change that introduced dark mode.
2024-11-28 18:46:24 +03:00
mi.IsSigned ? dom.span(msgAttrStyle, css('msgAttrSigned', {backgroundColor: styles.colorMild, color: styles.backgroundColorMild, borderRadius: '.15em'}), 'Message has a signature') : [],
mi.IsEncrypted ? dom.span(msgAttrStyle, css('msgAttrEncrypted', {backgroundColor: styles.colorMild, color: styles.backgroundColorMild, borderRadius: '.15em'}), 'Message is encrypted') : [],
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
refineKeyword ? (mi.Message.Keywords || []).map(kw =>
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.clickbutton(styleClasses.keyword, dom._class('keywordButton'), kw, async function click() {
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
await refineKeyword(kw)
}),
) : [],
),
)
),
),
webmail: don't lose display of additional headers when a flag/keyword changes (e.g. marked as read)
2023-08-11 09:38:57 +03:00
moreHeaders.map(k =>
dom.tr(
webmail: change many inline styles to using css classes, and add dark mode this started with looking into the dark mode of PR #163 by mattfbacon. it's a very good solution, especially for the amount of code. while looking into dark mode, some common problems with inverting colors are: - box-shadow start "glowing" which isn't great. likewise, semitransparent layers would become brighter, not darker. - while popups/overlays in light mode just stay the same white, in dark mode they should become lighter than the regular content because box shadows don't give enough contrast in dark mode. while looking at adding explicit styles for dark mode, it turns out that's easier when we work more with css rules/classes instead of inline styles (so we can use the @media rule). so we now also create css rules instead of working with inline styles a lot. benefits: - creating css rules is useful for items that repeat. they'll have a single css class. changing a style on a css class is now reflected in all elements of that kind (with that class) - css class names are helpful when inspecting the DOM while developing: they typically describe the function of the element. most css classes are defined near where they are used, often while making the element using the class (the css rule is created on first use). this changes moves colors used for styling to a single place in webmail/lib.ts. each property can get two values: one for regular/light mode, one for dark mode. that should prevent forgetting one of them and makes it easy to configure both. this change sets colors for the dark mode. i think the popups look better than in PR #163, but in other ways it may be worse. this is a start, we can tweak the styling. if we can reduce the number of needed colors some more, we could make them configurable in the webmail settings in the future. so this is also a step towards making the ui looks configurable as discussed in issue #107.
2024-05-06 10:13:50 +03:00
dom.td(k+':', msgHeaderFieldStyle),
webmail: don't lose display of additional headers when a flag/keyword changes (e.g. marked as read)
2023-08-11 09:38:57 +03:00
dom.td(),
)
),
add webmail it was far down on the roadmap, but implemented earlier, because it's interesting, and to help prepare for a jmap implementation. for jmap we need to implement more client-like functionality than with just imap. internal data structures need to change. jmap has lots of other requirements, so it's already a big project. by implementing a webmail now, some of the required data structure changes become clear and can be made now, so the later jmap implementation can do things similarly to the webmail code. the webmail frontend and webmail are written together, making their interface/api much smaller and simpler than jmap. one of the internal changes is that we now keep track of per-mailbox total/unread/unseen/deleted message counts and mailbox sizes. keeping this data consistent after any change to the stored messages (through the code base) is tricky, so mox now has a consistency check that verifies the counts are correct, which runs only during tests, each time an internal account reference is closed. we have a few more internal "changes" that are propagated for the webmail frontend (that imap doesn't have a way to propagate on a connection), like changes to the special-use flags on mailboxes, and used keywords in a mailbox. more changes that will be required have revealed themselves while implementing the webmail, and will be implemented next. the webmail user interface is modeled after the mail clients i use or have used: thunderbird, macos mail, mutt; and webmails i normally only use for testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed, but still the goal is to make this webmail client easy to use for everyone. the user interface looks like most other mail clients: a list of mailboxes, a search bar, a message list view, and message details. there is a top/bottom and a left/right layout for the list/message view, default is automatic based on screen size. the panes can be resized by the user. buttons for actions are just text, not icons. clicking a button briefly shows the shortcut for the action in the bottom right, helping with learning to operate quickly. any text that is underdotted has a title attribute that causes more information to be displayed, e.g. what a button does or a field is about. to highlight potential phishing attempts, any text (anywhere in the webclient) that switches unicode "blocks" (a rough approximation to (language) scripts) within a word is underlined orange. multiple messages can be selected with familiar ui interaction: clicking while holding control and/or shift keys. keyboard navigation works with arrows/page up/down and home/end keys, and also with a few basic vi-like keys for list/message navigation. we prefer showing the text instead of html (with inlined images only) version of a message. html messages are shown in an iframe served from an endpoint with CSP headers to prevent dangerous resources (scripts, external images) from being loaded. the html is also sanitized, with javascript removed. a user can choose to load external resources (e.g. images for tracking purposes). the frontend is just (strict) typescript, no external frameworks. all incoming/outgoing data is typechecked, both the api request parameters and response types, and the data coming in over SSE. the types and checking code are generated with sherpats, which uses the api definitions generated by sherpadoc based on the Go code. so types from the backend are automatically propagated to the frontend. since there is no framework to automatically propagate properties and rerender components, changes coming in over the SSE connection are propagated explicitly with regular function calls. the ui is separated into "views", each with a "root" dom element that is added to the visible document. these views have additional functions for getting changes propagated, often resulting in the view updating its (internal) ui state (dom). we keep the frontend compilation simple, it's just a few typescript files that get compiled (combined and types stripped) into a single js file, no additional runtime code needed or complicated build processes used. the webmail is served is served from a compressed, cachable html file that includes style and the javascript, currently just over 225kb uncompressed, under 60kb compressed (not minified, including comments). we include the generated js files in the repository, to keep Go's easily buildable self-contained binaries. authentication is basic http, as with the account and admin pages. most data comes in over one long-term SSE connection to the backend. api requests signal which mailbox/search/messages are requested over the SSE connection. fetching individual messages, and making changes, are done through api calls. the operations are similar to imap, so some code has been moved from package imapserver to package store. the future jmap implementation will benefit from these changes too. more functionality will probably be moved to the store package in the future. the quickstart enables webmail on the internal listener by default (for new installs). users can enable it on the public listener if they want to. mox localserve enables it too. to enable webmail on existing installs, add settings like the following to the listeners in mox.conf, similar to AccountHTTP(S): WebmailHTTP: Enabled: true WebmailHTTPS: Enabled: true special thanks to liesbeth, gerben, andrii for early user feedback. there is plenty still to do, see the list at the top of webmail/webmail.ts. feedback welcome as always.
2023-08-07 22:57:03 +03:00
)
}
Reference in a new issue Copy permalink