I have an ASP.NET page that contains an iframe. Inside that iframe, there is a form with a DefaultFocus and a DefaultButton set, as shown below.
<form id="Form1" method="post" runat="server" defaultfocus="txtSearchPhrase" defaultbutton="btnSearch">
When viewing this page in IE11, all of the content inside of the iframe appears to be shifted off the left side of the screen by about 100px or so. This does not happen in any other browser, including IE10.
If I remove the DefaultButton and DefaultFocus from the form, the problem disappears. I can then use Javascript to manually hookup the default button and focus, but since I have many different pages that are potentially rendered inside the iframe, it's not ideal to have to change each and every one of those pages.
Does anyone know what's causing this or if there's a better way to address it?
I looked into this and found some interesting things.
First, when you include DefaultFocus or DefaultButton on a form in ASP .NET WebForms, ASP .NET will automatically emit two things:
The definition of a WebForm_AutoFocus method.
A call to this method, which looks something like: WebForm_AutoFocus('defaultFocusElementID'); It does this for both DefaultFocus and DefaultButton settings, though I'm not sure why it needs to do this for the DefaultButton setting.
The WebForm_AutoFocus method attempts to call the scrollIntoView method on the element, but only if the browser is detected as a "non MS DOM" browser. Strangely enough, IE11 is not considered an MS DOM browser, at least as far as this method is concerned. So the scrollIntoView method is designed to run on browsers which are not IE.
I suppose one could argue the bug is with the implementation of the scrollIntoView method in IE11, but it could also be viewed as a bug in the MS JS library which detects whether the browser is an MS DOM browser. I'm not sure - either way, I blame Microsoft. :)
I recommend not using DefaultFocus and DefaultButton from a philosophical perspective because these are Microsoft-specific things, and when you can keep your code away from Microsoft-specific things, you usually should. Especially when using the "Microsoft way" is totally broken. Rather, try something like this (if you're using jQuery):
<form data-defaultfocus="search">
<asp:TextBox ID="search" />
</form>
<script type="text/javascript">
// jQuery on document ready
$(function() {
var form = $('form'),
defaultButtonID,
defaultFocusID;
if (form.data('defaultfocus')) {
defaultFocusID = form.data('defaultfocus');
$('#' + defaultFocusID).focus();
}
if (form.data('defaultbutton')) {
defaultButtonID = form.data('defaultbutton');
form.on('keypress', function(event) {
if (event.keyCode === 13) {
__doPostBack(defaultButtonID, '');
}
});
}
});
</script>
This is not tested code, but you get the idea. Then you can go through and use data-defaultbutton and data-defaultfocus on your form elements instead of the Microsofty way of doing it, and it will actually work, and if it doesn't, you can fix it, because you control the code!
I hope this helps.
Update
I found this Microsoft KB article which discusses a .NET 4 patch. Issue 2 on this page appears to address an issue which might be the one you described.
When you access an ASP.NET-based webpage by using Internet Explorer 11, the webpage renders the content incorrectly.
Note This issue occurs because Internet Explorer 11 is not recognized as Internet Explorer by ASP.NET.
I haven't tried it out yet, but it seems like this would fix it.
Related
I cannot seem to get Chrome to pop up an "alert" page. The alert page has code in it, so it can't really be a DIV or I would just do it that way. It worked for many years, but likely do to a Chrome update it will no longer function. Still works fine in IE11, though.
The following code is used to pop up an "alert" page when there is an alert that is queried from a Database. It has always worked until recently (15 years and running)
CODE:
ClientScript.RegisterStartupScript(GetType(Page), "Alarm", "<script language='javascript'>window.showModalDialog('Alarm.aspx?ID=" & AlarmID & "', null, 'dialogWidth=460px;dialogHeight=310px;status=no;resizable=yes');document.frmA.submit();</script>")
I've tried a few things like windows.open and creating a hidden button on the asp.net page and then using the click event. Nothing works. I do not see a blocked popup in Chrome and I have even went into settings and did the following:
Set Safe Browsing to "No Protection"
Set allow pop-ups and redirects on the server name (http://servername and http://localhost)
As noted, near all browsers quite much have clamped down on popup windows. this makes things more difficult for web developers.
There are two good approaches. one I don't fancy at all is using bootstrap dialogs, but they tend to "sort of work all on their own" kind of deal based on class settings for divs etc. - really hard to debug.
Since near all sites these days include jQuery for your js code, then I quite much hands down recommend you introduce jquery.UI. It has a whole slew of nice things such as date pickers etc. But it also has a rather nice dialog pop option. They just work, and when you code them up? They follow "normal" like code approaches.
it not quite clear if your message/dialog pops after say a button click (and post back), and the at the end of that process, you need/want some dialog message to display. But all in all, I would high recommend jQuery.UI for this dialog/message that you need.
jQuery.UI in most cases expects the content you want to "display/pop" exists in a simple div in the current existing page. However, it also works VERY well if you supply the dialog another existing web page. The only REAL big issue to keep in mind? That dialog page you pop cannot handle multiple post-backs. (so, some buttons, or ONE post back in that dialog is fine - but you ONLY get the ONE post-back.
So, if that page display allows some input, or some interaction and ONLY requires ONE post-back, then jQuery.UI is again great. If that pop page requires several buttons and several post-backs, then you are in for a world of pain and hurt - jQuery.UI dialogs (like most) cannot survive or handle multiple postbacks. Any post-back means the dialog closes (collapses). So in those cases, you have to adopt ajax calls (web methods) if you need/have/want that page to have more then one active post-back button or event.
So, you could have/place a script in even your master page, and little function code stub that your register script can call.
Or, I suppose you could inject the whole script, but the script would look like this:
So, the pop page actualy is SHOVED into a div. So we have a div that "holds" the page.
The jQuery.UI code script then looks like this:
<div id="poppagearea">
</div>
<script>
function showpage() {
var mydiv = $('#poppagearea');
mydiv.dialog({
autoOpen: false, modal: true, title: 'My cool other page', width: '30%',
position: { my: 'top', at: 'top+150' },
buttons: {
'ok': function () {
mydiv.dialog('close');
alert('user click ok');
},
'cancel': function () {
mydiv.dialog('close');
alert('user click cancel');
}
}
});
mydiv.load('Default.aspx');
// Open the dialog
mydiv.dialog('open');
}
So, in above, we loaded "default.aspx" into that dialog and thus displayed it on the page.
So, I would consider jQuery.UI - but it does mean adopting a new js library into your existing project.
The pop page does gray out the full page, and you do get a title bar, and your own ok, cancel button. The above thus looks like this:
So, it does a great job - but as noted, that page can only have one post-back, and it can't be a general working aspx page with lots of buttons and post backs - but it will render and display rather well.
I've inherited some code that I need to debug. It isn't working at present. My task is to get it to work. No other requirements have been given to me. No, this isn't homework, this is a maintenance nightmare job.
ASP.Net (Framework 3.5), C#, jQuery 1.4.2. This project makes heavy use of jQuery and AJAX. There is a drop down on a page that, when an item is chosen, is supposed to add that item (it's a user) to an object in the database.
To accomplish this, the previous programmer first, on page load, dynamically loads the entire page through AJAX. To do this, he's got 5 div's, and each one is loaded from a jQuery call to a different full page in the website.
Somehow, the HTML and BODY and all the other stuff is stripped out and the contents of the div are loaded with the content of the aspx page. Which seems incredibly wrong to me since it relies on the browser to magically strip out html, head, body, form tags and merge with the existing html head body form tags.
Also, as the "content" page is returned as a string, the previous programmer has this code running on it before it is appended to the div:
function CleanupResponseText(responseText, uniqueName) {
responseText = responseText.replace("theForm.submit();", "SubmitSubForm(theForm, $(theForm).parent());");
responseText = responseText.replace(new RegExp("theForm", "g"), uniqueName);
responseText = responseText.replace(new RegExp("doPostBack", "g"), "doPostBack" + uniqueName);
return responseText;
}
When the dropdown itself fires it's onchange event, here is the code that gets fired:
function SubmitSubForm(form, container) {
//ShowLoading(container);
$(form).ajaxSubmit( {
url: $(form).attr("action"),
success: function(responseText) {
$(container).html(CleanupResponseText(responseText, form.id));
$("form", container).css("margin-top", "0").css("padding-top", "0");
//HideLoading(container);
}
}
);
}
This blows up in IE, with the message that "Microsoft JScript runtime error: Object doesn't support this property or method" -- which, I think, has to be that $(form).ajaxSubmit method doesn't exist.
What is this code really trying to do? I am so turned around right now that I think my only option is to scrap everything and start over. But I'd rather not do that unless necessary.
Is this code good? Is it working against .Net, and is that why we are having issues?
A google search for
jquery ajax submit
reveals the jQuery Form Plugin. Given that, is that file included on your page where the other code will have access to the method? Does this code work in Firefox and not IE?
Seems like there was too much jQuery fun going on. I completely reworked the entire code block since it was poorly designed in the first place.
I'm implementing a search service called SearchInsideOut.
This search service simply replaces web page results by full web pages (Yes, I used iframe).
The problem I have to deal with is iframe-breaking pages.
The promising solution I found is using onbeforeunload to let users decide whether to stay or leave my site.
But this also creates another annoying behavior.
When users click other links in my site, onbeforeunload will also be triggered.
Fortunately, I could solve this case by placing window.onbeforeunload=null in the onclick event of those links of my site.
Unfortunately, I have no idea how to detect external events like clicking "refresh/back" buttons.
What should I do to solve this difficulty?
All suggestions and comments are highly appreciated.
Take as example this site. Try to refresh the page after u typed some text answering to a post. You will see that the page it will ask you to continue ur work or exit. Make another test without answering to a post, just refresh, you will see that the confirm will not showed, because the site is making a test if the "answer" is empty or not.
Example:
<html>
<head>
<script>
function closeIt()
{
var mytext = document.getElementById("mytext").value;
if(mytext != "")
return "Any string value here forces a dialog box to \n" +
"appear before closing the window.";
}
window.onbeforeunload = closeIt;
</script>
</head>
<body>
<textarea id="mytext"></textarea>
</body>
</html>
So it's up to u to decide when the box will show or not. Visit also Microsoft Msdn to understand when and how onbeforeunload works
I am writing an intranet application and am considering the use of a pop up window. I am not worried about accessibility since it's an intranet app.
The scenario is such as I need to be able to have the same code be used in a server page as well as in the middle of a process; which is why I decided when using it in the middle of the process, it's best to have it as a pop up window to running out of the real estate on the screen.
Any thoughts on this? I am hesitant to use a pop up window in such a manner as I usually only use it for error messages.
I don't completely understand what you're trying to do, but I think a popup window might be somewhat of an issue if the user's browser automatically blocks popup windows. Plus, if you were trying to run a process in the popup window, the user could close it and no longer have a way to check on the process.
Would it be possible to use Ajax to call back to a web service that gives the page information about the process? You could give the user a way to make the Ajax call to check on the status of the process or just have it continually polling in the background.
Edit:
You said you weren't too familiar with Ajax. For the most part, there are libraries to handle all the of hard details. I'll recommend jQuery because that's what I've been using for a while now.
If you go the Ajax route you'll be able to contain everything on one page and make the updates you need to make when the Ajax call is successful. Depending on how you write the code, it should be pretty reusable if you do it right. It really depends on how specific the your needs on each page.
Take a look at the jQuery documentation though. It may have what you need already built into it. Otherwise, someone else might be able to suggest some reasons why their favorite JavaScript library works better for what you're trying to do.
I think you might want to do something like this:
Inside of the parent page:
<input id="btnShowModal" runat="server" type="button" value='Show Modal' onclick="ShowModal()" />
function ShowModal()
{
var retVal = window.showModalDialog("MyPopup.aspx?param1=value","","center=yes;dialogWidth=200px;dialogHeight=200px;status:0;help:0")
if(retVal != "" && retVal != undefined)
{
//This code will be executed when the modal popup is closed, retVal will contain the value assigned to window.returnValue
}
}
Inside of the modal popup:
<input id="btnSave" runat="server" type="button" value='Save' onclick="Save()" />
function Save()
{
window.returnValue = "Whatever you want returned to the parent here"
window.close()
}
The usual argument against popup windows is that they are unreliable. The user may have disabled script initiated popups, I know I have.
In a controlled environment, such as an inranet, you may be able to be guaranteed that this is not the case, but even so, why risk it, there is an alternative.
Instead of popping up a new window just insert a new, absolutely positioned <div> into the document and insert your content into that using ajax or even an <iframe>. There are lots of examples/libraries on the web.
Thickbox for jQuery for example. There are of course scripts that don't require libraries.
I generally use a div with a z-index and absolute positioning; the .show() can be written and called on demand, it would have a button to .close(), and AJAX can make it seem modal so it must be clicked to close if you so desire. Then again, I hate messageboxes.
I was trying to avoid AJAX, simply because I have never used and don't have the time frame to learn it now. However, I am not totally opposed to it.
In short what I need to do is for the pop up window interact back with the page. Imagine that on the page I am building the links of the chain. Each link has unique properties. When user clicks on "ADD LINK" button, I was thinking have a pop up window with the little form and a Save button. The only issue with this is that a pop up needs to interact with the page; we need to know when something has been saved or not saved.
A div on the same page is one way. A pop up is yet another way. Another catch is that this code (adding new link) needs to be reusable, because I am also going to have a page that just creates new links.
I have built a basic data entry application allowing users to browse external content in iframe and enter data quickly from the same page. One of the data variables is the URL.
Ideally I would like to be able to load the iframes current url into a textbox with javascript. I realize now that this is not going to happen due to security issues.
Has anyone done anything on the server side? or know of any .Net browser in browser controls. The ultimate goal is to just give the user an easy method of extracting the url of the page they are viewing in the iframe It doesn't necessarily HAVE to be an iframe, a browser in the browser would be ideal.
Thanks,
Adam
I did some tests in Firefox 3 comparing the value of .src and .documentWindow.location.href in an iframe. (Note: The documentWindow is called contentDocument in Chrome, so instead of .documentWindow.location.href in Chrome it will be .contentDocument.location.href.)
src is always the last URL that was loaded in the iframe without user interaction. I.e., it contains the first value for the URL, or the last value you set up with Javascript from the containing window doing:
document.getElementById("myiframe").src = 'http://www.google.com/';
If the user navigates inside the iframe, you can't anymore access the value of the URL using src. In the previous example, if the user goes away from www.google.com and you do:
alert(document.getElementById("myiframe").src);
You will still get "http://www.google.com".
documentWindow.location.href is only available if the iframe contains a page in the same domain as the containing window, but if it's available it always contains the right value for the URL, even if the user navigates in the iframe.
If you try to access documentWindow.location.href (or anything under documentWindow) and the iframe is in a page that doesn't belong to the domain of the containing window, it will raise an exception:
document.getElementById("myiframe").src = 'http://www.google.com/';
alert(document.getElementById("myiframe").documentWindow.location.href);
Error: Permission denied to get property Location.href
I have not tested any other browser.
Hope it helps!
document.getElementById('iframeID').contentWindow.location.href
You can't access cross-domain iframe location at all.
I use this.
var iframe = parent.document.getElementById("theiframe");
var innerDoc = iframe.contentDocument || iframe.contentWindow.document;
var currentFrame = innerDoc.location.href;
HTA works like a normal windows application.
You write HTML code, and save it as an .hta file.
However, there are, at least, one drawback: The browser can't open an .hta file; it's handled as a normal .exe program. So, if you place a link to an .hta onto your web page, it will open a download dialog, asking of you want to open or save the HTA file. If its not a problem for you, you can click "Open" and it will open a new window (that have no toolbars, so no Back button, neither address bar, neither menubar).
I needed to do something very similar to what you want, but instead of iframes, I used a real frameset.
The main page need to be a .hta file; the other should be a normal .htm page (or .php or whatever).
Here's an example of a HTA page with 2 frames, where the top one have a button and a text field, that contains the second frame URL; the button updates the field:
frameset.hta
<html>
<head>
<title>HTA Example</title>
<HTA:APPLICATION id="frames" border="thin" caption="yes" icon="http://www.google.com/favicon.ico" showintaskbar="yes" singleinstance="no" sysmenu="yes" navigable="yes" contextmenu="no" innerborder="no" scroll="auto" scrollflat="yes" selection="yes" windowstate="normal"></HTA:APPLICATION>
</head>
<frameset rows="60px, *">
<frame src="topo.htm" name="topo" id="topo" application="yes" />
<frame src="http://www.google.com" name="conteudo" id="conteudo" application="yes" />
</frameset>
</html>
There's an HTA:APPLICATION tag that sets some properties to the file; it's good to have, but it isn't a must.
You NEED to place an application="yes" at the frames' tags. It says they belongs to the program too and should have access to all data (if you don't, the frames will still show the error you had before).
topo.htm
<html>
<head>
<title>Topo</title>
<script type="text/javascript">
function copia_url() {
campo.value = parent.conteudo.location;
}
</script>
</head>
<body style="background: lightBlue;" onload="copia_url()">
<input type="button" value="Copiar URL" onclick="copia_url()" />
<input type="text" size="120" id="campo" />
</body>
</html>
You should notice that I didn't used any getElement function to fetch the field; on HTA file, all elements that have an ID becomes instantly an object
I hope this help you, and others that get to this question. It solved my problem, that looks like to be the same as you have.
You can found more information here: http://www.irt.org/articles/js191/index.htm
Enjoy =]
I like your server side idea, even if my proposed implementation of it sounds a little bit ghetto.
You could set the .innerHTML of the iframe to the HTML contents you grab server side. Depending on how you grab this, you will have to pay attention to relative versus absolute paths.
Plus, depending on how the page you are grabbing interacts with other pages, this could totally not work (cookies being set for the page you are grabbing won't work across domains, maybe state is being tracked in Javascript... Lots of reasons this might not work.)
I don't believe that tracking the current state of the page you are trying to mirror is theoretically possible, but I'm not sure. The site could track all sorts of things server side, you won't have access to this state. Imagine the case where on a page load a variable is set to a random value server-side, how would you capture this state?
Do these ideas help with anything?
-Brian J. Stinar-
Does this help?
http://www.quirksmode.org/js/iframe.html
I only tested this in firefox, but if you have something like this:
<iframe name='myframe' id='myframe' src='http://www.google.com'></iframe>
You can get its address by using:
document.getElementById('myframe').src
Not sure if I understood your question correctly but anyways :)
You can use Ra-Ajax and have an iframe wrapped inside e.g. a Window control. Though in general terms I don't encourage people to use iframes (for anything)
Another alternative is to load the HTML on the server and send it directly into the Window as the content of a Label or something. Check out how this Ajax RSS parser is loading the RSS items in the source which can be downloaded here (Open Source - LGPL)
(Disclaimer; I work with Ra-Ajax...)
Ok, so in this application, there is an iframe in which the user is supplied with links or some capacity that allows that iframe to browse to some external site. You are then looking to capture the URL to which the user has browsed.
Something to keep in mind. Since the URL is to an external source, you will be limited in how much you can interact with this iframe via javascript (or an client side access for that matter), this is known as browser cross-domain security, as apparently you have discovered. There are clever work arounds, as presented here Cross-domain, cross-frame Javascript, although I do not think this work around applies in this case.
About all you can access is the location, as you need.
I would suggest making the code presented more resilitant and less error prone. Try browsing the web sometime with IE or FF configured to show javascript errors. You will be surprised just how many javascript errors are thrown, largely because there is a lot of error prone javascript out there, which just continues to proliferate.
This solution assumes that the iframe in question is the same "window" context where you are running the javascript. (Meaning, it is not embedded within another frame or iframe, in which case, the javascript code gets more involved, and you likely need to recursively search through the window hierarchy.)
<iframe name='frmExternal' id='frmExternal' src='http://www.stackoverflow.com'></frame>
<input type='text' id='txtUrl' />
<input type='button' id='btnGetUrl' value='Get URL' onclick='GetIFrameUrl();' />
<script language='javascript' type='text/javascript'>
function GetIFrameUrl()
{
if (!document.getElementById)
{
return;
}
var frm = document.getElementById("frmExternal");
var txt = document.getElementById("txtUrl");
if (frm == null || txt == null)
{
// not great user feedback but slightly better than obnoxious script errors
alert("There was a problem with this page, please refresh.");
return;
}
txt.value = frm.src;
}
</script>
Hope this helps.
You can access the src property of the iframe but that will only give you the initially loaded URL. If the user is navigating around in the iframe via you'll need to use an HTA to solve the security problem.
http://msdn.microsoft.com/en-us/library/ms536474(VS.85).aspx
Check out the link, using an HTA and setting the "application" property of an iframe will allow you to access the document.href property and parse out all of the information you want, including DOM elements and their values if you so choose.