I'm trying to get this simple code to work:
<a href="#" target="_blank" style="display: inline-block;">
<object data="icons/chrome.svg" type="image/svg+xml" style="pointer-events: none;">
fallback text
</object>
</a>
When I use
data="http://images3.wikia.nocookie.net/__cb20120330024139/logopedia/images/d/d7/Google_Chrome_logo_2011.svg"
it works. However when I save that exact file onto my own server and reference it as above, it just shows the fallback text in Firefox. In Chrome it downloads the file when I open the page (which proves that the file link is correct).
Anyone know what's going on here?
I can think of four possibilities:
Your server is using the wrong MIME type for SVG images. (Can be fixed by adding AddType image/svg+xml svg to your .htaccess file; other methods discussed here)
You saved the SVG file somewhere else and it doesn't exist at icons/chrome.svg. (Try navigating straight to the SVG file at icons/chrome.svg. Does it display in your browser?)
You saved the file with insufficient permissions, resulting in your web server being unable to access the file. (Can be fixed by navigating to the icons directory and typing chmod 0644 chrome.svg at the command line prompt.)
The file you downloaded from nocookie.net isn't actually an SVG file at all. (Try opening it inside a text editor.)
I was experiencing the first of the problems described by #r3mainer.
On my lighttpd server the problem was caused by the missing
".svg" => "image/svg+xml",
line in the mimetype.assign section of the lighttpd configuration file.
Related
I have the following HTML code:
<a href="data:text/x-c;charset=utf-8,struct%20example%20%7B%0A%09int%20number%20%3D%205%3B%0A%7D%3B"
download="example.cpp" target="_blank">Download a struct stub</a>
but for some reason, clicking this anchor results downloading an example.cp file and not example.cpp. I think I've checked everything. For instance, for .json files it works correctly. Also text/x-c is the right Content-Type for .cpp files. I've also tried with text/plain, but it still kept getting changed to .cp. Why does this happen and is there a workaround to it? I'm using Google Chrome.
As of April 2022: I have the same issue when trying to download .cpp files using Google Chrome.
Switching to Safari and Firefox works for me.
Update: I have concluded that this is a firefox issue. Chrome, Chromium Edge and Safari all work well with my solution. I have created a bug on the firefox bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1658877
I have a front-end that can download a file in 2 ways:
Click button 1 to open the file in the browser
Click button 2 to download the file to the hard drive
The way this works in the front-end is by using the <a download="FILENAME.EXTENSION"> tag and attribute for forcefully downloading the file, and to use <a> (without download) to make it open in the browser.
This works because the API never returns a content-disposition header (We use ASP.NET Core's File() method without the fileName parameter, which doesnt add a content-disposition header in this case) so the download attribute ensures it is downloaded.
Please read the background information before continuing
To try the fix the mentioned background information's issue, I changed our API to always return the following header for a file:
content-disposition: inline; filename=FILENAME.EXTENSION.
My idea is that the browser should open the file in the browser. if this is not possible, it will open a download pop-up and use the filename bit of the content-disposition header to give it a correct name. If it can open the file in the browser but the user pressed the download button, the <a download> should have higher priority and download.
The problem is that when using the <a download> way of downloading, that it STILL tries to open the file in the browser. I can understand why, but I would rather that it would respect the download attribute. I am using Firefox and the front-end and back-end run on the same domain!
Any clues?
For some background info:
We use ASP.NET Core 2.0. And if you use the built-in BaseController.File() method WITH the fileName parameter, it FORCES the attachment bit in a content-disposition header which makes it always download the file. We do not want that, so we used the variant of File() without specifiying a filename, which would not add a content-disposition header; this worked fine...
UNTIL we had to support MS word and MS excel files. When trying to use option 1, the user gets a pop-up like this:
As you can see, the filename is missing because the browser is not sending it in the content-disposition header. And I can't use the download attribute to specify it, because I pressed option 1 which means the file should be opened in the browser. If the file would be a PNG, it would then be forced to download.
At this point, I tried using inline;filename="FILENAME.EXTENSION as my content-disposition header, but this takes priority over the <a download> bit, defeating the purpose.
I can come up with 2 workarounds:
MS Word and MS Excel files must have a attachment bit in their content-disposition header so I can specify the filename and they download to disk, even if you tried opening it directly in browser.
But this isn't pretty; if some user would not have image/pdf support and downloaded an image or PDF file, my issue would still exist because the filename would be download again...
Have a download queryparam with the value 0 or 1 that specifies if the file should be downloaded with a INLINE or ATTACHMENT content-disposition header.
this might, compared to my current situation, be prettier, perhaps. but it is more work, and I wish that <a download> could just work.
I have a download attribute on two different anchor tags. One is for an Excel file and one for PDF. The Excel file downloads. The PDF opens in new tab instead. Why is this happening? Code below:
<div class="col-2 center">
<a download href="files/excel-sample.xlsx">
<img src="img/excel-logo.png" />
</a>
</div>
<div class="col-2 center">
<a download href="files/pdf-sample.pdf">
<img src="img/pdf-logo.png" />
</a>
</div>
Download Basics
So essentially what is happening is that when you link to a file URL, the browser opens that URL and if it has accessibility to display the content, it almost always will. Some most common examples of this are image files (.png, .jpg, etc...). However, if the browser can't read the file type (.zip) then it will almost always download the content. A great way to force the browser to download the file is by adding the download attribute in the <a> tag.
PDFs are readable and accessible by most modern browsers so by default, the browser is set to open the file instead of download it. Because of this accessibility, most modern browsers have introduced settings that allow users to decide on a machine by machine basis whether or not a PDF (or any other readable file) should open in another window or download by default. In many cases, even with the download attribute, the browser can still decide for itself how to handle the file.
Possible Solutions
1 - If you are just trying to achieve the download functionality on your browser only (which it looks like you aren't but I thought I should include anyway), you can open chrome, go to Settings -> Advanced Settings -> Content Settings -> PDF Documents -> Toggle on Download
2 - You can compress and zip the file so the browser is forced to download the file.
3 - If you have root server access to your site and it is using Apache, you can add the following to your .htaccess
ForceType application/octet-stream
Header set Content-Disposition attachment
If you are using an NGINX web server, you can add the following redirect
location ~* (.*\.pdf) {
types { application/octet-stream .pdf; }
default_type application/octet-stream;
}
So the solution is:
<a href="pdf-sample" download="pdf-samle.pdf">
Note that "href" has a value without the .pdf reduction, but "download" has a value with the .pdf reduction. Remember you also have to remove the .pdf reduction from the targeted file. As it seems the browser treats the downloaded file as a non pdf file and therefore is not opening it by default.
you cannot use <a download href="files/pdf-sample.pdf">
but you can use <a href="files/pdf-sample.pdf"> for preview your file
I have saved a complete HTML page from a server using Chrome.
When I load the local file again in Chrome, the SVGZ images do not render and instead shows a broken image icon.
Double checking the file and loading again from the original server, I find that the SVGZ loads just fine
If I load just the local image file on its own, I get prompted to save the image
If I edit the local image filename extension to .SVG, and load on its own, it renders just fine
If I then edit the HTML file to refer to the renamed file with the .SVG extension, then the entire page and image all loads correctly
I know this is not strictly a programming issue, but in doing a lot of searching, I have found more closely related answers here on StackOverflow than on say AskUbuntu.
This answer provides the best clue I have found thus far:
Chrome not rendering SVG referenced via <img> tag
I came here because I had a similar problem, the image was not being
rendered. What I found out was that the content type header of my
testing server wasn't correct. I fixed it by adding the following to
my .htaccess file:
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
So I am guessing that the problem lies somewhere with:
when loaded from the server, the content type is correctly specified
when loaded from my local file, the content type is NOT correctly specified
Is there any way to resolve this ?
Can I "mimic" the .htaccess mime type and encoding by changing a Chrome setting ?
Any advice is appreciated.
I created a test HTML file with an <img> that loads a .svgz file. It worked okay (Chrome on Win7).
Check that your .svgz file is actually a gzipped SVG file, and not something else. For instance I suspect that it is actually a normal SVG file but with a ".svgz" extension. That will fail in the way you describe.
I am using an <iframe> to display a text file:
<div class="document-view">
<img src="img/302.GIF" />
</div>
$(window).load(function () {
<s:if test="extention.equalsIgnoreCase('txt')">
element = '<iframe class="iframe" src="/dmsrepo/<s:property value="docLocation"/>" />';
</s:if>
$('.document-view').html(element);
});
When I inspect element in the browser I can see the file location.
<iframe class="iframe" src="/dmsrepo/Legal Doc Type/LegalDocType_123456789_1.0.txt" />
But the text file is getting downloaded in Chrome, Firefox and IE.
How to resolve this issue?
EDIT: you can reproduce the behavior in the following fiddle, that strangely affects only Firefox, for every page load after the first one.
Simply open the page, then press Run.
Note: it affects also the first load if Firebug Net module is activated.
This is the issue with the file. it is not formatted as html. because it has some special unicode (eg) characters at end of file read. if text response has special character like that. it failed to parse response as html embedded in iframe.
you can check this example :
<iframe src='http://humanstxt.org/humans.txt' /> </iframe>
because browser understands only html. Change your file extension to .html
or use server side language like php and using file_get_contents() function, you can display text file to browser.
to display file add below line(s) in .htaccess
AddType text/plain .txt
AddType text/plain .log
This is signal Firefox that you don't have to download the file instead view file as plain text.This technique can be applied to all the files that you need to view instead off download.
The Content-Disposition response header could be the culprit. If set to attachment; filename="..." then the file will download. If set to inline then it can displayed in the Web page.
If you are serving these files from Amazon S3, you can add Metadata to the file with the Key=Content-Disposition and the Value=inline.
Note: the default value is typically inline.