Currently we're opening a new aspx page with window.open. The window.open is in a javascript function (openNewWindow()) in the current aspx page which is called when an asp.net hyperlink control is clicked.
The links are dynamically created on the page by our framework and so I'd like to avoid changing that functionality.
The problem seems to be that when this new 'child' window is closed, session state is lost. I should mention that session is available in the child window just not in the 'parent' window after the 'child' window is closed.
Funnily enough, it seems that elsewhere in our application, if an open.window call is added to a page by using a ClientScriptManager.RegisterStartupScript call on the codebehind click event of a hyperlink control (rather than it calling a function that is coded in the aspx) session is preserved.
The latter solution would be difficult to implement in the current framework code without a significant change and all the regression testing that would entail.
Anybody got any ideas how to keep the session state alive after the close of the child window.
BTW this is occurring in IE7 and our app is asp.net 2.0 based.
Thanks in advance for your insightful and elegant solutions to this problem! ;o)
IE 7 changed the behavior of new windows. Basically, each window is opened in it's own process. Tabs are still opened in the same process.
This means that each new window will have it's own cookie bag. Which means that the new window does not have the Sesssion_ID cookie automatically assigned. The .Net link control will send the cookies to the new window. However, just opening a new window with straight javascript probably won't do that.
FireFox has been this way for awhile, and Chrome, I believe, has always been this way. IE 6 and previous shared process space, even for multiple windows so everything was shared between the two which caused no end of headaches for debugging sites strictly in IE.
UPDATE
Here's a link that describes the problem in detail. You'll notice that this behavior is somewhat inconsistent. The reason is that sometimes IE 7 decides to open the new window in its own process, and sometimes it opens it in a new one.
There are two real solutions. Either stop relying on session entirely (my first choice, and I have strong technical reasons for this) or you need to switch to a cookie-less session.
I should correct myself (sorry can't edit the original question) and say that the control firing the javascript to do 'window.open' is a link button not a hyperlink.
It happened in my Chrome also.
I solved this by adding:
<link rel="shortcut icon" href="../../img/favicon.ico">
in <head></head> in page which will be opened.
Related
So, I have a ChromiumBrowser inside a Windows Form in VB.net.
That form is atached to the "main" parent of the application. When the From is stripped from its parent, it becomes undocked and can be moved outside of the main form. But the moment the parent is removed, the browser is refreshed and I don't want it to do that.
I implemented IResourceHandler to check what method is being called but now the browser won't work because it doesn't know how to handle anything.
Is there a specific handler where I can intercept that call?
Any info is appreciated.
EDIT: Ok, so after reading #amaitland 's comment I changed the URL that I was using to instead load google, and after undocking the form it looks like it is refreshing, but manages to keep the page where it was.
The weird thing is, the default browser does not behave like this.
So, I've seen this approach on one site (I can't remember it, though) and it works like this:
First, there is a simple page with a simple login form. But when you click the login button of the form, if the validation of user and password is positive and the response from the server is positive as well, a new pop-up window appears (which contains the application written in javascript - ExtJS) and the current tab of the browser (which was the login form page) closes.
In my opinion, this is an excellent approach because the ExtJS is a single page application pattern, powerful enough to run full AJAX, without visible redirects. Plus, the pop-up scenario eliminates the browser page control buttons (back, forward, refresh) and the address bar is read-only.
Now, I'm trying to reproduce this by using the help of ASP.NET as server side scripting language, among ExtJS as the main application. So, the results would be as following:
Login page with a login form - HTML5 + CSS3
Application page (pop-up window) - purely ExtJS
A web service - ServiceStack
The web service exposes the method for login purpose, as well as the other methods, and it always returns JSON responses. A session variable must be set (if the login was successful) before opening the pop-up and closing the window.
And here comes the question:
How can I accomplish this scenario of opening a pop-up and closing the current window/tab if the login was successful? Any help, hints, references, advices, criticism is totally what I'm expecting.
Thank you!
you should be able to close the current window after open another one.
window.open('new window url'); window.close();
I tried this on my box, and it works well on chrome and safari
<input type="button" onClick="window.open('popop.html'); window.close();" value="open" />
Keep away from opening pop-ups if you really don't have to. All modern browsers are set up to prevent you from opening pop-up windows by default.
AFAIK the only 100% scenario to open a new window (with target attribute) is a hyperlink clicked by user.
window.open() and even document.getElementById("hiddenLink").click() are blocked by certain browsers.
Are there any real positives of doing so or is it only a false novelty of that site? The reasons you state are all well with one-window scenario.
In an ASP.NET 3.5 website we are noticing that the back button is not working properly. If the user does several postbacks (say 10 times), and than starts pressing back button - the back button gets disabled before the user gets through all the pages. The site does not use AJAX.net.
I can reproduce the issue on IE 7 and 8 almost always. The problem seems to be with some sort of limit IE has on History Cache for a given tab/instance. In the tests I did the post request to the server are large - around 83k, and the responses are are round 300k. It seems that with these request sizes the history does not hold more than 4 items. The moment I get to the 5 post, the first item i had selected is dropped.
We experienced the same issue. We would load a particular page, and after about 5 seconds, IE8 browser history would get blown away. As a result, history.back() would not work, and IE8 back button would not work. Eventually, we narrowed it down to the large "viewstate" (In our case, the size of the "viewstate" was like 600KB due to "Repeater" control having "viewstate" enabled). When we disabled the "viewstate" on the "Repeater" control, the size came down to about 11KB. Now, both IE8 back button and history.back() work well.
The user has to have gone back to the first page; that's the only way I know of to disable the back button in IE (or any other browser). Did the application open another tab; that could cause confusion on how far the back button will go.
Also, is the user getting prompted, by IE, to reapply changes when they hit the back button? I know that is an issue with ASP.NET sites in general and that could cause problems in the browser with using the back button.
window.location.replace
or
history.forward();
in the head
This is a bug in IE that has manifested in one way or another since (at least) IE6. The bug is in the TravelLog code. It sometimes gets confused.
We have an ASP.NET application that we recently migrated onto a new server with IIS7 and .NET 3.5.
In this new environment, some users that are on IE (6, 7, or 8) are experiencing bizarre intermittent problems with postback not working on ASP.NET buttons. (you click the button and nothing happens)
The issue happens sporadically. Sometimes it works, sometimes it doesn't. For some users the button postback almost never works (but sometimes yes!). To complicate matters there are some pages with asp.net button postbacks that DO always work.
Other pages contain a mix of 'asp buttons' and 'asp link buttons', in which the asp button postbacks often don't work, but the link button postbacks always work.
Javascript is enabled and works. The source DOES contain valid tags.
I actually managed to take View Source snapshots of the same page when it was working and when it was not working and the source was EXACTLY the same!!!
At first I thought it was a problem with IE6, but it's now been reproduced on IE7 on one user's machine.
How would I even BEGIN to tackle this problem?
Any help, ideas, or guidance would be vastly appreciated. I am at the end of my mental rope here.
I know this topic is pretty old, but I found the same problem in my code.
I am using the ComponentArt component library.
In certain circumstances after a postback, buttons with codebehind will no longer execute in IE. I also noticed that buttons with onClientSide clicks would execute their postback when the JS function completes and returns true.
I was able to get all the buttons on the page to submit by adding the following code to my buttons:
OnClientClick="javascript:return true"
Any buttons that are already running a JS function and returning true, should work without issue.
See if this post helps? IE 6 treats buttons a little differently, especially if you have some name conflicts. I could see this being a problem for events if that is the case.
Found the culprit.
It was ComponentArt's 2007 Web.UI components that were being dropped on the page.
Apparently the menu control mixed with the 3.5 framework causes wierd issues with postback not working.
I am writing an ASP.NET 3.5 web app that displays a list of items. I want to be able to display a non-modal popup with details when the user selects an item. I want to be able to display several detail popups simultaneously. (i.e., the user can click an item to see its details, then click another item to get another popup.) Currently I call RegisterStartupScript during postback to write a "window.open(...)" script to the page when it re-renders. The problem, of course, is that this requires a full page postback and refresh.
It occured to me that this might be a perfect use for XMLHttpRequest or AJAX but I don't know how to do it (or whether it's even possible or smart to do this). Can someone show me the way?
I have the AJAX Extensions installed but I'd prefer not to use the AJAX Control Toolkit.
EDIT:
Some clarification: When the user selects an item a custom event is raised. On the server I handle this event and use some server-side logic to construct a URL which I then use with RegisterStartupScript to construct a "window.open(myUrl...)" script. But posting back the whole page to do this seems inefficient and I'd like to know if I can just make a call to a simple server-side function that constructs the url and sends it back without having to roundtrip the entire page.
Creating a popup has very little to do with AJAX, and a lot more to do with JavaScript. See the jQuery dialog library here. You can then use jQuery's AJAX API to do your server dirty work :)
jQuery Dialog UI
--
Bill Konrad
Devtacular - Web Development Tutorials
You can use DHTML Window widget.
It offers many way to display either modal or non modal window.
Also it supports AJAX.
You can use dhtmlwindow for open a new window, or
dhtmlmodal to open a new modal window.
Of course, you can edit it to match your requirement.
Sample:
var insWindow = dhtmlmodal.open("insbox", "iframe","UserMaster.aspx?" + queryStr, "User Master", "width=425px,height=500,center=1,resize=0,scrolling=1", "recal");
Do you really need to open a new window? Opening an absolutely positioned DIV or a new layer on top of the current page in the same window is all the rage these days.
Edit:
I don't think it would limit the number of popups, there is some neat stuff that can be done these days with libraries like jQuery + jQuery UI, you can simply create as many of these DIVs/layers as you need and make them movable, resizable, etc. Only thing that real popups have and these do not is that they do not appear on the tab panel/taskbar.
Yes, you will be limited to the size of the window in which is the main page opened, however, I don't personally see it as a problem since most people surf in a maximized browser window anyways.
Implementation of the oldschool typical popup window is undoubtedly much easier for you, but it also runs into problems with end user popup blockers. Just had that problem # my work, they needed to make a popup during the certificate authentication process for some reason and as soon as Yahoo released a new version their toolbar, it quit working).