# Dialog boxes don't display body text on project page

On the project page:

In the editor:

This seems to happen every time I open it up.

Dialog boxes should not be opened in the project page. They were never intended to do so.

This doesn't look like a Snap! dialog to me, so it's not a Snap! bug.

It's a dialog made in js that uses the same engine. If this happens, it is your fault because it's YOUR ENGINE

Sigh. Look, get this into your head: We are not providing a JavaScript programming environment. We are providing a self-contained programming language that's totally unlike JavaScript. We also, mainly for the sake of our own development work, have an escape to JavaScript. This is useful in some libraries; it's also useful to robot developers who want to provide a way to use their robots in Snap!.

But, advance notice, we are eventually going to eliminate the JS Function block. Yes, that will break a lot of old projects, which is why we aren't doing it now. You'll have plenty of warning. The reason to eliminate it is that it's a security problem; people can (and so eventually will) write malicious projects that harm whoever runs them.

So, if all you want from Snap! is a development environment for JavaScript programming, you're in the wrong place.

Wouldn't that break a lot of libraries that provide extra functionality via JS?

That's one of the reasons we didn't just do it yesterday at our monthly meeting. Our best guess right now about how we'll solve that problem is to include the JS functions in Snap! itself. We've already largely done that with the APL library, adding things like transpose and rank and lists of item numbers to the core language, along with the big thing of course, which is hyperblocks.

The big stumbling block (no pun intended), though, is the bignums library, which extensively modifies JS primitives all over the place. Jens uses words like "evil" to describe that technique; we had a big fight about it last week. But he and I are now agreeing that we should find a way to make it work that doesn't violate his principles. :~)

What about people who aren't Snap! developers and can't modify the source code?

technically it's Jens's engine. Jens created morphic.js. So it's not bh's fault. Also, they didn't make the dialogs for the user to use on the project page, much less, use custom dialogs. There's no way (without js) to even show a dialog on the project page. That means that this really isn't a real problem. If you want to make it work, modify the dialog code yourself.

edit: I just realized you can show a list dialog on the project page.

The problem we're trying to solve is that JS Function gives malicious users way too much power to cause harm. Really this was a back-burner concern all along, but it's becoming more important as school districts want us to sign contracts promising to keep their data secure. I'm afraid we can't have it both ways.

Jens has suggested that we could allow JSF in a Snap! instance running on localhost, so that people who really want to can experiment with it just for themselves. And I guess if someone who seems mature and helpful sends us a proposed library we'd consider it. (Not yet! Don't start sending in libraries! This is for after we eliminate JSF.)

But, as I said, this is an early warning of something coming months from now, maybe years, although I don't think so, if we are otherwise ready to sign contracts with school districts this summer. (Berkeley's contract-signing department is reading over our draft as we speak.)

Everything I said above about the security reasons for undertaking this change is 100% true. But, yes, a wonderful consequence of the change will be to make it totally clear to y'all that Snap! is not an IDE for JS.

I think that was meant as a plural "you." I'm happy to take responsibility for our policy saying that we're not an IDE for JS.

Looking at cloud.js, there doesn't seem to be any data stored client side, if I'm not mistaken.

I've seen this to many times... You means Snap! "primitives", i.e.
implementations of basic operators reporter? It's matter of hours rather than days to recreate this as a dedicated reporters just for processing of bignums without this whole "big" concerns.

Snap! is hosted in JS/HTML. Accesing the hosting environment (aka native libraries) is a future that distinguish toys from the tools. Allows acces to newly developed browser functions like I/O, accessibility, device OS/capability. It also lessen the burden to the core developers while allowing some, community driven, progress.
For the people outside the High Castle - extensibility, expressive powers and FREEDOM given by Snap! has a much value. It's sad, that You guys, consider such valuable future a drawback.

If You need a crippled down version for BJC or some restricted environment there was a Microworld concept presented by Bernat.

So, the canonical bad thing would be a project that deletes all your projects. It's logged in as you, so it can tell the cloud to do that.

The textbook solution to that problem is to sandbox the JS Function. But what makes JSF a useful feature is that it has access to all the code that implements Snap!. So it's not obvious to us how to make a sandbox secure without limiting it beyond usefulness.

I hear you about the extensibility. I'm not sure I'm with you about expressive powers. What gives Snap! expressive power is lambda. If you can't express yourself without doing JS coding instead of Snap! coding, I'd call that a failure of Snap!.

We should support new browser features as Snap! primitives, if they're useful.

Accessibility is a bit of a sore point for us. Because we use Morphic instead of DOM widgets, we don't get the benefit of built-in browser support for screen readers. So Jens, or someone, has to invent screen reader support for Morphic. (The benefit of Morphic over DOM capabilities is "lively" programming -- you can edit a script while it's running and the edit takes effect immediately. Jens also likes being able to drop an expression into a script that isn't the topmost, visible one, I think, but that feels like a misfeature to me.)

I actually feel more like a community member than like a High Castle resident, especially recently, but I suppose that's not quite right.

I don't think that's a fair characterization of the situation. It's not BJC, specifically, that needs more security. It's any use of Snap! in schools in the US. Probably in Europe, too; I suspect the GDPR imposes the same sort of requirements on us, even for non-school users.

It's the "hide primitives" feature to which you should be directing that sort of rhetoric. :~/

People like you, and Simon, and all the extension writers, get a lot of value from JSF and we don't want to take that away from you. You're not going to write malicious projects that delete other people's projects, for one thing. But people like I started listing names here but that's probably not a good idea and that crowd are, we think, actually held back in their learning computer science by programming in JS rather than in Snap!. That's not the reason for moving away from JSF; the reason is security. But it may be a side benefit. The dividing line isn't how old you and they are; it's what vision you and they have for extending Snap!, whether it's just adding bells and whistles or really extending the expressive power of users of your extensions. And it's not a rigid line in any case. But (getting back to the beginning of this thread) when people file bug reports against Snap! because their JS code is buggy, it's pretty clear that writing JS code isn't helping them.

Oh I forgot to answer this part. That's what Jens says, too; add blocks called bignum-+ and bignum-< and so on. But that doesn't serve the need. People should be able to write regular old Snap! code and have it work on all numbers. In a perfect world, you wouldn't be able to turn off support for all numbers! It should just be an expectation of users that their programming languages can do math. What we have now is an uneasy compromise.

How about blocking requests from projects with the Referer header?

After seeing this, I decided to test it and saw that the built-in dialog boxes invoked by Snap! itself actually do work on the project page. (Even ones with both images and text, which was the problem.)
I thought it was a problem with Snap!, but now I know it's simply a problem with the JS code.