Client broken state with stalwart mailserver

[SinnySupernova]

Description

I'm trying to use tmail web with the stalwart mailserver. Unfortunately, there seem to be a few issues right off the bat:

• layout is misplaced (see screenshot below)
• client makes request to https://mail.tld/.well-known/webfinger?resource=https://mail.tld&rel=http://openid.net/specs/connect/1.0/issuer, which fails (cors failure when ran from the browser client, and 404 when ran with curl)
  If this is required by the (jmap?) spec I'll open an issue in stalwart, if not - there needs to be a workaround, e.g. setting env vars. Either way the client should not end up in such a state.

Expected result

Web client doesn't get into completely broken state 😅

Current behavior

yes,this is all I see and neither the button nor the privacy policy links are clickable

Preconditions (optional)

n/a

Reproduction Steps

• Open tmail web in librewolf (=firefox)

Acceptance criteria

??

Context

firefox on linux

Additional information

n/a

[chibenwa]

Hello @SinnySupernova , thanks for report!

If this is required by the (jmap?) spec I'll open an issue in stalwart

No not realy JMAP spec do not state anything about auth...

client makes request to https://mail.tld/.well-known/webfinger?resource=https://mail.tld&rel=http://openid.net/specs/connect/1.0/issuer, which fails (cors failure when ran from the browser client, and 404 when ran with curl)

The right thing here is to correctly handle these errors in the front and fallback to regular (basic auth) login page.

Otherwise we can document a NGINX setup in front of the JMAP endpoint actually compatible with basic auth.

Finally @florentos17 you might run into this issue when running on top of Cyrus so it might be worth a look.

[chibenwa]

The right thing here is to correctly handle these errors in the front and fallback to regular (basic auth) login page.

We need to be careful in differenciating 'outage' ie 500, timeouts where saying oups is ok
From unconfigured endpoint where we should display login page.

Contribution appreciated if in your reach.

[SinnySupernova]

Can we have the client completely bypass that webfinger call? Or even better - specify an environmental variable that points to the correct issuer URL.
I would like to avoid having to add an extra nginx container to the stalwart deployment (it is using a different reverse proxy)

Additionally, I'd like to share a few extra things I just checked:

• v0.13.1 doesn't call the webfinger endpoint and shows the email/password fields
• both latest and v0.13.1 layout is completely unusable in my librewolf browser because it has WebGL disabled

v0.13.1 looks like this:

• apparently you can click the elements where they should have been, but visually everything is shifted upwards (see where the cursor is, and the slightly darker color of the password field)

I'm looking into the docs for options. Tried to build with --wasm, and js interop lib is not supported there :(

[chibenwa]

specify an environmental variable that points to the correct issuer URL.

For web why not but for mobile app loading per deployment config is not relevant.

both latest and v0.13.1 layout is completely unusable in my librewolf browser because it has WebGL disabled

Old version, and sadly we are also tied down to flutter limitations