User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

navigate to any pdf document and view it embeeded.
then, try to print it, using the printer icon in embeeded zone.

Actual results:

the PRINTER options are opened.
( this may be not a bug, may be a feature, but it is wrong ).

Expected results:

The PREVIEW options should be opened instead, just like when we use the MENU OPTION "Print..."

preview options help user to adjust the correct desired orientation. just like google chrome does it. even if the pdf document pdf is showing in the page correctly, some undesired result can happen if the document is not previewed before printing occurs.

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

(In reply to Sepocar from comment #0)

Actual results:
the PRINTER options are opened.
( this may be not a bug, may be a feature, but it is wrong ).

Expected results:
The PREVIEW options should be opened instead, just like when we use the MENU OPTION "Print..."

Actually, File-menu|Print does the same thing and always has (it opens the print dialog, not print-preview).

The hamburger-menu (the upper right three-lines-menu) is different for some reason -- it opens Print Preview for some reason. I agree that it is confusing that these 3 different "print" options don't all do the same thing, though I don't know if there's a great way to unify them. Having said that, I suspect the Print dialog is really the right dialog to open in this case, because Print-Preview is meant to let you adjust formatting for HTML documents, and PDFs are more meant to be straight-to-printer.

Anyway, as-filed, this is a PDF Viewer bug (since that's where this print icon exists), though I don't think this behavior is likely to change.

(In reply to Daniel Holbert [:dholbert] (reduced availability until June 12) from comment #2)

(In reply to Sepocar from comment #0)

Actual results:
the PRINTER options are opened.
( this may be not a bug, may be a feature, but it is wrong ).

Expected results:
The PREVIEW options should be opened instead, just like when we use the MENU OPTION "Print..."

Actually, File-menu|Print does the same thing and always has (it opens the print dialog, not print-preview).

The hamburger-menu (the upper right three-lines-menu) is different for some reason -- it opens Print Preview for some reason. I agree that it is confusing that these 3 different "print" options don't all do the same thing, though I don't know if there's a great way to unify them.
Having said that, I suspect the Print dialog is really the right dialog to open in this case, because Print-Preview is meant to let you adjust formatting for HTML documents, and PDFs are more meant to be straight-to-printer.

Yes, that's correct assuming that all PDF are well formatted and contain all information about the orientation ( we agree that in this case, direct printing only is the way to go ). BUT, that is not always the case, for example, many php pdf creators like laravel/dom-pdf, does not include orientation information in output pdf. or may be has to be activate one flag like in imagemagick pdf generator. anyway, my point is: there are many pdf creators that not include orientation in their output, or requires the developer (generator of the pdf) that know flags to generate a perfect pdf, and, like in html, there are many resulting flavors out there. solution: give to the end user the power to modify or apply proper format to his pdf output, if this is not done, becomes a pain, and the user has to go to chrome ( where the preview appears by default ) in order to print his inproper created pdf document.

Anyway, as-filed, this is a PDF Viewer bug (since that's where this print icon exists), though I don't think this behavior is likely to change.

Thanks for take a look.

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

I think this bug, as-described, is fixed by our new tab-modal printing UI (which removes the distinction between "print preview" vs. "print", and shows a preview automatically as part of the standard print flow).

That work is tracked under bug 133787.

I don't think there's anything additional to do here beyond getting that UI implemented + shipped, so I'm duping this to bug 133787.