Some users who navigate to my page do so via an url like this : http://domain/ProductDetail.aspx?Productid=123#Pricing
In this section is a asp:button to make a purchase. This button cause a postback, and when the page rerendering in the broswer the FragmentIdentifier #Pricing is still in the address window.
This is causing problems because there is new content rendered on the page which isn't visible if the browser navigates to the #Pricing section.
How do I prevent the FragmentIdentifier on postback?
Clarification:
It appears that this problem happens in Chrome but does not happen in IE8 or FireFox. Chrome holds on to the #FragmentIdentifier after postback even those there is no reference to it in the action attribute.
You can't, browser doesn't send it:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted by the user agent after the
retrieval action has been successfully completed. As such, it is not
part of a URI, but is often used in conjunction with a URI.
How to get Url Hash (#) from server side
Browsers don't send URL fragments on the server side. You can't modify them the only option you can try is URL rewrite, if that helps. good luck...
The ASP.NET engine will cause a simple submit without any given URL, so the browser is forced to take the URL of the current page.
You can get rid of the hash after the postback by hooking a self executing javascript into the HTML that will replace the hash to an empty string.
Here is an example:
if(this.Page.IsPostback)
{
this.Page.ClientScript.RegisterStartupScript(this.GetType(), "RemoveHash", "window.location.hash=''", true);
}
You can force the browser to get rid of the # tag by redirecting to the same page.
Related
Is there a way to only update part of the page and update the query string parameters at the same time without completely refreshing the whole page in ASP.NET?
I only need to update the "main" section of my page and not the whole page. I understand I can do a partial page postback (or use asp ajax) to do the partial page update, but then how do I update the query string parameters in the URL at the same time? Is that even possible?
Or is it not possible and I'll have to just do a Response.Redirect in the code behind of the partial page postback redirecting to the same page with new query params and just let the whole page refresh?
Use pushState.
This new feature offers you a way to change the URL displayed in the browser* through javascript without reloading the page. It will also create a back-button event and you even have a state object you can interact with.
window.history.pushState(“object or string”, “Title”, “/new-url”);
Described here
You have absolutely zero programmatic access to the address bar. The only way to change it is to redirect.
You could, however, do it like some sites do and provide a "send a link to this page to your friends" area. Youtube comes to mind - see how it provides a URL, querystring parameters included, for you to copy, should you wish to send someone a link to a video starting from some specific point.
Also check the handy "Share" link right under your question. You could provide a link like that, with the target URL, so for the user it's just a matter of right-clicking and copying from the context menu. A link well structured into your site is more user friendly than having the user copy directly from the bar, or from a text box. Specially for mobile browsers, where the sequence is usually press-and-hold, then copy. Copying from the address bar, on the other hand, may involve selecting the address bar text, which in some Android devices is a pain in the ass.
My All Js and css are in script.jsp file and include on every page
<jsp:include page="../include/scripts.jsp" />
when page submit / refresh it reload again and again ?
How to control this ?
Here's an explanation I found that could explain it. It helped me out when i needed it
Here's an explanation of the problem...
Clicking the "submit" button on a form sends a request to the web server, which includes all the data entered on the form. Not only the URL but also the form data is part of the request, and this request is remembered by the browser. If the user clicks "refresh", the browser repeats the request, sending the same URL and form data to the web server again.
But forms can be submitted in two different ways, GET or POST, depending on the "method" attribute of the "form" tag. There is a convention that a GET request has no side-effects; it only fetches data but does not make any changes to the database. On the other hand, if a request changes data it should always use a POST request. As I said, these are only conventions, and there is not much technical difference between them, but a very important difference is that browsers will warn the user if they try to repeat a POST -- clicking "refresh" will pop up a dialog box warning the user that this may cause an operation to be repeated, and confirming that they really want to resubmit. The browser does not show this confirmation when refreshing a GET request.
Is your form using the GET method changing it to POST is the simplest solution, since this will at least mean that the user is warned if they try to refresh.
But a better solution is the POST+REDIRECT+GET idiom suggested by #cletus. This splits the database update (POST) and the view (GET) into two operations. Clicking refresh on the browser then merely repeats the GET, which has no side-effects.
Use the include directive <%# include/> as against the <jsp:include/> tag you're using now.
<jsp:include/> will instruct the jsp runtime to go and fetch the included resource everytime the compiler comes across that tag (first-time requests, refreshes) while <# include/> means that the included resource is built into the parent resource at compile-time
The difference is that the directive is a compile-time include. This means that the content of the directive (in your case scripts.jsp) is baked into the parent jsp (and ultimately the servlet that the jsp will be compiled into). The effect is that the included file is read only the first time the parent jsp is rendered.
What you should have:
<%# include page="../include/scripts.jsp" />
Related:
What is the difference between <jsp:include page = ... > and <%# include file = ... >?
I thought you couldn't change the QueryString on the server without a redirect.
But this code works* for me:
Request.QueryString edit
I'm so amazed.
So here are my questions regarding this:
Why is Request.QueryString readonly?
Why does this code/hack work*?
How safe is it, if you change to readonly as soon as you are done editing, both regarding bad errors or unexpected behaviour, and regarding maintaining and understanding the code?
Where in the event cycle would it make most sense to do this crazy edit if you are only using PageLoad and OnPageRender?
*More details:
I have a page with items that are grouped into tabs. Each tab is an asp:LinkButton
I want to be able to link directly to a specific tab. I do that with a QueryString parameter 'tab=tabName'. It works. But when I then click a new tab, the querystring is still in the Url, and thus the tab specified in the Querystring gets activated and not the one I clicked.
By using Request.QueryString edit this does not happen. Then my solution 'works'.
Thanks in advance.
Well the QueryString property is readonly because it cannot be changed on a single request. Obviously the browser sends only one request with only one string so only one collection is created. The hack uses reflection (i.e. manipulates the code and the memory) to change stuff that you cannot change normally. This hack breaks the encapsulation and the design of the QueryString property. You should not use it. It makes no sense from design standpoint. Your query DOES NOT change so why change the object that represents it? Only the browser can send new query string so you are basically lying to your own code about what the browser sent.
If you want the tabs to use the URL just use Hyperlinks instead of LinkButton.
From what I remember reading, this is a security standard that all browsers adhere to. It's main purpose is to stop phishing attacks, where someone could have the website www.MyLameWarcraftPhishingSite.com" and when someone hits the page, rewrite the url to look like www.blizzard.com. The only way to get to that url is to actually redirect to it.
mmm, last post was in Feb 11 - hope its ok to post in this.
Is it possible to determine - server-side - whether a page has been loaded within an IFrame?
When certain errors happen in my application the user gets redirected to Default.aspx and an error message is shown. The text of that error message gets set in session by exception handling code. The error message gets cleared from session once it has been shown.
However, part of my application has to use an IFrame (it's doing a 3D Secure card payment check, which mandates an IFrame in order to display the card provider's authentication UI). If an error takes place during this process my redirect takes effect within the IFrame. I am using JavaScript to detect this and reload Default.aspx correctly, but this means that I get two Page_Loads in rapid succession, and the error message only gets shown on the first one (and then cleared).
You can do it in client side: How to identify if a webpage is being loaded inside an iframe or directly into the browser window?
The workaround i found is put some identifier into querystring of a url opened inside iframe.
I don't think you can detect in the sense of having some sort of Page.IsInIFrame() kind of functionality, but you could consider having different base classes for those pages that are loaded in an IFrame and those that aren't so that you can know the error is from a request that was for an IFrame page that may help to some extent.
There's no way from the server-side. The only way is via javascript. When you do the redirect, can you pass the error message or code via a querystring?
Won't it work to redirect using Javascript with window.location? Forcing a full page redirect?
This is impossible because client can open iframe with javascript disabled. http://caniuse.com/#feat=iframe-sandbox
simply, check the url of current page..
if it's the same with the IFrame page then redirect to Default.aspx or whatever.
Dim urlpath1 As String = HttpContext.Current.Request.Url.AbsoluteUri
If Right(urlpath1, 13) = "WebForm1.aspx" Then
Response.Redirect("~/")
Else
Response.Write("It's OK!")
End If
I have an asp.net application that runs exclusively on IE7 (internal web site).
When a user needs to enter data, I pop up a child window with a form. When the form closes, it calls javascript:window.opener.location.reload(true) so that the new data will display on the main page.
The problem is that the browser complains that it must repost the page. Is there any way to turn this feature off?
No, but there is a solution. Its generally considered good design to use a 302 redirect immediately after someone posts data to a page. This prevents that popup from ever occuring. Allow me to elaborate.
1) The user fills in a form and submits data via POST.
2) The backend receives the data and acts upon it.
3) Instead of returning the content to the user, the backend issues a 302 redirect as soon as its done processing the page (possibly redirecting the user back to the exact same url, if need be)
4) The page that the user will see is the page you told their browser to redirect to. They will load up the redirected page with a standard GET request. If they try to refresh the page, it will not repost the data. Problem solved.
This is a problem with the usual "postback" way of ASP.NET. If you need to reload a page without this warning, this page must come from a GET, not a POST. You could do a Response.Redirect("...") yourself. But this will destroy the use of viewstate.
asp.net mvc fixes this issue, not an ie7 only problem but a security feature of most browsers. No fix that I know of except you could just update the content in the main form with js rather than reloading the whole page
It's because the page in window.opener comes from a POST Request
Maybe you can use
javascript:window.opener.location = window.opener.location; to do just a GET request if the data can be fetched without a POST.
I do not believe that there is a way to do that. Instead, why not direct the parent window to a page without a reload.
javascript:window.opener.location='your url'
AFAIK, not via your scripts.
You might try:
window.opener.location = '#';
It should circumvent the browser reposting. And, you can adjust the hash name as needed.
If you move from page1 to page2, and want to disable the browser from going back to page 1,then add the following at the top of page1.
<script>
if(window.history.forward(1) != null)
window.history.forward(1);
</script>