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

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

Firefox changed IFRAME behaviour - I need a remedy??

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

Contents

  Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-07-20 12:53 -0700
    Re: Firefox changed IFRAME behaviour - I need a remedy?? Andrew Poulos <ap_prog@hotmail.com> - 2019-07-21 15:15 +1000
    Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-07-22 03:07 -0700
    Re: Firefox changed IFRAME behaviour - I need a remedy?? Martin Honnen <martin.honnen@gmx.de> - 2019-07-22 16:20 +0200
      Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-07-30 08:20 -0700
    Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-07-30 18:24 -0700
      Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-07-31 04:14 -0700
        Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-07-31 05:32 -0700
          Re: Firefox changed IFRAME behaviour - I need a remedy?? "R.Wieser" <address@not.available> - 2019-07-31 18:22 +0200
            Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-02 02:37 -0700
              Re: Firefox changed IFRAME behaviour - I need a remedy?? "R.Wieser" <address@not.available> - 2019-08-02 13:38 +0200
                Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-02 05:59 -0700
                  Re: Firefox changed IFRAME behaviour - I need a remedy?? "R.Wieser" <address@not.available> - 2019-08-02 17:55 +0200
                  Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-02 15:57 -0700
                    Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-03 06:11 -0700
                    Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-04 11:44 +0200
                Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-02 15:10 -0700
                  Re: Firefox changed IFRAME behaviour - I need a remedy?? "R.Wieser" <address@not.available> - 2019-08-03 08:59 +0200
                  OT: Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-03 05:18 -0700
                    Re: OT: Re: Firefox changed IFRAME behaviour - I need a remedy?? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-08-03 15:27 +0200
                      Re: OT: Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-03 09:28 -0700
                        Re: OT: Re: Firefox changed IFRAME behaviour - I need a remedy?? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-08-04 12:32 +0200
                  Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-04 11:30 +0200
                    Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-04 15:31 -0700
                      Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-05 13:48 +0200
                        Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-05 16:51 -0700
                          Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-07 01:42 +0200
                            Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-07 01:47 -0700
                              Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-08 20:56 +0200
                                Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-08 13:16 -0700
                                  Re: Firefox changed IFRAME behaviour - I need a remedy?? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2019-08-08 23:57 -0600
                                  Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-09 12:48 +0200
                      Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-05 06:37 -0700
                        Re: Firefox changed IFRAME behaviour - I need a remedy?? John G Harris <niam@jghnorth.org.uk.invalid> - 2019-08-05 18:46 +0100
                          Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-06 03:39 -0700
                        Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-05 17:30 -0700
              Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-02 15:05 -0700
        Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-07-31 18:58 -0700
          Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-02 05:01 -0700
            Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-02 16:07 -0700
              Re: Firefox changed IFRAME behaviour - I need a remedy?? dr.j.r.stockton@gmail.com - 2019-08-03 08:19 -0700
                Re: Firefox changed IFRAME behaviour - I need a remedy?? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-08-03 18:42 -0700
                  Re: Firefox changed IFRAME behaviour - I need a remedy?? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-08-04 11:27 +0200

Page 1 of 3  [1] 2 3  Next page →

#36966 — Firefox changed IFRAME behaviour - I need a remedy??

With Fram being an IFRAME element of the .HTM page P that is
running, which element has been loaded with content by
src=SomeString, and both and the file F indicated by
SomeString being on the same drive of a Windows PC, I have been
using Fram.contentDocument.body to get, in P, either the DOM tree
of F if F is a pseudo-Web page or the text of F it is a .TXT file.

That used to work (see CODE below) on most or all browsers.
It stopped working on various browsers until, up to a few
days ago, I could only use Firefox or MSIE for this work.
No problem there, as Firefox is my preferred browser.  But,
since updating Firefox to 68.0 or 68.0.1, it no longer works
there.

/***
     In Edge, I can read .TXT files thusly; but the main page of
     interest declines to present its "Start" button, so there is
     some other difference affecting my code.
***/

That, I presume, is because Firefox now interprets the
same-origin policy for allowing access to IFRAME contents
as other browsers have taken to using (I cannot comprehend
why two files on the same local drive are not considered
as same-origin, but there it is).

The code still works in IE11 - and as Microsoft are now
pressing the use of Edge instead of IE, there seems some
reason to hope that they are not likely to make the same
change in IE.

