Soliciting advice on #650960 (replacement for print progress bars)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Soliciting advice on #650960 (replacement for print progress bars)

Zack Weinberg-2
https://bugzilla.mozilla.org/show_bug.cgi?id=650960 seeks to replace the
existing print progress bars with something that isn't app-modal.
Ignore musings in the description and first few comments about getting
rid of them entirely and/or waiting for bug 629500.  The current
thinking is that we need *some* indication that a print job is in
progress, because we need to prevent the user from closing the tab or
window until the print job has been completely handed off to the OS.
However, the way this is implemented now is inconvenient (it's been
shoehorned into the nsIWebProgressListener interface, which is not
really fit for the purpose, and it involves some really icky [that's a
technical term] back-and-forth between C++ and JS) and app-modal
anything is Just Wrong.

The existing patches in the bug have been vetoed because doorhanger
notifications aren't even universally available within Firefox, never
mind other applications.  I am not aware of any universal alternative,
and I know very little about XUL.  I *think* that the low-level approach
in the bug, of firing special chrome events at the window (plus some
docshell goo to do the actual close suppression), is still viable, and I
think doorhangers are appropriate for this when they're available.  But
I would like some help figuring out what a good universal-backstop
*receiver* of those chrome events would look like, both in UX terms and

dev-embedding mailing list
[hidden email]