Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38352 > unrolled thread

Reading a local file from an HTML page

Back to article view | Back to comp.lang.javascript

Contents

  Reading a local file from an HTML page dr.j.r.stockton@gmail.com - 2020-04-02 13:29 -0700
    Re: Reading a local file from an HTML page minajaich@gmail.com - 2020-04-02 18:59 -0700
    Re: Reading a local file from an HTML page JJ <jj4public@vfemail.net> - 2020-04-03 20:18 +0700
    Re: Reading a local file from an HTML page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-04-03 10:57 -0700
      Re: Reading a local file from an HTML page dr.j.r.stockton@gmail.com - 2020-04-03 15:24 -0700
        Re: Reading a local file from an HTML page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-04-03 17:11 -0700
          Re: Reading a local file from an HTML page dr.j.r.stockton@gmail.com - 2020-04-04 05:41 -0700
        Re: Reading a local file from an HTML page "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-04-04 12:17 +0200
    Re: Reading a local file from an HTML page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-04-06 17:01 -0700
      Re: Reading a local file from an HTML page dr.j.r.stockton@gmail.com - 2020-04-13 12:11 -0700
        Re: Reading a local file from an HTML page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-04-14 10:04 -0700

#38352 — Reading a local file from an HTML page

I currently have, in a HTML page

<iframe class=FYL ID=Iframe style="width:99%; height:270px;">
</iframe>

Fram = document.getElementById("Iframe")

function DiryToIframe(Diry) {
  Fram.onload = TimeOut ? DummyF : ReadDiryFromFram
  Fram.src = Diry
  if (TimeOut) setTimeout(ReadDiryFromFram, TimeOut)
  }                                                  

and that function call would, in several browsers, put the
contents of the file given by Diry, on the same computer, into
the above iframe element, and I could then do

  var DIR = Fram.contentDocument.body
  DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8

and the variable DIR would then contain the contents of file
Diry.

That now only(?) works in Internet Explorer.

How do I set about doing that in all up-to-date browsers, disregarding
IE11 and current Edge, but including the imminent new Edge?

The whole thing must operate without user intervention, browsing
for a file name, even if the full name were known exactly, would
be intolerable.

Currently, I would be sufficiently sure that the file Diry exists;
but subsequently I will want to know whether the file does exist
before/after attempting to read it.


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [next] | [standalone]

#38354

I think it's better idea, when you just put a link to a file on webpage....

Kristjan
Tel: 372 6861327
E-mail: ro ba m man 20 2 0@ ho t mai l . co m
(Please remove spaces)

neljapäev, 2. aprill 2020 23:29.22 UTC+3 kirjutas dr.j.r...@gmail.com:
> I currently have, in a HTML page
> 
> <iframe class=FYL ID=Iframe style="width:99%; height:270px;">
> </iframe>
> 
> Fram = document.getElementById("Iframe")
> 
> function DiryToIframe(Diry) {
>   Fram.onload = TimeOut ? DummyF : ReadDiryFromFram
>   Fram.src = Diry
>   if (TimeOut) setTimeout(ReadDiryFromFram, TimeOut)
>   }                                                  
> 
> and that function call would, in several browsers, put the
> contents of the file given by Diry, on the same computer, into
> the above iframe element, and I could then do
> 
>   var DIR = Fram.contentDocument.body
>   DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8
> 
> and the variable DIR would then contain the contents of file
> Diry.
> 
> That now only(?) works in Internet Explorer.
> 
> How do I set about doing that in all up-to-date browsers, disregarding
> IE11 and current Edge, but including the imminent new Edge?
> 
> The whole thing must operate without user intervention, browsing
> for a file name, even if the full name were known exactly, would
> be intolerable.
> 
> Currently, I would be sufficiently sure that the file Diry exists;
> but subsequently I will want to know whether the file does exist
> before/after attempting to read it.
> 
> 
> -- 
>   (c) John Stockton, near London, UK.  Using Google Groups.           |
>  Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#38361