However, I see that I have noted (long ago) that, in
this work, IE had other peculiarities best dealt with
by not using IE.

So what suggestions do you all have?  I want the job
to run in a browser with default settings, since I
want it to be able to run on computers other than those
I own - though the main use will be on my main (at the
time) PC.  I would like it to work on non-PC browsers,
though I don't yet know of anyone who uses such.

I don't want to use true World-Wide-Web pages for this.

I don't want to have to run a local Web server.

I should, I think, be able to re-use MH's previous
assistance and make the job an HTA - but would I be
able to get a DOM tree corresponding to F (I rule
out writing my own parser)?

I could, in principle, pull the JavaScript out of my
.HTM page P and use WScript or CScript to execute it;
but that would require a parser with DOM output and
major rework of the I/O, at least.

I could revert to using my XP PC, which has an older Firefox
which cannot be updated there, but that PC is not at all healthy.

Thoughts?  Suggestions?

CODE (which traps the case where the next part cannot work):

function ReadDiryFromFram() { var DIR
  try { DIR = Fram.contentDocument.body }
    catch(e) { TXAR.value = "FAIL" ; return }
  // DoMoreWork(DIR)
  }


H'mmm - perhaps I should look into the "Edge: no start
button" situation first.

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

[toc] | [next] | [standalone]

#36970

On 21/07/2019 5:53 am, dr.j.r.stockton@gmail.com wrote:
> 
> With Fram being an IFRAME element of the .HTM page P that is
> running, which element has been loaded with content by
> src=SomeString, and both and the file F indicated by
> SomeString being on the same drive of a Windows PC, I have been
> using Fram.contentDocument.body to get, in P, either the DOM tree
> of F if F is a pseudo-Web page or the text of F it is a .TXT file.
> 
> That used to work (see CODE below) on most or all browsers.
> It stopped working on various browsers until, up to a few
> days ago, I could only use Firefox or MSIE for this work.
> No problem there, as Firefox is my preferred browser.  But,
> since updating Firefox to 68.0 or 68.0.1, it no longer works
> there.

Perhaps this link has info that helps
<http://kb.mozillazine.org/Links_to_local_pages_do_not_work>

Andrew Poulos

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

#36974

On Saturday, July 20, 2019 at 2:53:15 PM UTC-5, dr.j.r...@gmail.com wrote:
> [...]
> That, I presume, is because Firefox now interprets the
> same-origin policy for allowing access to IFRAME contents
> as other browsers have taken to using (I cannot comprehend
> why two files on the same local drive are not considered
> as same-origin, but there it is).
>
> [...]
>
> So what suggestions do you all have?  I want the job
> to run in a browser with default settings, since I
> want it to be able to run on computers other than those
> I own - though the main use will be on my main (at the
> time) PC.  I would like it to work on non-PC browsers,
> though I don't yet know of anyone who uses such.
> 
> I don't want to use true World-Wide-Web pages for this.
> 
> I don't want to have to run a local Web server.


If you use absolute or relative paths to your webpages then it will work fine.

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

#36975

On 20.07.2019 21:53, dr.j.r.stockton@gmail.com wrote:
> 
> With Fram being an IFRAME element of the .HTM page P that is
> running, which element has been loaded with content by
> src=SomeString, and both and the file F indicated by
> SomeString being on the same drive of a Windows PC, I have been
> using Fram.contentDocument.body to get, in P, either the DOM tree
> of F if F is a pseudo-Web page or the text of F it is a .TXT file.
> 
> That used to work (see CODE below) on most or all browsers.
> It stopped working on various browsers until, up to a few
> days ago, I could only use Firefox or MSIE for this work.
> No problem there, as Firefox is my preferred browser.  But,
> since updating Firefox to 68.0 or 68.0.1, it no longer works
> there.
> 
> /***
>       In Edge, I can read .TXT files thusly; but the main page of
>       interest declines to present its "Start" button, so there is
>       some other difference affecting my code.
> ***/
> 
> That, I presume, is because Firefox now interprets the
> same-origin policy for allowing access to IFRAME contents
> as other browsers have taken to using (I cannot comprehend
> why two files on the same local drive are not considered
> as same-origin, but there it is).

There has been a change in FF 68 following the 
https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730, 
unfortunately https://bugzilla.mozilla.org/show_bug.cgi?id=1558299 is 
not accessible to most mortals it seems.

