The __doPostBack is not working in firefox 3 (have not checked 2). Everything is working great in IE 6&7 and it even works in Chrome??
It's a simple asp:LinkButton with an OnClick event
<asp:LinkButton ID="DeleteAllPicturesLinkButton" Enabled="False" OnClientClick="javascript:return confirm('Are you sure you want to delete all pictures? \n This action cannot be undone.');" OnClick="DeletePictureLinkButton_Click" CommandName="DeleteAll" CssClass="button" runat="server">
The javascript confirm is firing so I know the javascript is working, it's specirically the __doPostBack event. There is a lot more going on on the page, just didn't know if it's work it to post the entire page.
I enable the control on the page load event.
Any ideas?
I hope this is the correct way to do this, but I found the answer. I figured I'd put it up here rather then in a stackoverflow "answer"
Seems it had something to do with nesting ajax toolkit UpdatePanel. When I removed the top level panel it was fixed.
Hope this helps if anyone else has the same problem. I still don't know what specifically was causing the problem, but that was the solution for me.
-
Is it because you are doing return confirm? seems like the return statement should prevent the rest of the code from firing. i would think an if statement would work
if (!confirm(...)) { return false; } _doPostBack(...);
Can you post all the js code in the OnClick of the link?
EDIT: aha, forgot that link button emits code like this
<a href="javascript:__doPostBack()" onclick="return confirm()" />
From Darren Kopp -
With or without the OnClientClick event it still doesn't work.
The _doPostBack event is the auto generated javascript that .NET produces.
function __doPostBack(eventTarget, eventArgument) { if (!theForm.onsubmit || (theForm.onsubmit() != false)) { theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); } }
*The &95; are underscores, seems to be a problem with the stackoverflow code block format.
Darren Kopp : no i mean post theFrom Dan Williams -
this might seem elemental, but did you verify that your firefox settings aren't set to interfere with the postback? Sometimes I encounter similar problems due to a odd browser configuration I had from a debugging session.
From Paulj -
Now that i think about it, as noted in my last edit, you want to drop the javascript: in the on client click property. It's not needed, because the onclick event is javascript as it is. try that, see if that works.
From Darren Kopp -
Are you handling the PageLoad event? If so, try the following
if (!isPostBack) { //do something } else if (Request.Form["__EVENTTARGET"].ToLower().IndexOf("myevent") >= 0) { //call appropriate function. }
Check if you are getting a call this way, if so then maybe the event is not wired and nedes to be explicitly called.
From moza -
what do you expect from "Enabled = 'false'" ?
From Jimmy -
I have had problems with firebug on some web forms, something to do with the network analyser can screw with postbacks.
From seanb -
Seems it had something to do with nesting ajax toolkit UpdatePanel. When I removed the top level panel it was fixed.
Hope this helps if anyone else has the same problem.
From Dan Williams -
Check your User Agent string. This same thing happened to me one time and I realized it was because I was testing out some pages as "googlebot". The JavaScript that is generated depends on knowing what the user agent is.
From http://support.mozilla.com/tiki-view_forum_thread.php?locale=tr&comments_parentId=160492&forumId=1:
To reset your user agent string type about:config into the location bar and press enter. This brings up a list of preferences. Enter general.useragent into the filter box, this should show a few preferences (probably 4 of them). If any have the status user set, right-click on the preference and choose Reset
From Terrapin -
I had this exact same issue in a web app I was working on, and I tried solving it for hours.
Eventually, I did a NEW webform, dropped a linkbutton in it, and it worked perfectly!
I then noticed the following issue:
...I switch the order to the following, and it immediately was fixed: ...
IE had no issue either way (that I noticed anyway).
From pearcewg -
I had this same problem (__doPostBack not working) in Firefox- caused a solid hour of wasted time. The problem turned out to be the HTML. If you use HTML like this:
<input type="button" id="yourButton" onclick="doSomethingThenPostBack();" value="Post" />
Where "doSomethingThenPostBack" is just a JavaScript method that calls doPostBack, the form *will not*** post in Firefox. It will PostBack in IE and Chrome. To solve the problem, make sure your HTML is:
<input type="submit" id="yourButton" ...
The key is the type attribute. It must be "submit" in Firefox for __doPostBack to work. Other browsers don't seem to care. Hope this helps anyone else who hits this problem.
From Todd -
Thanks to Todd, for me it was the 'type' value being set to 'button' instead of 'submit' that was the problem. Typical SharePoint code!
From Andrew -
I had a similar issue. It turned out that Akamai was modifying the user-agent string because an setting was being applied that was not needed.
This meant that some .NET controls did not render __doPostBack code properly. This issue has been blogged here.
From DotNetDevster -
@Terrapin: you got this exactly right (for me, anyways).
I was running User Agent Switcher and had inadvertently left the Googlebot 2.1 agent selected.
In Reporting Services 2008 it was causing the iframes that reports are actually rendered in to be about 300x200 px, and in Reporting Services 2008 R2 is was throwing "__doPostBack undefined" errors in the Error Console.
Switching back to the Default User Agent fixed all my issues.
From AlwaysLearning