On Thu, 2 Apr 2020 13:29:16 -0700 (PDT), dr.j.r.stockton@gmail.com wrote:
> 
> That now only(?) works in Internet Explorer.
> 
> How do I set about doing that in all up-to-date browsers, disregarding
> IE11 and current Edge, but including the imminent new Edge?
> 
> The whole thing must operate without user intervention, browsing
> for a file name, even if the full name were known exactly, would
> be intolerable.
> 
> Currently, I would be sufficiently sure that the file Diry exists;
> but subsequently I will want to know whether the file does exist
> before/after attempting to read it.

You'll have to use window message to asynchronously send the child page data
in the IFRAME, to the host page which hold the IFRAME.

e.g. the host HTML page: (only the relevant code)

    <iframe id=ifr></iframe>
    <script>
    addEventListener("message", function(ev) {
      console.log(ev.data);
    });
    ifr.src = "child.html";
    </script>

The child HTML page: (only the relevant code)

    <script>
    onload = function() {
      parent.postMessage(document.documentElement.outerHTML, "*");
    };
    </script>

In above example, the message data is a string value of the HTML code for
the `html` tag including its contents.

The message data is any value which can be serialized. i.e. can not be a
function, or a circular object. Whether it's contained within another object
or not. Basically, a value which can be represented as a valid JSON data.

So, to make all of these to work, the child page must be a HTML file. If the
main data is a text file, then the text data must be wrapped within the HTML
code - preferrably using SCRIPT tag with custom MIME type. If the main data
is binary, then the binary data must be encoded using Base64 or any other
binary-to-text encoding algorithm. And when the host page receives the data,
it must decode the data back to binary if it needs to use the data in binary
form.

[toc] | [prev] | [next] | [standalone]

#38363

On Thursday, April 2, 2020 at 3:29:22 PM UTC-5, dr.j.r...@gmail.com wrote:
> I currently have, in a HTML page
> 
> <iframe class=FYL ID=Iframe style="width:99%; height:270px;">
> </iframe>
> 
> Fram = document.getElementById("Iframe")
> 
> function DiryToIframe(Diry) {
>   Fram.onload = TimeOut ? DummyF : ReadDiryFromFram
>   Fram.src = Diry
>   if (TimeOut) setTimeout(ReadDiryFromFram, TimeOut)
>   }                                                  
> 
> and that function call would, in several browsers, put the
> contents of the file given by Diry, on the same computer, into
> the above iframe element, and I could then do
> 
>   var DIR = Fram.contentDocument.body
>   DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8
> 
> and the variable DIR would then contain the contents of file
> Diry.
> 
> That now only(?) works in Internet Explorer.
> 
> How do I set about doing that in all up-to-date browsers, disregarding
> IE11 and current Edge, but including the imminent new Edge?
> 
> The whole thing must operate without user intervention, browsing
> for a file name, even if the full name were known exactly, would
> be intolerable.
> 
> Currently, I would be sufficiently sure that the file Diry exists;
> but subsequently I will want to know whether the file does exist
> before/after attempting to read it.

I think we've covered this topic a few times in the past. 

What's the use case?

[toc] | [prev] | [next] | [standalone]

#38365

