I'd like confirmation, should I be able to set onebeforeunload on an opened window in IE11.
Edit: some extra info
The page opening the window is located on a page such as
https://subsub.sub.company.tld/someapp/#/somepage
The window is opening an url like
https://subsub.sub.company.tld/someService/SomeIdentifier?timestamp=214124
As far as I am aware this should be fine?
var pop = window.open("url-on-same-domain");
pop.addEventListener("beforeunload", function() {
//something here
}):
Currently I can't add this listener due to Permissions (as far as I know this shouldn't be an issue on a same-domain environment). It does however have a unverified SSL connection e.g. defect certificate due to dev env.
Error: Permission denied
... some stack which goes back to pop.addEventListener
I also tried setting pop.onbeforeunload = function(){} but this is being ignored.
Anyone who can fill me in on this? We also have an issue on our test environment which is on localhost where attaching the evenListener won't work on IE and Edge.
My problem was caused by the popup opening a PDF File. In IE there is never access to Files opened in a window.
We worked around this by wrapping the file in an iFrame, which might sound nasty, but we needed to be able to display custom messages sometimes so it was OK for us as no other solution was workable.
Related
Apologies that this is a long question, I wanted to make sure it was clear what the problem is and, just as importantly, what it isn't - because I know there are a lot of questions that seem related but they don't seem to be about quite the same issue:
The web application we're developing at work needs to open a URL in a new tab when the user presses a particular button, after an API request has completed. The URL in question happens to open a PDF document.
We're aware of the issue with popup blockers, so are opening a blank tab straight away when the button is pressed, then setting the location to the URL a short time later after the API request completes. And this is working fine on desktop browsers as well as on Safari on iPad.
But there is a peculiar problem with Chrome on Android - at least we have observed the problem on Galaxy tablet versions 6 and 7. I'm aware that for some reason Chrome on Android does not have a built-in PDF viewer - however, it seems that accessing the PDF should trigger the OS to ask the user which app they want to use to view the PDF, and we are OK with that. What we do not want - but what is happening at the moment - is the PDF simply getting downloaded in the background, and the user not being given the option of viewing it directly.
From my research on how browsers handle PDFs, it seems this behaviour is dependent on various response headers - notably Content-Type and Content-Disposition. But we are doing this correctly as far as I know - the Content-Type is application/pdf and there is no Content-Disposition header so it should default to "inline", ie opening up to view rather than downloading. And I have tried adjusting the backend to send this header explicitly, both with and without a filename parameter - with no change in observed behaviour.
I strongly suspect this is a bug with Chrome and/or Android, but I cannot find it clearly reported anywhere. The key thing is that there is a delay in setting the URL - because if I put this directly into the console (which I can do when running browserstack from my desktop; not sure if there's any way to input it into a real device directly):
function test1() {
window.open("url/for/my/pdf");
}
this works fine (the device prompts you with a choice of how to open the PDF)
but not with either
function test2() {
const newTab = window.open();
setTimeout(() => {
newTab.location = "url/for/my/pdf";
}, 1000);
}
or even with this, non-asynchronous, version:
function test3() {
const newTab = window.open();
newTab.location = "url/for/my/pdf";
}
Both test2 and test3 above, when called from the console, result in the PDF being downloaded rather than viewed. And this isn't specific to our endpoints - I've tested it with URLs to various random PDF documents I've found online, and the same behaviour occurs.
So my questions are:
is this a known bug with Chrome or Android?
whatever the answer to 1) above, is there any straightforward workaround which will ensure the user is always prompted to open an application to view the PDF, rather than simply downloading it? (Bearing in mind that we can't avoid the delay between opening the tab and setting the location - or at least this is our preferred way.)
Thanks in advance!
So I am implementing oauth login and it works on every browser except microsoft edge. Chrome also has an unnoticeable error that might prove important.
I call:
window.open(facebookoauthurl)
from https://www.example.com/home/index This then opens a new tab. In this tab the user logins and is redirected back to https://www.example.com/externalauth/callback
The callback page is empty except for:
try {
top.window.opener.loginMethods.handleRedirect('#Html.Raw(Model.RedirectUrl)');
} catch (e) {
alert(e);
top.window.opener.location = '#Html.Raw(Model.RedirectUrl)';
}
window.close();
This works in all browsers except edge where top.window.opener is not defined. If i extract this script into a function which is executed when you press a button google chrome shows an alert saying: "security error blocked a frame with origin from accessing a cross origin frame" however once you dismiss the alert it executes the code anyway and the parent tab gets data passed to it!
I have read into the causes of this. The domains are exactly the same, I have even gone to setting document.domain on both pages to be exactly the same. It appears in various other examples that an issue can arise going through different zones in IE/edge but these are both in the same internet zone. It also works perfectly fine running on localhost in edge. The code will work if facebook and my site are in trusted sites.
There were multiple suggestions of using showModalDialog to achieve this but that is obviously now deprecated. I know this has to be possible somehow but I am absolutely stuck now.
It is just based upon: http://www.codeproject.com/Articles/1006013/OAuth-Social-Logins-Facebook-Google-Twitter-PayPal
I have a classic ASP web page that used to work... but the network guys have made a lot of changes including moving the app to winodws 2008 server running iis 7.5. We also upgraded to IE 9.
I'm getting a Permission denied error message when I try to click on the following link:
<a href=javascript:window.parent.ElementContent('SearchCriteria','OBJECT=321402.EV806','cmboSearchType','D',false)>
But other links like the following one work just fine:
<a href="javascript:ElementContent('SearchCriteria','OBJECT=321402.EV806', 'cmboSearchType','D',false)">
The difference is that the link that is failing is in an iframe. I noticed on other posts, it makes a difference whether or not the iframe content is coming from another domain.
In my case, it's not. But I am getting data from another server by doing the following...
set objhttp = Server.CreateObject("winhttp.winhttprequest.5.1")
objhttp.open "get", strURL
objhttp.send
and then i change the actual html that i get back ... add some hyperlinks etc. Then i save it to a file on my local server. (saved as *.html files)
Then when my page is loading, i look for the specific html file and load it into the iframe.
I know some group policy options in IE have changed... and i'm looking into those changes. but the fact that one javascript link works makes me wonder whether the problem lies somewhere else...???
any suggestions would be appreciated.
thanks.
You could try with Msxml2.ServerXMLHTTP instead of WinHttp.WinHttpRequest.
See differences between Msxml2.ServerXMLHTTP and WinHttp.WinHttpRequest? for the difference between Msxml2.ServerXMLHTTP.
On this exellent site about ASP you get plenty of codesamples on how to use Msxml2.ServerXMLHTTP which is the most recent of the two:
http://classicasp.aspfaq.com/general/how-do-i-read-the-contents-of-a-remote-web-page.html
About the IE9 issue: connect a pc with an older IE or another browser to test if the browser that is the culprit. Also in IE9 (or better in Firefox/Firebug) use the development tools (F12) and watch the console for errors while the contents of the iFrame load.
Your method to get dynamic pages is not efficient i'm afraid, ASP itself can do that and you could use eg a div instead of an iframe and replace the contents with what you get from the request. I will need to see more code to give better advice.
I'm using IE9 to debug a web app. I made some changes to the javascript after loading the page. I'm not able to get IE9 to stop on the new code. The message is "The code in the document is not loaded". I can set breakpoints when I'm not debugging, but they won't be valid when I start debugging. I'm using IE7 Browswer Mode, IE7 Document Mode.
Things I've tried:
close dev tools window, re-open
stop debugging, start debugging
Ctrl R in dev tools window (same as Clear Browser Cache button)
Ctrl R on the IE9 web page
Ctrl F5 on the Ie9 web page
Clear browser cache for this domain
Check (set) Always refresh cache from server
Next thing to try (I guess) would be closing IE completely. Is that the fix for this? If so, yuck. It takes me a couple of minutes to set the page up so doing that after every JS change really stinks. I can use FF4 to develop the JS, but the JS issue I'm seeing is specific to IE7 so I have to do it this way.
>> How can I get IE9 (running in IE7 mode) to reliably debug the most current JS from the server?
This issue wasn't related to caching etc. IE9 was hitting a script error (missing closing paren) in the new code and not allowing breakpoints anywhere in the script. IE seemed very quiet about the script error though. Anyway, fixing the script error fixed the issues with breakpoints / caching.
If you have access to the code:
In you javascript file reference add a query string, something like this:
<script src="Scripts/main.js?v=1" type="text/javascript"></script>
And every time you change in the js file change the v value to something else, like that the browser will feel that this is a new file and will get it.
Add this:
window.applicationCache.addEventListener('updateready', function (e)
{
if (window.applicationCache.status == window.applicationCache.UPDATEREADY)
{
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?'))
window.location.reload();
}
}, false);
I found this solution somwhere in the Net. Sorry, but I don't remember the author. It works for me when I debug Web App with JavaScript in Visual Studio and use IE.
I found this question based on the "the code in the document is not loaded" error message. I'm not using IE7 document mode or any of that, just IE9.
Like jcollum, my issue wasn't related to caching.
I'm using MVC.Net, and someone had set up a piece of javascript to rely on a string in the ViewBag. I changed a couple things, and that ViewBag string disappeared, so the resulting javascript looked something like this:
if(!()) {
// Some code
}
Javascript died right here, and wouldn't process the rest of the code in the block. This was confusing, as it was still trying to execute javascript in a different set of script tags, but which relied on a variable set in the other block it wouldn't load.
So, basically, a syntax error was introduced via strange means, and the debugger refused to load some of the code which came after it. Another lesson on the dangers of ViewBag.
I'm developing an extension in Chrome 4 (currently 4.0.249.0) that will show the user's StackOverflow/SuperUser/ServerFault reputation in the status bar. I've designed an options page to get the user's profile IDs and I save them to localStorage and read them well in the extension. It all works great.
The problem is I cannot find a (programmatic) way to refresh the extension upon options saving. I tried calling location.reload(); from the extension page itself upon right clicking it - to no avail. I pursued it further and tried looking at what Chrome's chrome://extensions/ page does to reload an extension, and found this code:
/**
* Handles a 'reload' button getting clicked.
*/
function handleReloadExtension(node) {
// Tell the C++ ExtensionDOMHandler to reload the extension.
chrome.send('reload', [node.extensionId]);
}
Copying this code to my event handler did not help (and yes, I tried replacing [node.extensionId] with the actual code). Can someone please assist me in doing this the right way, or pointing me at a code of an extension that does this correctly? Once done, I'll put the extension and its source up on my blog.
Now the simplest way to make extension to reload itself is to call chrome.runtime.reload(). This feature doesn't need any permissions in manifest.
To reload another extension use chrome.management.setEnabled(). It requires "permissions": [ "management" ] in manifest.
window.location.reload() works for me
I am using chromium 6.x so it might be fixed in newer version
The chrome.send function is not accessible by your extension's javascript code, pages like the newtab page, history and the extensions page use it to communicate with the C++ controller code for those pages.
You can push updates of your extension to users who have it installed, this is described here. The user's application will be updated once the autoupdate interval is hit or when they restart the browser. You cannot however reload a user's extension programmatically. I think that would be a security risk.
I just had this same problem with an extension.
Turns out you can listen for storage changes within background.js using chrome.storage.onChanged and have that perform the refresh logic.
For example:
// Perform a reload any time the user clicks "Save"
chrome.storage.onChanged.addListener(function(changes, namespace) {
chrome.storage.sync.get({
profileId: 0
}, function(items) {
// Update status bar text here
});
});
You could also reload parts of your extension this way by taking the changes parameter into account. chrome.runtime.reload() might be easier, but this has less overhead.
For all future Googlers - the Browser Extension spec now includes runtime.reload() - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/reload
For Chrome, you might need to use chrome.runtime.reload() (but I'd handle such cases via Mozilla's awesome webextension-polyfill).