I have used <img> tag in html for displaying images. The image gets displayed in Internet Explorer 10, but it is not visible in mozilla, chrome. Could someone please tell me the reason why?
<img src="file:///d:/maruthi.jpg" style="width: 150px; height: 140px;" alt="Photo">
Chrome stops access to local file:// links from with in http:// page for security reasons by default.
file:// is not allowed in Chrome and Firefox for security reasons by default, but this answer shows you how to change those settings. Really, you should set up a lightweight local server.
The <img> tag is standard across all browsers (except text-based browsers like Lyx). That should work, however given that it is a local path it may be that you are testing it in a different environment that can't access that path?
Review this wikipedia page on the file URI scheme and it will also highlight that some browser will limit access to local files for security reasons.
The original title to OP's question is NOT misleading - it is perfectly valid. However, they did not say whether they were using Windows or Linux. Windows and Windows programs (like DOS from which they originated) are completely indiscriminate with regard to the use of upper or lower case in filenames.
Two possibilities to consider:
Linux is fully case sensitive, including its use of filenames. Yourfile.JPG is NOT recognized as being the same as Yourfile.jpg! I recently migrated from Windows to Linux and encountered exactly the same problem with Firefox. It displayed images in sites on the internet, but not in perfectly valid local HTML and CSS markup. Later, I noticed that the Windows image-editing program I'd been using had saved all the images with uppercase .JPG or .PNG extensions. A few that I'd previously renamed manually had lowercase extensions - these DID display normally! Linux 'properties' for those files identified them correctly as JPEG files, while those with uppercase extensions were simply identified as IMAGE. Also, my markup references all images with lowercase extensions (professional usage). When non-displaying image file extensions were changed to lowercase, they all displayed correctly.
If Steve is still using Windows, it's possible that Internet Explorer is displaying local images for the same reason as above. Firefox, though, uses a different engine (Mozilla) and, being open-source, maybe more strict with regards to case sensitivity in file names. However, I'm not in a position to check this out. Maybe someone else can test.
i have used in jsp as this : and working in firefox and chrome
<a href="Welcome.jsp"><img src="home.jpg">
Related
I'm trying to upload my resume to a company's website and I'm getting a C:\fakepath\myfilename,
Does this means that my file can't be uploaded to the website? or is it just for security reasons?
(I tried uploading with Microsoft Edge and Chrome)
When a file is chosen using an <input type="file">, the real path to the source file is not shown in the input's value attribute for obvious security reasons. Instead, the filename is shown, with C:\fakepath\ appended to the beginning of it. There are some historical reasons for this quirk, but it is supported across all modern browsers, and in fact is defined in the spec.
So, the browser shows the fake path for security reasons and it will not cause any issue with the file upload functionality. The file upload will work fine.
References:
Refer to the second point of the Notes section
FileUpload in Chrome giving some fake path value
FakePath issue in Chrome browser
So ive been through several posts and searches, but im still at a loss for how to get Chrome to display images when the src attribute uses a file thats located on another server. Im getting the image and setting its path via a custom file browser that Im hooking into CKeditor with. Works fine in IE, just not chrome.
This is for an intranet, and some of the image content is stored off of the web server. Although IE displays fine, it seems that Chrome does not like to display images with the src attribute is of a format like
file://server_name/share_name/folder_1/file_1.png
Strange, even though Chrome will pass the users identity, so its not a security issue. Also, if I take the path and directly paste it in the url window of Chrome, it displays fine. Just not when a img src value.
If this was just a page on its own, I could use a custom handler and write to the response stream, but this needs to work with a content editor.
Id like to include Chrome since many of our users have it and use it daily, but our default is IE.
Are there any file url schemes, or Chrome settings that will override these issues?
The issue may not be the image or URL format. I'd wager that it's browser security restrictions.
To ensure that maliciously designed web pages can't access a user's local files, accessing any data from the user's filesystem (especially network drives) is generally disallowed in most modern browsers. (At least in their default configuration. There may be policies or runtime parameters to override these for testing purposes such as Chrome's --disable-web-security parameter, but these are purposefully difficult to turn off.)
If you want the content to display across all browsers, you'll likely need to deliver it via HTTP(s) like the rest of the page content.
I have a Razor MVC application that contains a link to open a PDF stored on a file server. My code works when I run it in Visual Studio but is not working when I try it on production on the same computer. I click the link and nothing happens, I can see the path when I hover over it though. There are no errors or anything. I've tried all browsers but only really care about IE.
View
Image when I hover over the link
Any ideas why this is not working?
Filesystem URLs from remote pages (i.e. pages on other protocols like http:// or even other directories in the file system) are blocked by modern browsers for security reasons.
Here is a page describing the behaviour for Firefox (along with reasons why it exists).
Internet Explorer has joined the ranks of these modern browsers:
By default, Internet Explorer prevents navigation to Uniform Resource
Identifiers (URIs) using the "file:" protocol when the current URL
matches the following conditions:
The current URL is opened in the Internet zone or the Restricted Sites zone.
The current URL uses a protocol other than "file:".
This is a security measure designed to
prevent malicious sites from accessing system file objects.
This can be changed, but only on a per-client basis (see the MSDN article for details.)
There is a standard from Adobe that in theory specifies opening PDF documents from a link clicked in a browser in a way to open specific sections (AKA "anchor", "named reference") of PDF document. This functionality should be of great help if one would like to refer to a specific portion of large PDF (such as some standard or specification).
However, from what I see now, support for this standard is close to non-existent.
For example, these links should open Scala Reference PDF at section 3.2.6, "Annotated Types":
http://www.scala-lang.org/docu/files/ScalaReference.pdf#subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#nameddest=subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=23
(Techincally, variant #3 should open page #23, which is essentially the same destination)
Is there a working way (may be with a couple of shims, proprietary wrappers or whatever else) to make this work on majority of systems? What is the usage share of Adobe Reader plugin, should I care about other systems?
If it's not possible, at least I'd like to find a working solution for every platform (i.e. Windows, Linux, Mac) that I could recommend to my site's users if they want to be able to use named destination links.
From what I've tested:
Windows, MSIE/Firefox/Chrome, Adobe Acrobat Reader plugin - all variants work with version 9+, but:
MSIE has a weird caching issue (i.e. anchor does not work until document was cached)
Older versions do not work
It has issues with link format: generally, it should be regular absolute link to a real web server, starting with "http://". Relative links, samba-style links (\\HOST\dir\file.pdf#something), anything else besides "http" (or probably, "https") scheme won't work
Windows, any browsers set up to run Adobe Acrobat Reader as a separate process - does not work
Windows, any browsers, FoxIt Reader - does not work
Windows, any browsers, CutePDF - does not work
Linux/Konqueror/Okular - only variant #1 works
Linux, any other browsers set up to run Okular or any other PDF viewer as external process - does not work (as browser does not pass any "#arguments" in a command line)
Any OS, Firefox 15+ PDF.js internal PDF viewer - does not work
I'd appreciate if you'd try it to test in various different combinations.
What seems to work in general is variant #4 but using the number of the page as in actual division into pages in the PDF document, in this case
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=31
The PDF document has page numbers that start from the content proper, after the table of content, but that numbering differs from the one to be used in #page=...
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.