`BASE_PATH=/mail` mounts the whole app under a prefix, for a host that is not
ihasmail's alone. Unset -- every deployment that exists -- is the domain root
and is byte-for-byte what it was: the canonical form of the setting is the
empty string, and `""` concatenated onto `/api/health` is `/api/health`.
That choice of canonical form is the whole design. A trailing slash would have
been the obvious alternative, and it fails quietly in exactly one place: at the
root it makes `//api/health`, which is not a path on this host but a
protocol-relative URL to a host called `api`. One call site forgetting to
branch is a request leaving the origin. So the empty string, one leading slash,
no trailing one, worked out once in `scripts/basePath.mjs` -- plain JS, next to
`version.mjs`, because the web build and the server both have to reach the same
answer and two implementations of "what does /mail/ mean" is precisely the bug
where the server serves an app whose script tags point somewhere else.
`/mail`, `mail`, `/mail/` and `//mail//` all mean the same mount; a deployment
should not fail over a trailing slash.
Unlike everything else ihasmail is told, this one cannot wait for the process
to start. The bundle writes its own asset URLs into index.html, so `BASE_PATH`
is read at build time for Vite's `base` as well as at run time for the routes,
and the Dockerfile carries one value into both. Get them out of step and the
page comes up blank with a 404 in a console nobody has open -- so the static
handler, which is reading index.html anyway, checks what it asks for and says
so in the log once per build.
Everything moves together. The API mounts at `${base}/api`; the router is
given the base once, so every `<Route path>` and `<Link href>` stays written
root-absolute and wouter does the rest; `apiFetch` adds the prefix in one place
rather than at forty call sites; the session cookie's Path narrows to the mount
so two instances on one host cannot sign each other out.
Two things need no prefix at all, and it is worth saying why they were not
given one. A manifest's members resolve against the manifest's own address, so
relative URLs there follow the mount with nothing substituted at build time --
which is also why `public/` needed no template step. The service worker is the
same trick: it is served from the mount, so `new URL("./", self.location)`
tells it where that is, and a worker that derives the value cannot disagree
with the page that registered it.
Anything outside the mount is a 404 rather than the app shell, and
`stripBasePath` does not use `startsWith` -- under `/mail` this process shares
a hostname, and answering `/mailbox` with our index would shadow a neighbour
instead of letting it 404 honestly. For the same reason the notification-click
handler now checks the path as well as the origin: `includeUncontrolled` widens
`matchAll` to the whole origin, which off the root would have navigated a
stranger's tab to our inbox.
Inline images in a draft were the one silent trap. They are matched by their
blob URL on the way out, once unanchored and once anchored, and a bare
`/api/blob/` still appears inside `/mail/api/blob/...` -- so one pattern would
have replaced the tail and left `/mail` in front of a `cid:`, and the other
would have missed and sent the message linking to the sender's own webmail.
Both patterns are built from the base now.
General had grown five unrelated headings and was where anything without
an obvious home ended up. Remote images were filed under "Reading", the
read-receipt policy under "Composing", the undo-send window beside the
default message format. They are the same kind of decision -- what reaches
a sender, and what asks before something happens -- and they were the
hardest settings in the app to find.
Privacy & safety now holds all six, in three groups: remote content, read
receipts, and the things that ask before it is too late. General keeps
what it is actually about and is thirty lines shorter.
The line against Security & sessions is worth stating, because two similar
words next to each other in a nav is how a menu becomes something people
hunt through. Security & sessions is credentials and access: password,
two-factor state, app passwords, live sessions. Privacy & safety is how
the app behaves towards the reader and towards senders.
Nothing moved in storage. Settings are a flat object in settings.json and
sections are only how they are grouped on screen, so this is a UI change
with no migration and no key renames.
Two things beyond the move.
The senders trusted with remote images are now listed and can be withdrawn
one at a time. A sender was added from a message and could then only be
removed by finding another message from that same sender, which is not a
way to review a list you cannot see.
And General's lead said settings are stored in this browser, which is only
true when the server has no FileNode support. They normally live in the
account's own Files and follow it between devices, so the sentence
contradicted the feature it sat above.
The calendar had next and previous as toolbar buttons and n/p, and nothing
for a thumb. Every other surface in the app that a finger drives already
answers to a swipe.
Day and month only. Those are the two views where a period is a page;
week and agenda scroll through a range rather than turning to the next
one, so there is nothing a sideways flick would obviously mean. Dragging
left pulls the next period in from the right, the way paper and every
phone do it.
Three things it deliberately does not do.
It draws nothing while the finger moves. The row swipe slides the row open
because the strip underneath has to name which of six actions is about to
happen; stepping a calendar has two outcomes and the direction of the
finger already says which. Translating the grid would also break the
sticky day header, since a transform makes a containing block. The
threshold is reported by the vibration motor instead, which is what the
haptics are for.
It does not start on an event. Which gesture was meant is decidable at the
moment the finger lands and only then, so dragging an event stays
available to be built later without having to be untangled from this
first.
And it asks for a longer drag than a row swipe -- not because the
consequence is bigger, since stepping back undoes it while a swiped row
has already been archived, but because this gesture has no way to change
its mind. A row reveals what it will do and can be let go early, and
offers Undo after. This shows nothing and offers nothing, so the distance
is the only chance to not mean it.
The axis lock is the shared one, keeping its bias towards the vertical:
the day grid scrolls through the hours, and a scroll misread as a swipe
throws the reader into another day. The toolbar buttons and n/p stay,
because a gesture with no visible control is one only the people who
already know about it can use.
Archiving put everything in one folder, so an Archive that has been
collecting for years is a single flat list with no way to narrow it except
search.
Archive by year and Archive by month file into Archive/2026 and
Archive/2026/09, creating the folders as needed and reusing them after
that, including folders made by hand or by another client.
The names are numeric and zero-padded rather than month names, because
these are real server-side mailboxes rather than anything of ihasmail's.
Every other client sees them: a folder created as "September" by someone
reading in English stays "September" for the same account read in
Japanese, since the name is stored and not translated. And 09 sorts
between 08 and 10 where a name does not.
The date is read in the reader's own timezone rather than UTC so it agrees
with the date shown against the message in the list. A message that
arrived at 00:30 UTC on 1 September is dated 31 August in New York, and
filing it under 09 while the list says August would be the app
disagreeing with itself. A message whose date cannot be read goes to
Archive itself rather than to a folder named after a guess.
A selection spanning two months is two destinations, not one. The moves
are made silently and one toast names where everything went -- the folder
where there is a single answer, the count where there is not -- because
each group raising its own toast with its own Undo would mean undoing a
third of a move. One Undo restores the whole selection to wherever each
message came from, captured before anything moved.
The menu labels name the destination where there is one, so it reads
"Archive to 2026/09" rather than describing the rule, and falls back to
"Archive by month" for a selection with no single answer.
Forwarding quoted the original into a new message, which is the right
thing for passing on something to be read and the wrong thing for passing
on something to be looked at. Quoting rewrites the body, drops the
headers, and re-parents the attachments, so a bounce, a phishing report or
anything else where the message itself is the evidence arrived altered.
Forward as attachment sends the message whole, as a message/rfc822 part.
It costs no upload at all: a message's own blobId is its RFC822 blob and
already lives in the account, so this goes through the same by-reference
path as attach-from-Files and a 40 MB message attaches as fast as a small
one.
It is in the message's own menu, the list's right-click menu, and the
overflow on the reply strip at the foot of a thread, which is the one a
thumb finds on a phone.
Two things fixed on the way, both exposed rather than introduced by this.
The filename rule was subject.replace(/[^\w.-]+/g, "_"), and \w without
the u flag is ASCII: every character of a Russian, Japanese or Chinese
subject failed the class, so those messages downloaded as a row of
underscores. What is actually unsafe in a filename is much shorter than
"not ASCII" -- path separators, the names Windows reserves, the control
range -- so the rule now keeps letters from any script and drops only
those. It lives in one place and the .eml download uses it too.
And the composer's attachment chip set overflow/text-overflow on a span,
where neither does anything, so the name never truncated and the size ran
on after it on the same line. Only long names showed it, which is every
.eml named from a subject.
The filter in front of the mailbox scores every delivered message and
writes its working into headers, and none of it was being read. A message
in Junk gave no reason for being there.
Nothing here scores anything. The headers are parsed and shown, so this
cannot disagree with the filter that actually made the decision.
Two formats cover what sits in front of a Stalwart mailbox in practice:
the SpamAssassin-shaped X-Spam-* set, which Stalwart's own filter writes,
and Rspamd's X-Spamd-Result. A header in neither shape is left unread
rather than guessed at, since a misparsed score shown confidently is worse
than no panel at all. Mail that arrived without any of them shows nothing.
Rules are listed largest mover first and signed, because which way a rule
pushed is the point, and the biggest contributor is the answer to why the
message scored what it did.
Two things it deliberately will not do. A score is always given the
threshold it was measured against, because 6.7 is damning against 5 and
unremarkable against 15 -- the number alone is not something a reader can
act on; where no threshold was stated, it says so rather than implying
one. And where the filter recorded no verdict, none is derived from score
against threshold: the filter applies policy we cannot see, and putting a
verdict in its mouth would be inventing one.
The mock writes the same headers at delivery -- spam in Junk, clean in the
Inbox, nothing on mail this account wrote -- so the panel can be developed
and demoed against it.
Templates were a fixed subject and body, so anything that changed per
message -- who it is going to, today's date -- had to be typed over
afterwards.
Eight names are recognised: recipientName, recipientFirstName,
recipientEmail, myName, myEmail, subject, date and time. Dates and times
go through datetime.ts rather than toLocaleDateString, so a template
follows the date order and clock the app was already told to use.
Filling happens on insert rather than on send. What a placeholder came to
is then visible in the composer and can be edited, instead of the message
changing between writing it and sending it.
Two things are deliberately left alone. A placeholder that cannot be
answered yet -- a recipient's name on a draft nobody has addressed -- stays
in the body as written, because substituting an empty string produces
"Hi ,", which is wrong rather than visibly unfinished; leaving the name
says which word is still missing and can be typed over. And a name that is
not a placeholder is left as written too, since a body that quietly ate an
unrecognised token would be worse than one that shows it.
Values are escaped on the way into HTML: a display name comes from a
contact card or a typed address and is not trusted markup.
Moving or deleting five files meant doing it five times, each with its own
confirm. Rows now select the way they do in a file manager: a plain click
replaces the selection, ctrl or cmd adds and removes one, shift takes the
run from the last row clicked, clicking past the last row or pressing
Escape clears it. Two or more selected raises a bar with Move to... and
Delete, and the row menu offers the same for the whole selection.
The move is one `FileNode/set` rather than a loop, and not only for the
round trip: a loop would apply half the moves and then throw, leaving a
selection split across two folders with nothing saying which half went.
One call is one answer, and `notUpdated` names whatever the server
refused.
Right-clicking inside the selection acts on all of it; right-clicking
outside means you meant that row, so the selection follows the pointer
rather than the menu quietly applying to something off-screen. A drag
carries the whole selection the same way, which is why the payload is now
a list -- and why a drop is refused unless every file in it can land,
since a drag that moves four of five and skips the fifth is worse than
one that will not start.
A selection belongs to the folder it was made in, so changing folder or
account drops it: rows left selected off-screen make the delete two
folders later a surprise.
v2 of the viewer: Edit, on text and Markdown, in the dialog and on the
row menu. Save is explicit -- every save mints a new blob, so autosave
would burn quota and multiply the conflicts it cannot see.
Two people editing one file is the case worth getting right. `saveText`
re-reads the node and compares the blob the editor started from: if
somebody else saved in the meantime it refuses, says so, and leaves the
work in the box to copy out. `ifInState` is the obvious tool and the
wrong one -- it is the state of every FileNode in the account, so an
unrelated upload in another folder would fail the save, and a warning
that cries wolf is a warning people click through.
Editing is not offered where saving would lose something: a file
truncated for display would have its tail written away, and one that did
not decode as UTF-8 would have mojibake written over whatever encoding it
really is. Both open read-only and say which. Nor is it offered without
mayModifyContent -- a read-only share just has no Edit.
Closing or cancelling with unsaved changes asks first, Ctrl+S saves, and
mail attachments are unaffected: they pass no onSave, because a message
part is not a thing that can be written back.
A .md previewed as its own source, which is reading the punctuation
rather than the notes. It now opens rendered, with Rendered | Source in
the dialog footer for anyone who wants what the file actually says.
Markdown only; a .txt has nothing to toggle between.
Rendering is `marked`, sanitised by DOMPurify -- the one the app already
carries for mail. Markdown is not a safe subset of anything: raw HTML
passes through it by design, so a <script> in a file somebody uploaded or
shared into the account is a script tag unless something takes it out.
Images become links rather than pictures. An image in a Markdown file is
either a relative path, which has no base to resolve against here, or a
URL somewhere else, which fetches on open and tells that server the file
was read -- the tracking pixel this app blocks in mail. The link keeps
the alt text and the address, so nothing vanishes silently.
Fixes the PDF preview while here, which never worked: securityHeaders
put X-Frame-Options: DENY on every response including the blob route, so
the iframe showed Chrome's "refused to connect" where the file should
have been -- in Files today and in mail attachments long before that.
The middleware now leaves a header the route has set, and a PDF served
inline says SAMEORIGIN. Nothing else on the server is framable.
Files could only hand you the bytes: double-clicking a picture put it on
disk and left you to find it. The viewer for this already existed --
images, PDFs and text, in the attachment preview in MessageView -- it was
just wired to one screen. It is now a component both screens use.
Two things it needed before it was any use on Files. The type detection
falls back to the file name: an upload carries whatever the browser
guessed, which for anything unusual is application/octet-stream, so the
old exact-type check saw nothing to show in a .md that had just been
uploaded. And text is read with fetch, which ignores Content-Disposition,
so Markdown previews even though the server will not serve it inline.
Whether we can show a file and whether the server will serve it inline
are separate questions, and lib/preview.ts answers them separately:
`openableInTab` mirrors the isInlineSafe allowlist in the blob route,
because navigating to a blob the server will not inline just starts a
download. SVG is left out of both -- it carries script, and how to show
one safely is its own question, not a detail of a file lister.
Printing goes with it. A picture or a text file prints from the dialog
with everything else dropped; a PDF prints itself from its own iframe,
since the page around it cannot paginate someone else's document. Hiding
`.app` alone was not enough there -- `#root` kept its height and printed a
blank first page, the same trap as the message card.
The Print in a message's own menu called window.print() bare, so it
printed the whole conversation -- every message on the page -- which is
what the toolbar's "Print conversation" is already for. Opening one
message's menu and asking to print it is not a request for the other
eleven.
It now marks the card it was opened from and the print stylesheet drops
the siblings for the duration. The subject heading stays: a printed
message with no subject on it is a page nobody can file. The "3 messages"
count beside it goes, since only one of them is on the paper.
The label is left as "Print" rather than made more specific -- it is
translated in all nine shipped catalogues, and the toolbar entry beside
it already says "conversation".
Printing carried whatever theme was on screen: a dark reader printed a
dark sheet, message body included -- that renders in a shadow root, and
follows the app palette through inherited custom properties, so no rule
in this stylesheet could reach it. The print block now pins the palette
tokens themselves to a light, unpainted set, which reaches the body the
same way the theme does. Backgrounds go white rather than the light
theme's greys; a printer should not lay ink over the whole page.
Page one was also blank apart from the subject. `break-inside: avoid` on
the message card cannot be honoured by a message taller than a sheet,
and Chrome answers by moving the card to a fresh page and breaking it
there anyway. Only the header is indivisible now, kept with the body
that follows it.
Ctrl-clicking a second message selected only the second. The first stayed
highlighted, because it was the one open -- which is a different state
wearing a similar colour -- and was never actually selected. So both looked
picked, one was, and every action that followed applied to half of what the
screen showed, silently.
The cause is visible once the two rules sit together: shift-click took the
whole run *including* the row it started from, and ctrl-click took only the
row clicked. Two branches of one handler that had drifted apart, with
nothing asserting they agreed.
So they are one function now, and tested. Ctrl-click brings the current row
with it while nothing is selected yet; once there is a selection it toggles
exactly one row, which is what it is for. Shift-click is unchanged, and
keeps its anchor where it is so extending a range twice grows it from the
same place rather than from wherever it last reached.
The last test asserts the property that failed rather than the branches:
whichever modifier begins a selection, the anchor is in it.
Somebody deciding whether to spend an evening on a mail client wants to
see it before they read about it. The link sits under the logo, above the
badges, because a demo answers the question the badges are only evidence
for.
The line under it says what the demo is -- invented mail, nothing kept --
so nobody arrives expecting to sign in with an address of their own.
FEATURES.md had nothing on three of them. The scheduling panel and what it
will not show, the filter editors no longer discarding work in silence,
and where compose-as-new can be reached from — including the reply strip,
which is the one a thumb finds.
KNOWN-ISSUES.md gains the free/busy finding, which is the sort of thing
that page exists for: it was checked against the live server rather than
assumed, free/busy between accounts turns out to need no sharing set up,
and a principal offers no route to its calendars at all. Also what the
check did *not* settle, and which way ihasmail errs in the meantime.
ROADMAP.md gains the two things left deliberately unbuilt: a scheduling
view you can visit with no event in hand, and per-message actions from the
message list on a touchscreen, where the gesture that would open them
already means "select".
It was never absent on a phone: it sits in the menu behind the ⋮ at the
top of a message card. But that is not where anybody looks. On a phone you
act on a thread from the strip at the bottom -- Reply, Reply all, Forward
-- and what is not there is, for practical purposes, not there.
The strip gets an overflow of its own, with compose-as-new in it. A fourth
labelled button does not fit; this does, and it says what it is once
opened.
Measuring to place it turned up something else. Three labelled buttons
want about 390px, and with the overflow rather more: enough for a 430px
phone and not for a 390, 360 or 320 one. The strip was already over that
line on the smaller ones before today, and simply overflowed. It now
wraps, and the spacer that would push the overflow onto a line of its own
is dropped on narrow screens so the buttons wrap as a group.
Closes#181
The availability bar showed the guests it had free/busy for and quietly
left out the ones it did not. In one row that is survivable. As a grid it
would be a lie: a row with nothing in it reads as a diary with nothing in
it, and "we cannot see this person's calendar" is the one thing that must
not look like "this person is free".
So everyone the event concerns now gets a row, and the ones with no
free/busy to read are drawn hatched rather than empty, with a line under
the grid saying how many and why. You get a row too, first. Scheduling
around the other people and not around yourself is how two things end up
at the same time, and the organiser was the one calendar the panel never
showed.
Your own row is never unknown. Where the directory does not list you under
the address your identity sends from -- an alias, a login that differs
from the address -- the account is still yours to read, and Stalwart
answers for it under the account's own id.
The window steps backwards and forwards a screenful at a time without
touching the event, which is the "movable forwards & backwards" the report
asks for, and offers its way back when you have wandered off.
And the bars are somewhere to put the event rather than only something to
read: the pointer shows the half hour it is over, and a click moves the
event there keeping its length. Clicking while stepped away moves the
event to where you clicked and returns the view to it, so it lands where
you were looking instead of jumping.
Free/busy is answered per principal, and only the server's own accounts
are principals. Somebody at another domain has none to read -- which is
not a gap to be closed, it is what the protocol can see -- so the grid
says so rather than drawing them blank.
Closes#172
The bar was a day wide whatever it was drawing. It began at midnight on
the event's start day and stopped 24 hours later, so an event running over
two days showed availability for the first of them and gave no sign there
was more. And it carried no marks at all, which left "is this the whole
day or only working hours" unanswerable without dragging the event about
to see where its own outline moved.
It now covers whole days from the day the event starts to the day it ends,
and the free/busy lookup asks for the same range it draws. Above the bars
is an axis: hours every three across a single day, every six across two,
day names beyond that. The marks are drawn down the bars too, so a busy
block can be read against the hour it starts at rather than guessed at.
Whole days, always. A bar starting at the event's own start time would
move under the reader every time they adjusted it, and "busy from about a
third of the way along" is not a time anybody can read.
A week is as far as it goes. Something running longer is not an event
anybody is hunting a free slot in, and a month at eight pixels a day would
say nothing; it says how many days it left out instead.
The span is measured between two real midnights rather than counted in
24-hour days, because twice a year they differ, and every position on the
bar is a fraction of it.
The mock answered with a single busy block on the first day whatever range
it was asked for -- all a day-wide bar could show -- which would have left
a multi-day bar looking like everyone was free from the second day on. It
now answers across the range.
This is parts 1 and 2 of #172. The separate multi-day scheduling view it
also asks for is still open, and needs an answer first on what to show for
participants who have no free/busy to read.
Somebody arriving from SOGo, Thunderbird or an LDAP directory has their
contacts in LDIF, and until now the only way in was vCard.
Nothing on the server reads LDIF, so this reads it here, in two pieces
that are two different problems. `ldif.ts` is RFC 2849 and nothing else:
folded lines, base64 values, case-insensitive attribute names, options,
comments, `version:` headers, change records. It knows no attribute by
name. `mozillaAb.ts` knows the attributes and no syntax -- Mozilla's
address book schema, which is what Thunderbird and SOGo write and what the
issue asks for by name. LDIF says nothing about what any attribute means,
so a file is only readable against a schema, and keeping the two apart is
what would let a second schema be added without touching the reader.
Work and home addresses, which the schema keeps in two separate sets of
attributes, come across as two addresses. So do every phone kind, the
second email, the organisation and its units, job title, nickname, web
pages and the AIM handle. The four custom fields have no equivalent in
JSContact and are appended to the note, labelled as Thunderbird labels
them: keeping something somebody chose to write down is worth more than
the tidiness of dropping it.
An entry with neither a name nor an address is skipped rather than
imported as a blank row that is impossible to identify and tedious to find
again to delete. The distinguished name is not used as the contact's uid:
it says where an entry sat in somebody else's directory.
One import control takes either format and decides by what is in the file
rather than by what it is called, because an address book exported as LDIF
arrives as .ldif, .ldi, .txt or with no extension at all.
Closes#174
A mail the far end rejected, or one that went to an address with a typo in
it, is a mail you want to send again -- not forward, and not reply to.
Doing it by hand meant a new message and copying five fields across.
"Compose as new" sits with Reply and Forward, in the message menu and in
the list's right-click menu. It opens a composer holding the recipients
the message had, its Reply-To, its subject with nothing prefixed to it,
its body with nothing wrapped around it, and its attachments.
What makes it a new mail is what it leaves behind. `draftId` stays null,
or sending would destroy the message it was made from. `inReplyTo`,
`references`, `relatedEmailId` and `relatedKeyword` stay null, so it hangs
off no thread and sending it marks the original neither answered nor
forwarded. The Message-ID is the server's and the date is stamped at
build time, so both are new without anything asking for them -- the send
path needed no changes at all.
A message you sent is composed as the identity you sent it as. One
somebody else sent has no identity of yours to match, and guessing from
whom it was addressed to would put the resend behind an alias that was
only ever the receiving end, so that case takes the account's default.
No signature is added. The body is the one that was sent, which already
ends in whatever signature went with it, and appending the identity's
would give it two.
Closes#176
An .ics reaches you by ways that are not your mailbox -- a ticketing
system a customer invited, a colleague's export, a booking confirmation
forwarded on -- and until now the only events ihasmail could take were the
ones attached to a message it had received.
The calendar's own menu now offers "Import iCAL file…", which files
everything in the file into that calendar. No global button: the issue is
right that this is not a frequent enough thing to earn one.
The parsing is the server's, through the same CalendarEvent/parse an
emailed invitation already goes through. An .ics is not a format worth
reimplementing in a browser, and Stalwart's reader handles what a
hand-rolled one would not.
Every event goes out in a single CalendarEvent/set. The round trips are
the smaller half of the reason: createEvent invalidates on the way out and
invalidating refetches every cached range, so a year of events imported
one at a time would refetch the calendar a few hundred times.
Nothing is mailed to anyone named in the file. Importing is filing
something you already have, and scheduling messages would be a surprise to
its participants.
The mock's parser read the whole file with one regex and returned one
event, which is all an invitation ever needed. It now reads per VEVENT, so
a multi-event file can be tested against it, and it invents an organiser
and an attendee only for events that carry a METHOD -- a plain export is
not addressed to anyone.
Closes#173
Both editors on the Filters & rules page kept their edits in component
state, so every way out of the page threw them away without a word: a
settings link, the app rail, even the Rules/Scripts switch. The only sign
there had been anything to lose was a Save button that a screenful of
rules had already pushed below the fold.
Editors now register what they have pending, and every in-app navigation
asks first -- offering to save, rather than making "leave without saving"
the easy answer and saving the one you have to back out and find. Wouter
routes links, redirects and navigate() through one place, so the guard
holds for the app rail and the settings nav without either knowing an
editor exists. The Rules/Scripts switch asks for itself, since it never
reaches the router. Reload and tab close get the browser's own prompt.
The save bar is pinned to the foot of the pane, so "Unsaved changes" is
on screen whether or not the rules fit in the window.
Two things fixed on the way past, both in the raw script editor: saving
cleared only the selection, which left the editor open with the name
unlocked so a second save created a duplicate script instead of updating
the one just written; and the pair of identical nested conditions that
decided whether the editor was open at all is now the one question it was
asking twice.
Fixes#175
The mail bullet in "What's in it" listed everything a message can turn
into -- a reply, a filter, a receipt -- except the newest one. It now
names the event too, and says the guests come with it, which is the half
that is not obvious from the feature's name.
jcoffey-dev
Coffey Labs