jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.51k stars 745 forks source link

Trouble with Chrome (Update Browser Requirements) #989

Closed maryfries closed 8 years ago

maryfries commented 9 years ago

In NYC, students are having trouble loading Snap in Chrome. June Mark tried one of their machines, and it just comes up as a blank (white) screen. This was on OS 10.9 and Chrome 29.0.1547.76 (up to date at the time). Aankit found a clue in the JS that he will send to us.

jmoenig commented 9 years ago

not sure what you mean with "up to date". That may just be the version that some IT "security" specialists believe is okay for poor students to work on. Right now the current Chrome version for general consumption (not any hackers preview thingy) is 46.0.2490.80. So, it's been a rather long time since v.29 was anywhere near "up-to-date". :-)

maryfries commented 9 years ago

I noticed that, but Chrome was reporting that it was up to date and the computer was online... ??

jmoenig commented 9 years ago

Ugh... that's strange.

Oh, now I understand: The OS version must have been so old that Chrome stopped supporting it with newer versions. I have this on some of my really old computers (like Brian's old Mac), Chrome will tell that it's "up-to-date" because it's the last OS version it supports. Point is, though: The whole system is totally behind :-(

maryfries commented 9 years ago

It was OS 10.9 though...

jmoenig commented 9 years ago

wait. That's not old. Strange...

maryfries commented 9 years ago

Here's the note from Aankit:

This is the error JS thrown in the console Uncaught ReferenceError: Map is not defined

This is file and line number morphic.js:3055

This is line 3055 var map = new Map(), c;

Hope that's helpful!

cycomachead commented 9 years ago

Chrome's auto-updater is horribly broken on OS X for some install methods...

And yeah, that error would make sense for the older Chrome, though that means something else in Snap! isn't working right.

jmoenig commented 9 years ago

this is a somewhat serious issue. If “Map is undefined” on their computer they cannot run Snap. Basically nothing will work right. There is a work-around for Map we could add to Snap’s code, but for the next steps, especially for the Snapi-like objects I’m totally relying on Map. Map is a relatively new ES6 feature that is not yet fully supported in all browsers, especially IE. However, the little API Snap requires actually is totally supported by all current browsers as of two months ago.

Please, please have them update their browsers! They absolutely need support for the current (non-experimental, btw.) JavaScript standard!

jmoenig commented 9 years ago

To be clear: This is not an issue with Snap. Snap is fine, it's just that their old browser don't support JS features that have become standard in the meantime.

cycomachead commented 9 years ago

I didn't realize we removed the polyfill, which is why I thought something was broken.

(we could add back the polyfill...I mean, Snap! isn't broken but it is possible to prevent this from happening.)

Though not super recent, it seems like Map things need some browser within the past year or two. (Chrome 38-10/2014, IE 11, Safari 7.1 10/2013, FF13 7/2013), but with all of those, something more recent is better.

I do think we need some statement on the website as well as a policy as to what browsers and technology we expect people to have. For example, Snap! won't currently run on @brianharvey's Safari, though I'm guessing he never noticed. Always being up to date can be difficult in schools, and a blank screen is definitely not acceptable as a first thing a new user finds.

I wish we had data about how up to date school districts were in general...

cycomachead commented 9 years ago

especially for the Snapi-like objects I’m totally relying on Map

Native in Snap! ? :+1:

jmoenig commented 9 years ago

yes, those Map-based objects are going to be first-class and at the core of everything else in future Snap. I'm okay with (some) polyfills, but really only in cases where we're using experimental, non-standard features (such as perhaps the file API). However, Map is totally standard and supported by all browsers now, as is web-audio. For these I don't want polyfills.

cycomachead commented 9 years ago

Yeah, but I think the issue we run into is that schools often move dangerously slow. :( and updating isn't always even in the teacher's power.

maryfries commented 9 years ago

Jens, can you suggest specific system and browser minimums that we can announce (knowing that this is a big thing to ask of teachers)? Michael is right; they may not even be able to update to our specifications. But at least if we have the information posted somewhere, they can point to that page and wave their fingers around until hopefully someone does something. (Or maybe their students can either do it or get it done!)

jmoenig commented 9 years ago

We could have a look at http://caniuse.com/#search=Map:

This is the absolute minimum requirement. Below this Snap fundamentals will not work correctly. If you also want web-audio (for playing notes), we can check http://caniuse.com/#search=web%20audio

but we can use:

But I can't really test these because I don't have old versions anymore, and I don't even know where to get them. However, according to the gurus, this should - kinda - work.

nemilya commented 9 years ago

May be possible to solve this kind problems by making standalone Snap! version - for example based on http://electron.atom.io (the minimum OS X version supported is OS X 10.8; Windows 7 and later), it is Chromium/Chrome 45 now.

cycomachead commented 9 years ago

CanIUse's Map is just a measure of basic ES5 stuff (like Array.map). This gives a better graph for ES6, http://kangax.github.io/compat-table/es6/#Map Also the Mozilla page for map: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map

I definitely think we should set some generic standards about how far back we should expect things to change, it would help with other projects like websites and tools we build.

May be possible to solve this kind problems by making standalone Snap! version - for example based on http://electron.atom.io (the minimum OS X version supported is OS X 10.8; Windows 7 and later), it is Chromium/Chrome 45 now.

I think @bromagosa Is infact working on this! :)

cycomachead commented 9 years ago

@brianharvey We should have those numbers on a website somewhere.

maryfries commented 9 years ago

Working on it. Just have a few more presentations to go... Busy week!

I'm going to post these: Chrome 43 Safari 8.4 Firefox 38 Edge 12 Opera 32 cannot use IE

Anything else that should be on there?

maryfries commented 9 years ago

Thoughts? http://bjc-edc.github.io/bjc-r/cur/teaching-guide/specifications.html

nemilya commented 9 years ago

About standalone Snap "I think @bromagosa Is infact working on this! :)"

Great!

Btw Snap4arduino https://github.com/edutec/Snap4Arduino is based on Node-WebKit (NW.js now)

May be standalone Snap can support arduino from the box. This will give possibility for physical computing field.

cycomachead commented 9 years ago

I think it's pretty good but we really should also have this on snap.berkeley.edu Because everyone going to Snap! should know. That's on Brian I guess.

Also is IE 11 really that bad? WebAudio I think is the only thing that's not working? I'd rather have that as a note than as "don't use this at all". (Also we might want to clearly point out that Chrome is the current recommendation. And then Safari or FF are tied for various reasons.)

The paragraph about updates is a little misleading. There are reasons where Chrome is perfectly able to run on older OSes but can't be auto updated because of computer access restrictions. :( It probably should just recommend checking chrome.google.com every few months.

I think this also means that we should try to preserve compatibility by at least 1 year back as many computers in schools only get updated once a year.

Also we probably do want to have a recommendation for mobile OSes as well.

iOS 8 and above should be totally fine with the exception that sound files uploaded can't be played in a script. (All iOS versions have this restriction.) in fact iOS 7 should be compatible too but iOS 8 will be a lot faster.

On Android I have no idea, but we should recommend using Chrome on android and not the stock browser that comes with some devices.

Michael

Michael Ball From my iPhone michaelballphoto.com

On Oct 30, 2015, at 12:54 PM, Mary notifications@github.com wrote:

Thoughts? http://bjc-edc.github.io/bjc-r/cur/teaching-guide/specifications.html

— Reply to this email directly or view it on GitHub.

bromagosa commented 9 years ago

Snap4Arduino is indeed based on nw.js. Actually, come to think about it, once I've updated Snap4Arduino to the latest Snap! version I could just remove the S4A part and the rest should work with minimal changes. All menus and OS interaction has already been taken care of in Snap4Aduino, so it may be easier to just take the Arduino part out than to start anew with a fresh Snap!. After all, all modifications to Snap! are performed dynamically at runtime, no Snap! source file is being changed at all.

Only trouble is with automatic updates. That should be looked into.

Good news is @elaval, early project collaborator, has just sent me the Win32 serial port plugin that I was missing to be able to update to the latest Snap! changes, so a new version should come out this week.

cycomachead commented 9 years ago

@bromagosa That's awesome! Is the S4A nw.js code open source?

Getting OT, but since it's on my mind: I was thinking if we had a packaged desktop app, we could build a small UI to manage extensions and then Snap! extensions that require the desktop could just be regular Node packages with a certain tag that Snap! knows about and could install on-demand.

bromagosa commented 9 years ago

Of course it is, Snap! and nw.js are both free software, so any derivative must be too :)

DISCLAIMER: This repo is a big ugly mess, and it weighs a million petabytes. I intend to fix it one of these days, but you know... human time is finite :(

https://github.com/edutec/Snap4Arduino

jmoenig commented 9 years ago

This is exciting!! So, as we're about to merge Snapi functionality into the main Snap trunk as well, we'll be unifying most of the best branches once again!

maryfries commented 9 years ago

@cycomachead How's this? http://bjc-edc.github.io/bjc-r/cur/teaching-guide/specifications.html

cycomachead commented 9 years ago

@maryfries Yes, I think that looks pretty good! :)

Still, going to say that @brianharvey should have something on the main snap.b.e webpage

jmoenig commented 9 years ago

Yep, I like it! And I also agree with Michael that it would be good to somehow make this information available on s.b.e, too. Thanks!

maryfries commented 9 years ago

Thanks!

brianharvey commented 9 years ago

OK, will do.

nemilya commented 9 years ago

Off-topic: do you have plans to migrate Snap site to github? Also for static site generation https://jekyllrb.com looks simple and good.

cycomachead commented 9 years ago

That one is on Brian. :smile: I'd be all for it, but Brain doesn't like git.

brianharvey commented 8 years ago

Info is on s.b.e

Moving to github over my dead body.

cycomachead commented 8 years ago

One day, you'll come around.