Pomoc pśepytaś

Glědajśo se wobšudy pomocy. Njenapominajomy was nigda, telefonowy numer zawołaś, SMS pósłaś abo wósobinske informacije pśeraźiś. Pšosym dajśo suspektnu aktiwitu z pomocu nastajenja „Znjewužywanje k wěsći daś“ k wěsći.

Dalšne informacije

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

  • 4 wótegrona
  • 9 ma toś ten problem
  • 4 naglědy
  • Slědne wótegrono wót 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?

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 <IMG SRC="D:\myfile.jpg"> 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?

Wšykne wótegrona (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
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.]