Bug 1669149 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
This is a sketch of an idea about how the PrintPreview API could be changed to improve performance and check settings against the printer.
It’s written as a change to the nsFrameLoader API, but could be done in frontend code, although some of the steps might need new platform APIs.
I don't know how the "Apply settings to printer" step works for CUPS printers or even if it is possible.

As it would now return print settings as well, it would now need to return a Promise that resolves to an object that contains the print settings and the current promise for the PrintPreviewSuccessInfo.
Steps involving printer interaction would need to be run async on background threads.

UpdatePrintPreview(nsIPrintSettings settings)->Promise->{nsIPrintSettings, Promise}:
1. settings passed in
2. call content API to create/update preview with settings
3. apply settings to printer and retrieve updated settings (like at [1])
4. compare settings from printer to settings from prefs
5. should normally be no difference so return Promise with settings and Promise
Alternatives
1a. no settings passed (this would be the first call)
   1a1. Get settings from prefs
   1a2. return to 2.
1b. no settings passed in or saved in prefs
   1b1. get default settings from printer
   1b2. call content API to create preview with settings
   1b3. return Promise with settings and Promise
5a. settings from printer differ to settings from prefs or passed in
   5a1. call content API to update preview with settings
   5a2. return Promise with settings and Promise

[1] https://searchfox.org/mozilla-central/rev/7ef5cefd0468b8f509efe38e0212de2398f4c8b3/widget/windows/nsDeviceContextSpecWin.cpp#439-453
Revision 1 by
on 
This is a sketch of an idea about how the PrintPreview API could be changed to improve performance and check settings against the printer.
It’s written as a change to the nsFrameLoader API, but could be done in frontend code, although some of the steps might need new platform APIs.
I don't know how the "Apply settings to printer" step works for CUPS printers or even if it is possible.

As it would now return print settings as well, it would now need to return a Promise that resolves to an object that contains the print settings and the current promise for the PrintPreviewSuccessInfo.
Steps involving printer interaction would need to be run async on background threads.

```
UpdatePrintPreview(nsIPrintSettings settings)->Promise->{nsIPrintSettings, Promise}:
1. settings passed in
2. call content API to create/update preview with settings
3. apply settings to printer and retrieve updated settings (like at [1])
4. compare settings from printer to settings from prefs
5. should normally be no difference so return Promise with settings and Promise
Alternatives
1a. no settings passed (this would be the first call)
   1a1. Get settings from prefs
   1a2. return to 2.
1b. no settings passed in or saved in prefs
   1b1. get default settings from printer
   1b2. call content API to create preview with settings
   1b3. return Promise with settings and Promise
5a. settings from printer differ to settings from prefs or passed in
   5a1. call content API to update preview with settings
   5a2. return Promise with settings and Promise
```

[1] https://searchfox.org/mozilla-central/rev/7ef5cefd0468b8f509efe38e0212de2398f4c8b3/widget/windows/nsDeviceContextSpecWin.cpp#439-453
Revision 2 by
on 
This is a sketch of an idea about how the PrintPreview API could be changed to improve performance and check settings against the printer.
It’s written as a change to the nsFrameLoader API, but could be done in frontend code, although some of the steps might need new platform APIs.
I don't know how the "Apply settings to printer" step works for CUPS printers or even if it is possible.

As it would now return print settings as well, it would now need to return a Promise that resolves to an object that contains the print settings and the current promise for the PrintPreviewSuccessInfo.
Steps involving printer interaction would need to be run async on background threads.

```
PrintPreview(nsIPrintSettings settings)->Promise->{nsIPrintSettings, Promise}:
1. settings passed in
2. call content API to create/update preview with settings
3. apply settings to printer and retrieve updated settings (like at [1])
4. compare settings from printer to settings from prefs
5. should normally be no difference so return Promise with settings and Promise
Alternatives
1a. no settings passed (this would be the first call)
   1a1. Get settings from prefs
   1a2. return to 2.
1b. no settings passed in or saved in prefs
   1b1. get default settings from printer
   1b2. call content API to create preview with settings
   1b3. return Promise with settings and Promise
5a. settings from printer differ to settings from prefs or passed in
   5a1. call content API to update preview with settings
   5a2. return Promise with settings and Promise
```

[1] https://searchfox.org/mozilla-central/rev/7ef5cefd0468b8f509efe38e0212de2398f4c8b3/widget/windows/nsDeviceContextSpecWin.cpp#439-453

Back to Bug 1669149 Comment 0