312018 - Page with "long" title saved as PDF as "Untitled.pdf"

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Shorter, but long-ish, title

Er, Camino 2005101004 (v1.0a1+) here, 10.3.9.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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?

Comment 3

[Livin Stephen Sharma]

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" ?

Comment 4

[Livin Stephen Sharma]

I'm using "Version 2007022701 (1.1b+)".

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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*.

Comment 6

[Stuart Morgan]

Attachment: 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.

Comment 7

[Stuart Morgan]

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.

Comment 8

[Josh Aas]

Comment on attachment 295384 [details] [diff] [review]
fix

looks good, thanks Stuart!

Comment 9

[Stuart Morgan]

Comment on attachment 295384 [details] [diff] [review]
fix

pink, are you a good person to sr this?

Comment 10

[Samuel Sidler (old account; do not CC)]

Boris or Benjamin should probably look at this patch.

Comment 11

[Benjamin Smedberg]

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

Comment 12

[Stuart Morgan]

Landed on trunk with the above changes.

Moving to Core, since that's probably where it belonged in the first place.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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)

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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 15

[Daniel Veditz [:dveditz]]

Comment on attachment 295384 [details] [diff] [review]
fix

approved for 1.8.1.12, a=dveditz for release-drivers

Comment 16

[Stuart Morgan]

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.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Sam Sidler, can you track down a Camino nightly using the 1.8 branch and verify this?

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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:1.8.1.12pre) Gecko/20080118 Camino/1.6b2 (like Firefox/2.0.0.12pre)