On Friday, 3 April 2020 18:57:08 UTC+1, Michael Haufe (TNO)  wrote:
> On Thursday, April 2, 2020 at 3:29:22 PM UTC-5, dr.j.r...@gmail.com wrote:
> > I currently have, in a HTML page
> > 
> > <iframe class=FYL ID=Iframe style="width:99%; height:270px;">
> > </iframe>
> > 
> > Fram = document.getElementById("Iframe")
> > 
> > function DiryToIframe(Diry) {
> >   Fram.onload = TimeOut ? DummyF : ReadDiryFromFram
> >   Fram.src = Diry
> >   if (TimeOut) setTimeout(ReadDiryFromFram, TimeOut)
> >   }                                                  
> > 
> > and that function call would, in several browsers, put the
> > contents of the file given by Diry, on the same computer, into
> > the above iframe element, and I could then do
> > 
> >   var DIR = Fram.contentDocument.body
> >   DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8
> > 
> > and the variable DIR would then contain the contents of file
> > Diry.
> > 
> > That now only(?) works in Internet Explorer.
> > 
> > How do I set about doing that in all up-to-date browsers, disregarding
> > IE11 and current Edge, but including the imminent new Edge?
> > 
> > The whole thing must operate without user intervention, browsing
> > for a file name, even if the full name were known exactly, would
> > be intolerable.
> > 
> > Currently, I would be sufficiently sure that the file Diry exists;
> > but subsequently I will want to know whether the file does exist
> > before/after attempting to read it.
> 
> I think we've covered this topic a few times in the past. 

We did; but circumstances prevented immediate implementation, and I cannot now locate the answer. 

> What's the use case?

Apologies to all, since I was mistaken as to where the code was actually not working nowadays.  The code I gave works, in at least 3 current browsers.  The contents of the page read first, code as given, do visibly appear in the desired textarea (in normal operation they are overwritten quicker than the eye can see, after the information content has been digested). The whole page worked, in all browsers tried, until the "same origin" policy implementation changed.  The problem lies with subsequent pages read by different (but similar) code.

I still think that "same origin" policy should allow a page running locally (no server) to access the DOM content of another page in the same directory or a child directory.  But, as implemented, it apparently does not.


Anyway, the use case is that I have a 64-bit Windows 10 PC (mid-range mid-2014, C: is now a SSD) with a folder C:\H, which contains a file INDEX.HTM indexing a pseudo-Web site.

At boot time, and whenever necessary if the facts change, a batch file lists (with DIR \B \S) in C:\H\$DIR.TXT all the files and folders in C:\H and sub-folders.  That enables me to check that a file exists before trying to open it.  When that list has been read, I store the information more compactly, disregarding at this stage all files of types that I don't want to know about (e.g. ones with backup extensions).

This represents, in the textarea, parts of the collected information

C:\H\DISCREPS.BAT
C:\H\DM034-24.HTM
C:\H\DOG1.JPG
...
C:\H\ZIPFILES\XALL.EXE
C:\H\ZIPFILES\Z.BAT
*
C:\H\20010716
C:\H\BENC

That part works.  It can be eliminated, I expect, by using try ... catch in subsequent file reads

NOW, THE REAL WORK OF THE PAGE BEGINS.

As is, the file of initial immediate interest is probably, but not necessarily, INDEX.HTM.

Recursively: I read the file of immediate interest into an IFRAME, creating a DOM tree.  I note everything of interest in that tree, the final stage of which is to scan the <a href="xxxx.EXT"> elements.  For each of those, I check that the named file exists, reporting if not.  Then, if the EXT part indicates that it is an HTML file, and it has not previously been read, it becomes the file of immediate interest, and recursion occurs.  Eventually, recursion ends.

It's like spidering a DOM tree, but the tree is now a rat's nest - it probably should be called a directed graph of some sort.

For links of the form <a href="xxxx.EXT#ankor">, a check is made of whether the anchor exists in xxxx.EXT. I must see whether it understands IDs as well.

Other things are checked, as convenient and some optionally; for example, it reports unused anchors and can report instances of YYYY-MM-DD DoW in which DoW is wrong.

That's probably enough context.  So what I need is

function GetDomTree(FileName) { // File will exist
  // code
  return DomTree }

or something like

function GetDomTree(FileName) { // File should exist
  // code with try ... catch
  return FileExists ? DomTree : null }

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


FOOTNOTE : latest result, for 198 scanned files, using IE11 ("Anchors not used" is WRONG in IE11; the reported anchors are all '') :-

   Consolidation : Time taken : 34917 ms.