https://www.fxsitecompat.dev/en-CA/docs/2019/local-files-are-now-each-given-a-different-origin/ 
is info for mortals.

But you should at least see a warning or error in the developer console 
you can open with F12 if the same origin policy is indeed what prevents 
your code from accessing contents.

Mozilla seems to be aware they have broken lots of features that way but 
https://bugzilla.mozilla.org/show_bug.cgi?id=1566172 suggests they want 
to adapt them to "other browser" which will probably mean looking what 
Chromium based browsers do.

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

#37005

On Monday, 22 July 2019 15:20:38 UTC+1, Martin Honnen  wrote:
> On 20.07.2019 21:53, JRS wrote:

Regret the delay : excessively hot weather, getting leaks mended,
helping an immigrant friend who has a bad employer *and* had her
dish-to-TV cable cut by a broadband installer *and* ... .
 
> > That, I presume, is because Firefox now interprets the
> > same-origin policy for allowing access to IFRAME contents
> > as other browsers have taken to using (I cannot comprehend
> > why two files on the same local drive are not considered
> > as same-origin, but there it is).
> 
> There has been a change in FF 68 following the 
> https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730, 
> unfortunately https://bugzilla.mozilla.org/show_bug.cgi?id=1558299 is 
> not accessible to most mortals it seems.
> 
> https://www.fxsitecompat.dev/en-CA/docs/2019/local-files-are-now-each-given-a-different-origin/ 
> is info for mortals.

That appears to be an explanation of using a sledgehammer to crack a nut, causing unnecessary collateral damage

 
> But you should at least see a warning or error in the developer console 
> you can open with F12 if the same origin policy is indeed what prevents 
> your code from accessing contents.

In Firefox, I would get console "TypeError: Fram.contentDocument
is null", except that 
           DIR = Fram.contentDocument.body
is in a try-catch loop in which the catch part gives a
conspicuous screen message and abandons the job.

Thanks.

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

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

#37007

On Saturday, July 20, 2019 at 2:53:15 PM UTC-5, dr.j.r...@gmail.com wrote:
> With Fram being an IFRAME element of the .HTM page P that is
> running, which element has been loaded with content by
> src=SomeString, and both and the file F indicated by
> SomeString being on the same drive of a Windows PC, I have been
> using Fram.contentDocument.body to get, in P, either the DOM tree
> of F if F is a pseudo-Web page or the text of F it is a .TXT file.
> 
> That used to work (see CODE below) on most or all browsers.
> It stopped working on various browsers until, up to a few
> days ago, I could only use Firefox or MSIE for this work.
> No problem there, as Firefox is my preferred browser.  But,
> since updating Firefox to 68.0 or 68.0.1, it no longer works
> there.
> 
> /***
>      In Edge, I can read .TXT files thusly; but the main page of
>      interest declines to present its "Start" button, so there is
>      some other difference affecting my code.
> ***/
> 
> That, I presume, is because Firefox now interprets the
> same-origin policy for allowing access to IFRAME contents
> as other browsers have taken to using (I cannot comprehend
> why two files on the same local drive are not considered
> as same-origin, but there it is).
> 
> The code still works in IE11 - and as Microsoft are now
> pressing the use of Edge instead of IE, there seems some
> reason to hope that they are not likely to make the same
> change in IE.
> 
> However, I see that I have noted (long ago) that, in
> this work, IE had other peculiarities best dealt with
> by not using IE.
> 
> So what suggestions do you all have?  I want the job
> to run in a browser with default settings, since I
> want it to be able to run on computers other than those
> I own - though the main use will be on my main (at the
> time) PC.  I would like it to work on non-PC browsers,
> though I don't yet know of anyone who uses such.
> 
> I don't want to use true World-Wide-Web pages for this.
> 
> I don't want to have to run a local Web server.
> 
> I should, I think, be able to re-use MH's previous
> assistance and make the job an HTA - but would I be
> able to get a DOM tree corresponding to F (I rule
> out writing my own parser)?
> 
> I could, in principle, pull the JavaScript out of my
> .HTM page P and use WScript or CScript to execute it;
> but that would require a parser with DOM output and
> major rework of the I/O, at least.
> 
> I could revert to using my XP PC, which has an older Firefox
> which cannot be updated there, but that PC is not at all healthy.
> 
> Thoughts?  Suggestions?
> 
> CODE (which traps the case where the next part cannot work):
> 
> function ReadDiryFromFram() { var DIR
>   try { DIR = Fram.contentDocument.body }
>     catch(e) { TXAR.value = "FAIL" ; return }
>   // DoMoreWork(DIR)
>   }
> 
> 
> H'mmm - perhaps I should look into the "Edge: no start
> button" situation first.


