Steps to reproduce.
- Create products on site
- Create view of products
- Put the add to cart form out onto the view
- Expose a filter on the view
- Set view to use Ajax
- Using IE9, 8 or 7, open up the view, and adjust the filter, wait for the throbber to stop
- Click "Add to cart"
IE opens up a dialogue: "Do you want to open or save ajax from example.com"
Comments
Comment #1
rszrama commentedI doubt this has anything to do with Commerce; worth a look anyways, but I've never heard of this problem. Did you give the Views queue a search?
Comment #2
tmsimont commentedthe closest i could find was this: #832844: Views update throws an error - IE attempts to download file but it doesn't seem to be the exact issue and the OP never described reproduction steps.
I can only get this kind of reaction using commerce's add to cart form row handler.
I think it has something to do with the way that form submits.
It's only an issue when the view is using Ajax and you apply a filter that will dynamically reload the view results. For now, I've disabled ajax on the view and it works. I don't see this behavior anywhere else in views.
Comment #3
rszrama commentedOk, perhaps a case of dueling form submissions? Using the AJAX behavior, is it resulting in nested FORMs or screwing up the HTML for the Add to Cart form?
Comment #4
tmsimont commentedNo the HTML is fine and the forms aren't nested. It happens only with Ajax reloaded rows on a view that otherwise works fine. Are you able to reproduce? I downloaded a clean install and ran through the steps and was able to get the exact issue.
Could it be related to the headers on the form Ajax callback? How is that Add to Cart form returning data? Is there any way it could be outputting whitespace or something before the header is set?
It could also be related to charset?
http://stackoverflow.com/questions/6114360/stupid-ie-prompts-to-open-or-...
http://stackoverflow.com/questions/2483771/how-can-i-convince-ie-to-simp...
Comment #5
jptarantoIm getting this same problem when adding new files & even when using multiple values for fields...
Comment #6
jptarantoTurned out to be caused by Tiny MCE! Changing to CKeditor fixed it.
Comment #7
tmsimont commentedI wasn't using Tiny MCE, and wasn't "adding new files" or using multiple values for fields. My issue was specific to the Commerce "add to cart" button that loads after a Views AJAX filter is applied... I just disabled AJAX for now.
Comment #8
efes commentedI'm so sorry that this problem was wiped out so rudely. This is a "common" problem on AJAX-based Views and "Add to cart" button, but the developers do not intend to deal with it.
If you try a different browser, you won't get the file download dialog, instead a JSON AJAX output will be displayed. IE could not able to handle it.
I've posted a bug report with the exact steps to reproduce the error:
https://drupal.org/node/2185239
I hope, someone will handle this...
Comment #9
rszrama commentedeFeS, my comments above were not delivered to be rude, and I hope you read my reply to your other issue in light of that. We cannot solve everything in Commerce itself, and sometimes the way other modules are designed results in an incompatibility. With limited project development and maintenance resources, I have to prioritize fixing issues somehow, and in this case it still appears that this is an incompatibility, not a bug in Commerce, and therefore not something I can easily address.
Comment #10
efes commentedPlease, don't get me wrong: there is a very good functionality, AJAX, in Views, which dedicated to ease page handling and work with big "data sheets" on web pages. It is definitely user friendly, modern, etc. way of handling form submissions with lots of data and "behind the scenes" logic. I suppose, it is a must on an ecommerce site, and I was totally busted, when realized, that there are no legitimate solutions to handle this.
I do not know, wether is this a Commerce incompatibilty OR an AJAX enabled Views "feature", impossible to program, or could be resolved, but needs too many working hours.
I only found suggestions - like in this thread - which was seamed to me at first, that only tried to avoid to deal with the problem, not to resolve it. Once the clear steps needed to deal with this issue. Well, the steps were provided...and nothing changed.
I know, there are nobody who has unlimited time and resource to fix everything and deal with every aspect of problems with a sophisticated contrib modul, like Commerce is. But I think, it should be better, if there will be no misleading with like-to-be suggestions and requirements, but a clear state at first, that this is a feature/incompatibility/bug OF Views/Commerce and will not be resolved.
If I could found answer like this at first, I hadn't written my comment...
Comment #11
rszrama commentedI'm sorry we never got to this issue, but after 5 years and multiple successive IE releases, I'm going to mark this "won't fix" without clear steps to reproduce / debug the problem. (I don't even have access to IE9 to test.)