2001-09-28-08-trunk Solaris7+/Linux + Win32 nightly build. The given example URL results in a blank page (title "about: blank") ...
David, I didn't think we where ever going to allow this, were we?
rods wrote: > David, I didn't think we where ever going to allow this, were we Er... why not ? I can print pages with HTML form controls. It should be possible to print pages with XUL components, too (navigator.xul may be a bad example - but even that should work...).
Works for me, using both file and chrome urls on XUL pages with window tags -- tested with 0.9.6 and 0.9.4 win2k.
Roland does this work for you now ?
1. I type chrome://navigator/content/navigator.xul 2. Menu "File/Print...", selecting printer, "OK" Result: print output of about:blank 3. load http://www.sunhelp.org/ in "embedded" chrome://navigator/content/navigator.xul 4. Menu "File/Print...", selecting printer, "OK" Result: print output of chrome://navigator/content/navigator.xul But I want to print the chrome+content - not only the content alone ...
Is there any work on making XUL pages printable ? Currently I get a "We are unable to Print or Print Preview this page."-error dialog... ;-(
need hyatt's help for this, I haven't looked into printing generic XUL, but the TReeWidget has major problems. All the problem stem from XUL always wanting to create scrollbars, not a good thing when printing
rods wrote: > need hyatt's help for this, I haven't looked into printing generic XUL, IMHO we should fix this ASAP since this makes the implementation of a "Print"-functionality in XUL/GRE(=Gecko Runtime Env.) near-to-impossible... ;-( > but the TReeWidget has major problems. What about handing the Tree widget like normal HTML tables (splitting it over multiple pages as neccesary etc. (e.g. make a common superclass for both tables and tree widget and put the pagination algorithm in the superclass)) ?
Roland wrote: IMHO we should fix this ASAP since this makes the implementation of a "Print"-functionality in XUL/GRE(=Gecko Runtime Env.) near-to-impossible... ;-( I am not sure what you mean by this, please elaborate.
Created attachment 99678 [details] PostScript file This is a PS file from printing the Print Setup Dialog, for some reason the two paper orientation images are scaled small. But other than that it looks pretty good. So it appears that the XUL tree is the one that messes up and is why we disabled it.
rods wrote: > So it appears that the XUL tree is the one that messes up and is why we > disabled it. OK, can we then re-enable XUL printing in general (e.g. file a sepeate bug (marking it a blocker for this one) with a patch, I'll r= it when I am back on Sunday) and file a bunch of new bugs for the following issues (all blockers for this bug): - Make Tree widget printable (I suggest to use the same algorithm as for the HTML table stuff) - Disable scrollers in print/print preview mode - RFE: Implement CSS2 page-* properties for XUL widgets (see bug 132035 ("Support all page-break-* CSS2 properties") for references) - Invetigate if shrink-to-fit must be adjusted for printing XUL widgets
Is there any argument in removing the code which generates the |NS_ERROR_GFX_PRINTER_NO_XUL|-error ?
Is this fixed by the patch in bug 137526?
15 years ago
Simon Fraser wrote: > Is this fixed by the patch in bug 137526? Sorry, no. That bug only removed the code which disabled printing of XUL documents completely. Now we have to work on getting XUL documents printing (which works mainly - except some kinds of XUL widgets cause crashes). I filed bug 188836 ("XUL printing tracking bug") to track the further work for XUL printing...
Printing XUL documents was disabled again in bug 240490 (in December 2004).
For the record, this came up at bug 1181630. There I noticed that "printing doesn't work for pages without web content" -- for example the about:config and Preferences pages. Now that we're "killing XUL", it's understandable that we don't want to add new features -- for example making XUL pages printable. But maybe, as part of the process of "killing XUL", we can make these pages printable by re-writing them in HTML? What do you think, Mark? Should I open a bug on this?
Personally, I'd WONTFIX this bug. Mozilla is no longer (and maybe never was) trying to get people to use XUL for building things.
I've gone ahead and opened bug 1182625.
(In reply to Mark Finkle (:mfinkle) (use needinfo?) from comment #18) > Personally, I'd WONTFIX this bug. Mozilla is no longer (and maybe never was) > trying to get people to use XUL for building things. (In reply to Steven Michaud [:smichaud] (Retired) from comment #20) > I've gone ahead and opened bug 1182625. => wontfix