I had three different answers for you, but before I could finish each one a new question comes up. Ultimately: Why do you not want to use IIS? It takes minutes to get your site running. Is it only because of distribution? Are these other machines on a shared network? Context, context. What is this project?

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

#37009

On Wednesday, 31 July 2019 02:24:10 UTC+1, Michael Haufe (TNO)  wrote:
> On Saturday, July 20, 2019 at 2:53:15 PM UTC-5, dr.j.r...@gmail.com wrote:
> > With Fram being an IFRAME element of the .HTM page P that is
> > running, which element has been loaded with content by
> > src=SomeString, and both and the file F indicated by
> > SomeString being on the same drive of a Windows PC, I have been
> > using Fram.contentDocument.body to get, in P, either the DOM tree
> > of F if F is a pseudo-Web page or the text of F it is a .TXT file.
> > 
> > That used to work (see CODE below) on most or all browsers.
> > It stopped working on various browsers until, up to a few
> > days ago, I could only use Firefox or MSIE for this work.
> > No problem there, as Firefox is my preferred browser.  But,
> > since updating Firefox to 68.0 or 68.0.1, it no longer works
> > there.
> > 
> > /***
> >      In Edge, I can read .TXT files thusly; but the main page of
> >      interest declines to present its "Start" button, so there is
> >      some other difference affecting my code.
> > ***/
> > 
> > That, I presume, is because Firefox now interprets the
> > same-origin policy for allowing access to IFRAME contents
> > as other browsers have taken to using (I cannot comprehend
> > why two files on the same local drive are not considered
> > as same-origin, but there it is).
> > 
> > The code still works in IE11 - and as Microsoft are now
> > pressing the use of Edge instead of IE, there seems some
> > reason to hope that they are not likely to make the same
> > change in IE.
> > 
> > However, I see that I have noted (long ago) that, in
> > this work, IE had other peculiarities best dealt with
> > by not using IE.
> > 
> > So what suggestions do you all have?  I want the job
> > to run in a browser with default settings, since I
> > want it to be able to run on computers other than those
> > I own - though the main use will be on my main (at the
> > time) PC.  I would like it to work on non-PC browsers,
> > though I don't yet know of anyone who uses such.
> > 
> > I don't want to use true World-Wide-Web pages for this.
> > 
> > I don't want to have to run a local Web server.
> > 
> > I should, I think, be able to re-use MH's previous
> > assistance and make the job an HTA - but would I be
> > able to get a DOM tree corresponding to F (I rule
> > out writing my own parser)?
> > 
> > I could, in principle, pull the JavaScript out of my
> > .HTM page P and use WScript or CScript to execute it;
> > but that would require a parser with DOM output and
> > major rework of the I/O, at least.
> > 
> > I could revert to using my XP PC, which has an older Firefox
> > which cannot be updated there, but that PC is not at all healthy.
> > 
> > Thoughts?  Suggestions?
> > 
> > CODE (which traps the case where the next part cannot work):
> > 
> > function ReadDiryFromFram() { var DIR
> >   try { DIR = Fram.contentDocument.body }
> >     catch(e) { TXAR.value = "FAIL" ; return }
> >   // DoMoreWork(DIR)
> >   }
> > 
> > 
> > H'mmm - perhaps I should look into the "Edge: no start
> > button" situation first.
> 
> 
> I had three different answers for you, but before I could finish each one a new question comes up. Ultimately: Why do you not want to use IIS? It takes minutes to get your site running. Is it only because of distribution? Are these other machines on a shared network? Context, context. What is this project?

Well, there is a simple answer to the first question - to the best of my recollection, this is the first time I've heard of such a thing being part of Windows.

I wrote LINXCHEK.HTM for me, to run on my main PC (and I want it to run on any machine I designate as "main" - and late last year I had to redesignate, as my main machine's C hard drive had failed).  I had, IIRC, coded LINXCHEK to be disabled before doing anything useful if loaded from my Web site, since for bandwidth reasons I did not want anyone to download it very frequently (anyone could disable that bit of code; but they would not be able to put the page in MY website) - therefore, I don't know what changes might be needed to make it run fully from a server).

