Modal dialog boxes invisible after upgrade to v0.12

[osi8]

I have just updated to v0.12 and run the binary directly (with a diy systemd unit).
I had v0.11 working for a while, but after updating it seems that the modal dialogs stay invisible after opening.

I found, that they use the bootstrap .fade class for a transition, but the required .show class never gets attached.
So they keep opacity: 0 and are rendered invisibly in front of the page (you can see by the scrollbars going away from the .modal-open class on body which makes the overflow hidden).

I have attached a screenshot from developer tools.

[Eugeny]

This should be already fixed in the nightly build - could you give it a try?

[wolveix]

I'm experiencing this same issue in v0.13.1. Removing .fade displays the modal again. Tested in Firefox, Chrome, and Safari.

For now, I've just added this TamperMonkey script to run on the domain:

// ==UserScript==
// @name         Fix Warpgate modal visibility
// @namespace    http://tampermonkey.net/
// @version      1.1
// @description  Fixes modal visibility on Warpgate
// @match *://warp.domain.tld/*
// @run-at document-idle
// @grant        GM_addStyle
// ==/UserScript==

(function() {
    'use strict';

    const style = document.createElement('style');
    style.innerHTML = `
        .modal-backdrop.fade {
            opacity: 1 !important;
        }
        .fade:not(.show) {
            opacity: 1 !important;
            visibility: visible !important;
            transition: none !important;
        }
    `;
    document.head.appendChild(style);
})();

[Eugeny]

Which modal are you seeing this with? I've clicked through all of them again and they all have both fade and show.

[wolveix]

With every modal it seems, e.g. clicking a connection on the landing page to view the SSH instructions, adding an SSH key to a user, etc. This was a fresh installation, for what it's worth.

[Eugeny]

Any errors in the devtools console?

[codyro]

I also had this issue; however, I couldn't identify what was causing it. I was experiencing it across browsers; however, none of my staff had issues with various platforms and browsers.

I have to prop up a new version of Warpgate, so I'll see if I'm still experiencing this/provide a HAR if it's helpful.

[Eugeny]

No errors. I've just added a dummy user and a dummy target so you can hopefully see for yourself: [REDACTED]

I've removed your comment so that your URL doesn't remain in the internet forever just in case

It works for me!

at this point I'm assuming it must be something client-specific - do you have any adblockers/userscripts that could be affecting it?

[wolveix]

Thanks for deleting the link :D I used an external link for exactly that reason!

Woah! I'm genuinely surprised! It happens across all of my browsers, seemingly regardless of extensions (tested Firefox, Firefox DE, Chrome, and Safari). I'll test it on another device, and report back.

[wolveix]

Okay I just tested it across Chrome and Firefox on a friend's PC (Windows 11), and yep no issues. I'm using macOS Sequoia 15.2 for what it's worth.

Edit: a colleague just tested it on macOS 12.6.3, no issues there either.

Edit: I'm at a loss here, this is very strange. I don't see any asset requests failing in browser dev tools either

[osi8]

I can confirm, the problem is gone, no clue what happened.
I used to use ublock origin, now chrome downgraded the api so ublock lite is there instead. Also my network is filtered.
But from what I know about those modals and their show/shown hooks, it might be something webkit did with regards to timing of js events.
Since it is gone and reproducability is gone too (for me at least) I will close the issue.
Anyone wanting to reproduce and fix it, can just reopen.
Thanks everyone.

[codyro]

@wolveix Seems to have found the culprit--it's for us weirdos using MacOS any OS + reduce motion: #1271 (comment)

[wolveix]

@codyro it can actually effect any OS :) If reduce motion is set at the system level, it will happen 😱

[codyro]

@codyro it can actually effect any OS :) If reduce motion is set at the system level, it will happen 😱

Oh, well that's even sillier than I thought. How this is not a bigger problem for bootstrap is beyond me.