accidental call to print() with no arguments crashes browser

[catarak]

Nature of issue?

• Found a bug
• Existing feature enhancement
• New feature request

Most appropriate sub-area of p5.js?

• Color
• Core
• Data
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Other (specify if possible): Environment

Which platform were you using when you encountered this?

• Mobile/Tablet (touch devices)
• Desktop/Laptop
• Others (specify if possible)

Details about the bug:

Posted originally in processing/p5.js-web-editor#614

Calling print(x) with an undefined variable brings up the browser print dialog. I noticed that there was a similar issue over on processing/p5.js-web-editor#474 but that seemed to be more focused on calling print outside of setup or draw. In this case, it just happens if a variable becomes undefined.

One of my students stumbled across this by accidentally providing the dist function without enough parameters let x = dist(10, 35), which ended up returning undefined.

• p5.js version: 0.6.0
• Web browser and version: Chrome/Firefox/Safari
• Operating System: MacOSX 10.12.6
• Steps to reproduce this:Alpha editor link

The P5 print is supposed to open the print dialogue, if no argument have been passed to the function. This has most likely been added to keep the ability to use the print dialogue.

core/environment.js, 41:

p5.prototype.print = function(args) {
  if (typeof args === 'undefined') {
    _windowPrint();
  } else {
    console.log.apply(console, arguments);
  }
};

It's easy to fix, just put your print() in an if statement:
if(str) print(str);

[catarak]

btw @aferriss. makes sense! gonna close this one ✨

[lmccart]

i wonder if removing the args named param and instead testing arguments.length lets us distinguish from calling print() vs print(undefined). i will investigate before we close this.

That would work @lmccart , and it would work better...

p5.prototype.print = function() {
	if (arguments.length == 0) {
		_windowPrint();
	} else {
		console.log.apply(console, arguments);
	}
};

If we don't want to update the print() function, we should at least update the documentation since it is a feature someone implemented knowingly!

[bmoren]

I would like to re-open this issue in relationship to the web editor & it's auto-reload functionality specifically:

from the reference:

Note that calling print() without any arguments invokes the window.print() function which opens the browser's print dialog. To print a blank line to console you can write print('\n').

This functionality along with the auto sketch reload means that if you write it w/o anything inside (a common way to write functions for beginners, first the function then fill it with the parameters) you're met with a looping avalanche of print dialogs which will inevitably crash the browser.

This dual, unrelated functionality, function feels counter intuitive to me. I've had many students trip up on this in class only to lose progress in their sketch because of the print() and auto refresh in tandem.

I propose:
Remove window.print() from print() and move it into it's own function classified under the output IO. perhaps as printDialog() or printCanvas()

[Spongman]

A problem with this approach is that print(); is a native javascript API that existing and/or non-p5 scripts may depend on.

It might be worth investigating why the web editor is behaving the way you describe. Maybe it’s running the sketch inside the print-preview panel, and the nested sketch is itself calling print() ad nauseam. If this is the cause, perhaps there is a way to disable print() when called in the preview window?

[bmoren]

Fixing the editor could be a good step, but with 1.0 coming up it's important to lock down syntax like this ahead of it if there is the potential for change.

There have been a number of issues opened here and in the online editor, a quick search reveals:

#3264 #2360 #1597 #1491 #887 #871

looks like the discussion on the current implementation happened here:
#1579

and over on the editor:
processing/p5.js-web-editor#743
processing/p5.js-web-editor#618
processing/p5.js-web-editor#614
processing/p5.js-web-editor#474

So here we have a dozen closed issues which dismiss the problem or re-direct it. We haven't solved the bug, just told people to look elsewhere or ignore it.

In my mind the confusion is that we have a function with a common name with 2 distinct functionalities which are really unrelated to one another (technically, not historically 😁).

As I said above, I think we should take care of this for beginners as I've already had to show a number of students how to force quit the browser to get out of the printer loop. And then go into talking about console.log() and what the dot means really early on.

[meiamsome]

Personally, I think p5 should back down from overriding print at all, and prefer to rename to function or delete it in its entirety. Is it harder for a new user to learn "console.log(<>)" than it is to learn "print(<>) but you have to but something in the brackets otherwise it will try to print out the document so you have to be careful not to run it when in that state"? I wouldn't think so, when that explanation would involve essentially function overloading, even if you have to explain what the dot means in the simple case for console.log. Obviously we could just do something like printLog or consoleLog but I don't see why p5 should add an API that already exists in a relatively simple and widely used and available way. Shouldn't we prefer to teach native Javascript when we can?

That said, I have no experience of teaching people who are new, so maybe I am overstating the ease of "Just write console.log" vs "Just write print" - would be great to get some input on if anyone has decided to drop using print in teaching entirely because of this.

[bmoren]

I do think you're overstating the ease for a lot of contexts p5 is used in. At least for an understanding of the functionality, but maybe less so in the sense of just saying use this instead of that, ultimately it's just vocab that the user has to internalize. (this is what I end up doing in class) But to a 10 year old, or an 18-22yo for that matter print() is friendlier than getting into object syntax on day 1. I don't really have an issue with console.log teaching at the college level, but I'm sure some folks would be sad to lose print(). As above (#1579), there was a println() for a minute, but the discussion ended up in the functionality we have now.

[meiamsome]

I can definitely see that there are benefits to not having the object stuff involved, and that that would be easier for new users.

I still don't really understand why print is used for a beginner anyway?

If you open your browser's log panel it's called "console".
In the p5js editor it is also called "console".
Nothing to me about outputting onto a console has ever screamed "print" as the word to use. It's definitely historically valid, "printf" of C which I suspect was based on the usage of teleprinters at the time, but a beginner wouldn't have any such context. I guess that to me this has always seemed a strange one, and that if I want something to output into the "console" I would expect the command to involve that name somewhere.

Looking at the history of this there is sentiment in there that is on a similar vein.

Honestly, this sounds like another situation where we need more outreach as @makeyourownalgorithmicart discussed in #3494 to decide on a path forward. Perhaps we should open this one up to a longer-form discussion? This is definitely a problem that has caused repeated issues, and that's usually a sign that something could be improved.