You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say we are on the 5. page of inbox, and reading an email.
Now there is no way to navigate back to the 5. page of the inbox, after I finished reading the current email.
(it always navigate back to the first page of inbox)
The browser's back button is not a solution, because if I replied or forwarded an email, it will not navigate back to the inbox. Also the browser's back button does not mark 'read' the last readed email.
(users assumed that this feature (removing bold of a readed email) is not working)
I think it is rather a minor feature to implement, because we can maybe determine the url where we are coming from.
I have not looked around deeply in the source code. But maybe easier then attachment forwarding.
This is a major complain from the users.
The text was updated successfully, but these errors were encountered:
I guess it would be doable. It would require to drag along the listing information, probably in a hidden field, so it would not get lost on forwarding or such.
It may be a little too early, but I'm playing with the idea, to have a rich email client,
just like gmail. I would implement it with react.
It would feature auto draft save (just like gmail),
multiple file attachment (with progressbar when attaching), deleting all emails in trash (800+ emails, one-by-one so the server only gets one delete at a time, or in chunks (10 at a time)).
Still a server side rendering (like now) is useful. Gmail calls it Load basic HTML.
So my question is:
do you like the idea?
should I implement it inside wildduck-webmail or in a separate repo ? (I would like to implement it here, to get your advises and expertises).
I dont want to look too overproud of myself, but I may be able to pull it off (of course with a pair of your expert eyes, to not do anything too stupid).
One of the reasons for the API based access to the email backend was to enable custom UIs. The existing webmail is more like a demo, I'd rather keep it as simple as possible, so I'd suggest you to fork the current webmail and build on top of it.
Let's say we are on the 5. page of inbox, and reading an email.
Now there is no way to navigate back to the 5. page of the inbox, after I finished reading the current email.
(it always navigate back to the first page of inbox)
The browser's back button is not a solution, because if I replied or forwarded an email, it will not navigate back to the inbox. Also the browser's back button does not mark 'read' the last readed email.
(users assumed that this feature (removing bold of a readed email) is not working)
I think it is rather a minor feature to implement, because we can maybe determine the url where we are coming from.
I have not looked around deeply in the source code. But maybe easier then attachment forwarding.
This is a major complain from the users.
The text was updated successfully, but these errors were encountered: