Add available paper size information to nsIPrinter interface
Categories
(Core :: Printing: Setup, enhancement, P1)
Tracking
()
People
(Reporter: nordzilla, Assigned: nordzilla)
References
(Blocks 1 open bug)
Details
(Whiteboard: [print2020_v81])
Attachments
(3 files, 1 obsolete file)
The new print preview UI will require page-size information. This patch will add functionality to get the available page size names and dimensions from an nsIPrinter
.
Implementation Plan
- Part 1 -- Add
nsIPaper
Interface and base implementation - Part 2 -- Implement retrieval for macOS
- Part 3 -- Implement retrieval for GTK
- Part 4 -- Implement retrieval for Windows
Assignee | ||
Comment 1•4 years ago
|
||
- Add
nsIPaper
interface. - Add
nsIPaper
implementaiton.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Backed out for perma failures.
Log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309456978&repo=autoland&lineNumber=117770
Backout: https://hg.mozilla.org/integration/autoland/rev/6c9609b0b2516c964a65b42796fd58917f7f66b6
Comment 6•4 years ago
|
||
At least some of this is down to a previous change that hasn't been hit until this test:
https://searchfox.org/mozilla-central/rev/af5cff556a9482d7aa2267a82f2ccfaf18e797e9/widget/windows/nsDeviceContextSpecWin.cpp#598
When the argument was changed this wasn't removed and never gets deleted.
I still seem to be getting another nsTArray_base leaked however ... still looking.
Comment 7•4 years ago
|
||
Found the last one, it is from here [1], which is called as part of [2].
I think we need to add a custom destructor to nsPrinterListWin and add the following into it:
GlobalPrinters::GetInstance()->FreeGlobalPrinters();
[1] https://searchfox.org/mozilla-central/rev/89814940895946b48b4c04c702efd2c676ec8e7e/widget/windows/nsDeviceContextSpecWin.cpp#624
[2] https://searchfox.org/mozilla-central/rev/89814940895946b48b4c04c702efd2c676ec8e7e/widget/windows/nsDeviceContextSpecWin.cpp#589
Assignee | ||
Comment 8•4 years ago
|
||
Thanks for hunting those down. I found the GlobalPrinters::GetInstance()->FreeGlobalPrinters();
one over the weekend but I saw that it didn't fix the entire issue:
I will patch this ASAP.
Assignee | ||
Comment 9•4 years ago
•
|
||
I've launched a try with the updated changes.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f65bc1f6b73a4d24b7a6df17f6a811ea26f1943c
Will land as soon as I see it's green. This is my fault for not running a try on Windows initially. I only tested the behavior on macOS because that is the implementation that is landing in part 2 where the test is introduced. I didn't consider that there may be a previously untested memory leak in the Windows code.
Edit:
Try came up green: re-queuing to land.
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
Backed outfor causing bustage at Unified_cpp_widget_windows1.obj
Backout link: https://hg.mozilla.org/integration/autoland/rev/70319a11bacb0a38df08ad586bbb3a5ce5c13764
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309623367&repo=autoland&lineNumber=37137
Assignee | ||
Comment 12•4 years ago
|
||
Oh gosh, that's embarrassing. I re-queued for landing after the try came up green, but I forgot to push the latest update to phabricator.
My apologies.
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
bugherder |
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
Comment 17•4 years ago
|
||
Comment 18•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 19•4 years ago
|
||
Marking as resolved, because all relevant patches have landed.
Updated•4 years ago
|
Updated•4 years ago
|
Description
•