I am working locally on an ASP.NET site and am experiencing problems with postbacks in IE8.
I have a page with a repeater that builds a table and each row has a LinkButton on it that is used to delete that row.
In FireFox and Chrome, the button works as expected - the forms posts back and all the values from the form are available for processing. In IE8, the form posts back but the forms collection is empty, except for the button that initiated the postback.
This is a problem because
it's odd and I don't understand and
I use the values from the posted back form to rebuild some business objects (I don't store them in viewstate or session but rebuild them from scratch based upon values input by user in form). When I post back from FF/Chrome, the full form is there (e.g. Request.Form.AllKeys has, say, 60 items) and I can derive the values for my business object. When I post back from IE, my form is practically empty and my rebuilding code fails (e.g. Request.Form.AllKeys has, say, only 9 items instead of the expected 60).
I am at a loss to explain why there is this difference in the contents of the form collection upon postback between FF/Chrome and IE and would greatly appreciate any insight/help in this regard.
I've tried to break the issue down as I see it - if any further info is required, please let me know. Thanks for your help.
Your problem sounds unusual and is not something I've ever come across. Whilst I can't help directly, I'd recommend using Fiddler - Web Debugging Proxy to examine the HTTP traffic as a means to diagnosing what is going on. To quote, "Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more..."
Solved this - turns out I had a form nested within the main form on my master page. Removed it and all is well.
We had similar problem in IE8 in Windows 2008 and the solution was related to User Right escalations.
On Windows 2008 Machine I had to go to:
Start > administrative Tools > Local Security Policy > Local Policies > Security Option
then select "User Account Control : Admin Approval Mode for Build-in Administrator account"
Select Enable & then Apply.
Thanks
Anugrah
Related
I have a search page published in a cms that locates database driven pages hosted in but not managed by the cms.
The search form consists of a number of different buttons and dropdowns. It works with a postback.
In the results listing, there are links to the resulting pages.
Is it possible (without changing from postback to a GET form) to make the back button work in IE such that I can click one of the result items and then get back to the result listing?
Currently when I click back I get the "Web page has expired".
Is it possible to do something smart with headers or redirects? I want to be able to history back to the search result in IE 8 and 9.
No, you will need to follow a POST-REDIRECT-GET pattern instead.
See:
http://en.wikipedia.org/wiki/Post/Redirect/Get
http://blog.simonlovely.com/archive/2008/11/26/post-redirect-get-pattern-in-mvc.aspx (shameless plug for implementing in MS MVC framework)
I'm bulding an ASP.NET website just to test my skills, and I'm using lots of callbacks that doesn't require a page refresh, and the URL doesn't change. In this example, assume I'm bulding a web-based Outlook with a treeview, a grid, and a detail pane.
Is there a standard (published or assumed) that says I should postback, or even update my URL from time to time?
The Standard you are probably looking for is called usability. DHTML, Ajax, or whatever you want to call it is fine until it breaks the users expectation of browser behavior. When the back button fails to work, and users can't bookmark the page exactly as they expect, you're doing it wrong.
I don't know about an official standard, but you may want to check out Gmail to see a good example of how something similar was done. The URL changes on the site much more often than the page refreshes.
I have a web application that I use Login Control and ASP.net membership for Sign in process.
my application work propebly untill last week I upload new version, in this version I didnt change the login UC and just the main page ( default page after user logged in ) changed.
but some users report me they cant login and redirect to Login page.
some note:
1- this problem occure just in IE browser
2- users that report this problem can login to old version
I add a log procedure and see users redirected becuase of this code
if (!this.User.Identity.IsAuthenticated)
{
Response.Redirect("~/Secure/Signin.aspx");
}
I checked and see this.User.Identity.Name was empty or null.
What setting maybe changed?
Thanks
I've seen a similar thing happen when there was a malformed FORM tag was rendered inside my ASP.Net Server FORM tag. By 'malformed' I mean that it was missing the required METHOD attribute.
It is my understanding that the HTML spec doesn't support nested FORM tags, so different browsers handle them differently. In my case, I saw a similar issue as you describe, with no issues in Firefox, and major issues in IE.
Check to ensure there are no Nested FORM tags on your page. Also check all FORM tags to ensure they have all required attributes.
Doubt this will solve the problem, it's kind of tangental. But, rather than hand coding the redirect url it's poosible to use
FormsAuthentication.RedirectToLoginPage()
which has the benefit of taking care of the returnUrl and stuff. It'd require the login Url set in the web.config.
We're developing a web shop, and process payments with a third party UI.
We have chosen to show the payment UI inside an iframe inside out check-out page, even though (we now realize), the payment solution provider recommend using a top-level window.
Now what happens is that in IE7/IE8, the payment UI loses session state on the first postback (inside the iframe), while in Firefox, it works just fine. We observe that the payment UI is developed using ASP.NET.
I was under the impression that as far as the server is concerned, there is no difference between being referenced from an iframe versus from a top-level window, but clearly there is.
Does anyone have a clue? What does an iframe do that could possibly make a difference to the payment server, causing it to lose session state?
Could it (it suddenly dawns on me) be differences in cookie handling? Stricter security perhaps?
Probably caused by this:
Internet Explorer 6 introduced support for the Platform for Privacy Preferences (P3P) Project. The P3P standard notes that if a FRAMESET or a parent window references another site inside a FRAME or inside a child window, the child site is considered third party content. Internet Explorer, which uses the default privacy setting of Medium, silently rejects cookies sent from third party sites.
http://support.microsoft.com/kb/323752/en-us
I once heard someone say that an IFrame is actually a new instance of IE, but apparently it's a bit more complicated.
You might find this article by Milan Negovan helpful to explain why framed pages get a separate Session ID. The article also talks about the P3P solution mentioned by Gerrie Schenck above.
so the structure of your code/site would be something like:
Site A has Page 1 has an iframe which displays Site B
the iframe updates and now displays Page 2 from Site A
and when you right-click on the contents of the iframe you can verify that the url is corresponding to Site A?
If you debug, does Page 2 fire off your breakpoints as expected?
Sometimes Microsoft does something so stunningly dumb that it makes my head hurt. Help me find out it's really not the case ... please!
I've got an issue with the login page of an ASP.NET (3.5) site I'm developing whereby IE (7 or 8 ... can't bear to open 6) doesn't offer to save the password when a user logs in. I've checked other browsers and Firefox, Chrome and Safari all offer to save the password just fine. I've also confirmed that IE password saving on my test boxes is is working OK on other sites and for e.g. Google etc it works fine.
The searching I've done has turned up very little, but what little it did turn up seems to suggest that IE won't offer to save a password if the form on the page contains more than two text controls. That's the case with my form which also has controls to allow a user to register. And when I remove these additional controls, IE magically prompts to save password, so this does seem to be true.
Now ... if ASP.NET would allow me to have multiple forms, all would be well and I would be able to separate out the two functions into standalone forms and IE would prompt to save passwords. But, ASP.NET doesn't allow me to do this as it only allows a single form. I could fudge a non runat=server form in there and try to do this, but guess what? Because my page uses a MasterPage, any form tag I add is automatically stripped out, even if it's a non runat=server form.
So, I don't see any way around this without fundamentally changing what I was trying to achieve. It looks like I have to explain to my users that they won't be prompted to have their passwords saved if they use IE (a Microsoft product) because I developed my site with ASP.NET (err ... a Microsoft product).
If this is so, I just can't get over how head-smackingly ridiculous this is. If anyone can offer any ideas on how to get around it, can tell me I've got it all wrong and am a big, stupid idiot myself, or just wants to confirm that it's not just me that thinks this is monumentously dumb, then please, please do so.
Just for the record, I really don't want to (and don't see why I should have to) compromise my design and split my pages in two (which will result in a worse experience for the user).
#Chris That's what I went for in the end.
So for the benefit of anyone else, I still have my activation controls in a runat=server form and process these in the code for that page. Then I have a second, standard HTML form with HTML input textfields that posts to a different .NET page. This deals with the users login. I pick up the values in this page via Request.Form and deal with the login from here.
Upsides:
It all works and users get their logins remembered as they would expect to.
Downsides:
I lost the ability to use a MasterPage (as I need two forms in the page) so I effectively have had to duplicate the template - I don't like this much.
If the users login is invalid or causes some kind of error, I have to redirect to the initial page and pass it a flag to get it to show a relevant error message - I don't like this much either.
Like I say, though, it just works and in this case that's what was most important. Thanks for your input.