Error saving profile on IE11

[David Marrs]

In IE11, on dev.udemi.org, I created a new user, and then went to edit their profile (just to add a location). On clicking save a pop-up appears that 'Error saving profile'.

I have added some breakpoints and enabled network traffic capturing in Developer Tools and I believe the POST from the call to httpReq() inside Udemi.user.save() is not actually being made: IE11 is instead using a cached result (this ties in with errors in the console from the use of $scope.$apply() inside the anonymous function passed to Udemi.user.save(): that callback should be fired asynchronously but is firing immediately, before we get to the line after the call to Udemi.user.save() (place a breakpoint inside the callback (say line 1602), and then at line 1604 to see this in action).

I see the call to $.ajax inside httpReq() is already set not to cache, but maybe a timestamp needs to be appended to the query string as well as suggested at http://stackoverflow.com/questions/20219590/strange-ajax-bug-with-ie-11

@enricosoft What's the safest way to do that without breaking existing usage of httpReq()? I guess we need to prefix it with either '?' or '&'

[David Marrs]

I think we have the same issue for GETs in IE11, for example if on dev.udemi.org I place the issues map around Oxford and London with Chrome I can see lots of pins. In IE11 no pins. Again with breakpoints in Udemi.stances.get() and use of network traffic capturing I can see that $.ajax is being called but no GETS are being made, and it is not firing asynchronously.

@enricosoft Unlikely that different map bounds have been cached so maybe it's a cross domain issue as that stack overflow suggests?

[Enrico Piccini]

I'm trying to understand what is happened to ajax calls

[David Marrs]

Had a thought: if the requests were cached, I guess they wouldn't be firing the error callbacks on $.ajax. So yeah, security issue?

[Enrico Piccini]

No, we don't need cache for this kind of requests

[David Marrs]

I know we don't need a cache, I meant maybe IE11 was caching regardless.

Anyway @enricosoft , I have an update: http://dev.udemi.org/ shows map pins but httpS://dev.udemi.org/ doesn't, and i was on httpS in IE11 so that might have been a red herring (sorry).

[Enrico Piccini]

When it doesn't work on IE is because the ajax call return an error: "Error: Permission denied"

Maybe also for Facebook Login is the same.

It's something related the cross-domain I think but it's very strange!

@dwmarrs

[Enrico Piccini]

@andrefsp Hi Andre, we're having some problem on API cause seems that we've a cross-domain problem with api, in particular with IE (from yous side can you help us?)

[Enrico Piccini]

Hi @andrefsp , I'm sure that the problem is IE!

Read this: http://www.webdavsystem.com/ajax/programming/cross_origin_requests If I disable the setting, the cross-domain api works well

Cause it's a default IE security setting, we cannot do nothing. A possibile solution for me is: create an api "proxy" on the same domain of the website (e.g. https://dev.udemi.org/api/.....) that of course prox the call to our https://api-dev.udemi.org In this case I think we're able to solve the problem cause for IE we're on the same domain We can try this solution.

@dwmarrs The FB login problem still persists on IE also after I disabled the setting. You said it could be a facebook app configuration problem. Well, It's possible but very strange because we've this problem only on IE

[David Marrs]

@enricosoft before I went out today, I tested in Chrome, FF and IE on dev.udemi.org and they were all having problems. See note I left on the other issue at https://bitbucket.org/udemi/api/issues/228/facebook-signup-does-not-work/#comment-27057402

That's why I think the login issue is an app configuration problem, because it's not just IE that has a problem now that we changed that caching parameter on the call to FB.getLoginStatus(). (I guess the cached value was correct for FF and Chrome by coincidence, and was just wrong for IE (because IE is awful)). On the plus side, it should be easier to work out if it's all the browsers that are affected now!

So does this mean Facebook have changed their required settings since you first set up the apps?

[Enrico Piccini]

The OAuth uri is required (we saw the error this morning when we share the screen) but the one I setted of course is not correct and we need to wait Andre add the right url

[Enrico Piccini]

@andrefsp Hi Andre, when you come back home, can you check if there are cross-domain problems on DEV, TEST and PROD (the online websites)? Cause in localhost the PATCH verb works well but on DEV for example that has debuggable code, it doesn't work and I get "Error: permission denied"

[Enrico Piccini]

Solved also this. THe problem was the version of jQuery that has a bug using PATCH verb on IE (cause they dismissed the use of ActiveX)