1668002 - Pressing Ctrl-P brings a non-functional popup, with an error in the console

Status: RESOLVED DUPLICATE of bug 1663503

(Toolkit :: Printing, defect, P1)

Description

[Julien Wajsberg [:julienw]]

When I try to print in any page in current nightly, this is the error I get:

Uncaught (in promise) TypeError: can't access property "id", matchedPaper is undefined    print.js:434:9
    refreshSettings chrome://global/content/print.js:434
    init chrome://global/content/print.js:250
    async* chrome://global/content/print.js:85
    EventListener.handleEvent* chrome://global/content/print.js:82

The print preview is never generated and no form element is displayed to move forward with the print operation.

I use nightly from Sep 28, but I also had the error in the nightly from Sep 22. I don't know for previous nightlies, but I know this worked before with the new interface.

I'd be happy to help debugging more.

Hey Jonathan, Sylvestre told me you're the right person to NI here!

Comment 1

[Julien Wajsberg [:julienw]]

Oh BTW: using Linux Debian (stable version).

Comment 2

[Julien Wajsberg [:julienw]]

Beta 82 works fine on my system.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

(Seems like an important regression…)

Comment 4

[Mark Striemer [:mstriemer]]

This looks like it will probably be fixed by bug 1663503

Comment 5

[Jonathan Watt [:jwatt]]

Can you attach your about:support?

Comment 6

[Julien Wajsberg [:julienw]]

Attachment: about:support output

sure, here you are!

Comment 7

[Julien Wajsberg [:julienw]]

Attachment: about:support output

Comment 8

[Julien Wajsberg [:julienw]]

Attachment: about-support-output.json

sorry for the churn, looks like it's too big for bugzilla text input, it was being cut.

Comment 9

[Jonathan Watt [:jwatt]]

So the print_paper_width, print_paper_height and print_scaling values in your prefs all look borked. They have leading whitespace, and the decimal separator is a comma instead of a period. These values are all stored as type double internally, and saved to prefs as that type. I have no idea how the Firefox code could possibly have converted these settings to the given strings in prefs.

Comment 10

[Jonathan Watt [:jwatt]]

It is also strange that your print settings are all saved to prefs without a printer name prefix, and that you do not have the pref print_printer (the last used printer name) set. Since bug 968753 landed, Linux users should have their print settings saved to prefixed prefs now. Have you ever successfully printed from this profile (since that bug landed), or is this a new profile that you've been unable to print from at all?

Comment 11

[Jonathan Watt [:jwatt]]

For future reference, its a bit easier for us humans to read if you use "Copy text to clipboard" in about:support, rather than using "Copy raw data to clipboard" (i.e. JSON). ;-)

Comment 12

[Julien Wajsberg [:julienw]]

(In reply to Jonathan Watt [:jwatt] from comment #9)

So the print_paper_width, print_paper_height and print_scaling values in your prefs all look borked. They have leading whitespace, and the decimal separator is a comma instead of a period. These values are all stored as type double internally, and saved to prefs as that type. I have no idea how the Firefox code could possibly have converted these settings to the given strings in prefs.

So, I use a french Firefox on a french System. Is that possible that localized floats instead of raw floats were output (in french floats use commas instead of periods), and so can't be re-read?

I tried printing in another en-US Firefox I use too. I saved the prefs before trying and had no print* prefs at all (besides that the new UI is enabled). After printing I also got the same bad values, but they were prefixed with the printer name this time.
But also the print dialog was still working after this!

(In reply to Jonathan Watt [:jwatt] from comment #10)

It is also strange that your print settings are all saved to prefs without a printer name prefix, and that you do not have the pref print_printer (the last used printer name) set. Since bug 968753 landed, Linux users should have their print settings saved to prefixed prefs now. Have you ever successfully printed from this profile (since that bug landed), or is this a new profile that you've been unable to print from at all?

This isn't a new profile. But I can't remember if I could print or if I even tried since that bug landed, sorry :/

(In reply to Jonathan Watt [:jwatt] from comment #11)

For future reference, its a bit easier for us humans to read if you use "Copy text to clipboard" in about:support, rather than using "Copy raw data to clipboard" (i.e. JSON). ;-)

Everything is in french, so I thought that the JSON format was better in that context :-) For prefs this should have been OK indeed, sorry about that!

Comment 13

[Jonathan Watt [:jwatt]]

(In reply to Julien Wajsberg [:julienw] from comment #12)

Is that possible that localized floats instead of raw floats were output

The relevant code is here:

https://searchfox.org/mozilla-central/rev/f21850ca45036ddb84cd25aa355a6969d7c94c4f/widget/nsPrintSettingsService.cpp#1007-1027

Given that atof is not locale aware, I previously assumed that, no, nsPrintfCString would not be locale aware. I mean, clearly after 20 years we'd have noticed that bug, right? Turns out, no, that's wrong. nsPrintfCString is locale aware by virtue of it using nsTSubstring::AppendPrintf which is locale aware!

Since atof will skip over leading whitespace, and will stop (rather than error) if it encounters an invalid character, in practice this means that your pref values essentially undergo a floor() conversion on being read. So:

print_paper_height: 11,69 -> 11
print_paper_width: 8,27 -> 8
print_scaling: 1,00 -> 1

I guess the reason that we've not noticed this bug before (other than the fact that the printing code has been unowned and 1000+ bug reports remain open) is that most users with a locale that uses a decimal separator other than "." probably use paper sizes in millimeters rather than inches. Well that, and the fact that this bug probably only causes some minor-ish misscaling I guess?

After printing I also got the same bad values, but they were prefixed with the printer name this time.

Thanks for that info. It seem like that part is working as expected then, and the prefs were unprefixed just because the last time you printed was prior to bug 968753 landing.

But also the print dialog was still working after this!

Okay, interesting! Is the original profile still not printing with the Nightly that worked using the new profile (with the same error in the console)? If so, it would be interesting to know what in that profile is causing the error. In your original profile with the problem can you (after backing up your prefs.js file from that profile) try incrementally deleting the print.* prefs and seeing if any/which prefs might be blocking printing? Nothing other than the localized float values stands out, but maybe print_in_color and print_resolution would be the most suspicious...maybe.

The patch for bug 1663503 is now queued for landing, but it would still be good to know the outcome of the above to better understand what is/was going on, so if you can possibly test before that reaches Nightly that would be great.

Everything is in french, so I thought that the JSON format was better in that context :-) For prefs this should have been OK indeed, sorry about that!

No worries! :-)

