@micha @jumblerg speaking of which... I am running alpha15 and can't see my site with Windows 7 IE 9

Really weird...

IE 8 doesn't work either

My terminal shows

2016-06-15 06:01:13.638:WARN:oejh.HttpParser:qtp997122451-776: Illegal character 0x16 in state=START for buffer HeapByteBuffer@26e46bb9[p=1,l=160,c=8192,r=159]=

oh, it doesn't seem related. Can't reproduce the error message

Trying with alpha16

Got the same problem. Can't see anything with IE 8 and 9.

with alpha12 also

if (typeof goog != "undefined") { goog.require("boot.cljs.main808"); } else { console.warn("ClojureScript could not load :main, did you forget to specify :asset-path?"); };

you have no body there in the DOM

any console warnings?

yes

SCRIPT600: Invalid target element for this operation. 
index.html.js, line 535 character 201
SCRIPT600: Invalid target element for this operation. 
index.html.js, line 535 character 201

line 535

p,q,r,t,v,x,C,G,K,S,Q,E,Ua,W,ba,Y,U,R,ca,ha,fa,Va,ob,oa,za,pb,mb,Qb,b,e,f,f,g,k,l,m,n),null),p,q,r,t,v,x,C,G,K,S,Q,E,Ua,W,ba,Y,U,R,ca,ha,fa,Va,ob,oa,za,pb,mb,Qb,b,e,f,f,g,k,l,m,n)).call(null,m,Ki)}();return tn.Ud?tn.Ud(p,q,r,t,v,x,C,G,K,S,Q,E,Ua,W,ba,Y,U,R,ca,ha,fa,Va,ob,oa,za,pb,mb,Qb,a):tn.call(null,p,q,r,t,v,x,C,G,K,S,Q,E,Ua,W,ba,Y,U,R,ca,ha,fa,Va,ob,oa,za,pb,mb,Qb,a)}a.G=0;a.H=function(a){a=A(a);return b(a)};a.l=b;return a}(),io=function(){function a(a){var d=null;if(0<arguments.length){for(var d=

this is in the IE console

no warnings in terminal

Any ideas?

@leontalbot: does it work in any versions of ie?

yes, IE 10+

@leontalbot: i’m looking into this now

can you give me an example *.hl file to reproduce?

ok, back to my laptop, on it...

@jumblerg

Any hl files cause this error

I've copied the handler code just in case...

static pages like error 404 works fine

i'm looking into it now

thanks

@jumblerg: Have you been able to reproduce?

@leontalbot: yep, thanks, running through some x-browser testing now

@leontalbot: do i understand correctly that this issue runs back to hoplon 6 alpha12?

yeah that's wierd because it didn't work out with alpha12 this morning

Maybe I tested to fastly and made a mistake

I am not in front of my computer in the next minutes, so I won't be able to double check that

@leontalbot, @micha: apparently the innerHTML property, which i introduced into alpha14 as part of a fix for this regression https://github.com/hoplon/hoplon/commit/128dc2134774bd6e3de74de88707745e34f99f5a (description is here, innerHTML was added in a subsequent commit), is read-only in ie 8.

it also breaks in 9

to summarize, in ie 8: (1) innerHTML write is unsupported on the body element which breaks alpha14 and (2) the type Node is not supported which breaks yesterday’s commits adding the extensible ->node fn. ie9 has similar issues, but i don’t want to spend any more time digging to understand better. i’m certain there’s a solution to the former with a bit of hacking (probably using removeChild instead); additionally, the fix for Node is relatively straightforward albeit less elegant. wrt to our conversations yesterday, the cost of continuing to support these ie versions is more tangible to me now, both in terms of time required for (1) xbrowser testing (2) hacking around to find non-mutually exclusive scenarios that satisfy ie 8, 9, and the other browsers and (3) managing the increased complexity of the codebase. in all cases, we appear to be in good shape with ie 10+.

my vote is that we drop support for ies 8 & 9 moving forward. maybe we tag one last release reverted to alpha13 (this will reintroduce the bug with cells in the body tag) for people who need 8 & 9.

it might also be worth noting that react dropped support for ie 8 early this year.

i’m curious to know how this will impact other users here

@jumblerg: I think it was you who pointed out that the number of webapp users on old versions of IE is probably minimal unless they are enterprise, I would agree with this. Personally I never care about old browser support with my projects, I have a “push-forward” view on these things, technology shouldn’t really care about the previous iteration, only the next one.

My biggest support limitation was recently removed when we upgraded all the offline systems to IE 11, no more gov requirements for clearly vulnerable browsers 😛

@flyboarder: thanks for weighing in, i agree. i’m using hoplon for financial services software, and even the banks who were using ie 6 a few years back have finally gotten with the program.

ultimately @micha makes the calls around here though. i can only argue with him. 🙂

Yeah I recently decided that IE 10+ was my benchmark for support, if it’s broken try edge, if that doesnt work, fix your infrastructure.

But I also dont write a whole lot of apps with thousands of users.

yeah, same, micha et. al might have different userbases to support

I'm open to change, especially if we conform to some widely adopted standard, like reactjs for example

Generally whichever userbase is getting the most coverage area should be the target

@micha: i do think react still supports 9, my suggestion, based more on development cost, is that we go one ie further.

and establish ie 10+ as our benchbark

I dont think much needs to be changed, more a decision for how to handle browser support for future issues? Also IE10 resolved a lot of IE specific differences

I see more <IE10 statements in source 😛

yeah. i was using an ie check that embedded google chrome frame for my financial services customers.

@jumblerg: thats what I did too 🙂

that was a clever product. then one day, i accidentally disabled it during xbrowser testing, happened to be on ten, and was temporarily confused when it worked anyway.

Also MS is pushing windows 10 to clients now, my friend had to actually rollback his OS because he declined a (partially installed) update, bad microsoft 🙃

yeah, that’s some sort of progress i suppose - even M$ can’t bear the cost any longer.

although, next thing is that you’ll probably have to get a linkedin account to log into windows

yeah i think windows 9 is effectively dead now, because M$ force updated them

i mean ie9

it's like 0.1% market share

ie10 is about the same as ie8 i think

awesome. after the way i spent my morning, this makes me happy to hear.

10 is evergreen, i believe

@jumblerg: are you on windows 10? You have to make it create a local account instead of an MS Live account on fresh setup. Now it’s just a crappy apple.

saucelabs is a pretty good product, btw https://saucelabs.com/

nope. osx.

@jumblerg: im forced to run VM’s on my mac 😕 but your windows logon is the same as iCloud password on OSX

i found saucelabs to be a nice alternative to the vms this am, i was able to test the changes i was serving locally on their system rather painlessly.

I have to VPN into client networks so I run a VM for each client env I use, waiting for windows containers so it’s more like docker, but back to Hoplon….. IE10+ support is my vote for future issues 😛

thanks for the feedback

@micha: if you decide to drop ie 8 and 9, there’s a thoroughly tested branch. ^^^

figured i’d strip the ie8 stuff out now and test against use of the js/Node type while i had all the xbrowser testing machinery up.

@jumblerg: thanks! Will land soon and catch up with new version

@leontalbot: np! i think i might have taken things in the exact opposite direction you were hoping for though. :)

are the ies 8 and 9 something you need support for?

yes

I need it

@jumblerg: ^^^

My biggests clients are governments

which means slow tech adoption

And as I do online polls as a living, we need to make sure we can offer the chance to any citizen to answer...

even IE 8 and 9

so I would need to stick to alpha9 or?

hmmm

Am I the only one in that position?

@leontalbot: what percentage of your users are 8 and 9?

(just curious)

IE 8 17% of all IE, IE 9 10%

though it is going down

the last distribution that properly supported ie 8 is alpha13, i believe

wow

and what percentage of users are ie users?

this I cannot say out of the box, because I didn't exclude my IP (which is gaming chrome a lot)

And the IP of our people on the streets that fill polls with iOS and Android

i did some testing on ios, android, everything worked fine there… mobile tends to be more progressive

can you try alpha13 and confirm that this distro works correctly for you?

Will do tonight

Thanks again @jumblerg

With alpha13 I may come up with the "null" that gets added in head and body, no?

@leontalbot: i thought that was in 13 but you’re correct. alpha12 is the last one that supports ie 8.

Shit!

Ok

So i should implement my own case-tpl etc. ?

I think we might want to keep the ie8 hacks in

i think we can figure out a way to make it work

the first step is to have a demo app that we can test in ie8, perhaps

and some method to test in ie8 without needing a windows computer, cause i don't have one

@micha: i’m actually doing some experiments now on an innerHTML alternative

innerHTML has a different implementation for ie 8 (read-only), 9 (who knows), and 10 (works)

fun

iirc that was just for the reloadig support, the innerHTML change

yeah

so that's not as important

we could take it out alltogether

or just do it if it's not ie8

my thinking is that we have a major release that includes the latest features and supports ie 8

then drop ie 8 and 9 after

i don’t like the idea of leaving people hanging

hoplon itself doesn't necessarily need to drop support for ie8 i don't think

hoplon is so simple, it doesn

t seem like too bad to have those special cases in there

i like the idea of supporting it, i think it is definitely a plus to, esp in an enterprise-grade thing, i just dislike paying the ie tax.

@leontalbot: sorry, just saw your upstream message, i was trying some things here, one way or another we’ll have a fix soon.

@jumblerg: ah great!

@micha: do you want an access to my browser VM account to test ?

Its a saas

@micha: how ironic that the very way you check to see if the brower version is ie 8 is to (not (aget js/window "Node”)).

my bug is your feature

lol yeah it was interfering with my plans as well

@micha: just fixed @leontalbot’s issue with a direct call to (merge-kids elem nil nil)

this iterates through all the script kids jammed into the body on load and calls removeChild on them

instead of attempting to blow them away with a single innerHTML

@leontalbot: can you check out master and give that a try?

i did some x-browser testing here with a hello-world and it passed

@jumblerg

Sure! How to build again?

clone master then boot build-jar

ok thanks

Ok, i just tested with IE 8 9 and 10

works only with IE 10

question: i've first erased .m2 hoplon alpha16 repo

then build-jar

then I did boot dev

Do I need to clean or smth, before?

@jumblerg

hm, that shouldn’t be necessary, you should be able to boot build-jar

it will overwrite the existing jar in ~/.m2

let me double check here to make sure i didn’t ovelook something that gave me a false positive

ok thanks

hmmm

(page "index.html")

(defc messages ["hello" "ie 8"])

(html
  (head)
  (body
   (for-tpl [m messages]
    (div m))))

I checked out master

The patch seems there, right?

these are the changes i made https://github.com/hoplon/hoplon/commit/2178ef60dbaa70bd3ce17b268c86fbf3db14fa2e