If you save a page with a long-ish title as a PDF from the Print dialogue, Camino suggests a filename of "Untitled.pdf" instead of "Document Title.pdf". However, this only seems to happen the *first* time you perform a "printing" operation on the page; if you've previously printed the page (the print job has the full document name, as expected, even if it's the first printing operation performed on a page) or saved the page as PDF, then saving as PDF (as the second print operation) gets the full document title suggested as the filename. Firefox properly suggests the full document title as the PDF name the first time out of the box. It even does it with really long titles, like that in the URL field. This happens even with a fresh launch of Camino, so it's not bug 303547.
Created attachment 199148 [details] Shorter, but long-ish, title Er, Camino 2005101004 (v1.0a1+) here, 10.3.9.
13 years ago
Assignee: mikepinkerton → nobody
QA Contact: printing
Target Milestone: --- → Camino1.2
Other sorts of pages (like bug query results, which have title "Bug List") also do this; I wonder if there's something about "generated"/dynamic pages that also causes this?
1. WRT the Description: > …Camino suggests a filename of "Untitled.pdf"… I found the "Untitled" to actually be ".pdf" - and this is pre-highlighted/selected when the dialogue pops up, and can be replaced like any transient selection; so that the suggested title is ".pdf.pdf". 2. And a quick question WRT Comment #1: Is the "Title:" of the attachment (id=199148) (displaying the following text) > "Testcase for long titles being saved as Untitled.pdf" - seen in the "Page Info" (Cmd-I) window - supposed to be… > "State Assistance Programs for SSI Recipients, January 2005 - Massachusetts" ?
I'm using "Version 2007022701 (1.1b+)".
Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Created attachment 295384 [details] [diff] [review] fix The issue here (and in bug 303547, although I don't know what causes the different bad default there) is that the print job name is set only once we actually start printing, and it's supposed to be set before showing the panel according to the Carbon printing docs. This will grab the page title and insert it into the print settings just before opening the panel, which seems like the right solution. It's not clear to me whether or not Firefox uses this code; the comments above sound like not, but I would have thought that they would... Josh, if you aren't a good person to review this, please let me know who is.
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #295384 - Flags: review?(joshmoz)
And actually, I think the underlying issue does affect Firefox; I suspect this fix would also cover bug 410527 and bug 244814 (as well as Camino bug 407434). Bug 407434 is probably the clearest description of the basic problem.
Severity: minor → normal
Comment on attachment 295384 [details] [diff] [review] fix looks good, thanks Stuart!
Attachment #295384 - Flags: review?(joshmoz) → review+
Comment on attachment 295384 [details] [diff] [review] fix pink, are you a good person to sr this?
Boris or Benjamin should probably look at this patch.
Attachment #295384 - Flags: superreview?(mikepinkerton) → superreview?(benjamin)
Comment on attachment 295384 [details] [diff] [review] fix >Index: embedding/components/printingui/src/mac/nsPrintingPromptServiceX.cpp >+ // Set the print job title >+ PRUnichar** docTitles; >+ PRUint32 titleCount; >+ webBrowserPrint->EnumerateDocumentNames(&titleCount, &docTitles); Please add an nsresult-check here. >+ nsMemory::Free(docTitles[i]); Here and below please use NS_Free instead of nsMemory::Free. sr=me with those changes
Attachment #295384 - Flags: superreview?(benjamin) → superreview+
Landed on trunk with the above changes. Moving to Core, since that's probably where it belonged in the first place.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Component: Printing → Printing
Product: Camino → Core
Resolution: --- → FIXED
Verified fixed with tinderbuild: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b3pre) Gecko/2008011019 Camino/2.0a1pre (like Firefox/3.0b3pre)
Status: RESOLVED → VERIFIED
11 years ago
I also ran through these testcases and a number of random pages (since bug 410527 and bug 244814 have no testcases) in the equivalent Minefield tinderbuild and could not trigger this bug (again, on 10.5.1): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011019 Firefox/3.0b2pre
Comment on attachment 295384 [details] [diff] [review] fix approved for 220.127.116.11, a=dveditz for release-drivers
Attachment #295384 - Flags: approval18.104.22.168? → approval22.214.171.124+
Landed on MOZILLA_1_8_BRANCH, with PMSetJobNameCFString instead of PMPrintSettingsSetJobName; the latter is the 10.4+ only version of the function (the former being deprecated as of 10.5), but both take the same arguments and have the same purpose and behavior.
Keywords: testcase → fixed126.96.36.199
Sam Sidler, can you track down a Camino nightly using the 1.8 branch and verify this?
Verified fixed on the branch with Camino 1.6b2 on 10.3.9/PPC and 10.5.1/Intel: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:188.8.131.52pre) Gecko/20080118 Camino/1.6b2 (like Firefox/184.108.40.206pre)
Keywords: fixed220.127.116.11 → verified18.104.22.168
10 years ago
Duplicate of this bug: 410527
You need to log in before you can comment on or make changes to this bug.