[FIX]Enable developers to fly their print dialog

VERIFIED FIXED in mozilla1.0

Status

()

Core
Printing: Output
P1
normal
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: rods (gone), Assigned: rods (gone))

Tracking

(Blocks: 1 bug, {topembed+})

Trunk
mozilla1.0
x86
Windows 2000
topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Assignee)

Description

16 years ago
 
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 1

16 years ago
Can you explain this bug a little better?
(Assignee)

Comment 2

16 years ago
The solution for this bug will be to introduce a "pluggable" dialog service.
Just like the network libs use the nsIPrompt mechanism for flynig dialogs and
embedders can override them with their own dialogs.

My guess is that much like what we do for netwerk, we will pass in a
nsIInterfaceRequestor for callbacks and then do a GetInterface on the callbacks
for the nsIPrintingPrompt interface.

The implementation of that can then be elsewhere like in the embedding
directory. The a particular platform can choose to use the nsIInterfaceRequestor
or just fly their own native one.

On Windows we may move entirely away from the XPDialog, but certainly for Linux
we need to do this.

Comment 3

16 years ago
I assume this solution would remove entirely the dependencies in gfx on dom and 
windowwatcher? Would gfx become dependent on embedcomponents, or would print 
dialogs be invoked entirely from outside of gfx?

Updated

16 years ago
Blocks: 108502
Marking nsbeta1+.
Keywords: nsbeta1+

Updated

16 years ago
Blocks: 124777
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0
(Assignee)

Updated

16 years ago
Priority: -- → P1

Updated

16 years ago
Blocks: 125824
(Assignee)

Updated

16 years ago
Blocks: 130094
(Assignee)

Updated

16 years ago
Summary: need pluggable service for Printing Dialogs → Enable developers to fly their print dialog
(Assignee)

Updated

16 years ago
Summary: Enable developers to fly their print dialog → [FIX]Enable developers to fly their print dialog
(Assignee)

Updated

16 years ago
Summary: [FIX]Enable developers to fly their print dialog → [PARTIAL-FIX]Enable developers to fly their print dialog

Comment 5

16 years ago
nsbeta1- per adt triage
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0 → ---

Comment 6

16 years ago
topembed+ per adt triage
Keywords: topembed+

Updated

16 years ago
Target Milestone: --- → mozilla1.0

Comment 7

15 years ago
rods:
How does this affect bug 136058 ("Implement nsPrinterFeatures" - the idea of
this RFE is to create a service to query printer properties/attributes like
available paper sizes/orientations for a specified printer...) ?
AFAIK embedders would need this info to "fly their" print dialog without using
hardcoded values in their print dialog (currently both PostScript module and
Xprint module use the printerfeatures prototype in
nsDeviceContextSpecGTK/nsDeviceContextSpecXlib - we only need to make the code a
XPCOM service... :)
(Assignee)

Comment 8

15 years ago
Created attachment 81155 [details] [diff] [review]
Phase #2 patch

Phase #1 patch is in Bug 135441 I will attach an overview document soon.
(Assignee)

Comment 9

15 years ago
Created attachment 82090 [details] [diff] [review]
patch

this is more up-to-date
Attachment #81155 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Summary: [PARTIAL-FIX]Enable developers to fly their print dialog → [FIX]Enable developers to fly their print dialog

Comment 10

15 years ago
rods:
Since you are already touching all platforms - is it possible to implement the
API calls for bug 133258 ("Enhance nsIDeviceContext print API with an additional
level to support multiple documents in one print job") with this patch - or (at
least) rename s/BeginDocument/BeginJob/ and s/EndDocument/EndJob/, please ?

Updated

15 years ago
Blocks: 98995
(Assignee)

Comment 11

15 years ago
Created attachment 82120 [details]
Documentation

Read about Phase #2

Comment 12

15 years ago
Glad to see that nsIPrintPromptService has landed, but, needless to say, a
pluggable print dialog system is useless if mozilla doesn't invoke print dialogs
through it. I hope rod's patch can land asap; we're (galeon) still getting
tortured by javascript.print()...

Comment 13

15 years ago
Heh, spoke too soon eh? Roadmap looks good.