.
. TargetsErrors - Targets missing  :      0
. TargetsErrors - Anchors not used :     92
. TargetsErrors - Anchors repeated :      0
. ID_unoriginal - ID rpt of Target :      0
. FolderMissing - Linked and Missing,     0 calls of      0 names
. Files_Missing - Linked and Missing,     0 calls of      0 names
. Files_Unfound - Unfound but Linked,     0 calls of      0 names
. Pages_Unhappy - Linked for Unfound,     0 calls of      0 names
. Date_Problems - Bad Date / Bad Day,     4 calls of      4 names
.
. UploadsNeeded - Transfer to Server, 12979 calls of    861 names
. FolderPresent - Linked and Present,    28 calls of      5 names
. Files_Present - Linked and Present, 25900 calls of    855 names
. Domains_Cited - Domains Linked For,  3159 calls of   1149 names
. LocalOutLinks - X-site Local Files,   145 calls of    105 names
. AllLocalLinks - Local Files Linked, 13123 calls of   4740 names
. AllLocalFiles - Total Files Linked, 13123 calls of    966 names
. All_LinkTexts - All Texts of Links, 15703 calls of   7408 names
. SRCattributes - 'SRC =' Attributes,   699 calls of    174 names
. Unlike8point3 - Vexing Name Format,    29 calls of      7 names
. Anchors sighted  :   3698
. IDs sighted      :    939
. SRCs sighted     :    699
. Links, total     :  15704
. Links, other     :   3280
. Protocols Used   : 'file:' 13123, 'ftp:' 73, 'http:' 2826, 'https:' 245, 'javascript:' 5, 'mailto:' 4, 'news:' 114, 'trump:' 1, 'view-source:' 12.
. File Extns Used  : '' 1, '.awk' 3, '.bat' 44, '.com' 2, '.css' 7, '.dat' 2, '.dok' 1, '.dpr' 1, '.exe' 136, '.gif' 115, '.hta' 4, '.htm' 11270, '.ico' 1, '.jpg' 25, '.js' 365, '.log' 1, '.odt' 2, '.out' 2, '.ovl' 1, '.pas' 303, '.pif' 1, '.pl' 2, '.png' 213, '.ps1' 8, '.rtf' 1, '.scr' 7, '.shtml' 14, '.txt' 220, '.vbs' 3, '.xhtml' 2, '.zip' 193.


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#38366

On Friday, April 3, 2020 at 5:24:34 PM UTC-5, dr.j.r...@gmail.com wrote:

> 
> Anyway, the use case is that I have a 64-bit Windows 10 PC (mid-range mid-2014, C: is now a SSD) with a folder C:\H, which contains a file INDEX.HTM indexing a pseudo-Web site.
> 
> At boot time, and whenever necessary if the facts change, a batch file lists (with DIR \B \S) in C:\H\$DIR.TXT all the files and folders in C:\H and sub-folders.  That enables me to check that a file exists before trying to open it.  When that list has been read, I store the information more compactly, disregarding at this stage all files of types that I don't want to know about (e.g. ones with backup extensions).
> 
> This represents, in the textarea, parts of the collected information
> 
> C:\H\DISCREPS.BAT
> C:\H\DM034-24.HTM
> C:\H\DOG1.JPG
> ...
> C:\H\ZIPFILES\XALL.EXE
> C:\H\ZIPFILES\Z.BAT
> *
> C:\H\20010716
> C:\H\BENC
> 
> That part works.  It can be eliminated, I expect, by using try ... catch in subsequent file reads
> 
> NOW, THE REAL WORK OF THE PAGE BEGINS.
> 
> As is, the file of initial immediate interest is probably, but not necessarily, INDEX.HTM.
> 
> Recursively: I read the file of immediate interest into an IFRAME, creating a DOM tree.  I note everything of interest in that tree, the final stage of which is to scan the <a href="xxxx.EXT"> elements.  For each of those, I check that the named file exists, reporting if not.  Then, if the EXT part indicates that it is an HTML file, and it has not previously been read, it becomes the file of immediate interest, and recursion occurs.  Eventually, recursion ends.
> 
> It's like spidering a DOM tree, but the tree is now a rat's nest - it probably should be called a directed graph of some sort.
> 
> For links of the form <a href="xxxx.EXT#ankor">, a check is made of whether the anchor exists in xxxx.EXT. I must see whether it understands IDs as well.
> 
> Other things are checked, as convenient and some optionally; for example, it reports unused anchors and can report instances of YYYY-MM-DD DoW in which DoW is wrong.
> 
> That's probably enough context.  So what I need is
> 
> function GetDomTree(FileName) { // File will exist
>   // code
>   return DomTree }
> 
> or something like
> 
> function GetDomTree(FileName) { // File should exist
>   // code with try ... catch
>   return FileExists ? DomTree : null }
> 

