CODEWITHSUNDEEP
response.redirect
nikivancic
nikivancic

Reputation: 188

response.redirect to a new browser tab

There are several discussions on this topic (the closest one might be at Redirecting new tab on button click.(Response.Redirect) in asp.net C#), but none fit my need. Here is my situation:

The code <asp:ImageButton ID="SearchButton"
runat="server" OnClick="SearchButton_Click" OnClientClick="target='_blank';"/>

allows me to handle the event in the "code behind" (to process the URL for this redirection) and if this markup is in a "regular" .aspx page and the event handler SearchButton_Click in the code behind all is fine.

My situation differs from this in that this code resides in an .ascx (User Control) element, which is dynamically loaded on the "top level" page. This same code results with the current page being replaced with this "search page" and cannot even use the browser's Back button to return to the original context.

Please note that I would prefer to handle this in C# as

protected void SearchButton_Click(object sender, EventArgs e)
{
    string what = queryText.Text;
    Response.Redirect(baseUrl + what);
}

Every advice appreciated.

Upvotes: 2

Views: 36528

Answers (3)

Steve Gray
Steve Gray

Reputation: 127

Or, you could do this:

Protected Sub Button2_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button2.Click
Dim url As String = "Page2.aspx"
Dim sb As New StringBuilder()
sb.Append("<script type = 'text/javascript'>")
sb.Append("window.open('")
sb.Append(url)
sb.Append("');")
sb.Append("</script>")
ClientScript.RegisterStartupScript(Me.GetType(), _
          "script", sb.ToString())

End Sub

Upvotes: 0

Steve
Steve

Reputation: 5545

If you think out of the box, there is always a way to solve this.

Look at this SO post. response-redirect-to-new-window. I went with the Extention Method way it it works. Yes, if they disable javascript, it does not, but who does that? Not your normal person and they are likely used to issues with not enabling javascript.

Upvotes: 0

Dai
Dai

Reputation: 155708

Your question is a bit involved, I'll explain some backstory:

Tabs and Windows, and why you shouldn't make any assumptions or demands of the browser

Traditionally hyperlinks (e.g. <a href="foo">) opened links in the same window viewport as the originating document. This is convention and is what users expect when they click on a link. Unless you know exactly what the user expects you should never cause a link to open up in a new window, tab, or in-document iframe popup or Ajax dialog.

Prior to the advent of tabbed browsers, hyperlinks with target="_blank" would cause them to open in new windows. In recent years, tabbed browsers prevent taskbar spam by opening them in new tabs - but this is a user preference. Browser tabs are not exposed to the browser through any public API, so your application will never know if a target="_blank" opens in a new window, a new tab, or even the same window viewport (unless you monitor window events in client-script).

I'm of the opinion that applications should never surprise the user, and that the user will always expect a link to open something in the same window.

When XHTML1.x was released, they removed the target attribute entirely because it was originally intended for frames (which were also removed in XHTML), because the committee felt that the _blank feature was being abused, and because XHTML can be rendered on a variety of devices that might not support multiple windows (think: 2005-era featurephones with terrible web browsers).

...unfortunately they brought it back in HTML5, oh well. I guess it does have some legitimate uses, but anyway.

ASP.NET Web Forms Events (e.g. _Click)

(This is why I ditched Web Forms for MVC, I strongly suggest you do the same).

ASP.NET Web Forms emulates WinForms by wrapping the entire page in a <form> element, then adding client-script to all of the control elements, such as <asp:Hyperlink> and <asp:Button> which causes the entire <form> to submit a POST back to the server, which re-creates the form and, during processing, raises these events. This is a particularly ingenious, if misguided, design. Fortunately it has been made obsolete by MVC, but I digress.

...it means that when you have <asp:Hyperlink> with a _Click handler in the server code it means that you're getting <a onclick="__doPostback()"> instead of <a href="URL to redirect to" />, so it provides a very poor user-experience, makes things brittle (as data not within the <form> element is not saved), and means you can run into problems like these where it's unclear (from a client-side perspective) where logic is being carried out: logically a link should be executed by the client, not the server.

Response.Redirect

Response.Redirect is a shortcut of sending a HTTP 3xx redirect to the client and ending further processing of the page. It sends this redirection back instead of the complete page response. A HTTP redirection can only tell the browser to follow it to the new location, there are no other options it can specify.

Conclusion

Piece these things together and you see that there is no way <asp:Hyperlink onclick="delegate() { Response.Redirect("someUrl") }" /> can cause someUrl to be loaded in a new browser tab.

I suggest that instead you use straightforward <a href="someUrl" /> without using any server-side logic. I can't see why you even need to at all in this case.

Upvotes: 8

Related Questions