Chromium

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

We purposely did not persist settings between browser sessions.

Printing in kiosk mode is a hack. :)

Ok now that I found that this is on purpose I found that I can do:
@page{
    margin-left: 0px;
    margin-right: 0px;
    margin-top: 0px;
    margin-bottom: 0px;
}

And it get's rid of margins, header and footers no matter what the settings in print review are. This allows me to use the kiosk mode and things work as expected. I wish I would have found this out weeks ago.

You should include an option in future chrome versions to edit your default print settings I've been having the exact same problem for two different elements inside my workplace. We have a Till System set-up which is proving to be a problem for receipt printing as we have to remove margins and headers and footers. We also manage our orders using an online order system and we have to remove headers and footers so that the URL isn't printed on these invoices. If you could add this feature in it would be greatly appreciated. With all the quality products google produces I was a bit shocked that this feature isn't already implemented. (Glad that you can remove them in the first place though, every website i've been to other than this one is saying about how you can't do it in chrome. therefore i presume they are old posts)

I agree that if the print settings do not persist by design, then there should be an setting to disable headers and footers from printouts by default.

There are lots of reasons why you may not want these printed, and in all other browsers  I have used respect this.

I hope this can be considered as a future feature.

I fully agree.

I use a web based POS system and I absolutely cannot have the headers and footers printed on my receipts.  This bug is forcing me to use Firefox since you can disable both headers and footers and use it along with silent printing(kiosk mode).

Please consider this a priority as many business, that plan on running in kiosk mode, will need to disable headers and footers for receipts.

Starting in Chrome 22 the selected printer and its settings should persist across browser restart.

[Empty comment from Monorail migration]

The margin settings still do not persist.  Not only do they not persist across browser restarts, they don't even persist from one print to another inside the same browser session!

1. Opened a test page and hit CTRL + P
2. Changed margins to 1" (they default to 0.4"), unchecked "Headers and Footers"
3. Printed the page
4. Hit CTRL + P again
5. Margins reset to 0.4" (bad), header/footer was still unchecked (good)

This is unexpected.  When using Chrome to print shipping labels we want the margins to persist.  We can't use Chrome to do a large volume of printing when margins reset every print!

Reopening for further investigate.

Robert, can you look into this?

Moving out to M24, Please pull back in to previous milestones if needed.

Please do not limit the fix to only saving margins. We need to persist the "Fit to page" option as well, when printing PDFs. Currently this is always ticked by default and we need it to be un-ticked by default. We are a web based point of sale vendor and this is necessary for printing receipts where the height of the receipt print-outs is not fixed. Thanks.

Fit to page is being tracked here: http://code.google.com/p/chromium/issues/detail?id=140827

[Empty comment from Monorail migration]

Hi I have the same problem on a Win 7 32bit PC (Chrome Version 22.0.1229.94 m)  but NOT on my 64 bit PC (chrome Version 23.0.1271.52 beta-m)

https://crbug.com/chromium/123741#c17 is absolutely correct.  I have Windows 7 64 bit and was using Chrome version 22.0.1229.94 m.  Upon his/her post I upgraded to version 23.0.1271.52 beta-m and it is now storing my custom margin settings!  I CAN HAPPILY PRINT LABELS FROM CHROME!  Thank you.

[Empty comment from Monorail migration]

Please file another bug, this issue is not about flash.

Bulk de-milestoning bugs which have been previously moved, are P2 or lower, and are targeted at M25.  You can find these via DroppedIn-25.

[Empty comment from Monorail migration]

micskidk: Please don't add things to tangentially related bugs, it just confuses the issues. In other words, file new bugs for new issues.

Try Chrome instead of chromium.  It uses printer default paper size and has options for adjusting margins. I would expect chromium to also use printer default paper size, but that's a different bug, please file it as one.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  It has also not been modified in a year (prior to this update).  Thanks for helping out!

-Anthony

[Empty comment from Monorail migration]

Cannot reproduce the issue with Windows 64 bit; header/footer and margin settings persist across different prints. Is this still an issue on 32 bit Windows?

Marking as fixed as we have been unable to reproduce on Windows 7 or Windows 10; margin and header/footer settings are now saved. Please reply if this is still an issue.

[Empty comment from Monorail migration]

The issue is back in Chrome v63! (W10 x64)
Print margins are again resetting back to default after every print job. Header/footer is remembered.

The bug is back and needs fixing asap. Testing in  Win 7 x64.

The bug is back and needs fixing asap. Testing in  Win 10 x64

Issue has returned. It makes it very difficult for my office to keep their legal paperwork consistent across the board. =(

Agreed. Bug is back and needs fixing. Testing in Win 7 x64. Please fix it right away. Receipts printed are all cut off!

We have customer reporting this issue on Chrome 63.0.3239.108 running Windows 7 x32 and Windows 8 x64.
Case # 14554335
I can reproduce on a Windows 10 x64 as well: https://drive.google.com/open?id=1_I7FKT5s6lhyng0l4s_3DRr4jbET-CKA 

There is a new issue for tracking non-persistence of custom margins and advanced settings here: https://crbug.com/796900.

Is anyone seeing the original reported problem that this bug is tracking (i.e. setting margins to none or toggling header/footer is not persisted)? As far as I can tell, https://crbug.com/chromium/123741#c32 is still accurate in Chrome 63 - if margins are set to None or Minimum or the header footer checkbox is toggled, the setting is restored when the dialog is re-opened. vkasatkin@ - since you re-opened the bug and can reproduce it, can you confirm whether you are seeing this bug or the custom margins/advanced settings bug? The video you linked looks like the custom margins bug to me. We try to track different bugs in separate issues even if they have somewhat similar symptoms, because they often need to be addressed separately.

Yes, I can confirm that issue only reproducible with Custom margins, so it should be a part of https://crbug.com/796900.
thank you rbpotter@

Confirmed bug with Version 63.0.3239.132 (Build ufficiale) (a 64 bit)
Please need fix ASAP because we have to print coupon fast and easy and we have to set margins every time and this is time consuming when there is too much people that have to bet on games

Confirmed on Win 10: Version 63.0.3239.84 (Official Build) (64-bit)

Please bring back margins that can be saved!

If you are seeing this issue with custom margins only, please see https://crbug.com/796900 which is the bug for tracking problems with Custom Margins and Advanced Settings not being saved. That issue has been fixed on Canary/Dev and was merged forward to Chrome 64 which is currently in Beta. Unfortunately, since it was not reported until Chrome 63 was already almost completely rolled out to Stable, it cannot be fixed in 63. Chrome 64 will become the Stable channel in a few weeks.

If you are seeing an issue with margin settings like "Minimum" or "None" not being remembered, or with the header/footer setting not being saved, which is the issue tracked by this bug, please specify that in your comments, as that would represent a separate bug that needs a different fix. Also please specify the steps to reproduce the problem, as per comments 40 and 41 we have not been able to reproduce that issue in Chrome 63+ so far.

Closing issue as Wontfix due to lack of feedback requested but not provided. If the issue still exists please open a new issue with the details requested.

Thanks..!

[Comment Deleted]

This issue was migrated from crbug.com/chromium/123741?no_tracker_redirect=1

[Multiple monorail components: Internals>Printing, UI]
[Monorail mergedwith: crbug.com/chromium/326262]
[Monorail components added to Component Tags custom field.]