I ran into a scenario where I was thrown an unexpected behavior only in IE8 browser. IE9 and Firefox browsers work fine. The behavior went like:
User populated a form
On purpose - user leaves a mandatory field blanked
User clicked "Submit button" and browser sent a POST request
Expected behavior - error message is thrown along with data that was already provided. Only mandatory field should be left blanked as we did not provide anything in step 2. But instead I'm getting an error message with previous data lost i.e. form empty.
And note this only happens in IE8. Any suggestions?
I am going to answer this questions myself. So, here's what happened in my scenario. It was a double click problem. But I only clicked the button once. Then how did that happen? Some programmer who worked on this project was handling a form submit where he did another submit using JavaScript. But then how did this work in Firefox or IE9+?
I used Fiddler to go deep into this - I noticed in IE8 browser two requests are sent to the server. But IE9 and Firefox correctly handles this scenario (i.e. learns about double click) and sends only 1 POST request instead of 2.
Technologies used: Spring Framework 2.0, JSP, HTML, JavaScript
Why data is lost has also to do with Server - Spring modifies the session attributes (to be specific it's a formObject which is temporarily removed and re-added) while processing requests. When there's another request at the same time it goes through another pipeline (handleInvalidSubmit) which ends up creating a new formObject and thus destroying old data.
Hope this will help others :)
Related
Here's the setup:
Very simple form, just a name field, plus two ActiveStorage attachment fields square_image and landscape_image.
Both fields have direct_upload: true set.
If all form fields are filled out, including the files, the submit work exactly right, no problem.
However, if you fill out only the name field, leaving any of the file fields blank, I get an invalid_request every time.
This only happens in Safari.
The debug logs from nginx reveal client prematurely closed stream: only 548 out of 953 bytes of request body received.
It doesn't seem to be an nginx issue, because I get a similar experience locally via pow (the connection just hangs for a long time, presumably because pow is waiting for the data that never arrives).
Has anyone else experienced this, or have any ideas about how to debug this? I can't figure out where to go from here.
Rails 5.2.0
Safari 11.1 (13605.1.33.1.2)
This is indeed a bug in webkit. It has allegly been fixed but at this point in time, the bug still affects Safari. https://trac.webkit.org/changeset/230963/webkit
I am trying to save user changes to a form on the server with AJAX on tab/window close.
This is a similar question:
Intercept page exit event
I am using this code :
$(window).bind('beforeunload', beforeUnload);
...and it seems to work fine except for when using IE11.
It seems that when the user verification alert pops up in IE11, every JS piece of code that was previously running gets halted (and my data is not sent over the wire).
So, if the user chooses to leave, everything is gone.
Has anybody made it work on that browser?
Is it possible?
EDIT :
I see now that it works sometimes and it fails on others.
When it fails, it starts the AJAX call (it hits the breakpoint at that point), but never gets in the success/fail function... (and I see nothing being sent when using Fiddler)
In summary, it first hits the AJAX call breakpoint, it then displays the confirmation dialog, and when you choose to leave the page nothing gets sent... :(
Turns out that this method of saving data is not reliable and it is working only by pure luck.
Also, the synchronous XHR is marked as deprecated by now, so it's not a good idea to use that either.
So, I guess the web is not meant to work this way...
I'm trying to figure out what is going on here. I've been at it for hours now and can't seem to get a grip on why this is happening.
I'm making a few AJAX calls, and I keep getting this error back only in Firefox (version 21) on Mac OS X.
Here is the error:
"[Exception... "A parameter or an operation is not supported by the underlying object"
code: "15" nsresult: "0x8053000f (InvalidAccessError)" location:
"https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js Line: 6"
I'm making a CORS call, so I set up my AJAX like so:
$.ajaxSetup({
crossDomain: true,
xhrFields: {
withCredentials: true
}
});
And continue calls henceforth. Basically, does anyone out there have ANY experience with this error? I see some posts online but they all seem to do with Cross-Domain CSS, which I'm not using.
Okay, so after of hours of testing (and great discussion from #Dave and #danronmoon, I've finally figured out what's going on.
The CORS (Cross-Domain Resource Sharing) calls I was making were set to 'async: false' -- (which I realize I did not include in my original post, as I thought it was inconsequential) this, seems to operate fine in all browsers except Firefox, where jQuery will bark at you and your ajax call will fail.
Thank you all for your help and I hope this helps someone else!
Since this is the first duckduckgo result for InvalidAccessError: A parameter or an operation is not supported by the underlying object I will add another source for this.
If you deal with such error when doing iframe/window actions, then you're probably prevented by the iframe's sandbox attribute (see https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox ) even when being on the same origin.
In my case, an iframe was trying to do a window.top.location.href = ... after a form submission success. The allow-top-navigation sandbox option is mandatory to do so.
Funny thing, this sandbox option is not mandatory to reload the top browsing context... it's only required for navigating in it.
For me, I was using WebSockets and called WebSocket.close(1001). It doesn't like my status code. Changing it to 1000 or not specifying a code (default 1005) works just fine.
this is the real solution by Diogo Cardoso, the xhr object or parent seems to lack a toString() method
CORS synchronous requests not working in firefox
Yes, it is a CORS problem caused by using ajax. But as user320550 asks, what if you NEED to use the property 'async:false'? I found that using the 'withCredentials:false' property as a workaround fixes the issue on firefox and doesn't affect other browsers.
Just want to add a somewhat nasty intermittent variant of Xenos's answer. As he mentioned, you can get this problem if you try and navigate the window by setting window.top.location.href = ... from within a sandboxed iframe, and that this can be prevented if your iframe has the allow-top-navigation option set.
But you might also find your iframe has the more restrictive allow-top-navigation-by-user-activation option. This will allow navigation, but only in response to a user action such as clicking a link or a button. For example, it will be allowed within a form submit event handler, but you can't just trigger it at an arbitrary point in time, such as from a setTimeout() callback with a long delay.
This can be problematic if you are (for example) using AJAX form submission before performing a redirect. The browser needs to decide if the navigation is in response to a user action or not. It does this by only allowing the navigation if it is considered to have happened within an acceptable time period of the user interaction. The HTML standard refers to this as transient activation.
The bottom line is that if your AJAX call is too slow, or if your user has a poor network connection, the navigation will fail. How slow is too slow? I have only tested Firefox, but it appears to allow 5 seconds before it considers the user interaction to have expired.
Possible solutions:
Ask whoever is responsible for the iframe options to upgrade to the blanket allow-top-navigation option
Don't perform async work such as AJAX requests in between user actions and top navigation. For example, use old-school POST form submission directly to the back-end, rather than using an AJAX request
Make sure your responses are as fast as possible. Catch any errors, and prompt the user to click something to trigger the navigation manually. For example:
async function submitForm() {
await doPotentiallySlowAsyncFormSubmit()
try {
window.top.location.href = ...
} catch (e) {
// Show message to user, e.g. "Form submitted, click here to go to the next step"
}
}
I never had any problems with "Delete" button on any browsers, but I had 2 users complain about it - they click on the button and nothing happens. One of the users did not have any problems with the buttons in the past. The code seems OK, no errors were ever generated. All other buttons work for these users too. Any idea on why it could be happening?
It's also possible that these 2 users have security applications performing deep inspection on the network traffic and blocking HTTP DELETE messages.
It's possible that the Rails controller action can't delete it but doesn't raise an exception, rather it returns some error code that the JavaScript isn't prepared to handle so it doesn't do anything when the request is returned.
So I have an app that submits a form to an external cart using Javascript (target is blank) then I want the window to navigate to a Rails controller to create a small tracker model, controller as such:
def add_to_cart
#product = Product.find(params[:id])
#product.cart_trackers.create
redirect_to :back
end
And the Javascript (in a link_to, onclick helper):
document.forms['addCart#{product.id}'].submit();
window.location.href=\"/products/add_to_cart/#{product.id}\";
return false;
And this works wonderfully in Firefox and Internet Explorer, but Google Chrome throws a fit about so much navigation. I realize AJAX could be a worthy solution, but due to the environment this app runs under (which is a clustercrap of Prototype, Jquery, iFrames, and includes) I'd like to avoid it if possible. Chrome's response is to actually run the window.location... code and skip the form submitting. Without one or the other lines of code, Chrome will perform the single action just fine.
So, what would be the proper way of writing this out? Or should I give in and just wrangle in some AJAX?
Try using AJAX-but-not-really-AJAX. Submit the form using whatever AJAX submitter you want (e.g., $.ajax), but don't do anything with the response (i.e., no callback). That way the data gets POSTed and maybe the browser won't be upset that you're asking it to visit two urls back-to-back.