From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2001:558:fe21:29:69:252:207:43; helo=resqmta-ch2-11v.sys.comcast.net; envelope-from=eklhad@comcast.net; receiver= Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) by hurricane.the-brannons.com (Postfix) with ESMTPS id A4ACF77AFE for ; Sat, 5 Aug 2017 15:39:31 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id e7jjdZof13U5Fe7jsdf2Sx; Sat, 05 Aug 2017 22:40:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1501972808; bh=+7ssWYP69XbbAy8df1n063rEpCxV/qRN9XorJSRtDrE=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=I5eHYIN4o8zkViP2c/IxZAaRzwfSLhkJqRA6a+mRq0Tc5pKLLryQ9PZC1DRJkrBNg R/PTlKsgAubs/KexlCRykq6x3zaOwVvRX6el7A3YHLg7M05ydM5+QZ5NT0rz3s5mLd e6Py+VPpD/SAuIp19D5OfUiRLnOrowe9cfUuMYdDYDKAXVU4RsG6osPNB5pzqfiiXs opbGHTJv2Q/oaY1fyZK3JCES4EH3gQlFhsEjz8d9KWmFoJG0DO2rOxIlb9bbotByla REmpBK+S7HRUEVyOmCtTSgbCNk95NWlGXHhxIeXJl0yIHi14tiXuDvDNoYJicQtTBn MRBSU01WjcDoA== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-10v.sys.comcast.net with SMTP id e7jrdu6dP6bpPe7jsdNMBM; Sat, 05 Aug 2017 22:40:08 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.0x Date: Sat, 05 Aug 2017 18:40:07 -0400 Message-ID: <20170705184007.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-733351 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBq+BOTbjzl+wXbhbz2qD3lmQ8lv4VGl9SCRFCsSOliDlLAcWnI4u4dovfm89FEuLhzoXF4F0or78ms+eenSEmSV6SPcDeHZp1EaTYoYBE1e2bbHOwa2 iwlXylydUPnFoJnlGmGpUobwnYUck9dOg8+258ffjWQ+4L14pIRfq+yZ Subject: [Edbrowse-dev] Frame AutoExpansion X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 22:39:31 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-733351 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable After the release, I'd like to think about expanding frames = automatically. It's complicated so I'm asking your advice. First, I don't want to do it at all. Opening websites is slow already, how much slower if I automatically = expand each frame before you can see the text? And most of those frames I don't care about anyways, they are = advertising or supplementary information. I like the current paradigm, type exp if you want to expand a frame. Most of them I never expand. But ... as Kevin has discovered ... some of the acid tests, and perhaps = some of the real world sites, have javascript that assumes the frames are expanded. They dip into the objects in those frames, and sometimes twiddle those = objects. So we have some choices here. 1. Don't expand the frames and just realize that some sites won't work = properly. Hopefully very few sites, hopefully it's just advertising or visual = effects that don't run. In other words do nothing, that's the easiest. 2. Expand each frame in the window. I'd have to expand the frames first, then run the javascript for the = main window, because the frames are suppose to be there. As part of parsing html, aha, a tag, stop what you're doing and = go expand that frame, then resume. And that frame could contain another frame and so on. All my html parsing and stacking has to be reentrant, and I'll bet it's = not today. So a bit of work, and again, it's gonna slow down edbrowse, which is = already pretty slow. 2A. All the frames probably fetch the same javascript files as the = original window, it would be nice if I could just pull them from cache. I know we already do this, but I mean don't even issue the head command. Surely the javascript isn't going to change in the quarter second since = I last fetched it. Maybe this should be a general mechanism, if you're fetching js, and it's in cache, and you accessed it less than = one minute ago, then skip the head request and just grab the file. 3. Only as we need it. I like this but it's the hardest to do. Don't expand anything at the start. Instead of a contentDocument object, each frame has a contentDocument = getter and setter. The getter returns the raw object content$Document if it is there, but = if not, then the frame has not been expanded. Expand the frame, link its document object to content$Document, then = return content$Document as though it was there all the time. Sweet, but watch what has to happen. Think of it as a 2 process model, because the messaging is really the = same even in one process. The 2 processes are client server. edbrowse asks for foo.bar ... js returns the value of foo.bar. edbrowse sets foo.bar =3D 7 ... js acknowledges. edbrowse says to run this javascript ... js runs it and returns the = result. It's a very direct protocol. To do what I'm talking about, we have to stand it on its head. edbrowse: run this script js: from inside the content$Document getter, oh my goodness, we have to = expand this frame, send a frame expand message back to edbrowse. edbrowse is waiting for an acknowledgement or a result from the script, = and now it gets a command. It has to pause what it is doing, pushing things onto a stack of some = sort, and expand the frame, as though the user had typed exp at the keyboard. Then it tells JS the frame is expanded, pops everything off the stack, = and waits for the result of the script that it asked js to run earlier, now in the state it was in before. Awkward enough, but even more awkward on the js side. It is in the middle of the getter, and it has to pause everything, push = it onto a stack or something, and go back to the main message loop, because edbrowse is expanding = another frame, and edbrowse is going to send all sorts of js requests to do that. Eventually edbrowse will send along a frame-is-done message and js pops = everything, goes back to the contentDocument getter, and returns content$document. Wow! There's another way that is easier. Stay within the one process model. Replace most of the messages with simple function calls. I don't have to send a message to a js process, or virtual process, to = find the value of foo.bar, and wait for the value to come back as a = message, I can just call the native function = get_property_string_nat(foo, "bar"); There we go. When js wants to expand a new frame it doesn't have to send a message = the wrong way down a one way street. It can just call the edbrowse parse and render mechanism as a function, which calls more js routines, as functions, and C provides the stack. I don't have to invent state stacks and use setjmp and longjmp, which = I've done before but it's like playing with fire, I can let C take care = of it. This assumes duktape is reentrant, which it probably is. I'm guessing that by the way you pass the context pointer to every = duktape function call. So yes that's good, but it locks us into the one process model. I'd keep the 2 process model around, but this feature simply wouldn't = work in the 2 process world. That gives you something to ponder over the next week or so. Karl Dahlke --nextpart-eb-733351--