8 ms·

Math.Round opens the browser print dialog

274 points by gokhan 7y ago

Groxx 7y ago
I agree with https://github.com/dotnet/try/issues/290#issuecomment-503768091 https://github.com/dotnet/try/issues/290#issuecomment-503768... - this seems pretty likely to be "you are using `print(...)` but don't have a custom one in scope, so it's calling the window's func" It happens in Firefox too, fwiw. Probably just a mono.js flaw.
deleted 7y ago
[deleted]
a1371 7y ago
So basically a library tries to print something in the console and instead of using `console.log(...)` they use `print (...)` as if it is Python. That instead invokes `window.print` used to actually send something to the printer.
- camjohnson26 7y ago
  This happens because of scope chaining in JavaScript. If you call a function it will look for it in the current context. If it’s not there it will try to find it in the parent. If it’s not there it will keep checking the parent objects until it finds it, or throw an exception. Since window is the top level context and includes a print function, it gets called and shows the printer dialog.
  - minitech 7y ago
    Not the parent objects – the containing scopes. (Which is how scope works in most languages.)
- Arnavion 7y ago
  >instead of using `console.log(...)` they use `print (...)` as if it is Python. There's a `Module.print` that wraps `console.log` with a bit of logic. The code might have intended to call that one. window.Module = function (e, n, f) { var d = { }, p = [ 'DEBUGGING ENABLED' ]; return d.print = function (e) { return p.indexOf(e) < 0 && console.log('WASM: ' + e) }, d.printErr = function (e) { return console.error('WASM: ' + e) }, ... d }(e, n, f)
tedunangst 7y ago
What is the expected behavior from calling print()?
- komali2 7y ago
  A globally defined print function is invoked I guess? It's weird for me to see it in the raw like that instead of this.print or errorController.print or this.emit('error', error) or just throw(error)...
- AgentME 7y ago
  Calling print() opens a print dialog in Javascript. The error-handling code in this project is doing the wrong thing. It's not an example of a wild Javascript-specific error, just an example of untested error handling code doing the wrong thing.
- masswerk 7y ago
  The JavaScript function "window.print()" is expected to open a print dialog for the current document. Since "window" is also the global object for the main/UI thread in a browser, "print()" resolves to "window.print()", if no function has been defined otherwise. This is, BTW, also a potential issue in Emscripten, which uses a similar logging mechanism by a custom "print()" function. (I guess, this is also, where it came from in the WASM implementation. A few years ago, I actually replaced all references to "print" by a more safe name for a customized Emscripten runtime, in order to prevent similar from happening in any edge cases. I suggest to treat "print" and similar global function names just as if they were reserved words in your projects to avoid "expectable unexpecteds" like this. For similar reasons, using a variable "self" to store a reference to the current this-object isn't a great idea, since "self" is already the canonical reference to the global object…) Edit: To be more specific, "window" is only the global object for the scripting context in a browser window (anything inside "script" tags). Meaning, you would have to use the full form, "window.print()", when calling the print function from outside this context, like inside an event handler attribute of an HTML tag. (E.g., '<button onclick="window.print()">Print page<button>'. Here, a simple "print()" wouldn't work.)
