Soliciting advice on #650960 (replacement for print progress bars)
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 implementation-wise. Thanks, zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
Do we actually need the tab, or just the document? If its the latter, can we just keep the document around invisibly? Andreas On Feb 25, 2013, at 10:14 PM, Zack Weinberg za...@panix.com wrote: 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 implementation-wise. Thanks, zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 2/25/2013 4:14 PM, Zack Weinberg wrote: 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. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedberg benja...@smedbergs.uswrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: 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. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/25/2013 04:57 PM, Bobby Holley wrote: On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedbergbenja...@smedbergs.uswrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: 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. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. The work I've already done on printing is at a rather lower level; I don't claim to understand fully how it works at the document/window/ shell level. But as far as I know, we do already clone a static copy of the document for normal printing. The only deep reason I can think of for keeping the tab around is that under some operating systems, closing the last tab triggers application shutdown, and it would probably violate expectations to delay that with no user-visible indication of why. However, I expect that if I tried to remove all the superficial reasons why we need to keep the tab around, I'd discover that it's a giant mess. Independent of all that, printing long documents can take tens of seconds just to complete the handoff to the OS print queue (I've been testing with the one-page HTML5 spec) and so I do think a user-visible indication of progress is desirable. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/26/2013 01:18 AM, Daniel Holbert wrote: On 02/25/2013 01:57 PM, Bobby Holley wrote: We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. I'm almost certain that we already do. (smaug would know for sure) We clone documents for printing and print preview. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/25/2013 11:28 PM, Benjamin Smedberg wrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: 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. Why? IIRC we still use plugins from the original page, in case we're printing pages with plugins. Is the user allowed to interact with the tab contents (potentially modifying the DOM)? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