It sounds to me you're just trying to build a sitemap. Why not simply crawl the site from index.html and validate the links?

Perform Breadth-First-Search on the document.links of the document where index.html is the start.

Then for each link attempt to fetch the target to see if it exists.

You can store the results in localStorage for future use. 

This should eliminate the need for a BAT file as well as issues with CORS.

[toc] | [prev] | [next] | [standalone]

#38368

On Saturday, 4 April 2020 01:11:07 UTC+1, Michael Haufe (TNO)  wrote:
> On Friday, April 3, 2020 at 5:24:34 PM UTC-5, dr.j.r...@gmail.com wrote:

> > ...
> > ... So what I need is
> > 
> > function GetDomTree(FileName) { // File will exist
> >   // code
> >   return DomTree }
> > 
> > or something like
> > 
> > function GetDomTree(FileName) { // File should exist
> >   // code with try ... catch
> >   return FileExists ? DomTree : null }
> > 


Remember that this is a page that I've been using for a long time, and it was necessarily written in that subset of old JavaScript that I then knew.

> It sounds to me you're just trying to build a sitemap. Why not simply crawl the site from index.html and validate the links?

No. I don't want a sitemap; though I do the surveying that a map would need, I don't keep enough observations for a map.  I do crawl the site, generally from INDEX.HTM, and validate the links.  I also validate any other connections, such as <IMG SRC="AAA.KPQ"> - or at least such as I know how to find.  I also report the content of various lists built during processing.
 
> Perform Breadth-First-Search on the document.links of the document where index.html is the start.

I have what I think is an excellent reason for not *necessarily* starting at INDEX.HTM - I can start at another page containing one or more intentional errors, in order to test what the code actually does in those cases; that page does not need to link to any other existing pages.  Also, I have a file, created at each boot or later, which contains links to all *.HTM files in the folder, about 30% of which are not on the main site; testing that has its uses.

> Then for each link attempt to fetch the target to see if it exists.

I use my directory file to see if the target exists, because I did not know how to deal with the "File Not Found" case.  I don't need to improve on that, because it works.  I suppose that you would suggest try...catch - but then to test the Not Found case I would need either to create a link to a non-file or hide a file, and it's easier to falsify the directory file, which can be recreated in the time needed for a click and six keystrokes.
 
> You can store the results in localStorage for future use. 

No need, and I don't know how to.
 
> This should eliminate the need for a BAT file as well as issues with CORS.

I knew nothing of CORS.  It appears to be about WEB pages, from servers, only.


But I need to have one (or both) of the GetDomTree functions, because I have the name of a file and I want to be able to read the DOM tree which that file generates when loaded. ... thought ... research ... I certainly want to read parts of the Document Object - the links and anchors arrays ---  I want to read the contentDocument.

So I need a getContentDocument(FileName) function, where the named file is directly accessible to the current user of the device - it will be in the current folder of the page that is running, or in the folder tree rooted in that current folder.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#38367

dr.j.r.stockton@gmail.com wrote on 04 Apr 2020 in comp.lang.javascript:
> We did; but circumstances prevented immediate implementation, and I
> cannot now locate the answer. 

Perhaps not directly applicable in your case, 
but I bypass all same-origin annoyance by uploding 
the html as a scripted string. 

