IE8 select called twice, callback not triggered sometimes

[mlarcher]

Demo page is not working in IE8, and I can't get it to work locally either.

There is an issue with console.log.apply in FileAPI when debug mode is set to true (cf https://github.com/mailru/FileAPI/issues/353 ) which block anything else on the demo page.

When this is fixed (or when debug is false), there is an "Error: Invalid argument." with stack [object Error]{description: "Invalid argument", message: "Invalid argument", name: "Error", number: -2147024809}.
I couldn't figure out where this one was coming from.

[danialfarid]

Demo page is working fine on IE8 WinXP for me.
Are you sure you have flash installed and you are not in compatibility mode or have any plugin installed that causes this problem?

[mlarcher]

I tried on a native IE version 8.0.7601.17514 on windows7 with Flash version 19,0,0,207 on a modern.ie vm and it doesn't work at all. I can select a file through the flash object, but then nothing happens.
Same thing with a with IE8 (8.0.6001.18702) on winXP, with Flash 19,0,0,226.
Same thing too on a vmware image of IE8 (8.0.6001.18702) on winXP, with Flash 10,3,181,26

If I try on a IE11 in compatibility mode IE8, I get an error in FileAPI on "console.log.apply" as soon as the page loads.

When I try a local implementation with the latest FileAPI.js in that same setup, I get the "invalid argument" error.

For most of the tests, I'm using modern.ie virtualbox images provided by microsoft for testing, and didn't install any plugin except Flash itself.

I'm a bit surprised that it would work for you. Could please test with a clean VM from https://dev.modern.ie/tools/vms/mac/ ?

[danialfarid]

Just tested on a fresh copy everything works fine on the demo page.
Are you sure you are not getting errors that flash is not installed in the console?

[mlarcher]

@danialfarid: I tried 4 different versions of IE8 on 2 different computers and locations/networks, all with a different version of Flash and with the same result. I'm positive flash is properly activated on them, as I saw the animation on the Adobe page after installing.

Here is what I have in the console:

LOG: FileAPI: 2.0.7
LOG: protocol: https:
LOG: doctype: [undefined] undefined undefined
LOG: FlashAPI.state: awaiting
LOG: (flash -> js).log: storeKey=40805140304506215235307292050727_2.0.7
LOG: (flash -> js).log: timeout=0
LOG: FlashAPI.state: ready
LOG: FlashAPI.event.mouseenter: [object Object]
LOG: (js -> flash).multiple: false
LOG: (flash -> js).log: parseCmd, command: multiple
LOG: (js -> flash).accept: art,bm,bmp,dwg,dxf,cbr,cbz,fif,fpx,gif,ico,iefs,jfif,jpe,jpeg,jpg,jps,jut,mcf,nap,nif,pbm,pcx,pgm,pict,pm,png,pnm,qif,qtif,ras,rast,rf,rp,svf,tga,tif,tiff,xbm,xpm,xwd,ART,BM,BMP,DWG,DXF,CBR,CBZ,FIF,FPX,GIF,ICO,IEFS,JFIF,JPE,JPEG,JPG,JPS,JUT,MCF,NAP,NIF,PBM,PCX,PGM,PICT,PM,PNG,PNM,QIF,QTIF,RAS,RAST,RF,RP,SVF,TGA,TIF,TIFF,XBM,XPM,XWD
LOG: (flash -> js).log: parseCmd, command: accept
LOG: FlashAPI.event.mouseDown: [object Object]
LOG: FlashAPI.event.select: [object Object]

Are you testing locally or on https://angular-file-upload.appspot.com/ ?
There must be something particular in your setup that makes it work...

[danialfarid]

I tested https://angular-file-upload.appspot.com/. It was a fresh install.
So what is the error? Any error on the console?

[danialfarid]

Can you verify if any of these working?
http://1-1-0.angular-file-upload.appspot.com/
http://3-0-7.angular-file-upload.appspot.com/
http://6-2-0.angular-file-upload.appspot.com/
http://1-6-10.angular-file-upload.appspot.com/

[mlarcher]

Tests with a native IE8 (8.0.6001.18702) on winXP (Pro SP3) with Flash 12.0.0.38:

• On http://1-6-10.angular-file-upload.appspot.com/ I have a working upload
  
• On http://3-0-7.angular-file-upload.appspot.com/ nothing seems to happen when selecting a document (no change on page)
• On http://6-2-0.angular-file-upload.appspot.com/ I get an img tag inserted in the document, but it has no src
  

On http://1-6-10.angular-file-upload.appspot.com/ the file size is detected, but progress bar stays at 0%

(I get an "unspecified error" in the console when trying with IE10 in compat mode)

• And on current https://angular-file-upload.appspot.com/ nothing seems to happen (no change on page)

[danialfarid]

So what's the error log or console output you get for the latest demo page?

[mlarcher]

As stated previously, there is an issue with console.log.apply in FileAPI when debug mode is set to true (cf mailru/FileAPI#353 ) which block anything else on the demo page.
Here is what it looks like in IE10 compat mode:

[mlarcher]

It seems the fileAPI repository didn't release the fix yet, so in order to try from current site you'd need to remove the debug:true that is causing the scripts to fail

[danialfarid]

But do you get the same error in IE8?
It wan't supported for the compatibility mode from the beginning.
Do you get the exact same error in actual IE8 developer tool console?

[mlarcher]

I get the same error in a native IE8. Here is what it looks like:

[danialfarid]

@mlarcher Could you verify if it is fixed now

[mlarcher]

I don't have the debugger console taking over in IE10 compat mode anymore, but I still have the errors in the console and a non functionnal demo page.

[danialfarid]

hmm well i fixed that line that you mentioned in the post.

[danialfarid]

Could it be still cashing the old version?

[danialfarid]

I made the demo to use nonminified version of the FileAPI so you can pin down where the error is.

[mlarcher]

@danialfarid here is a few screenshot highlighting where IE10 in compat mode IE8 chokes (sorry the error messages are in french, I couldn't find how to change that). Hopefully it will get you an idea on how to tackle the issue.
Note that those errors arise several times on page load, I'll only present the distinct ones.

(This one is not really an issue as the exception is handled by angular)




I still wonder how come you can't reproduce it in a VM on your side, though.

[mlarcher]

I think the culprit is Object.defineProperty (cf https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Browser_compatibility )

[danialfarid]

I made a fix for that Object.defineProperty on the demo page, could you test again.
Also could you test it on the actual IE8? Compatibility mode may not work, I remember issues before that the plugin would work on the actual browser but no in compatibility mode.
Thanks

[mlarcher]

Now I get errors on the console.log.apply workaround in FileAPI...

[mlarcher]

It seems you forgot to decalre the _supportConsoleLog and _supportConsoleLogApply variables when you applied the fix in FileAPI. Why not just npm install it ? The fix is already in the master branch.

[danialfarid]

Does the upload work?

[danialfarid]

I made some changes to get rid of that error.

[mlarcher]

I don't have any error in the console now. Hurray ;)
Unfortunately, upload is still not working, and now we don't have an error to work on :(

I tried again in IE10 compat mode, and after a few tries got to the following error, though:

Perhaps it'll help figuring out what's going wrong.

[danialfarid]

Could you make sure you haven't change the html code in IE8, click on edit html link and then click on reset to default.
Also could you put breakpoints in IE8 https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L312 and https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L313 to make sure the change function is registered and being fired by file api?

Also FYI the plugin only works with the fileapi version that is shipped with this plugin. Other versions of fileapi may not work.

[danialfarid]

Does it hit https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L97 when you click submit?

[mlarcher]

nope.
It throws before that. I placed a breakpoint on the submit and it appears to be throwing from within the depth of angular.js when calling $digest within $apply.

[danialfarid]

Can you put a breakpoint here: https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload.js#L292
and go through the plugin code to find out at what line exactly it blows up?
That is the upload function and it would set up config etc and eventually call angular's $http().

[mlarcher]

Actually placing a breakpoint there doesn't lead to the line creating the error as far as I can tell. I've recorded the screen on video in case you can get some relevant info out if it. It is available on http://ringabell.org/temp/screen1.mp4

[mlarcher]

After deeper investigation, it appears that the error resides in https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L90 where orig doesn't have an apply method.

If I evaluate window.XMLHttpRequest.prototype['setRequestHeader'].apply directly in the console in IE10 compat mode, I get an "Object doesn't support this property or method" error. Native IE8 doesn't produce this error from the console, but crashes at the same place in the -shim code anyhow.

This error happens in a try/catch block in angular (cf https://github.com/angular/code.angularjs.org/blob/master/1.2.24/angular.js#L11574 ) hence the "unspecified error" output.

[danialfarid]

Alright we are getting closer.
So could you verify that window.XMLHttpRequest exists and new window.XMLHttpRequest().setRequestHeader' exists butnew window.XMLHttpRequest().setRequestHeader('test', 'test');' produces and error?
Also in IE8 could you go deeper in the angular code and see where in angular code it crashes. It should eventually let angular to call setRequestHeader on the xhr. Also make sure that xhr object is of type XMLHttpRequest.

Also could you see the network tab and see if there is any OPTIONS request being sent to the server?

[danialfarid]

Also could you see if normal angular http works in your browser?
$http({url: 'http://angular-file-upload.appspot.com/upload', method:'post', headers: {'TestHeader', 'Test'}, data: 'test'})

[mlarcher]

I can confirm that window.XMLHttpRequest and new window.XMLHttpRequest().setRequestHeader exist, and that new window.XMLHttpRequest().setRequestHeader('test', 'test'); produces error.

About the angular code, I don't see how I can be any more specific than I've already been in my previous meassage.

For the options request, I don't see any, but afaik only Chrome shows preflight requests in the network tab.

On xhr, I'm not sure I ever come to a place in the code where it is defined atm. How can I check that ?
If I run angular.element(document.querySelector('body')).injector().get('$http')({url: 'http://angular-file-upload.appspot.com/upload', method:'post', headers: {'TestHeader': 'Test'}, data: 'test'}) I end up on the same error on orig.apply(this, arguments);.
Setting a breakpoint on var initializeUploadListener = function (xhr) {'s first line allow me to see that 'xhr' is of type "DispHTMLXMLHttpRequest"

[danialfarid]

hmm so if the angular's $http is not working then this is an angular issue. Can you change the version of the angular on top right side of the page to a different one, earlier or later and see if it works with any of the angular versions. You can open an issue on angular github.

[mlarcher]

@danialfarid: this is not an angular issue, as the code throwing the error resides in ng-file-upload-shim ( https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L90 ). I'm just saying that making a post request through $http the way I pasted above ends up in the problematic code in ng-file-upload-shim being called.
Also, I already tried bumping angular to 1.2.28 (the latest with IE8 support) and it didn't change anything.
It seems to me that window.XMLHttpRequest.prototype['setRequestHeader'] in IE8 returns the same kind of object as console.log in the FileAPI bug pointed at in the beginning of this thread, i.e. something you can't use the "apply" method on.
I think we need to find a workaround for this particular "apply" issue to be back on tracks.

[danialfarid]

Right, Can you put a breakpoint where the apply on setRequestHeader is called and see if orig.call(this, header, valie); or orig(header, value) works?

[mlarcher]

So, now I'm sur that the original reference to window.XMLHttpRequest.prototype['setRequestHeader'] that you store as orig is a special kind of object, on which you can't call/apply. It was actually what the SO post I pointed to in the FileAPI issue was about ( cf http://stackoverflow.com/questions/10982739/typeof-returning-unknown-in-ie ).

You can check the following screenshot for more details.

For what it's worth, the upload was working once upon a time in version 1.6.4.
Which is weird as it seems the same system was in place already...

[danialfarid]

Would it work if you call in the console orig(header, value) instead of call or apply?

[mlarcher]

It doesn't :(
I'm perplex as to how it could ever have worked in IE8.
Could you please tell me which version of windows/IE you are using ? There must be something we're missing...

[danialfarid]

I have WinXP SP3, IE8.0.60001.18702 and I tried on the virtual box instance you posted earlier with Win7 IE8.

Can you somehow make a clone of the vm that is not working and send it to me?

[danialfarid]

From the screenshot above I can see that origin is actually an object not a function.
Can you see what properties that object have? for (var key in origin) console.log(key)

[mlarcher]

I replaced orig.apply(this, arguments); with for (var key in orig) console.log(key) and for (var key in orig) {alert(key);} but go no output. I think it is a special kind of entity in IE8 (cf http://stackoverflow.com/questions/10982739/typeof-returning-unknown-in-ie )

Also, as I removed the orig.apply() call, I saw that the upload became functional, reporting progress and eventually displaying "Upload Succesful". Of course, that would be without the headers, but that's something.

For the VM, I used several environments, one of them being the same VM you tried (to be confirmed). I'll make sure it was on a WinXP SP3 with the same version you have.
In the meantime, could you please set a breakpoint on ng-file-upload-shim line 90 and add spies for typeof orig, typeof orig.apply, orig.apply(this, arguments), orig.call(this, header, value), orig(header, value), header, and value?

[danialfarid]

The type is the same as yours, but calling apply or call on it will not produce any error.
I can put that in a try/catch but it would probably break other libraries that making any XMLHttpRequest with some headers.

It is so weird that it is failing only for setRequestHeader and not open or send.

[mlarcher]

Hi @danialfarid ,
sorry I didn't reply earlier, I was too busy working on other stuff.

I have just tested again the demo site in a virtualbox, and found it working! Weird thing is that it still fails in the vmware box, but well, if it can work in a ie8 in a vm, I can assume a native one on a real OS should work too.

I updated the code on our application with the latest version of ng-file-upload (plus shim and fileapi), and got the following problems, though:

1. The callback passed to ngf-select is called twice when in IE8. This is something that had already been tackled in File select callback is called twice in IE8 #284 so maybe that is the same problem and could be a quick fix. It seems this is the root cause of an 'invalid argument' error in the js. If I hack the application code so that the onFileSelect method only acts once, there is no error and the upload progresses as expected.
2. The upload works, but neither of the callbacks on the promised returned by Upload.upload() are called, so we can't notify the user that the upload is over. It seems the promise if never resolved nor rejected.

Could you please have a look at those ?

[mlarcher]

also, and even on the demo site, the second upload will fail because there is no prevFiles. I believe it is due to the same reason: promise being never resolved, the prevfiles would not be filled.

[mlarcher]

@danialfarid : any news on the matter ?

[danialfarid]

For number 1 do you use jquery? If you remove jquery dependency would it work? I wanna make sure it is related to jquery. It could be because upload will be called when you click on the element since it is reseting the previous files, so it might be the reason it is being called twice.

For number 2 make sure your server returns something. If the response doesn't have content or it is 400 error code Flash will not fire request complete.

[mlarcher]

We don't use jQuery at all, and the server returns a json object on upload completion.

[danialfarid]

So why do you think it is related to #284?
The demo page works with 200 response. You need to investigate more to see why the response is not coming back.
You can put a breakpoint here and see what happens there. That's where the flash callback from FileAPI comes back: https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L105

[mlarcher]

I think it may be related to #284 because it fixed the same issue (File select callback is called twice in IE8) on the same project when I opened it at the time. Might be another issue with the same symptoms, though.

When placing a breakpoint where you said, I see the expected output from the server. It's hard to figure out what's going on next, as there are many jumps into angular and other scripts. Do you have something more specific to test ?

[danialfarid]

The fix for #284 is just an if condition for the case jquery is available. so I don't think the same fix would help here.

If you get the response back correctly from the server then everything should be fine.
Put a breakpoint here: https://github.com/danialfarid/ng-file-upload/blob/master/dist/ng-file-upload-shim.js#L157 and it should go through angular xhr handlers until it would eventually call the promises then functions for success, failure which would be here if you are debugging the demo page: https://github.com/danialfarid/ng-file-upload/blob/master/demo/src/main/webapp/js/upload.js#L85

[sendreams]

[sendreams]

i also have this problem, ie 11 with compatible mode ie9. win10 64.