Strange IE7 behavior with JavaScript window.open() - asp.net

The following code was known to be working three weeks ago. In the interim we have installed IE 7 and a bunch of security patches. The ultimate question will be, does anyone know how to restore the old behavior?
Scenario
We have the following JavaScript code in web page 1 (let's call it foo.aspx), that is invoked on a button click:
window.open("http://Foo/App2/bar.aspx, "_blank", "titlebar,status,width=650,height=600");
The second web page (bar.aspx) is then supposed to open on top of foo.aspx. The user does some stuff, and when they click a button bar.aspx writes some values from bar.aspx back into fields on foo.aspx using JavaScript via window.opener.document, addressing each element individually and modifying its innerText. Then the user closes bar.aspx and there's foo.aspx where they left it, except now it has the values from bar.aspx in certain fields, and the user goes happily on their way using foo.aspx. This has been working for over two years.
During the last two weeks we've applied a bunch of security patches and upgraded to IE 7. Now the behavior is this:
If I am testing and simply navigate to foo.aspx directly, then upon clicking the button bar.aspx opens and then suddenly the focus switches back to foo.aspx with a popup dialog with "The webpage you are viewing is trying to close the window. Do you want to close this window? " If I choose "No", then foo.aspx stays alive, I have to Alt-Tab to get back to bar.aspx, and after that everything works as before. However, this is going to be a pain for the users. Note: NOWHERE IN foo.aspx NOR bar.aspx IS THERE A CALL TO THE close() METHOD!!! So I don't understand why the popup says what it says.
If I access foo.aspx via the application, which means it has been opened programmatically and not explicitly by the user, then bar.aspx opens and you can see foo.aspx disappear (close) behind it. Then bar.aspx gets JavaScript errors because the window.opener is no longer available.
Secenario #1 is non-optimal but at least would be a valid work around (if somewhat of a user training issue to train them to hit "No" and then Alt-Tab, where before none of this was happening. Scenario #2 is non-optimal in the extreme, given that the whole purpose of bar.aspx is to write those values back to foo.aspx.
Other things to note
Now that we've installed IE 7 and the subsequent Active Directory policy changes, the behavior is happening as described even on IE 6.
Both foo.aspx and bar.aspx run on the web server, on the same web site, but in different virtual directories. These are internal application accessible only from inside our network by authenticated users.
Having the server in Intranet zone (where it normally is) or in Trusted Sites makes no difference. I can see no settings in either Zone nor in Advanced Settings that would apply to this behavior, and both the Intranet and Trusted Sites zones are set to be extremely liberal in their policies, especially around script behavior.
I can make any changes I need to in bar.aspx and its client-side scripts, but am limited to only being able to change the button click JavaScript code in foo.aspx (that page is supplied by a vendor, whereas bar.aspx is internally developed).
I reiterate that other than the updates through window.opener.document, foo.aspx is not touched by bar.aspx, and certainly there is no attempt to invoke close() on it.
So, the question remains what in IE 7, or more likely in a security patch, would have broken this? We have a sister shop that is running the same code on IE 7 and they have not reported this issue. So it seems like it has to be something environmental, and right now I keep thinking it must be a patch that got applied. I would take a KB article, IE setting, registry hack, JavaScript change or anything else to fix this.
Thanks for any and all suggestions.

it might be a typo but there's a missing " after the bar.aspx in the sample code.

Opening a window programatically and setting the name to _blank, why are you doing that?
I'm not saying that has anything to do with your issue, but it's probably not a good idea.

It is odd, first thing I would do is fix up a couple strange things in the code so far.
Use an absolute path such as "/App2/bar.aspx" without the protocol or server name since the apps are on the same server.
You can't actually control the titlebar or status bar outside the intranet zone so remove those values from the options list.

Is the pop up blocker closing the pop up window?

Related

IOS 15 select listitem disappearing on bookmarked website

Alright so in the link below someone already described my issue that I am encountering.
https://developer.apple.com/forums/thread/699982
Basically means that on bookmarked pages on IOS 15, if you minimize the window. dropdownsoptions will become invisible.
now my client luckily accepts that is something I can not solve. But I was wondering if there are workarounds besides telling the users to close their bookmark after using the webapp. like is there a way to hard refresh the browser in such way after minimizing so the users don't have to close the webapp every time?

Links inside of a Xamarin.Forms/Xamarin.Android WebView won't work

I have a Xamarin.Forms app that opens locally saved HTML files which contain relative link to each other (think an old HTML offline docs) in a WebView. Everything functioned in Android 10, but now I needed to make a custom renderer in Xamarin.Android due to the new Android 11 changes needing AllowFileAccess (I have all accesses currently on for testing until I get this problem fixed) in the WebSettings. The WebView's OnElementChange sets all the Control's settings, sets the WebClient (which has a ShouldOverrideUrlLoading set to handle particular filetypes like PDF), and then loads the URL. The first page loads fine, but none of the links operate (this testing page has a few links to other HTML pages and some to PDFs). Click on the highlights them as normal, but nothing opens.
No breakpoints in the WebClient's ShouldOverride are hit and neither are any in the Android WebView's OnElementChanged when I click a link. The output window registers the touch, but doesn't do anything more. I feel like this is some kind of communication problem between Xamarin.Forms WebView and Xamarin.Android WebView (possibly even the Xamarin.Android's WebView not being up to date with Android's WebView), but I do not know where to look. Has anyone run into a similar situation and have a fix to get the links functioning again?
Thanks.
After much blood, sweat, and tears, mostly tears, I found the solution.
First off, WebView doesn't tell you directly, but anything that targets a new window (IE _blank and potentially others) will not hit your WebViewClient's ShouldOverrideUrlLoading method and instead hit your WebViewChromeClient's OnCreateWindow method. So you need to handle loading through that one as well as through your WebViewClient.
Second, links will not always work because of Safe Browsing in the WebView. Again, Google doesn't specifically say it can cause issues with urls, but it works against outside urls (which in a file is potentially every url). I had to turn it off, which you can find instructions at developer.android.com/guide/webapps/managing-webview, and I was able to navigate just fine. I feel you will want to set up safeguards to prevent people from abusing your app (like having a WebView that is for your stuff with Safe Browsing off and another for all others, or blocking any sites that aren't yours) since cybersecurity is always a thing.
Lastly, I found IFrames won't load properly if you manually load the page in the view passed to WebViewClient's ShouldOverrideUrlLoading. The sizing goes all off in my docs, which leads me to believe the elves in the background do something special if you return false and the WebView handles it. I found I needed to handle all my other cases (IE pdfs, images, etc) and then return false from ShouldOverrideUrlLoading if it is my iframe htmls.
As a note, because I had forgotten this having worked on Windows for so long, remember that Android's base file system is case sensitive, which makes links case sensitive. You need to either makes sure all your casing is correct in your files or have them on a FAT file system SD card if you want them to be insensitive.

Flex - invisible text until mouse pointer moves outside textInput

We have an application running flex sdk 4.5 and have recently encountered an issue with textInput fields which we have not been able to reproduce on our end for the better part of a month now.
Here are the symptoms:
Users opens an input form which contains several input fields (combo boxes, calendars, text inputs, etc)
User clicks inside a text field
Users types (obviously!)
** Nothing appears in the text input - we have validators on some of these fields and they do kick in properly (ie. user sees red box around textInput disappearing)
User moves cursor outside of text input field and text appears
Give or take, this is the test case we've been provided. We have been unable to reproduce this and I'm reaching out to see if anybody has heard of issues like this in the past.
They are running our flex application in the following environment:
Windows XP SP3
IE 7.0.5730.13 (locale = en-gb)
Flash Player 10.3.181.14
Upgrading either of these components is not an option. Installing the flash player debugger is not an option either.
Now we've setup a pc exactly the same way as they have on their end and still haven't reproduced. So we're really stuck at this point :)
Any suggestion is greatly appreciated. I'll provide any additional info needed.
-Marc
Feb. 2nd 2012 - Update
As I noted in my comment reply to shaun, it seems our customer was more or less precise in their description of the issue. We ran a webex session with them this morning and actually saw the issues first hand.
Here's what happens:
- User loads our application via its url
- User is able to input data and pretty much do any function for a 'random' time period
- All of a sudden, the issues start (there are more symptoms than just the one I originally mentioned):
1. Users type in text input fields and they won't see the text appear until they move the cursor out of / into any other component (could be entering an hbox, exiting a text input field, etc)
2. Combo boxes behave more or less the same. They can drop them down, but then the mouse wheel no longer refreshes the list. It actually scrolls in the background, but until the user moves the mouse, the list does not refresh
3. We also communicate between the server and client via an amf channel. The events make it to the client, but again, they won't see the screen refresh until they move their cursor.
So basically, the application still seems to work, but the screen is no longer refreshing. Could it be something to do with an invalidate / update of the display list that doesn't kick in? We'd like to get them to install the debugger version of FP, but that doesn't seem to be an option.
Another thing to keep in mind: they have a VERY bad internet connection. They average around 1-1.5mbps (megabits) which is enough for our app, but I just thought I'd let you know.
We learned that they also use a Citrix presentation layer to deploy IE 7 to the end users. We've received confirmation from the end user that even if they launch IE on their workstation (not through citrix), they get the issue also.
Another note is that we've seen no errors in our web server, jboss or application logs...
So that's the update I've got... anyone have more thoughts on this? We've more or less discarded the fonts being an issue at this point since the issue affects more than just 'fonts'. Is everything on the screen not updating anymore.

I don't want to display back and forward button in my browser. Is there any solution apart from popup trick?

customers does not want to allow user to use back or forward button. Just a clean page without commandbar and toolbar, same for FF an IE.
Disabling them is not an option as now.
You cannot change that kind of thing in a existing window -- the only way you can make those disappear is by opening a popup, specifying they should not appear in that popup when it's being opened.
Still, note that you should not try to disable those buttons nor have them disappear : your application should work fine with them, handle their actions -- after all, it's one of the few things users have understood in browsers...
And as a user, this is disturbing and annoying :
I don't like popup windows -- and I'm not the only one who doesn't
I don't like when a website tryies to take control over my browser
It will not always work anyway.
And, as a sidenote : even if the back/forward buttons are not displayed, users can still use Ctrl+left/right or some kind of equivalent !
I know this is not easy, but a part of your work as a web-developper is to explain your clients how Internet and web-applications work... not the same way as desktop applications !
If you can force your users into IE (can't believe I'm suggesting use of IE!) you can do this trick. Try running this from the command line
"C:\Program Files\Internet Explorer\iexplore.exe" -k
This will force IE into kiosk (or full screen mode), similar to pressing F11 when in a usual browser session.
PS. I agree with the other answers suggesting this should be discouraged but there are instances (such as when the end user really can't be trusted) that this is a good solution.
No, there's no other way.
However, this is extremely annoying behavior and should be greatly discouraged. This isn't a code issue to solve...this is behavior that shouldn't be implemented at all.
My opinion here, you have a client problem not a code problem. Whatever standard is the expectation, and the user has the expectation of having their back/forward buttons, break that and you break their experience.
Ever see a Windows application that removes the taskbar? That's the equivalent...
I don't think there is a reasonable way to disable the behavior. You may get rid of the buttons in various ways, but the behavior is still there (through keyboard commands, popup menus and so on).
The only reasonable way is to make your web application follow web semantics, and make the client realize this.
many web based ERP (for example) does not tolerate people using navigation buttons. BUT these web applications handle the fact people use these buttons and do not crash. That's what you should do. If each time people use the back button, they get an error message, they will quickly stop using it.
The solution that used to work in IE was adding a startup script with one line:
location.forward();

browser, navigation issues

This is basically a continuation of a question of mine from yesterday,
"Foregoing intialization on a page"
(And btw, kudos to all who give selflessly in this forum to help others - need to do more of that myself.)
So anyway, I was told about HistoryManager, BrowserManager and SharedObject, and so quickly ascertained that its no problem to store a few data items in a shared object so a flex page restores the previous configuration when the browser navigates back to it.
But my real concern would be speed of loading. Its a 15mb page and it only takes 2 seconds to load, but that's still not instantaneous. If it were in a tabbed browser and I just clicked on another tab containing my page, my page would then appear instantaneously. Is there any way to achieve that behavior when my page is navigated back to (via the browser back button for example.) Would that mean that the entire 15mb flex web page would have to be stored in memory.
Thanks.
Here's what I'm thinking, you're going the wrong way about this,(unless I missed the boad on what you want to acheive) what you need to do is work with javascript to interact with the browsers url. Thjis is assuming that you want to be able to go back on a page without reloading content.
Basicaly a java script would override the reloading, and when you hit back, the page doesn't reload, but the javascript notifies the flash what change in has occurred.
Have a look at the gaya framework for how they do it
or lookat http://www.robertpenner.com/experiments/backbutton/backbutton.html

Resources