User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) Gecko/2010111021 Camino/2.0.6 (like Firefox/3.0.19) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) Gecko/2010111021 Camino/2.0.6 (like Firefox/3.0.19) In earlier versions of Camino (since v1.0), it was possible to change the print headers and footers via the OS X integration, i.e. via the Camino tab of the Print dialog. This appears to be no longer possible as of at least v2.0.6 (possibly earlier). When printing from Firefox, there is a Firefox tab in the Print dialog, and I am able to change the print headers/footers there. In Camino, there does not appear to be a Camino tab in the Print dialog anymore, and I can't find any other GUI method of changing the print headers/footers. Reproducible: Always Steps to Reproduce: 1. Try to print 2. In the Print dialog, try to change headers and footers Actual Results: There does not appear to be a GUI way of changing the printed headers/footers. Expected Results: There should be a way of doing it... Obviously, one can manually edit the print.print_(header|footer)* parameters within about:config, but this is not optimal. Firefox retains its OS X print integration and allows a GUI method of modifying these options; Camino seems to have lost it. I am using OS X 10.6.5 with Camino v2.0.6.

Either access this UI before viewing a page with a plug-in, or use the nightlies. (The way plug-ins draw their own windows breaks something in the PrintPDE architecture; nightlies, like the current version of Firefox, now use Cocoa rather than the PrintPDE for this UI.)

Smokey, I may not have been clear: this occurs when trying to print from __ANY__ page, not just a page with a plugin. For example, if I try to print this very bugzilla page, I cannot access the UI to change page headers/footers. This appears to be _related_ to bug 303548, but I don't believe it is actually a duplicate. Since this page doesn't have any plugins, why would the dialog still be disabled?

(In reply to comment #2) > Since this page doesn't have any plugins, why would the dialog > still be disabled? Because that's how it works. Viewing any plugin content, in any window, breaks all future use of the print dialog within that browsing session on older Geckos. This is *exactly* the symptom described in the other bug. The URL you're viewing at the time you notice the problem is totally irrelevant; it can be anything you wish (even about:blank) and the bug will still manifest. All that's required is that you visited some plugin content earlier in your browsing session. With the ubiquity of Flash these days, it's pretty hard *not* to do this. cl

OIC - it's not limited to the specific browser window, and even if you've closed all windows, then the bug still presents because a plugin had loaded at some point in the past? Ouch. Thanks for clarifying. I guess I'll wait until the next official release, which I assume will incorporate the fixes from the nightlies. Sorry for the dupe.

Yeah, exactly. It's a nasty bug for people who hit it regularly, but it's at least simple to work around -- do any print configuration immediately upon launching :) The nightlies are pretty much alpha-quality if you'd like to try one :) (Be sure to back up your profile, as they'll make irreversible changes to some files in there if you decide to go back to the 2.0.x release builds.) cl