Other machines might be on networks, but don't share with me.

The page LINXCHEK.HTM runs a local spider.

Way back when I had only dial-up Internet, I wanted to be able to check links and anchors on the local master copy of my Web site; I wrote a Borland Pascal 7 program (CHEKLINX.PAS, 16-bit EXE) to empirically parse an HTM page (to help it, I write in a large subset of HTML), get the links and anchors, and check; and it would follow local links to HTM pages, recursively.  When I got Delphi 3 I made a CHEKLINX.EXE (32-bit) with it - and that still runs.

But when I discovered that HTML has IFRAME, and IFRAME has contentDocument.body, I realised that I can spider the properly-parsed bodies of my local INDEX.HTM page and all local pages that can be reached from it, and do the above much better with many added features (such as checking YYYY-MM-DD DoW) to see if DoW is calendrically correct <g>).  That is  LINXCHEK.HTM.

And, now that the C drive is a solid-state disc, Firefox processes^Hd  over 200 pages in about 20 seconds.

LINXCHEK.HTM starts by reading a Directory File, essentially as obtained by previously running Prompt>DIR /b /s > $DIR.TXT .


For (much) more description, see an older version of the page itself at
https://web.archive.org/web/20140809171940/http://www.merlyn.demon.co.uk/linxchek.htm

That will not run when loaded from that server, as the GO-type button is disabled; but one can read the page, and one can download it with Save As and then run it (after making a suitable Directory File).  It would like a stylesheet and an include file, but (IIRC) neither is really needed.



I've gutted a copy of one of the HTAs that you helped me to write, and intend next to see what happens if I get it to read a whole HTM page into a string
and assign that string to the innerHTML of a DIV.  If I get a DOM-like tree in the DIV, I can proceed ...


Must stop, routine medical appointment imminent.

Thanks, regards,

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

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

#37010

On Wednesday, 31 July 2019 12:14:15 UTC+1, dr.j.r...@gmail.com  wrote:

> I've gutted a copy of one of the HTAs that you helped me to write,
> and intend next to see what happens if I get it to read a whole
> HTM page into a string and assign that string to the innerHTML of
> a DIV.  If I get a DOM-like tree in the DIV, I can proceed ...

In an HTA using JScript or VBScript, can I read a local plaintext file of extension TXT or HTM into a single string, and if so what do I need; or must I get it as a load of lines and concatenate them?

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

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

#37011

John,

> In an HTA using JScript or VBScript, can I read a local
> plaintext file of extension TXT or HTM into a single string,
> and if so what do I need;

Using VBScript you certainly can.  This is what I use myself (keyword: 
"ReadAll")

  set oSrcFile = oFS.opentextfile(sSrcFile,1)
    sFileDat = oSrcFile.ReadAll
  oSrcFile.Close

I have no experience with JScript in this regard though.

Regards,
Rudy Wieser

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

#37020

On Wednesday, 31 July 2019 17:22:44 UTC+1, R.Wieser  wrote:
> John,
> 
> > In an HTA using JScript or VBScript, can I read a local
> > plaintext file of extension TXT or HTM into a single string,
> > and if so what do I need;
> 
> Using VBScript you certainly can.  This is what I use myself (keyword: 
> "ReadAll")
> 
>   set oSrcFile = oFS.opentextfile(sSrcFile,1)
>     sFileDat = oSrcFile.ReadAll
>   oSrcFile.Close
> 
> I have no experience with JScript in this regard though.


I just needed to realise that 'oFS' must be equivalent to what a
certain pseudo-book names 'fso' !

Converting those parts of VBScript which are not in ECMAScript
and the usual browser's DOM, for a JScript system which includes
the corresponding functions, is really rather easy.

I use http://wsh2.uw.hu/index.html which is for both VBscript
and JScript; it is undoubtedly comprehensive (for its time)
but I find its presentation uncongenial.  But, now I know
the answer to my question, I'm virtually certain that I could
easily find the answer there.

The following does what I have been doing with an IFRAME,
except that I have been loading the frame from a file and
reading its contents as a page's tree of elements, and this
reads the file as a string and loads it into a page-like
tree of elements at 'xxx'.