I make a second file [2nd.jshtml] enclosing the whole content in:

let secondFileContent = `xxxx`;

where xxxx is the content with newlines and all.
[NB: these `` are backticks!]

You would need to escape backticks ` to \`
in the text, but they probably are not there anyway,
and also escape ${ to \${.

You can easily do all this with a .bat file or with cscript/wscript.

Then the string is available in the main page by

<script src='2nd.jshtml'></script>
<script>
console.log(secondFileContent);
</script>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#38369

On Thursday, April 2, 2020 at 3:29:22 PM UTC-5, dr.j.r...@gmail.com wrote:
> I currently have, in a HTML page
> 
> <iframe class=FYL ID=Iframe style="width:99%; height:270px;">
> </iframe>
> 
> Fram = document.getElementById("Iframe")
> 
> function DiryToIframe(Diry) {
>   Fram.onload = TimeOut ? DummyF : ReadDiryFromFram
>   Fram.src = Diry
>   if (TimeOut) setTimeout(ReadDiryFromFram, TimeOut)
>   }                                                  
> 
> and that function call would, in several browsers, put the
> contents of the file given by Diry, on the same computer, into
> the above iframe element, and I could then do
> 
>   var DIR = Fram.contentDocument.body
>   DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8
> 
> and the variable DIR would then contain the contents of file
> Diry.
> 
> That now only(?) works in Internet Explorer.
> 
> How do I set about doing that in all up-to-date browsers, disregarding
> IE11 and current Edge, but including the imminent new Edge?
> 
> The whole thing must operate without user intervention, browsing
> for a file name, even if the full name were known exactly, would
> be intolerable.
> 
> Currently, I would be sufficiently sure that the file Diry exists;
> but subsequently I will want to know whether the file does exist
> before/after attempting to read it.


What is the url of the page? The following seems to work fine in IE11, Edge Brave, and Firefox:

```
<!doctype html>
<html>
    <head>
        <meta charset="utf-8">
        <title></title>
    </head>
    <body>
        <h2>Directory List</h2>
        <iframe id="dir"></iframe>
        <h2>Loaded File</h2>
        <iframe id="out"></iframe>
        <script>
            let winDir = document.getElementById('dir'),
                winOut = document.getElementById('out');

            winDir.onload = function(){
                let txtList = this.contentDocument.documentElement.innerText
                winOut.src = txtList
            }

            winDir.src = 'dir.txt'
        </script>
    </body>