ChrisSD 7y ago
var ASM_CONSTS = [(function(){ var err = new Error; print('Stacktrace: \n'); print(err.stack) } // ... The issue is that print call. They expect it to call their own print function. But that's not in scope so it falls back on window.print (I.e. the function defined in the global object).
- ncr100 7y ago
  Code coverage auditing, Test error handling.
  - Sharlin 7y ago
    Use of a language with sane scoping rules…
    - Cthulhu_ 7y ago
      Yeah I wouldn't mind a run mode or utility where you don't have the window global and you have to explicitly import what are currently globals. It should be doable with e.g. a webpack or browser plugin.
    - acdha 7y ago
      I’d categorize this not as scoping but the polluted global namespace in the browser environment and JavaScript’s behavior of ignoring extra arguments.
      - Sharlin 7y ago
        It’s not a global `print` function that’s called but `window.print`, right? `print` is sugar for `this.print` and `this` is the window object if it’s not explicitly bound to something else. So I’d definitely say it’s a very JS-specific scoping issue.
        laszlokorte 7y ago
        It‘s not that print is sugar for this.print but that print is undefined and undefined variables fall back to a lookup in the global window object.
mustak_im 7y ago
Why does `print(...)` in Firefox acts like `console.log`?
- nanny 7y ago
  It only acts like console.log in the browser console, not in a script. Interesting.
  - 6nf 7y ago
    Handy for debugging I guess?
  - panopticon 7y ago
    The Chrome console defines a few console-only convenience functions too: https://github.com/GoogleChrome/devtools-docs/blob/master/docs/commandline-api.md https://github.com/GoogleChrome/devtools-docs/blob/master/do...
shereadsthenews 7y ago
C:\>copy WEB LPT1
- deleted 7y ago
  [deleted]
picozeta 7y ago
> "But exactly which concrete bugs would a programming language and environment with a strong type system prevent?" asked the young student Master Typikos. "These kind of errors." Master Typikos said - and she told the student the story about the time when a bug in a runtime caused Math.Round to do IO although it's type was `Integer -> Float32 -> Float32`. The student did not believe this story. Later he was enlightened. EDIT: refined type
- mpeg 7y ago
  How would strong typing really prevent this? This is a side effect caused by a scoping issue, calling window.print instead of the local print function.
  - lelf 7y ago
    You cannot “window.print” in a Float32→Float32 function. It just won’t compile.
    - H8crilA 7y ago
      In what language?
      - pathikrit 7y ago
        Haskell
    - tedunangst 7y ago
      You can't console.log either...
      - drdaeman 7y ago
        There is Debug.Trace.trace which does the trick with unsafePerformIO (which is a special non-type-safe escape hatch for IO)
    - gmfawcett 7y ago
keanebean86 7y ago
I wish the world could decide on a standard console method. I, far too often, catch myself typing console. in Java. It's even worse if I've done some C# recently.
libman 7y ago
One does not simply print() a stacktrace...
exogen 7y ago
So it's caused by a reference to `print` not being what they expected. The create-react-app project maintains a great list of "confusing browser globals" for exactly this situation! https://github.com/facebook/create-react-app/tree/master/packages/confusing-browser-globals https://github.com/facebook/create-react-app/tree/master/pac... You can use it along with ESLint to detect situations where a variable reference is technically valid (it will refer to the window property) but is probably not what you're intending. Some of them are really easy to trip over, like `error`, `name`, and `open`. All global properties on the window!
- habosa 7y ago
  Name got me the other day. I was writing typescript and not even targeting the browser but I guess I had browser globals in the .d.ts I had a string like "Hello ${name}" and it would compile but crash at runtime. Wasted a whole day, learned a lot about why even with great tools the JS ecosystem still has some fundamental crap at the bottom.
T3RMINATED 7y ago
i've seen this when people dont use jQuery and think they are smarter than John Resig.
patrick5415 7y ago
And here I thought the story was about the endless stream of “me too” comments in the bug report. Hard to find much signal in there.
yellowapple 7y ago
In the process of trying to reproduce this bug in some rather silly environments, I've instead discovered that try.dot.net is completely broken on multiple browsers: - On Firefox for Android, it's impossible to type in a program, since when typing something as simple as "using System;" it'll garble the text like crazy - On Android browsers in general, the Monaco editor on that page is too "smart" for its own good and presents a worthless context menu when I press and hold (i.e. to select all text or paste it in). Microsoft: could y'all not? - On both the (presumably-Chromium-based) default browser on my Android phone and Firefox 52.9.0 ESR on a reasonably "recent" OpenIndiana, the Blazor runtime fails to run anything at all when I click "Run", complaining in the JS console (at least on OpenIndiana; didn't check on my phone, but the symptoms are the same) that "No .NET call dispatcher has been set". - On a reasonably-recent nightly version of Haiku, loading try.dot.net at all causes WebPositive to outright crash within seconds.
- zaroth 7y ago
  But why exactly are so many people determined to try to reproduce this particular bug in every permutation of device/os/browser known to man?
  - acdha 7y ago
    They’re joining a “LOL JavaScript” but refusing to use the easy tools available to understand what’s actually happening, so there’s lots of shooting in the dark – not unlike the thread here about strong type systems.
  - yellowapple 7y ago
    Why not?
- brianush1 7y ago
  Microsoft explicitly states[0] that they do not support Monaco on mobile browsers, since it's just too much hassle to maintain and, frankly, nobody codes on mobile. [0]: https://microsoft.github.io/monaco-editor/ https://microsoft.github.io/monaco-editor/
owl57 7y ago
Curious if there are any browsers and circumstances where instead of the dialog window.print() would immediately print something.

274 points by gokhan 7y ago

I agree with https://github.com/dotnet/try/issues/290#issuecomment-503768091 https://github.com/dotnet/try/issues/290#issuecomment-503768... - this seems pretty likely to be "you are using `print(...)` but don't have a custom one in scope, so it's calling the window's func" It happens in Firefox too, fwiw. Probably just a mono.js flaw.

deleted 7y ago

[deleted]

a1371 7y ago

So basically a library tries to print something in the console and instead of using `console.log(...)` they use `print (...)` as if it is Python. That instead invokes `window.print` used to actually send something to the printer.

camjohnson26 7y ago
This happens because of scope chaining in JavaScript. If you call a function it will look for it in the current context. If it’s not there it will try to find it in the parent. If it’s not there it will keep checking the parent objects until it finds it, or throw an exception. Since window is the top level context and includes a print function, it gets called and shows the printer dialog.
- minitech 7y ago
  Not the parent objects – the containing scopes. (Which is how scope works in most languages.)
Arnavion 7y ago
>instead of using `console.log(...)` they use `print (...)` as if it is Python. There's a `Module.print` that wraps `console.log` with a bit of logic. The code might have intended to call that one. window.Module = function (e, n, f) { var d = { }, p = [ 'DEBUGGING ENABLED' ]; return d.print = function (e) { return p.indexOf(e) < 0 && console.log('WASM: ' + e) }, d.printErr = function (e) { return console.error('WASM: ' + e) }, ... d }(e, n, f)

tedunangst 7y ago

What is the expected behavior from calling print()?

komali2 7y ago
A globally defined print function is invoked I guess? It's weird for me to see it in the raw like that instead of this.print or errorController.print or this.emit('error', error) or just throw(error)...
AgentME 7y ago
Calling print() opens a print dialog in Javascript. The error-handling code in this project is doing the wrong thing. It's not an example of a wild Javascript-specific error, just an example of untested error handling code doing the wrong thing.
masswerk 7y ago
The JavaScript function "window.print()" is expected to open a print dialog for the current document. Since "window" is also the global object for the main/UI thread in a browser, "print()" resolves to "window.print()", if no function has been defined otherwise. This is, BTW, also a potential issue in Emscripten, which uses a similar logging mechanism by a custom "print()" function. (I guess, this is also, where it came from in the WASM implementation. A few years ago, I actually replaced all references to "print" by a more safe name for a customized Emscripten runtime, in order to prevent similar from happening in any edge cases. I suggest to treat "print" and similar global function names just as if they were reserved words in your projects to avoid "expectable unexpecteds" like this. For similar reasons, using a variable "self" to store a reference to the current this-object isn't a great idea, since "self" is already the canonical reference to the global object…) Edit: To be more specific, "window" is only the global object for the scripting context in a browser window (anything inside "script" tags). Meaning, you would have to use the full form, "window.print()", when calling the print function from outside this context, like inside an event handler attribute of an HTML tag. (E.g., '<button onclick="window.print()">Print page<button>'. Here, a simple "print()" wouldn't work.)

ChrisSD 7y ago

var ASM_CONSTS = [(function(){ var err = new Error; print('Stacktrace: \n'); print(err.stack) } // ... The issue is that print call. They expect it to call their own print function. But that's not in scope so it falls back on window.print (I.e. the function defined in the global object).

ncr100 7y ago
Code coverage auditing, Test error handling.
- Sharlin 7y ago
  Use of a language with sane scoping rules…
  - Cthulhu_ 7y ago
    Yeah I wouldn't mind a run mode or utility where you don't have the window global and you have to explicitly import what are currently globals. It should be doable with e.g. a webpack or browser plugin.
  - acdha 7y ago
    I’d categorize this not as scoping but the polluted global namespace in the browser environment and JavaScript’s behavior of ignoring extra arguments.
    - Sharlin 7y ago
      It’s not a global `print` function that’s called but `window.print`, right? `print` is sugar for `this.print` and `this` is the window object if it’s not explicitly bound to something else. So I’d definitely say it’s a very JS-specific scoping issue.
      - laszlokorte 7y ago
        It‘s not that print is sugar for this.print but that print is undefined and undefined variables fall back to a lookup in the global window object.

mustak_im 7y ago

Why does `print(...)` in Firefox acts like `console.log`?

nanny 7y ago
It only acts like console.log in the browser console, not in a script. Interesting.
- 6nf 7y ago
  Handy for debugging I guess?
- panopticon 7y ago
  The Chrome console defines a few console-only convenience functions too: https://github.com/GoogleChrome/devtools-docs/blob/master/docs/commandline-api.md https://github.com/GoogleChrome/devtools-docs/blob/master/do...

shereadsthenews 7y ago

C:\>copy WEB LPT1

deleted 7y ago
[deleted]

picozeta 7y ago

> "But exactly which concrete bugs would a programming language and environment with a strong type system prevent?" asked the young student Master Typikos. "These kind of errors." Master Typikos said - and she told the student the story about the time when a bug in a runtime caused Math.Round to do IO although it's type was `Integer -> Float32 -> Float32`. The student did not believe this story. Later he was enlightened. EDIT: refined type

mpeg 7y ago
How would strong typing really prevent this? This is a side effect caused by a scoping issue, calling window.print instead of the local print function.
- lelf 7y ago
  You cannot “window.print” in a Float32→Float32 function. It just won’t compile.
  - H8crilA 7y ago
    In what language?
    - pathikrit 7y ago
      Haskell
  - tedunangst 7y ago
    You can't console.log either...
    - drdaeman 7y ago
      There is Debug.Trace.trace which does the trick with unsafePerformIO (which is a special non-type-safe escape hatch for IO)
  - gmfawcett 7y ago

keanebean86 7y ago

I wish the world could decide on a standard console method. I, far too often, catch myself typing console. in Java. It's even worse if I've done some C# recently.

libman 7y ago

One does not simply print() a stacktrace...

exogen 7y ago

So it's caused by a reference to `print` not being what they expected. The create-react-app project maintains a great list of "confusing browser globals" for exactly this situation! https://github.com/facebook/create-react-app/tree/master/packages/confusing-browser-globals https://github.com/facebook/create-react-app/tree/master/pac... You can use it along with ESLint to detect situations where a variable reference is technically valid (it will refer to the window property) but is probably not what you're intending. Some of them are really easy to trip over, like `error`, `name`, and `open`. All global properties on the window!

habosa 7y ago
Name got me the other day. I was writing typescript and not even targeting the browser but I guess I had browser globals in the .d.ts I had a string like "Hello ${name}" and it would compile but crash at runtime. Wasted a whole day, learned a lot about why even with great tools the JS ecosystem still has some fundamental crap at the bottom.

T3RMINATED 7y ago

i've seen this when people dont use jQuery and think they are smarter than John Resig.

patrick5415 7y ago

And here I thought the story was about the endless stream of “me too” comments in the bug report. Hard to find much signal in there.

yellowapple 7y ago

In the process of trying to reproduce this bug in some rather silly environments, I've instead discovered that try.dot.net is completely broken on multiple browsers: - On Firefox for Android, it's impossible to type in a program, since when typing something as simple as "using System;" it'll garble the text like crazy - On Android browsers in general, the Monaco editor on that page is too "smart" for its own good and presents a worthless context menu when I press and hold (i.e. to select all text or paste it in). Microsoft: could y'all not? - On both the (presumably-Chromium-based) default browser on my Android phone and Firefox 52.9.0 ESR on a reasonably "recent" OpenIndiana, the Blazor runtime fails to run anything at all when I click "Run", complaining in the JS console (at least on OpenIndiana; didn't check on my phone, but the symptoms are the same) that "No .NET call dispatcher has been set". - On a reasonably-recent nightly version of Haiku, loading try.dot.net at all causes WebPositive to outright crash within seconds.

zaroth 7y ago
But why exactly are so many people determined to try to reproduce this particular bug in every permutation of device/os/browser known to man?
- acdha 7y ago
  They’re joining a “LOL JavaScript” but refusing to use the easy tools available to understand what’s actually happening, so there’s lots of shooting in the dark – not unlike the thread here about strong type systems.
- yellowapple 7y ago
  Why not?
brianush1 7y ago
Microsoft explicitly states[0] that they do not support Monaco on mobile browsers, since it's just too much hassle to maintain and, frankly, nobody codes on mobile. [0]: https://microsoft.github.io/monaco-editor/ https://microsoft.github.io/monaco-editor/

owl57 7y ago

Curious if there are any browsers and circumstances where instead of the dialog window.print() would immediately print something.