var fso = new ActiveXObject("Scripting.FileSystemObject")
// ...
var sSrcFile = "C:\\homepage\\$contact.htm"
var oSrcFile = fso.opentextfile(sSrcFile, ForReading) 
var sFileDat = oSrcFile.ReadAll()
oSrcFile.Close()	// para after Rudy Wieser in c.l.j
// ...
alert(sFileDat)
document.getElementById('xxx').innerHTML = sFileDat


Other tests have shown that xxx will now contain a structure
matching the DOM tree of $contact.htm - or maybe I'll have to
load sFileDat into a second window to make it have its own
individual arrays(/collections?) of links and anchors rather
than sharing with the page being executed.

Thanks,

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

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

#37021

John,

> I just needed to realise that 'oFS' must be equivalent to
> what a certain pseudo-book names 'fso' !

Correct.

From your post I assumed you already knew about the "File System Object", 
and that the "fso" variable is just that, a variable - and thus can be named 
anything you want.

In my case I am a bit of an old git in this regard, prefixing the variable 
name with what its intended use : "o" for object, and the "FS" from the the 
capitals of the "File System" name.

> But, now I know the answer to my question, I'm virtually
> certain that I could easily find the answer there.

:-)   Thats mostly the problem when searching for something new, not knowing 
what the keywords are.

> Other tests have shown that xxx will now contain a
> structure matching the DOM tree of $contact.htm

Yep. That is nowerdays a feature of setting innerHTML to something, 
auto-parsing its new contents.

> or maybe I'll have toload sFileDat into a second window
> to make it have its own individual arrays(/collections?) of
> links and anchors ...

If-and-when you do find out how to do that than please post it.  I could 
also use it.

> ... rather than sharing with the page being executed.

You do not actually need to put it in a page to be able to parse it. 
instead of  document.getElementsByClassName(....) you can just use 
MyElement.getElementsByClassName(....).  Even when MyElement has not (yet) 
been placed on the page.

(in case you are wondering: I've got FF with GreaseMonkey installed, and do 
write some scrubber code).

Regards,
Rudy Wieser

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

#37023

On Friday, 2 August 2019 12:38:29 UTC+1, R.Wieser  wrote:
> John,
> 
> > I just needed to realise that 'oFS' must be equivalent to
> > what a certain pseudo-book names 'fso' !
> 
> Correct.
> 
> From your post I assumed you already knew about the "File System Object", 
> and that the "fso" variable is just that, a variable - and thus can be named 
> anything you want.
> 
> In my case I am a bit of an old git in this regard, prefixing the variable 
> name with what its intended use : "o" for object, and the "FS" from the the 
> capitals of the "File System" name.
> 
> > But, now I know the answer to my question, I'm virtually
> > certain that I could easily find the answer there.
> 
> :-)   Thats mostly the problem when searching for something new, not knowing 
> what the keywords are.

And that was my *first* thought on seeing   new Set   in Michael's
code.  Google for   set   gives about 13,250,000,000 results; but
Google for   new set   gives about 11,590,000,000 results, of which
the first looks almost ideal - and Google for "new set" gives a mere
45,400,000 results, of which the first looks even better.   <g>

I use an Object as a Set, and don't need the additional properties
of a Set.

> > Other tests have shown that xxx will now contain a
> > structure matching the DOM tree of $contact.htm
> 
> Yep. That is nowerdays a feature of setting innerHTML to something, 
> auto-parsing its new contents.
> 
> > or maybe I'll have toload sFileDat into a second window
> > to make it have its own individual arrays(/collections?) of
> > links and anchors ...
> 
> If-and-when you do find out how to do that than please post it.  I could 
> also use it.

I think I've misunderstood the question, as the answer seems too
easy :-

function NewWindow(Title, Body) { // New window and content
  var Wndw = window.open("", "X"+new Date().getTime())
  var Site = "Merlyn", Owner = "J R Stockton" // not inherited
  Wndw.document.writeln(PageString(Site, Title, Owner, Body))
  Wndw.document.close() }

There, new Date is to ensure uniqueness, and PageString just
decorates Body with the usual non-body part of a simple Web
page and a short header to display.

I'm **assuming** that the new window has the same parts
(i.e., or e.g., the Links and Anchors elements) as would
be the case if Body was an actual file read by a browser.



