Αναζήτηση στην υποστήριξη

Προσοχή στις απάτες! Δεν θα σας ζητήσουμε ποτέ να καλέσετε ή να στείλετε μήνυμα σε κάποιον αριθμό τηλεφώνου ή να μοιραστείτε προσωπικά δεδομένα. Αναφέρετε τυχόν ύποπτη δραστηριότητα μέσω της επιλογής «Αναφορά κατάχρησης».

Learn More

<a href="D:\myfile.htm"> does not work-unlike IE, it requires added "file://"

  • 4 απαντήσεις
  • 9 έχουν αυτό το πρόβλημα
  • 1 προβολή
  • Τελευταία απάντηση από rblanks

more options

I have a number of html pages with references to other html pages on another drive. They work well with IE, but fail with FireFox. The sources have links coded like: <a href="D:\myfile.htm"> But Firefox requires: <a href="file://D:\myfile.htm"> Similar situation for I'd like not to have to go edit my already existing html files to make this work. What I don't get is why Firefox allows the use of the same "abbreviation"/"shorthand" technique in the URL field of the browser and yet not in the HTML itself.

Is this somehow a security issue? How would that be, while adding the missing text would not be?

Όλες οι απαντήσεις (4)

more options

See URI

http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

The case where you use just /directory... is a relative URI - relative, that is, to the document's base URI

D: ... is a non-standard Microsoft invention - as is the use of backslashes

more options

Non-standard or not, I have no way of predicting or knowing "what" Drive ID (port, drive device...) the reader of my CD (or flash drive, or DVD, etc.) will be using. WHAT SIMPLE HTML WILL WORK FOR BOTH BROWSERS, PLEASE?? HTML I used frequently to get back to 'home' file (on 'root' directory of medium): HREF="/FGAMHome.htm" [Note: No results below differ if "backslash" (\) used instead.] WITH CURSOR OVER ELEMENT: Firefox 11.0 Shows Firefox CLICK Action


------------------------

file:///FGAMHome.htm (*Nothing*)

IE Shows IE Action


--------------------

file:///G:/FGAMHome.htm Shows page in upper Directory. Thanks.

more options

This is an interesting & probably helpful link to my problem. Interestingly, the problem all stems from a default Firefox practice in the name of security, and I have to research the workarounds for suitability, not to mention doability.

Here's my wrinkle: I am supplying 'local' content that is completely self-contained (i.e., ALL local); while this conceptually runs 'counter' to notion of 'Internet', the point is that the application is like an old-style book but in e-book form; and of course there is no security issue (while "Work Offline" is True) since non-local links aren't used. [Put another way, some of us are using Browsers as our interface for local E-books, and browsers' features to support Internet access at same time sometimes get in the way. You'd think 'Work Offline' addresses this, but No.]

QUESTION: Does Firefox's default action in NOT supporting local links constitute a Ham-Handed Approach (i.e., faulty logic) IF it is NOT CHECKING for 'Work Offline=True' ?? If agreed, should this be considered an "Enhancement" request?

 [Note:  For those concerned about nefarious malware gathering info in a 'store & forward' manner while offline for later online use, this is a circular argument -- the damage is already done by the presence of the malware whether a browser then permits a user to go from 'one page to the next' across local files, or not.]