Comment 14

[Jonathan Watt [:jwatt]]

[I spun off the float serialization issue as bug 1668492.]

Comment 15

[Julien Wajsberg [:julienw]]

I tried removing the prefs one by one and ended up removing everything, but I still have the problem, with the same error in the console :/ (even after restarting firefox)

Comment 16

[Julien Wajsberg [:julienw]]

AH I found the culprit: the pref print_printer had something bogus, probably a printer that was added automatically by autodiscovery and was removed afterwards.

Comment 17

[Julien Wajsberg [:julienw]]

The value was 192_168_101_51_MacBook_Air_de_Pierre_LEROUTIER_2_. If I remove this only (and keep all other print prefs) the panel then works properly. That value is still present in my list of printers. But maybe it's not reachable anymore, or too far, or I don't know? (I don't even know what this is TBH).

Also: I added something else bogus (eg FOO) and it still worked. So this is something related to have a value that's valid (part of my printer list) but also invalid (can't reach the printer or something).

Comment 18

[Jonathan Watt [:jwatt]]

Awesome, thanks for tracking down the source of the issue!

Can you go to http://localhost:631/printers/ and click on this printer and then copy and paste the text from that page here?

Comment 19

[Julien Wajsberg [:julienw]]

Here it is:

192_168_101_51_MacBook_Air_de_Pierre_LEROUTIER_2_
192_168_101_51_MacBook_Air_de_Pierre_LEROUTIER_2_ (Paused, Rejecting Jobs, Not Shared)
Description:	192_168_101_51_MacBook_Air_de_Pierre_LEROUTIER_2_
Location:	
Driver:	Local Raw Printer (grayscale, 2-sided printing)
Connection:	file:///dev/null
Defaults:	job-sheets=none, none media=unknown 

Comment 20

[Jonathan Kew [:jfkthame]]

Presumably the immediate cause of the failure here is that .availablePaperSizes is empty here, leaving us with matchedPaper being undefined. So we should check for that and.... just ignore it, I guess?

Comment 21

[Jonathan Watt [:jwatt]]

Thank you, Julien, that's very helpful! BTW does any part of the "de_Pierre_LEROUTIER" string mean anything to you at all? I'm just wondering if this is some settings stuff that has been carried over from an old MacBook Air that you maybe used to own when you migrated from machine to machine in the past (or something like that)? The 'file:///dev/null' is very weird though.

Jonathan: Indeed.

I also wonder if we should filter out CUPS_PRINTER_REJECTING in nsPrinterListCUPS::Printers. Emily, Hiro, any opinions on that?

Comment 22

[Jonathan Watt [:jwatt]]

Sam, please see comment 20.

Comment 23

[Julien Wajsberg [:julienw]]

(In reply to Jonathan Watt [:jwatt] from comment #21)

Thank you, Julien, that's very helpful! BTW does any part of the "de_Pierre_LEROUTIER" string mean anything to you at all?

"de" means "of" in french :) so this was probably some macbook from some folk in some network I connected. I don't know the name of this person :-)

I'm just wondering if this is some settings stuff that has been carried over from an old MacBook Air that you maybe used to own when you migrated from machine to machine in the past (or something like that)? The 'file:///dev/null' is very weird though.

Most similar "automatic" entries in the list have the same dev/null. I wonder if that's a bug in cups, that it autodiscovers but doesn't autoremove...

Comment 24

[Jonathan Kew [:jfkthame]]

It looks to me like bug 1663503 should resolve this [edit: oops, I see comment 4 already said this] (although we still may want to try and filter such printers out of the list altogether).

Comment 25

[Sam Foster [:sfoster] (he/him)]

Yeah this looks like it should be fixed by bug 1663503, :julienw, can you try to reproduce with today's nightly?

Comment 26

[Julien Wajsberg [:julienw]]

In today's nightly (Build id 20201002092536) I still have the issue, but with a different error message ;)

Uncaught (in promise) TypeError: can't access property "marginTop", settingsToUpdate.customMargins is undefined    print.js:454:7
    getSettingsToUpdate chrome://global/content/print.js:454
    refreshSettings chrome://global/content/print.js:381
    init chrome://global/content/print.js:251
    async* chrome://global/content/print.js:85
    EventListener.handleEvent* chrome://global/content/print.js:82
print.js:454:7

Comment 27

[Julien Cristau [:jcristau]]

That looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1663503#c42

Comment 28

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Watt [:jwatt] from comment #21)

I also wonder if we should filter out CUPS_PRINTER_REJECTING in nsPrinterListCUPS::Printers. Emily, Hiro, any opinions on that?

I spun that off into bug 1668962.

Comment 29

[Mike Conley (:mconley) (:⚙️)]

I'm kinda getting lost in this soup of bugs. It looks like bug 1663503 is closed... is this bug still around, julienw?

Comment 30

[Julien Wajsberg [:julienw]]

ahah, I think this bug is now fixed indeed. I filed several follow-ups.