I have struck a strange issue. I have some images on the page which are rendered from Data URI's, and I would like to enable my users to copy them to the clipboard.
However, for some reason, neither Firefox nor Chrome seems to allow me to do that.
As an example take this page:
<!doctype html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta charset="utf-8" />
<title>Clipboard Test</title>
</head>
<body>
<img id="target" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEsAAABHCAYAAABPjLqRAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAASdEVYdFNvZnR3YXJlAEdyZWVuc2hvdF5VCAUAAA5HSURBVHhe7dq5qmXVFsbxehYDM8EHMDEwU7BBQd9BM81MNTMTxA5DMdBAjATBJlDRQLED+75sEF9A9+U3L//FOMt9yrL0BudcCz7GmKP5xphjzbX22vvUhe+///5w8eLFw3fffXf49ttvDz/88MOmk9Zi4Kuvvjp88803y14M+48//rg4wFqM2K+//nqLF2sN1uzFyq9esXNd/NTlqieOrG86f7aZV71yIFu8088X+C+UJCgjPTuwIYgU2L/88suVU76YyOMDA5p8DW0OLu7qyJt8rWdcvfDh/eKLL5Zkwz1zXBCSP764gN1wy89f79YXFEBUUlfDyaghcuqziHi2yOnI6bOpJFQj3oCPPe7yi68WNAx2enyTowGIK8baRa4GW3XoUP+AswFutyGCjGyGBRWUWAEE1hqoeTn50svZ5+LDS58188etp1kDii0PGggbOXujk138YuJRQ0x8uBwevmZQ7IVJGCnHLAwSZhwf4hrllyMGR03kJ/nJ8m0om3V2eWR8Tr91zzZ5ckAtMaAHfrpca5Anp5j8s1b1YPLjYyPXyaLMzdIjihQkW/OXM2/h7GKAT04+G+PHS87acy23vHjqJ8mXFNNJ4rfOxzYHlQ3KpfOXB2x7nguTiLNmSkjmJyfBtMUVz2w8ruzlT74kFAPiArvhVYOsRrbi9ieELb3hluNC0qvN16m15lu3oQUgEBBRdgkzuTXidHK/sXzpFSWLrbnq5KsHeqcsWzJ/kn32Y80ef9BDz0OopxAfPX769sySAAXub6EISXZSoWw42mxXr1wQmy0pDuSwdZta11O3YDZ+9jhJvvrir1Z59SrW868c3D1b2aC9VKd86zUsCQIRcqRPKSkyOdC6mCB2NmBd0TmQhi5GfJvtBJcPNlbd+MrLFhedTY41fc8349LFqG3Nbl/xk9ttqBDDHBx7iZGKg4jafKTxhb0tvnzy2IDNurhQT9CFqR45kT9+YCP1zR7ay08//bT8XbyZS6/u+jRs4/QPP/zwcOONNx6uuuqqBfoHH3ywEiRrnIxgbkSh4mq++JrotuObp2yi3DjjBf5qpPNbdyrk8sU/bdYNzzr+asgRWx5p7ZSurzsMFgLd07fccss2LPonn3yyCpRMVtjmJ/DxiSeLrYFs9Nk0XUw87CA2FEtWR9/ZsovFwQ7WMy9Yq9sFLVYu3uKyX5hEEj/77LM/DOvTTz/dNtCmJ3BA/vjinvz0GikW4q05OtDjnzHl5ws9wKtl3YmDOUT54tjpcaphgHzW1bnQECwQOEXHhlWTFamwRoAv8rhI4CNrbNYDPNY1xl8+vbU6rXGSYuKKJ94GBuxyemyokz2ffBLKz07fXkpdAcU///zzo8MSI7HGFajxWXhulqzgCy+8cHjyySc3P4jvFmhNihdnOBrF1QYgW3nQaZ19QXHlQnFqVKc+6A0ZJ4gRv/1EI0CwweyHZYB8EiteU7N4vjkQvC+//PLh+uuvP1x99dWHxx57bNnEQxv3iZQNX/l8+OqPr01CNfFUj826nuKLp37z81VXDD2efPQLOS3IY8NiM/mSEdV8kk+xms72/vvvH26//faNz8AeffTRbaPBhZBTPySwzc3pw10gx5qPXk0no9s1bjHyZq/xzbj49r2xk+sBP5s69mloWILbQM0ns1W4grgefPDBjSsY2COPPLLibQwHvXxrSK83ehLUMAC2ZDxQrgvoYpByssuxbm89ivKng5g1LEklHntmsSmkmRqq6Ww2XWGw9owymDmo0C0pp1M1G61BfnonNv5s6dUmxRW/t4utd5icE9Xl94hgW5+Gs9nTbsP8oFjNAOKGVYHnn3/+cO21154Y0B4GZqDluGB03A0CJzudD+jiW4sVN2OC24/PHruocsXO+PjIqVcb1s/Kc+OnDUtww4iILUIcGhLz9ttvH+64444TgzkNnbB5QmtOnWpUh1/PDXbGdmLENmzrNpxfj1BMXNZkHzb1RFd3fd0pQZFjL6V9GlYcqWIVQVgBg73nnntODOTPYGCPP/74xtVw1Kg/On/1xbEbXB/7fOLaINjPHEa++OOplqHw708gbL+UkshOG1ZTn0UnEQ4FHnjggRODuFw0MJvXeJuBNgf1APkaAFmMAcHDDz98eOONN7Z+89Xz7B/sjez0zrz16tA06cce8AbIHzG9eGiQXjz/7Dl1KRjYE088sWrgjNdaHY2TbSLw2yCdj/7xxx8f7rvvvsX77LPPrjxccYppL0lzqDY/G87i10upBTKGY8Nya/E31FkINPjaa6+tF8/yrhRzYLOWPrs1wBr48utDjGfmnXfeuXHef//9y2cPxeOwBsNhUy9e8dNG325DBvLYA94AZ1ybiPidd9657Af65aBbUo1qgY1Vk54f2vhLL710uOGGG07w3XrrreunJ/7iwZD2fA21mp22NayZLOi0T8NJJlE83RfvYy+efxedMDUaCp2seeibBTzzzDNHHwPXXHPN4ZVXXlk84uJpeNbHnlETbOuZhaQpH7sNe8CHksU/9dRTa2OzuX8KeL1W6C+0QUPyqpL+0EMPXbIP3xgaQnsmA5+9GRgdxFiT1utXB0DiyB07WR6WGuKvkJzLefH8u5gnTMPq16+13u69996juRNeZ9wFBtIwXOwGAXxs7VOd/OT2zMp42m2oOTEIkL733nv/6HPqUjAwz7BOQHj33XcPd91119GcPa677rrD66+/vnpvrw2cbH9qpIN4awNcJ8uiE3NsWG7DGpUs5u677z7RzP8aBtbvYfp98cUX//Ag/zN4hbAHe45n6nxm0DzIhmu9TlaB5LFh9fCTRL/SF8+/CwPz887TTz99Rbe/V4guvG8cPfPmkIIhgVinim2dLMESPZdOO1ni4KOPPjrcfPPNJ5o4K/AK4S9V9mo4DQEaWM+rDg+09zWsmXjaHyw8+LoFp/8swSvEq6++ug3Bvu0/3ZDsEwyLj3SIxKw/soJpC77UHywk7l8tzhq8Qthnp6sBebw4MB0ew7Ff/ma03rOm4djJMsCS9/6zBq8QHiWGBYbTrWf/7h577U6it/f13ZDRgn5sWH2RRrY/eWcNXiHeeuut7XDYMxicGdhntx+9wyRm3YYm27CO3YZuPfetJMf1LA8LnnvuuW1QBgMOzDxh0IlqeCf+unOpYUkWc5Yf8MErhIveqdmfIGgeZB9+2/91ANM97TYs+aw/4KFfIey3/dtfYGtA0Ilbvzr0IJO0HwadrStw1h/w0K8QPeQ7QR41ZpBseO19uw1zHhtWrw5iz8PJAq8Q9g09k+yPNDz21nQD3P7IynjayWpYjuN5GZZXCM8t++pkNRi23hDmfLaXUgvG/QOcjjS/n0TOw7C8Qrz55ptrTwZif27JOY8GJwa2P4V19I6drF73JZ6XYYFfIRoUaSD22ElrSM1n3YYNjH7a153IzsN7VvAK0TDmDMDQSAfFM42+Daujd+xk9Uup2PM0rNtuu239CtFg7N8+naJOV/Y1LA9tk2tYx96zDEgMnIeX0uAVwp/wDKZb0FCSMF+rtv/aTcL/w0vpRL9CtP9OVJjrdbIYCt4/wOn96sB/1r9I7+EVYj6T7TFpQG7L1uul1LB6pT/tPctxhF9++eXw+++/H87Lv99+++3w888/r2FAt18Dohsaub4bWhiWYRwbVi9vkYjva0LkbPniZKe7OvLpU8YTh/o4Ou1sfRLhADGkXBCLqzh5dDLu4sUBW/2J7T+rqc1G1mOc5DpZGmCgn3ayesiLBXoNIwo4agpspmFVvFNMx8M+uVrTSZsmywf5cun1Hkec7G20ocZLh/oVl58UX1wXaD3gK0o/7QGPDBFyyeUhZe+k1Yy4GhXLzxa6QJooL9QgWXy+em0gbNWon+LZgE0NnOzW80TDjLeuJ4eEdPq2P4UJop+nV4MrwU033bT9BchcXEzDp6/bkKErdt5eDf4q7N0bgbl0Gsk1LAuD4iT/HdbJx86867ZfHTL+O6z/DqsPJUMCh+nE//wjPcjO03vUX/1n77/++us2IAPrw2T7z2yG5qEmaE5UIPAHfjn5kIJ4dn7rYsXEVy4UP+GTqk9C+dnrYdaOMx4+uvwuflzgk80e2fa1i3eiyHLmO9g6WRTgLLlGyVATCGuSreKgGbG4rNNxtcaR3aZJa6jRXklg31Mf5+Im+Pb7mL7Zq7pQXHn5y03yr5MlqQ1MvWZLotuEmGkvJ1K5bVZxfmArXiy/jbNlJ+XHB9bp7PEGNnkkVKe49kJWx5o+axSTnD3I2f4zW8lODRTYg65Cs7Fya4A+m6sZEtiyFzM56LPJqZPVno8La3axEHexBhcXWV61xFgHefue7Im+Tla3VfenZkrkn1KBriYZEbtc4JvF+cXxZZ82uQ2bXf1OGcQhliyWzBavWLZQ/p5Pjfk84u9ghHjrZ3vAz4bmsCILEewln6tYjLyGQAdxxYrhEwPZ97HxG2wbFt+FiotOgvw2Hx/wue3l4BQD1Y5TXL3J46Of+J9/UEP0mp3IFon1fBbNfGgYbYwtHpsptvx4y6ODfPGt+cTT5bjAOJJx7nWQS8ptP2zium1nPDvbdrIERUpCzZCa1ci+ALvYmsQT2NsUsJHVSMZXHTX2MdWZPPLYy7Wed0V2OshL1xc5efCzA5tTGKfY9QYvsGRrRbqfrdkrDBHKy0YPFY0L6K35g/h9DLs1Xvq04yVtoHW51g2Snh/YqtM+Qf16bU3i6eQDru3P92QbF9w0BfHX1CwUaYTTnq1m29z0k9XP1ibzVa8+6mnm9hxqPf1ke9JHtvzxzr2zz4tYzDpZETCCiUpsyj0o2SQ1gIqzFVdMXBD3rBUPOykvnU9cF4K9E2Aw9cbOD+6E+KfdurzsbMXN2Hy48YE13osXLx7+A1szFjfFBZ3lAAAAAElFTkSuQmCC"/>
</body>
</html>
available here if you want to try it.
Right clicking on the image and choosing 'Copy Image' does not seem to work for Chrome, Firefox or IE11. However right click and 'Save Image As...' does work.
Since it seems consistent across all browsers, I am assuming there must be a deliberate decision not to allow such images to be copied. Is it related to CORS - since the data URI has a different origin?
Is there anything I can do to allow these images to be copied?
The background to this is that I am trying to make it possible for users of my web application to copy SVG images onto the clipboard. I am able to convert the SVG images into PNG data URIs, which I can even save on the user's computer, but I cannot seem to get them onto the clipboard. If there are other / better ways to do this then please feel free to point them out instead!
UPDATE It seems this might be related to the receiving application rather than the browser. After seeing the comments from #Mi-Creativity I re-tested using additional applications. Pasting such images into MS Paint does seem to work, while pasting them into MS Office applications does not. Unfortunately for me that is the main use case of my users.
I installed the inside clipboard tool and used that to compare data on the clipboard when using a data URI vs. a normal HTTP URI for the image. Using Chrome, in both cases there are four formats placed on the clipboard:
CF_BITMAP
CF_DIB
CF_DIBV5
HTML
The first three are identical in content. The HTML version is different - they contain snippets of the HTML document, one with a data URI and the other with a HTTP URI.
Armed with this additional information I did some more googling and found this similar previously reported problem.
It seems the likely cause is that MS Office applications are attempting to paste in the HTML version, which fails because Office does not understand data URIs, and ignoring the more useful bitmap versions available on the clipboard.
Users can work around this by using the 'paste-special' option, although it is a lot fiddlier than I would like.
Related
I made some simple HTML files and tried to open them on my iPhone, in both the files app and some third party HTML viewer apps from the App Store, but the images are not being displayed, not a single one.
It‘s not because the image is in another folder or the file path is incorrect, I‘ve checked all that. Also I‘ve looked up the issue and it seems that this might be caused by too large png files, but I tried to resize the images and also changing them to jpg, but still didn‘t work. So what could be the issue here?
I‘ve attached an image of the result that I get with this example code (the png file is in the same folder as the HTML file):
<html>
<head>
</head>
<body>
Test
<br>
<br>
<img src="image.png">
</body>
</html>
Result
This is almost certainly a security related issue.
I ran into this helping a friend who was working on an email newsletter and sent it to herself as an attachment. Opening in gmail showed the same behavior - no images.
So I tried saving the file to the Files app and opening it. Same thing. Loading the page from a web server it worked n
It doesn’t entirely make sense why they need to be so strict - the same thing in a desktop browser would show images. But I don’t think there’s anything you can do in this case.
Saving as a complete web page archive may work if the goal is to email an attachment that someone needs to open - but that’s not a common thing to do and if you send the message as a real email it’ll work fine.
Is there a way to force Google Chrome to use the <title> tag data instead of writing the web page address?
Eg. <title> </title> is ignored by Chrome and the browser writes "[domain].com/index.html" on the tab instead of the expected space. The problem occurs whether I use an actual space or the HTML character code. Other major browsers correctly read the title data as a space.
So does anyone know if there are any other invisible characters that Chrome will actually "display"? I've tried a number of other &nb__; characters to no avail. I'm looking for an HTML solution if possible, because I access this site on a number of computers and I won't be able to install extensions in every situation.
And before I get any flack about having a blank title, this is a personal website I made for my own use, so I'm not worried about accessibility or other user's experience, just my own. I recently switched from Firefox to Chrome and this is really bugging me.
I have this crazy idea to have a simple file .html with textareas which can be edited but I don't want to have a database or any backend, just this one file and to be able to open it in browser and in browser add text and save it somehow....is this possible without backend and Database?
This a simple example:
<!DOCTYPE html>
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Test</title>
</head>
<body>
<textarea rows="4" cols="50">
At w3schools.com you will learn how to make a website. We offer free tutorials in all web development technologies.
</textarea>
</body>
</html>
And what I want is to be able to save the changes made in Textarea to be permanent so when I copy that .htm file those changes should be there in source code of that htm file.
It looks as if this is possible simply by using a browsers Save page as... (or similarly named) feature, which can usually be easily accessed via CTRL+S.
Try this:
Create a very simple .html file that has some element with the contenteditable attribute.
Open that file in your browser.
Change the contents of the editable element from within the browsers.
Hit CTRL+S and save the file over itself.
Reload the page or reopen the same file.
The changes you performed from within the browser should be there and should also be reflected in other editors or browsers.
However, as this is a browser feature that is not covered by any standard, some browsers might not offer this feature or save the file in its original, unchanged state. Also, the way browsers handle this can obviously be subject to change.
At the time of writing, this has been successfully tested with these browsers / OS:
Chrome 60, Windows
Opera 47, Windows
Firefox 55, Windows and OSX
Browsers / OS that do not save the changes:
Edge 40, Windows (also, opening local files is non-trivial)
Chrome 60, OSX
Safari Version 10.1.2 (12603.3.8)
Opera 47, OSX
It is possible to edit an HTML file on the fly using the contenteditable attribute, or simply from your browser's web inspector.
For saving the page you could use localStorage or other mechanisms to save it just on your computer.
It's even possible to create a simple text editor that works in your browser, just by going to this URL: data:text/html,<html contenteditable></html>
You can have a look at this blog post for more: https://www.simonewebdesign.it/how-to-make-browser-editor-with-html5-contenteditable/ (I am the author)
In HTML5 you can use local storage to save the data.
The localStorage object stores the data with no expiration date. The
data will not be deleted when the browser is closed, and will be
available the next day, week, or year.
use the following example in javascript to store and retrieve the data:
// Store
localStorage.setItem("lastname", "Smith");
// Retrieve
document.getElementById("result").innerHTML = localStorage.getItem("lastname");
I have an app that displays the same image in multiple locations and may change the src of an image.
When I point to a PNG image that I've already used before, the browser does not bother making a new request, it simply uses the PNG image that's already in the cache. However, when I point to an SVG image image that I've used before, the browser (Chrome 22) makes a new request. The server returns 304 (Not Modified), so no new image needs to be downloaded, but this still takes some extra processing.
This can be easily tested in this jsFiddle: http://jsfiddle.net/jtmuw/1/
$('button').click( function() {
$('#a').attr('src', "myImage.svg");
$('#b').attr('src', "myImage.png");
});
If you open the fiddle with Chrome (or at least Chrome v.22.0.1229.94) and you open up your network tab you will see the two images have been requested. If you then hit "reload images" several times, your network tab will show multiple requests for the SVG image but no further requests for the PNG image.
As far as I can tell, the same headers are being returned by the server, so I can't see any reason for the difference.
I am not seeing this on FF or Safari, so this may be a Chrome issue. However, I still feel like maybe there is some underlying differences in the headers that I'm missing, and it's not just that Chrome is treating SVG images weirdly.
You can perhaps force Chrome to cache the file. w3schools has a pretty good overview of this as follows: http://www.w3schools.com/html/html5_app_cache.asp
Essentially you'll want to create a manifest file (call it... "myCache.appcache" or whatever else)
CACHE MANIFEST
/path/to/svg/file.svg
and then point to this in your html file as so:
<html manifest="myCache.appcache">
This will tell Chrome that, even when you don't have internet access, this file should be cached and accessible anyway.
Include the SVG image at the top of the document.
<html>
<head>
...
</head>
<body>
<img style="display:none" src="cached.svg">
....
</body>
<html>
It's been a while since I did serious web development. Now I meet a host of brand new problems I'm no longer familiar with..
I have some .png images for various icons in my web page. What I find is that whenever I edit these images, they stop working inside a page in IE8. That is, they (usually) display OK when I first open the page, then are replaced by the placeholder icon on refresh. Sometimes, some of the icons display and others, with the same src, don't.
My image tags are nothing fancy, typically:
<img src="images/misc/smallreport.png" alt="Report" />
When I right-click an icon in the page and select "properties", protocol, type, address and size are shown as "Not Available", and dimensions are incorrect (size of the placeholder, I bet).
If I open the images directly in IE (ie. not within the page), they work just fine.
I have used Paint.NET to edit the images, but have also tried saving them with Paint.
Right now, I am working right off the hard disk (ie. not through a web server). And, oh yes, none of this happens in Google Chrome.
What's going on here?
check the path to the file is correct - can we see the tag please.
Well, we learn something new every day..
I mentioned that I'm running this directly off the harddisk? Now, it turns out the html page (which I had gotten off a coworker) was blocked "to help protect my computer", as Windows does.
This is no big surprise, lots of files I'm working with originate on other computers, and I usually don't worry much about it (except with executables, which won't run until unblocked).
It seems, however, that when IE8 loads such a blocked HTML file, its security settings adjust somehow, and - well, I can only guess at the details, but as soon as I right-clicked the HTML file, selected Properties and clicked the "unblock" button, the problem went away.
Something similar happened to me once, I tried hard to find what was wrong, then I realized I was saving (from Photoshop) the file as PSD but with extension .png. Make sure you're not doing the same.
Also:
Clear temporary Internet files
Verify that the Show Pictures option has not been turned off
Make sure that the Toggle Images.exe Web accessory is not present and disabling images
Make sure that a third-party Internet security, firewall, or cookie-blocking program is not causing the problem
Enable the Auto-Select encoding option
Source
It might be that the website you have browse has a lack of support
for an IE browser. IE is a nightmare for all web developers & Web designers.
It might be the developer of that website didn't care for an IE display because
of IE issues. Perhaps IE is trying to create a web standard to increase their
sales and marketing strategy. That's why don't care the modern Web development standard.
Why Chrome or Firefox or Safari, it's a free anyway.