Treestyletab: new style tree close confirmation dialog flashes as small blank square window, in the upper left corner, before finally showing

[bughit]

Short description

new style tree close confirmation dialog briefly flashes as small blank square window, in the upper left corner of fx, before finally showing properly rendered. This type of flashing is distracting and annoying and appears to lengthen the time to full open.

In the screenshot it's partially transparent due to the timing of the capture

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. create a tree of tabs
4. close this tree

Environment

• Platform (OS): win7 sp1 x64
• Version of Firefox: 75.0.0 x64
• Version (or revision) of Tree Style Tab: 3.5.3

[davidmbesonen]

[Windows 7 SP1 64-bit, Firefox 68.3.0esr 64-bit, TST 3.5.3]

I noticed the same small square blank window just before the "Bookmark this tree..." dialog box is displayed. This began after upgrading from 3.3.6 to 3.5.3.

[DaAngus]

Linux, Sway Window Manager, Wayland Firefox
Can confirm, it opens up a new Window for the dialog

[piroor]

Sadly this is due to a bug of Firefox. Technical behind:
https://github.com/piroor/treestyletab/issues/2566#issuecomment-619395241

[piroor]

With recent changes the small window now appears near the final position, so I hope it reduce annoyings from flicking at the edge of your sight.

[bughit]

Why did you switch to this new style with the bug? Can you add an option to use the old one?

[piroor]

Answer from my comment at #2566 :

I think this popup window based dialog is required to improve user experience around special pages (about: pages and some websites of Mozilla), because the old style in-page dialog is not available on such cases if the sidebar is hidden.

[bughit]

because the old style in-page dialog is not available on such cases if the sidebar is hidden

It looks like you are sacrificing more general usability for a relative corner case. Please restore the old dialog where it works.

[piroor]

I thought that the old style had more problem when the dialog was shown in the content area:

• The appearance of the confirmation message can be affected from CSS of the current page.
• The behavior of the dialog can be affected from scripts of the current page.
• Looks not compatible with webpages containing subframes.
• The dialog is tab-modal, so you can switch tabs while the dialog is shown and you can open/close tabs while the confirmation is shown. Such operations can break the result of the confirmation.
• The sidebar area is narrow, so dialogs become narrow also.

The old style was initially used just because I didn't know how to show a modal dialog by an WebExtensions addon. I agree that the current implementation has some problems, but stability is prior to speed and beauty appearance, this is a basic design policy of this project. On this policy sometimes you may see degression like this.

[bughit]

There's is no rule that all dialogs should be the same. If the old one does not work for content, fine show the new one, but for this use case, in the side-bar, the old dialog currently works better and shouldn't be made worse for the sake of consistency with content.

[davidmbesonen]

[Windows 7 SP1 64-bit, Firefox 68.3.0esr 64-bit, TST 3.4.10]

Please return the old dialog box for the "Bookmark this Tree..." function. The new dialog box made this function so unbearable (super slow responsiveness) to use that had to downgrade to TST 3.4.10. As soon as I did that, I was hugely relieved to have this dialog box (which I use a lot) be snappy again.

[piroor]

OK, I've reintroduced a new optional behavior: show dialogs in the sidebar if possible. I won't use the option but put them into the codebase for people actually suffering from slow window open and bad experience due to poor API of Firefox itself.

[piroor]

There's is no rule that all dialogs should be the same.

I don't think so. Consistency of UI is important, this is one of high priority topics I'm struggling on TST. Indeed the context menu on TST's sidebar imitates Firefox's native tab context menu except features impossible to be implemented on WebExtensions API. Dialogs also should behave same to Firefox's one on same reason. I think the new option to get back the old behavior (it improves speed but reduces UI consistency) is a symbol of defeat due to WebExtensions restrictions (and my poor technological capability)...

[piroor]

I've posted a patch to Firefox fixing the restriction.
https://bugzilla.mozilla.org/show_bug.cgi?id=1271047#c10

[davidmbesonen]

OK, I've reintroduced a new optional behavior: show dialogs in the sidebar if possible. I won't use the option but put them into the codebase for people actually suffering from slow window open and bad experience due to poor API of Firefox itself.

Thanks. How will we enable this option?

[piroor]

A new checkbox will appear under the "Appearance" section.

By the way I've introduced more changes about popup type dialog. Now the size of a popup is calculated before it is really opened, so you won't see the flashing small square window anymore. (But it may be still slow on some environment.)

[DaAngus]

Just to expand that its not only

slow window open

that creates potential for problems:
If you use a tiling window manager any dialogs that open in a new window the way its done now
(close multiple tabs, open multiple tabs flat or stacked)
will cause firefox and the dialog to share the screen in equal areas.

before:
firefox is fullscreen, dialog opens inside firefox, select option and keep going.
now:
firefox is fullscreen, dialog opens over half the screen, firefox takes the rest of the screen, select option, dialog disappears and firefox resizes to full screen.

That is the default for sway, i3 and I guess others. It is configurable with special rules but I refrain from that for now because its only this extension.

[bughit]

@piroor

Fixed. In conclusion I would suggest making sidebar dialogs the default for sidebar operations. Not only do they open faster, seemingly still, but they're positioned better, closer to the sidebar action being performed. Such dialogs should not be main window centered.

[piroor]

@DaAngus

If you use a tiling window manager any dialogs that open in a new window the way its done now
(close multiple tabs, open multiple tabs flat or stacked)
will cause firefox and the dialog to share the screen in equal areas.

Oh... I didn't know that. On such an environment, how Firefox's built-in dialogs (window closing with multiple tabs, and others) are shown?

[DaAngus]

@DaAngus

If you use a tiling window manager any dialogs that open in a new window the way its done now
(close multiple tabs, open multiple tabs flat or stacked)
will cause firefox and the dialog to share the screen in equal areas.

Oh... I didn't know that. On such an environment, how Firefox's built-in dialogs (window closing with multiple tabs, and others) are shown?

Every firefox (and other extensions) dialog is inside the regular window limit, the treestyletab dialogs are the only ones that create a new window.

I forgot about the FF "webcam/microphone active" notification which is the only instance I came across that creates a new window, but I guess there is a security reason behind it.

[piroor]

@DaAngus I've tried "i3" on Ubuntu 20.04LTS but it allows me to show a dialog as a floating window.

"i3" looks to be able to handle "dialog" type windows intelligently, so I think that half-screen size dialog problem can be fixed by the window manager side. Is that true?