</html>
```

The localhost url is: <http://iframe-test.local/>

If I open the page with the file system url:
<file:///C:/inetpub/wwwroot/iframe-test/index.html>

The loading will fail. I assume this is your problem.

Are you not using IIS?

[toc] | [prev] | [next] | [standalone]

#38370

On Tuesday, 7 April 2020 01:01:31 UTC+1, Michael Haufe (TNO)  wrote:
> On Thursday, April 2, 2020 at 3:29:22 PM UTC-5, dr.j.r...@gmail.com wrote:
 
> > How do I set about doing that in all up-to-date browsers, disregarding
> > IE11 and current Edge, but including the imminent new Edge?

I have now seen the new Edge.  As it does not show a HOME icon, and I could not rapidly find a way of making it show one, I have lost interest in using it.

> What is the url of the page? The following seems to work fine in IE11, Edge Brave, and Firefox:

It has no URL; all this is entirely on a Windows PC, on which the only relevant non-default applications are this page and a nice browser to run it.

> If I open the page with the file system url:
> <file:///C:/inetpub/wwwroot/iframe-test/index.html>
> 
> The loading will fail. I assume this is your problem.
> 
> Are you not using IIS?

I am not using IIS.  I would be content to not use even a browser.


What I need is

function GetDomTree(FileName) { // File will exist
  // code
  return DomTree }

or similar.

Since the current browser implementations of the "same origin" policy exclude this case of a same origin, the question has become that of whether VBScript and/or JScript natively possesses such a function or a fairly direct means of writing one; VBScript seems much better or more widely documented than JScript, but VBScript docs + ECMA 3 suffice for JScript.

I seem to recollect reading that the VBScript API(s) include a means of generating a DOM tree; if so, I just would need to know the name of the API routine, and Google should let me find the rest.

Then, I could port my JavaScript to JScript, running with WSH at the MS-DOS Command Line, or in an HTA.  I don't know how long it would take me to do that, though.

However, I now have an alternative to running this page in Windows 10 & MSIE 11; I have revived my old WinXP PC, which has Firefox 52.9.0esr, and the page works properly there.  My normal backup scheme already gets enough onto a USB stick, and the XP PC can process it there at its leisure.


But a further question, about the DOM :

I know of these >20-year-old pseudo-array properties of the document object : anchors, links, forms, images (& applets, embeds); are there now any other "similar" objects?

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#38371

On Monday, April 13, 2020 at 2:11:43 PM UTC-5, dr.j.r...@gmail.com wrote:
> On Tuesday, 7 April 2020 01:01:31 UTC+1, Michael Haufe (TNO)  wrote:

> I have now seen the new Edge.  As it does not show a HOME icon, and I could not rapidly find a way of making it show one, I have lost interest in using it.

It's a radio button in the settings. It says: "Show the home button"
 
> > What is the url of the page? The following seems to work fine in IE11, Edge Brave, and Firefox:
> 
> It has no URL; all this is entirely on a Windows PC, on which the only relevant non-default applications are this page and a nice browser to run it.

Assuming you opened the html page in a browser, it most certainly does have a url. I am also guessing that it's a 'file://' url.

> > If I open the page with the file system url:
> > <file:///C:/inetpub/wwwroot/iframe-test/index.html>
> > 
> > The loading will fail. I assume this is your problem.
> > 
> > Are you not using IIS?
> 
> I am not using IIS.  I would be content to not use even a browser.

Given that these are html pages, you're going to have difficulties viewing rendered content without a browser. 

> What I need is
> 
> function GetDomTree(FileName) { // File will exist
>   // code
>   return DomTree }
> 
> or similar.

Your challenge is how to obtain "FileName". You don't want to use <input type="file">, and you don't want to use IIS like you should be doing in order to satisfy the security requirements. 

> Since the current browser implementations of the "same origin" policy exclude this case of a same origin, the question has become that of whether VBScript and/or JScript natively possesses such a function or a fairly direct means of writing one; VBScript seems much better or more widely documented than JScript, but VBScript docs + ECMA 3 suffice for JScript.

Hardly, they are both sufficiently documented in the *.chm file:

<https://www.robvanderwoude.com/wshlinks.php>

Also, WSH is in maintenance mode now and is pending complete deprecation and removal sooner than later. 

<https://twitter.com/ScriptingGuys/status/175229475812945921>

> I seem to recollect reading that the VBScript API(s) include a means of generating a DOM tree; if so, I just would need to know the name of the API routine, and Google should let me find the rest.

The DOM is an API, it is exposed to any script used in a browser.

> Then, I could port my JavaScript to JScript, running with WSH at the MS-DOS Command Line, or in an HTA.  I don't know how long it would take me to do that, though.

How would that help you then? You started this thread talking about using an iframe. What would a batch file or WSH file give you?

> However, I now have an alternative to running this page in Windows 10 & MSIE 11; I have revived my old WinXP PC, which has Firefox 52.9.0esr, and the page works properly there.  My normal backup scheme already gets enough onto a USB stick, and the XP PC can process it there at its leisure.

Or... put your website in the proper folder and be done with it. IIS is made for this.

> But a further question, about the DOM :
> 
> I know of these >20-year-old pseudo-array properties of the document object : anchors, links, forms, images (& applets, embeds); are there now any other "similar" objects?

Yes:

<https://developer.mozilla.org/en-US/docs/Web/API/Document>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web