I have am using html2canvas to enable screenshots of divs within my web application. It's working well enough in Chrome (including Android), Safari (including iOS) and FireFox. In IE 11, however the image won't save.
Code looks like this:
function displayModalWithImage(canvas, filename) {
var modalcontainer = $('#snapshot');
var modalcontainer_body = modalcontainer.children().find('.snap_shot_container');
var modalcontainer_save = modalcontainer.children().find('.save_snapshot');
var image = new Image();
var data = canvas.toDataURL("image/png");
image.src = data;
modalcontainer_save.attr('download', filename +".png");
modalcontainer_save.attr('href',
data.replace(/^data[:]image\/png[;]/i, "data:application/octet-stream;"));
$(modalcontainer_body).html('');
$(image).appendTo(modalcontainer_body);
$(modalcontainer_save).on('click', function() {
modalcontainer.modal('hide');
});
modalcontainer.modal();
}
Browser behavior varies:
Chrome: displays modal and then saves the file when "Save" is clicked. (acceptable)
Firefox: displays modal and then displays a separate dialog when "Save" is clicked (acceptable)
Safari: display modal and then loads image in a separate tab when "Save" is clicked (acceptable... maybe)
IE 11: displays modal, but does nothing but hide the dialog when "Save" is clicked (unacceptable)
The data.replace was suggested by another SO answer, but it did not appear to have any effect on the behavior of any of the browsers. Previously the href attribute was simply set to data.
So, anyway, at this point replacing the modal dialog with a simple window.location = data is a viable alternative. But, since Chrome works well and Safari and FF work well enough, i'd like to simply do a feature detection that would window.location for IE but show the modal for the other browsers. But, I don't know what "feature" is missing in IE to check for.
tl;dr
is there simply a change or bug in my javascript that would enable IE to work (save the image encoded as data to a file).
if not, which feature in IE should I detect for that would enable me to customize the behavior for IE
if that's not an option; what's the current best practices for old-fashioned browser detection?
Related
I am using the following function to allow the user to save an image. (Half the charts they might want to save as image are hidden, so they can't right click on them. They're displayed instead as SVGs.) I also want download-as-image options available for those who don't know about right clicking on images.
This is all working perfectly in my text editor & Chrome. I click the button with the saveChart function attached and the file downloads. In Safari a new tab opens at the URL - not the behaviour I want but understandable. I can't test on IE. But on Firefox nothing happens at all. It's as though i haven't pressed the button.
JS is enabled and works on other buttons / functions.
function saveChart(obj) {
var tempStr = obj.parentNode.id;
var newID = Number(tempStr.substr(6,tempStr.length-6));
var a = document.createElement('a');
a.href = 'charts/chart'+newID+'.png';
a.download = 'image.png';
a.click();
}
Is the difference caused by user security settings and if so what are they? Is there any way to secure the same (download) behaviour cross-browser?
Thanks
Emma
I have TinyMCE 4.0 in the page and when I select the text and try to paste it via CTRL+V, I get an error message saying that "Clipboard access not possible." This happens in IE8/9. However the same works fine in Chrome. Is there any workaround for this to get this working in IE?
Bounty:
I've tried resetting all IE settings (via Internet Options->Advanced->Reset All...) on two different computers, both running IE9, and one has the problem while the other does not.
Ultimately, I need to be able to paste formatted text (often with bullets or numeric lists and such) into TinyMCE and have it format them correctly. For this, I'm using the paste plugin, which seems to be throwing the error.
It seems to me that you're using an older TinyMCE 4 version, so in my opinion you should first do an upgrade to the latest version (4.0.3).
I've checked the source code of such version and I've found no trace of the Clipboard access not possible error message, which seems instead to be present in an earlier version of the tinymce/plugins/paste/plugin.min.js file, and only for Internet Explorer:
e.ie ? o.on("init", function () {
var e = o.dom;
o.dom.bind(o.getBody(), "paste", function (n) {
var r;
if (n.preventDefault(), a() && e.doc.dataTransfer)
return c(e.doc.dataTransfer.getData("Text")), t;
var i = u();
e.bind(i, "paste", function (e) {
e.stopPropagation(), r = !0
});
var s = o.selection.getRng(),
f = e.doc.body.createTextRange();
if (f.moveToElementText(i.firstChild), f.execCommand("Paste"), d(), !r)
return o.windowManager.alert("Clipboard access not possible."), t;
var p = i.firstChild.innerHTML;
o.selection.setRng(s), l(p)
})
}
Not being able to find an unminified version of this script, I can't say why such code fails, nor can I explain why it works only on one of your's computers.
In Internet Explorer's Tools menu, choose Internet Options.
Click the Security tab.
Click Trusted Sites.
Click the Sites... button.
Type your domain name (for example, widgetdesigns.com) in the first field, then click Add.
Unselect the checkbox that says Require server verification (https:) for all sites in this zone.
Click OK to apply your change.
Back on the Security tab, confirm that Trusted Sites is still selected, then click the Custom Level button.
Scroll down the Security section (near the bottom) and check the Disable box below Allow Programmatic clipboard access. (Checking this box will disable the access alert only for sites in your Trusted Sites list.)
Click OK then OK again to apply your changes.
What about this? Does this work?
I use window.open to populate a new window with varying content. Mostly reports and stored HTML from automated processes.
I have noticed some very inconsistent behavior with Chrome with respect to window.open().
Some of my calls will create a new tab (preferred behavior) and some cause popups.
var w = window.open('','_new');
w.document.write(page_content);
page_content is just regular HTML from AJAX calls. Reports contain some information in the header like title, favicon, and some style sheets.
In IE9 the code does cause a new tab instead of a pop-up, while Chrome flatly refuses to show the content in question in a new tab. Since the content is sensitive business data I cannot post it here. I'll answer questions if I can.
I know some people will say this is behavior left up to the user, but this is an internal business platform. We don't have time to train all the users on how to manage popups, and we just need it to be in a new tab. Heck, even a new window would be preferable to the popup since you cannot dock a popup in Chrome. Not to mention none of the popup blocking code would affect it.
Appreciate any insight.
window.open must be called within a callback which is triggered by a user action (example onclick) for the page to open in a new tab instead of a window.
Example:
$("a.runReport").click(function(evt) {
// open a popup within the click handler
// this should open in a new tab
var popup = window.open("about:blank", "myPopup");
//do some ajax calls
$.get("/run/the/report", function(result) {
// now write to the popup
popup.document.write(result.page_content);
// or change the location
// popup.location = 'someOtherPage.html';
});
});
You can try this:
open a new tab please
<script>
function openWindow(){
var w = window.open("about:blank");
w.document.write("heheh new page opened");
}
</script>
Is very easy, in order to force Chrome to open in a new tab, use the onmouseup event
onmouseup="switchMenu(event);"
I have tried this and it worked fine in chrome. If opening a new tab is on a user action(such as a mouse click) this will work fine without any issues. But if the code is executed in another script block, you may need to enable pop-ups in chrome. Looks like this is to handle all the click-bait sites.
let newTab = window.open('', '_blank');
if (this.viewerTab == null) {
console.log("opening in new tab to work, pop-ups should be enabled.");
return;
}
................
newTab.location.href = viewerUrl;
window.open('page.html', '_newtab');
Specify the '_newtab'. This works in IE and FF, and should work in Chrome. But if the user has things configured to not open in new tab then not much you can do.
I can't seem to figure out why the following simple popup will not work in IE9. FF & Chrome popup as expected, but IE does not appear to do anything when the link is clicked. I tried the IE9 debugger, but didn't get any helpful information out of it.
In the head section:
<script type="text/javascript" language="JavaScript">
function JSPopup(linkref) {
window.open(linkref,"Report Definitions","width=600,height=480");
return false;
}
In the body:
<strong>Report Definitions</strong>
Thanks for your help,
Filip
Turns out the problem was the name given to the popup - IE doesn't allow spaces, FF & Chrome do:
window.open(linkref,"Report Definitions","width=600,height=480");
needed to be changed to:
window.open(linkref,"ReportDefinitions","width=600,height=480");
This works across browsers.
Filip
This is part of the security changes made in IE6. Now you can only call "window.open" from within a user-initiated event. For example, your code would work inside an element's onclick event. The "window.open" http://msdn.microsoft.com/en-us/library/ms536651(VS.85).aspx MSDN page says this:
"This method must use a user-initiated action, such as clicking on a link or tabbing to a link and pressing enter, to open a pop-up window. The Pop-up Blocker feature in Internet Explorer 6 blocks windows that are opened without being initiated by the user."
Example...
function popUpWin(url,wtitle,wprop){
if (!window.open){ return; } // checking if we can't do this basic function
// Kill if(win), since win was a local var this was a usless check
var win = window.open(url,wtitle,wprop);
// next line important in case you open multiple with the same 'wtitle'
// to make sure the window is reused and refocused.
if (win && win.focus){ win.focus(); }
return false;
}
As the title says "Google Chrome opens window.open(someurl) just fine...but page/window with clicked link also opens someurl.com.
When I click the "Click here" link with the onclick="shpop..." call attached, my pop up opens /facebook_login.php' correctly...BUT...at the same time, the original window opens /facebook_login.php too!
This happens in Chrome and IE, but FF is fine and doing just what i want..
I have this link:
Click here
I know I could remove the href="/facebook_login.php" and replace with href="#" .. but I need the link to work if js is disabled.
I have this js code imported in my tag:
function shpop(u,t,w,v)
{
var text = encodeURI(t);
var uri = encodeURI(u);
var h = document.location.href;
h = encodeURI(h);
var wwidth='600'; /*popup window width*/
var wheight='300'; /*popup window height*/
if(v=='' || undefined==v)v=document.domain; /*popup name/title */
switch(w){
case 'loginfb':
var url = '/facebook_login.php';
wwidth='980';
wheight='600';
break;
}
window.open(url,v,'width='+wwidth+',height='+wheight);
return false
}
Any ideas?
what is with returning false, and having false in the onclick?
This
onclick="shpop('','','loginfb','');return false"
Just needs to be
onclick="return shpop('','','loginfb','');"
If the onclick returns any error, the link will still open up. Do you see any errors in the JavaScript console? I wonder if the browsers are freaking out about any . in the window name from using document.domain. Try giving it a name.
onclick="return shpop('','','loginfb','foobar');"
According to the latest browser statistics - well last time it was measured anyway (2008) only 5% of users had Javascript disabled. Nowadays it's likely to be less. Consider that all browsers have it enabled by default. Therefore it's generally only advanced users that for whatever reason choose to disable javascript, and will therefore understand that there's a good chance any website they visit won't work as expected - Facebook, Google, Amazon - everyone uses javascript these days. It's perfectly acceptable to assume the user is using it, with one overall <noscript> version at the start of your page for those users if you really really want to cover all your bases :)
Here is the simplest solution:
<a href="/facebook_login.php"
target="FBpopup"
onclick="window.open('about:blank','FBpopup','width=980,height=600')">
Click here
</a>
You don't need return false because you actually want the link to execute.
The trick is to use the same window name in both the window.open and in the link target.
window.open will create the popup, then your login page will run in that popup.
If popups are blocked or Javascript is disabled, your login page will run in a new tab.