Comment 14

15 years ago
Comment on attachment 82090 [details] [diff] [review]
patch

r=dcone
Attachment #82090 - Flags: review+
Blocks: 141849

Comment 15

15 years ago
Comment on attachment 82090 [details] [diff] [review]
patch

sr=attinasi, based partially on email comments that testing has been thorough
and on all platforms
Attachment #82090 - Flags: superreview+
(Assignee)

Comment 16

15 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
(Assignee)

Comment 17

15 years ago
verifying, this has been working for a couple of weeks
Status: RESOLVED → VERIFIED

Comment 18

15 years ago
Let's get this verified by QA either on the trunk or if they are substantial,
please create a test build with the batch and the branch and let QA test that. 
(Assignee)

Updated

15 years ago
Blocks: 143241

Comment 19

15 years ago
verified...
(Assignee)

Updated

15 years ago
Blocks: 99619

Comment 20

15 years ago
this patch has a bunch of conflicts.
(Assignee)

Comment 21

15 years ago
Created attachment 83866 [details] [diff] [review]
this is what was checked in

Here the patch of what was checked in and this is a list of things that had
changed:
1) Change to encode '\n' as '_' in printer names for prefs (apparently I was
testing this idea; took out the calling code but left this in, the code worked
fin ein testing)
2) The nsDeviceContextSpecOS2.cpp which had conflicts was changed to the one
mkapply sent me.
3) At the last minute we discovered that the attr isPrintPreview in the
nsIWebBrowserPrint was no longer being used, so I removed the two calls to it
in DocViewer, It was removed later from the IDL.
4) Several Mac makefile file changes that came out of the last round of builds
Conrad did
5) For reason I can't explain I must changed to debug output statments from
inside a "if (doDebug)" if statment in printjoboptions.js
6) A bunch of stuff removed from
embedding/browser/powerplant/source/CPrintAttachment.cpp and few lines added to
better use the new APIs (I reviewed) 
7) A change in an embedding make to use a renamed directory from gtk to
unixshared.
8) A bunch of changes to get the viewer app working with printing again.

So here is my justification for checking this all in without further reviews:
Conrad had just spent a lot of time diligently doing builds on Mac for Mac9,
Carbon, and OSX. Waiting any length of time might for re-reviews for I think
are fairly minor issues might require doing builds on the Mac again.

Item #1 - that is the only item of concern, but it works fine.
Item #3 - I didn't feel removing code was worth a re-review. 
Item #6 - I reviewed.
Item #8 - nobody but the layout-group cares about viewer and I am usually the
only one you uses the Print" menu item, so I figure that didn't really need to
be reviewed at this point, I didn't even have a bug on this, so obivously
nobody uses it.

Most of the others were makefile changes that cam out of Conrad's builds.

Updated

15 years ago
Attachment #83866 - Flags: approval+
(Assignee)

Comment 22

15 years ago
Created attachment 84098 [details] [diff] [review]
patch against the branch

This is the the patch against the branch, al the new embedding files are
already in on the branch, but not in the build.
(Assignee)

Comment 23

15 years ago
Created attachment 84100 [details] [diff] [review]
Merged against the Branch

Attachment 84098 [details] [diff] is in Bug 135441

This attachment is the correct one
Attachment #84098 - Attachment is obsolete: true

Comment 24

15 years ago
adding adt1.0.0+.  Please get drivers approval and then check into the 1.0 branch.
Keywords: adt1.0.0 → adt1.0.0+

Comment 25

15 years ago
changing to adt1.0.1+ for checkin to the 1.0 branch.  Please get drivers
approval before checking in.
Keywords: adt1.0.0+ → adt1.0.1+

Comment 26

15 years ago
please land on the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword,
and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1+

Updated

15 years ago
Attachment #84100 - Flags: approval+
(Assignee)

Comment 27

15 years ago
checked in on branch
Keywords: mozilla1.0.1+ → fixed1.0.1

Updated

15 years ago
Keywords: fixed1.0.1 → verified1.0.1

Updated

11 years ago
Blocks: 362840

Updated

11 years ago
Blocks: 362841
You need to log in before you can comment on or make changes to this bug.