> 
> > ... rather than sharing with the page being executed.
> 
> You do not actually need to put it in a page to be able to parse it. 
> instead of  document.getElementsByClassName(....) you can just use 
> MyElement.getElementsByClassName(....).  Even when MyElement has not (yet) 
> been placed on the page.

But I do want to be sure that the links-and-anchors collection
in the new element is not shared with the main page.

Actually, I quite like to be shown the pages as they are
processed, as happens naturally by reading them into an
IFRAME - indeed, I found a disadvantage of my new solid-state
C drive over the old rotating one - with the new one, a page
is processed so quickly that the renderer has no time to show
it before the next page arrives - the work-in progress
indication of the IFRAME appears stuck and the refresh/stop
icon of the browser appears to have gone berserk.  I could
easily add a small delay in the processing, but I'm now used
to the new effect. ...  Ha! I see that there is a default
40ms delay; I only need to increase it.

> (in case you are wondering: I've got FF with GreaseMonkey installed, and do 
> write some scrubber code).


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

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

#37024

John,

> And that was my *first* thought on  seeing
>  new Set   in Michael's code. Google for   set
> gives about 13,250,000,000 results;

:-)  Yep, thats one the things I've run a few times in too: keywords that 
have a very generic meaning too. :-(

> I think I've misunderstood the question, as the answer
> seems too easy :-
>
> function NewWindow(Title, Body)

You did not misunderstand it, as I didn't / forgot to mention that my 
intention was/is to have a temporary, non-visible DOM - but which I can 
still access from the script which created it.  For (extra) scrubbing and 
subsequently saving (in a WYSIWYG -save attempt).

> But I do want to be sure that the links-and-anchors
> collection in the new element is not shared with the
> main page.

That should be easy to check: let the new body contain an element with a 
unique classname, and than search the current DOM for that classname.   If 
not found ...

But, I understand your caution.

Ofcourse, using an iframe makes it, just like you mentioned, possible to see 
the actual result page.   In my case the result is saved to file (and can 
check it there)

Regards,
Rudy Wieser

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

#37027

On Friday, August 2, 2019 at 7:59:50 AM UTC-5, dr.j.r...@gmail.com wrote:

> And that was my *first* thought on seeing   new Set   in Michael's
> code.  Google for   set   gives about 13,250,000,000 results; but
> Google for   new set   gives about 11,590,000,000 results, of which
> the first looks almost ideal - and Google for "new set" gives a mere
> 45,400,000 results, of which the first looks even better.   <g>

For JavaScript and Web Development information, the Mozilla wiki (MDN) [1] is the accepted [2] portal for reference.

In this instance: <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set>



> I use an Object as a Set, and don't need the additional properties
> of a Set.

If you want a set, use a Set. Semantics matter. All elements of a set must support an equality test. Using an object you can't do this as you are forced to represent every member as a string. Example:

<script>
var fakeSet = Object.create(null)

fakeSet[undefined] = true
fakeSet['undefined'] = true

fakeSet[undefined] === fakeSet['undefined'] // true

</script>

undefined !== 'undefined' but due to the implicit string conversion you cannot accomplish this. For non-primitive objects you have to override the toString method to return the equivalent of a hash to make sure the items are stored. 

Using a proper Set, this is not an issue.

[1] <https://developer.mozilla.org>
[2] <https://www.bleepingcomputer.com/news/technology/browser-makers-agree-to-move-web-documentation-to-mozillas-portal/>

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

#37031

On Friday, 2 August 2019 23:57:09 UTC+1, Michael Haufe (TNO)  wrote:
> On Friday, August 2, 2019 at 7:59:50 AM UTC-5, dr.j.r...@gmail.com wrote:
> 
> > And that was my *first* thought on seeing   new Set   in Michael's
> > code.  Google for   set   gives about 13,250,000,000 results; but
> > Google for   new set   gives about 11,590,000,000 results, of which
> > the first looks almost ideal - and Google for "new set" gives a mere
> > 45,400,000 results, of which the first looks even better.   <g>
> 
> For JavaScript and Web Development information, the Mozilla wiki (MDN) [1] is the accepted [2] portal for reference.
> 
> In this instance: <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set>

For me, using that site is much like trying to learn Swedish
from just a dictionary.  And I resent the fact that, while
there are versions of that page in, for example, /fr/, /de/,
and /it/, there appears to be nothing in /en-UK/.


> > I use an Object as a Set, and don't need the additional properties
> > of a Set.
> 
> If you want a set, use a Set. Semantics matter. All elements of a set must support an equality test. Using an object you can't do this as you are forced to represent every member as a string. 

In my case, every Object to be stored _is_ a pure-bred String,
with no taint of any other JavaScript type in its ancestry.
In fact, all characters will have been printable ASCII (or
possibly "£").  And I tested with various foreign strings too -
and (though I won't be using it) the empty string.  And Number
1/+0 would be distinguished from Number 1/-0, too.

But, certainly, it would be more logical to use a Set, now
that I know that the type exists - unless the required
operations are appreciably slower using a Set.

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

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

#37040

Michael Haufe (TNO) wrote:

> On Friday, August 2, 2019 at 7:59:50 AM UTC-5, dr.j.r...@gmail.com wrote:
>> I use an Object as a Set, and don't need the additional properties
>> of a Set.
> 
> If you want a set, use a Set. Semantics matter. All elements of a set must
> support an equality test. Using an object you can't do this as you are
> forced to represent every member as a string. Example:

JFTR, a Set in OOPLs *is* conceptually, and particularly in ECMAScript Ed. 
6+ *literally*, an object.  It is just not *an Object instance* when built-
in, and it would not be a *plain* Object instance when emulated (yes, this 
is possible using explicit setters and getters, or ES 6+ Proxy [but the
latter is probably pointless]).

<https://www.ecma-international.org/ecma-262/6.0/index.html#sec-set-objects>
<https://www.ecma-international.org/ecma-262/10.0/index.html#sec-set-objects>
 
> <script>
> var fakeSet = Object.create(null)
> 
> fakeSet[undefined] = true
> fakeSet['undefined'] = true
> 
> fakeSet[undefined] === fakeSet['undefined'] // true

Well, this is rather unsurprising, as the previous two assignments are 
already equivalent.  The proof is more convincing if you omit the previous 
“undefined” property access.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#37026

On Friday, August 2, 2019 at 6:38:29 AM UTC-5, R.Wieser wrote:
 
> In my case I am a bit of an old git in this regard, prefixing the variable 
> name with what its intended use : "o" for object, and the "FS" from the the 
> capitals of the "File System" name.

In other words Hungarian Notation. I think this is reasonable in programming languages without a sufficient type system (like modern JavaScript)

<http://wiki.c2.com/?HungarianNotation>

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

#37029

Michael,

> In other words Hungarian Notation.

Only the barest minimum of it.  At one time I tried doing it fully, but 
prefixes like "awsz" (array of zero terminated wide-strings) simply did not 
appeal to me.

Also, I use the prefixes as reminders, not as descriptions.

Regards,
Rudy Wieser

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

#37030 — OT: Re: Firefox changed IFRAME behaviour - I need a remedy??

On Friday, 2 August 2019 23:10:20 UTC+1, Michael Haufe (TNO)  wrote:
> On Friday, August 2, 2019 at 6:38:29 AM UTC-5, R.Wieser wrote:
>  
> > In my case I am a bit of an old git in this regard, prefixing the variable 
> > name with what its intended use : "o" for object, and the "FS" from the the 
> > capitals of the "File System" name.
> 
> In other words Hungarian Notation. I think this is reasonable in programming languages without a sufficient type system (like modern JavaScript)
> 
> <http://wiki.c2.com/?HungarianNotation>

I knew what Hungarian Notation is, and refreshed my knowledge
using that link.

But you remind me of a time, in the early days of FFT, when we
were beginning to use FT.  I asked to be sent a machine-readable
copy of a cited FFT algorithm (in FORTRAN or Algol 60, IIRC).
It was indeed machine-readable; the compiler was happy with it.
But the variable names and the comment were all in Hungarian,
which did not help us to understand the algorithm itself.

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

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

#37032 — Re: OT: Re: Firefox changed IFRAME behaviour - I need a remedy??

dr.j.r.stockton@gmail.com wrote on 03 Aug 2019 in comp.lang.javascript:

> But the variable names and the comment were all in Hungarian,
> which did not help us to understand the algorithm itself.

Did they sound like <https://youtu.be/LdH1hSWGFGU?t=7>? 

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web