edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Interwindow Communication
Date: Wed, 26 Jul 2017 02:57:44 -0400	[thread overview]
Message-ID: <20170626025744.eklhad@comcast.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

This is where javascript accesses the objects in the subordinate windows, also known as frames.
It sort of works, and I'm in shock.
I'm amazed that 30 or 40 lines of code brings this to life.
I had no clue how to do this in mozilla, no clue whatsoever, but I did the obvious dozen lines of code in duktape, and it works.
Remember that jsrt has a frame, so browse jsrt and expand the frame with the exp command.
That frame is now part of the screen you're already familiar with.
If you enter jdb in the frame you'll have access to all the objects of the frame, but that isn't really what we want to demonstrate.
go back to line 1, or any line outside of the frame, and type jdb.
frames[0] is the one and only frame, and under this is contentDocument,
and under that is all the nodes of the frame.
I even went in and set foo = 77 in a style object, so we have read write access.

Kevin, don't get excited and assume the next acid test will pass. It won't.
That's because I don't expand frames automatically at load time.
They're not there until you type exp.
If possible I'd like to keep it that way.
edbrowse is slow enough as it is, and most of those frames are google analytics or advertising or other such crap.
Now there may be a really tricky way around this, for some day in the future.
Imagine each frame has a default contentDocument object that I create, that has a getter.
The first time any javascript tries to access it, the getter runs, and expands the frame inside,
and passes back the real contentDocument for that frame, and js marches on none the wiser.
Pretty sneaky eh?
Then you only expand if you really have to.
Even then, the expansion is under the covers, you don't actually see the frame unless you type exp.
Then it's expand and contract as usual, which are really hide and unhide.
Anyways, play around with it if you like, especially you Kevin, to see if everything is linked in the way it's suppose to be.

Karl Dahlke

             reply	other threads:[~2017-07-26  6:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-26  6:57 Karl Dahlke [this message]
2017-07-26  9:09 ` Kevin Carhart
2017-07-26 10:09   ` Chuck Hallenbeck
2017-07-26 22:56     ` Kevin Carhart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170626025744.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).