Browser Compatibility about processing-hour-of-code HOT 15 CLOSED

Are there any hard browser support requirements from the code.org people?

If not, I agree with your approach — WebKit browsers first, then Firefox as much as possible, then newest versions of IE as lowest priority (and older versions of everything, not at all).

from processing-hour-of-code.

Just to expand on this slightly, the Initializr build I used includes Modernizr and Chrome Frame support. Anyone viewing the site in an IE version less than 7 should be prompted to switch to Chrome or at least use Chrome Frame.

Modernizer includes an HTML5 Shiv to enable some things in IE that normally aren't available. It can also be used for feature detection so we can turn away browsers that don't support a given feature, though we'd have to write those conditions as they crop up.

I personally have very strict anti-Windows policy and a doubly strict anti-IE policy, but a full QA evaluation of the site would probably require checking it in IE 7, 8, 9 and 10 running in XP, Vista, Windows 7 and Windows 8.

Actually getting it to work in all of those instances without a ton of work would be a minor miracle, though we could at least know where to redirect if necessary. I could, for example, change the Chrome Frame message to turn anything away below IE 10.

from processing-hour-of-code.

I don't think its realistic to worry about these issues given our resources (feel the same about tablet). If it works in other browsers by accident great . . and we can always return to this after the launch if we decide we want to. I will go with what you recommend @scottgarner in terms of the chrome frame message.

from processing-hour-of-code.

I'll quickly test in whatever versions of Windows/IE happen to be on the production laptops at ITP and on the PCs at the NYU libraries.

My only real concern is a classroom of students somewhere with older machines, but agree with @shiffman that we can revisit this later on if needed.

from processing-hour-of-code.

I just finished a grueling refactor with jslint and things actually seem to work reasonably well in IE 10 after a cursory check. The only problems I had were with events not firing when scrubbing, but I think that's a problem with Flash, Vimeo or Popcorn and it will hopefully not affect us when the video plays through normally.

Every method I knew of to figure out the version of Windows was disabled for security, but I think it was Windows Vista or Windows 7.

from processing-hour-of-code.

Just tested in IE11/Windows 7.

• You can't click "Click here to start" on the splash screen
• The video won't show (and make the browser hanging)

Perhaps show a warning message when IE is used at all?

from processing-hour-of-code.

Thanks for the report. I imagine some of the changes I made today broke IE compatibility. I'll have to test next week when I have access to a Windows machine.

from processing-hour-of-code.

Just as an update here. Any version of IE below 9 is automatically out because it doesn't support , on which Processing.js relies. IE 9 should technically be okay, but I was having some issues with it during testing and both Popcorn and Vimeo were throwing errors.

As of now, any browser that doesn't support

The biggest question here is whether or not to redirect the iPhone since it can't play inline video. Unfortunately, there's no reliable way to to check for that particular feature, so it would probably be safest to cut out all mobile browsers with something like http://detectmobilebrowsers.com.

from processing-hour-of-code.

In IE11, I still can't click the "click to start area". Everything else is working.

from processing-hour-of-code.

Thanks for the update. Still planning an IE 10 and 11 debug session this week.

from processing-hour-of-code.

I am seeing the following in Google Chrome Version 31.0.1650.57

Text:

Blocked a frame with origin "http://hello.processing.org" from accessing a frame with origin "http://player.vimeo.com". Protocols, domains, and ports must match.
84
Blocked a frame with origin "http://hello.processing.org" from accessing a frame with origin "http://player.vimeo.com". Protocols, domains, and ports must match. markdown-here.js:32

It also makes the interactive part not work in Chrome.

from processing-hour-of-code.

@tundal45, are you noticing any functionality problems with those errors? At least one of them looks like an issue with and extension you're using, markdown-here.js.

from processing-hour-of-code.

@scottgarner Yes, the issue I am seeing is that the textarea with the code and the side canvas don't show up when the video is at a part where it assumes it's there. I disabled markdown-here and I am still seeing the issue with the interactive pieces not showing up. Apologies for missing the error messages were generated by Markdown Here.

from processing-hour-of-code.

@tundal45 I don't see this error, and everything is working perfectly in Chrome 31.

from processing-hour-of-code.

I tested in IE 11 this morning and all seems well. I still haven't been able to reproduce any problems in Chrome.

@tundal45, could it be some other extension that you're using or some increased security setting?

from processing-hour-of-code.