Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API key signup form broken in IE8 and IE9 #174

Closed
GUI opened this issue Jan 16, 2015 · 1 comment
Closed

API key signup form broken in IE8 and IE9 #174

GUI opened this issue Jan 16, 2015 · 1 comment

Comments

@GUI
Copy link
Member

GUI commented Jan 16, 2015

In IE8 and IE9, when you hit signup, it just says "Loading…" but never returns. Behind the scenes an error has occurred. There are several issues here:

  • Signup is obviously broken in IE8 and IE9. :( This is due to their lack of CORS support. We're using an IE CORS shim, which I know has worked in the past (see 5c20df0). So I need to figure out what broke it and when. It appears like IE doesn't submit the form with a content-type, which is causing the Rails app to not parse the form data submitted. This is a known issue with IE8-9's pseudo CORS support shim, but I thought we were somehow working around this in the Rails app.
  • When an error occurs during signup, the user should at the very least receive an error message with a link to our contact form. In this case, this was not happening (there was no really indication anything was happening), which isn't good.
  • This was triggering a Rails error, but I wasn't receiving our error notifications we should get from those type of errors. I need to also figure out
  • We obviously need to add some test coverage around this, so this doesn't regress again. A full blown selenium test would be nice to actually test it in various IE versions, but in the meantime, we could at least reproduce this more simple IE CORS problem by performing a controller test in the web app without a content-type.
@GUI GUI added the bug label Jan 16, 2015
GUI added a commit that referenced this issue Jan 17, 2015
This fixes error handling so that if the CORS request fails, jQuery's
error handling is triggered and the user will get an error message,
rather than no response.

Fork: https://github.com/GUI/jquery.iecors

Related to: #174
GUI added a commit to NREL/api-umbrella-web that referenced this issue Jan 17, 2015
There was a difference between how Passenger and Puma handled empty
Content-Type POST requests that meant the pseudo-CORS requests from
IE8-9 were no longer working. We're now addressing this more formally
inside the Rails app, so that we're not dependent on our Rack server
behavior (so it should work in Puma, Passenger, and any other servers).

Also add tests surrounding these odd content-type situations.

See: 18F/api.data.gov#174
@GUI
Copy link
Member Author

GUI commented Jan 17, 2015

These various issues should now be fixed.

  • IE8-9 signups are now fixed: NREL/api-umbrella-web@554e03d This had indeed worked at one point, but it became broken in October when we rolled out the large API Umbrella update. It was caused by a subtle change in behavior in the Rails app server (Passenger vs Puma). Sorry for not catching this sooner. I've added test coverage around the specific pseudo-CORS behavior we expect from our app for IE8-9 to work, so hopefully this won't crop up again.
  • If a signup error does occur in IE8-9, the user will now receive an error message (rather than just hanging): 5fa9a61
  • We will now get error notifications if errors like this do crop up. Getting errors from the Rails app should be fixed by NREL/api-umbrella-web@1ca86aa and NREL/api-umbrella-web@fcbc5c7 While getting error notifications from the frontend javascript failures should also be fixed by the above improvements to IE8-9's error handling.

@GUI GUI closed this as completed Jan 17, 2015
@GUI GUI added this to the Sprint 13 (1/12-1/23) milestone Jan 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant