ProgressWindow stays on top when Zotero is minimized on macOS - any alternatives?

[José Fernandes]

Hi everyone,

I'm developing a Zotero plugin and got a bug report about ProgressWindow staying visible when Zotero is minimized to the dock on macOS. The progress popup floats above all other apps, which is confusing for users.

I traced it to progressWindow.js line 130:

    _progressWindow = _window.openDialog("chrome://zotero/content/progressWindow.xhtml",
        "", "chrome,dialog=no,titlebar=no,alwaysontop=yes");

The "alwaysontop=yes" keeps it above everything, even when Zotero is minimized.

I noticed progressQueueDialog.js uses "dependent" instead, which correctly makes the window follow its parent when minimizing on macOS.

From the plugin side I tried:

• Setting win.opener = mainWindow after creation (doesn't affect z-level)
• Modifying xulWin.zLevel to normalZ (read-only after creation)
• Creating custom window with "dependent" (works but requires reimplementing all ProgressWindow functionality)

A few questions:

1. Is there a recommended way for plugins to show progress that respects macOS window management?
2. Would changing "alwaysontop=yes" to "dependent" in progressWindow.js be reasonable for macOS? Or is there a specific reason alwaysontop is used?
3. Is there an alternative API I should use for long-running operations?

Happy to submit a PR if there's interest in changing the core behavior.

Thanks!

References:

• User report: https://github.com/introfini/ZotSeek/issues/14
• progressWindow.js: https://github.com/zotero/zotero/blob/main/chrome/content/zotero/xpcom/progressWindow.js#L130
• progressQueueDialog.js (uses dependent): https://github.com/zotero/zotero/blob/main/chrome/content/zotero/xpcom/progressQueueDialog.js#L48

[Alain Borel]

Apparently this was integrated into Zotero, which makes complete sense, but it is causing an issue for me https://github.com/UB-Mannheim/zotero-ocr/issues/124

The user can think that there is no progress window, or assume that it has been closed, while it is actually running just fine behind the main Zotero window.

Is there a way to set the position of the progress window, or to make it easier for a user to find it back if it has been pushed backwards?

The user can just move the main window, which will reveal the ongoing progress window, but I am not sure everybody will think about that...

All ideas are welcome.

Best regards,

Alain Borel

[José Fernandes]

Hi Alain,

Thanks for chiming in, and sorry you're hitting this too. What you describe in zotero-ocr looks like the flip side of the same root cause I opened this thread about: progressWindow.js opens the popup with alwaysontop=yes and no opener, so it sits entirely outside the main window's z-order hierarchy. On macOS it floats above every application even when Zotero is minimized; in your case it ends up stranded where users can't find it and assume the operation failed or was cancelled.

For reference, the report that led me to open this thread is still open on my side as well, so this now affects at least two plugins that use Zotero.ProgressWindow for long-running operations:

https://github.com/introfini/ZotSeek/issues/14

Since Zotero's own progressQueueDialog.js already uses "dependent" and behaves correctly with respect to the parent window, would a PR switching progressWindow.js to the same approach (or making it configurable) be welcome? Alternatively, if there's a recommended API for plugins to show progress on long operations that doesn't have this problem, I'd happily migrate both use cases to it.

[Alain Borel]

Hello José,

I'm not sure we are exactly on the same page here, allow me to check :-) As far as I can tell, a change introduced in Zotero in July (in progressWindow.js, line 131) could (I think) address your issue - and I agree that keeping the progress window on top of all windows, disregarding status of the main Zotero window. However, the new dependant option is not right for me since it allows the progressWindow to be hidden by the main one (or other Zotero dialogs, I guess). My sweet spot would be something intermediate (always on top *OF ZOTERO*, not syste-wide), or a good workaround to ensure a reasonable UX.

If I am misunderstanding something, somebody please let me know!

Alain

[Alain Borel]

Sorry, incomplete sentence: ... I agree that keeping the progress window on top of all windows, disregarding status of the main Zotero window, is not great.

[José Fernandes]

Hi Alain,

Following up on my promise to verify: the Zotero 10 change helps, but it turns out "dependent" is almost a no-op on macOS, so I want to share what I found since it likely explains your experience too.

I tested on Zotero 10.0.1 (macOS): the popup is indeed created with the dependent chrome flag and without always-on-top, and it no longer floats over other applications once you click another window. But it does not follow the main window when you minimize Zotero: it lingers on screen over whatever was behind, until something forces a raise. The reason is in Firefox's Cocoa widget (nsCocoaWindow.mm): addChildWindow: is only applied to popup-type windows (menus, tooltips), and the floating window level only to alwaysontop/alert windows. For a top-level chrome window like the progress popup, the dependent feature's only effect is setting the widget parent, which Cocoa then ignores. This is the same in ESR 140, ESR 153 and current mozilla-central, and it has been known upstream since 2007: https://www.google.com/url?q=https://bugzilla.mozilla.org/show_bug.cgi?id%3D385714&source=gmail&ust=1788185868748000&sa=E (closed WORKSFORME in 2021 without an actual fix). On Windows and Linux, dependent maps to the native owner/transient relationship, so there you get both "floats above the parent" and "minimizes with it" for free; on macOS you get neither.

Your sweet spot (always on top OF Zotero, not system-wide) is exactly what addChildWindow:ordered:NSWindowAbove provides natively on macOS, so the OS supports it; it is just not wired up in Firefox for this window type. That might be worth an upstream ask, either on the Zotero side (attach the popup as a native child window on macOS) or by reopening the Bugzilla issue with a current test case.

In the meantime I fixed my half on the plugin side: ZotSeek 1.21.1 listens for the main window's sizemodechange and hides/shows the popup via nsIBaseWindow.visibility, so it now follows minimize/restore. One trap if you try the same in zotero-ocr: the visibility getter does not read back what the setter wrote, so only ever write it and track the intended state yourself.

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/4245e405-e7b5-43a4-9200-a2b5323c684en%40googlegroups.com.

[Alain Borel]

Thanks for this very useful and detailed explanation!

I will take a closer look at your code, and hopefully I can adjust mine.

Best regards,

Alain

To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.

[XY Wong]

Thank you for the discussion. We will consider the suggestions for future plugin API design.