[Edbrowse-dev] jspool

[Edbrowse-dev] jspool

[Karl Dahlke]

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

You know what's funny? I finally got rid of the old jspool parameter.
Remember we had to set the size of the js pool at startup?
We had to anticipate, guess, how much space edbrowse would need for js, and if we were in edbrowse all day and browsed yet one more site with lots of js, boom!
Well we don't have to worry about that any more.
duktape doesn't have a pool of a fixed size, it allocates what it needs. Duh!
So jspool is a nice thing to leave behind.

I left the memory hog test in jsrt for now.
Push the memorry fill button and it creates 20 million objects no problem.
Although, ha ha, it prints a counter every 10,000 objects, which is fine for me, but my wife finally told me that alert on any other browser is not the same as print,
it's a message that you have to acknowledge before you can move on.
Sometimes I'm at a real disadvantage never running a regular browser.
Nobody would want to click ok 200 times, so maybe I should remove that status alert.
Well nobody runs jsrt on a regular browser, except Geoff, cause he's curious.

Karl Dahlke

Re: [Edbrowse-dev] jspool

[Kevin Carhart]

> duktape doesn't have a pool of a fixed size, it allocates what it needs. Duh!

This is great!  Occasionally I will hit the message about cannot allocate 
more memory.  And I also think that ability to allocate memory dynamically 
could be another test that site-makers put the client through in order to 
call the bluff of user-agent spoofers, in addition to things like styles 
and testing the decimal places on numbers.

Re: [Edbrowse-dev] jspool

[Kevin Carhart]

Is this a good time to have a thread about the more specific end of 
things, or is there still so much going on with the basic architecture 
that it's premature?

I have built the latest a few times and pulled up acid3.acidtests.org.
There are a bunch of things we could talk about.  In order to take it from 
the top, I tried test #0.  (The tests are numbered 1 to 100, but there is 
also a zero.)  Test #0 actually does not use the iframes, but it does use 
CSS selectors.  So we could discuss #0, or leap ahead to one of the tests 
that uses the new iframe support but still doesn't pass, or wait a while.

Kevin


  On Sun, 13 Aug 2017, Karl Dahlke wrote:

> I think we have a good foundation now - so over the next couple months I hope we can get a lot more sites working, either by plowing through acid tests methodically, or fixing individual sites that people want.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] test #0

[Kevin Carhart]

Thanks Karl.  I'm putting it on list because I hope everyone will have 
some remarks.  Adam, you brough up the acidtests in the first place but I 
haven't talked to you about it much lately.

This is going to be lovely and hospitable JS in some ways, 
in the same vein as observing that the author called a variable 
kungfuDeathGrip - goofy, capricious, but at least we know that this is 
javascript written by human beings, intended to be read, with comments, 
linefeeds, and carved up into small pieces!

So here's the code for test zero.

Note: the assertEquals function is referenced but I didn't copy it in 
also.  So that could be a problem for understanding the test, but you 
can probably tell from context what assertEquals does.  It's a utility 
called at the end of a test, to assert that two things should be equal 
and pass or fail based on whether they are.


function () {
       // test 0: whether removing an element that is the last child 
correctly recomputes styles for the new last child
       // also tests support for getComputedStyle, :last-child, pre-wrap, 
removing a <script> element
       // removing script:
       var scripts = document.getElementsByTagName('script');
       document.body.removeChild(scripts[scripts.length-1]);
       // removing last child:
       var last = document.getElementById('remove-last-child-test');
       var penultimate = last.previousSibling; // this should be the 
whitespace node
       penultimate = penultimate.previousSibling; // this should now be the 
actual penultimate element
       last.parentNode.removeChild(last);
       assertEquals(document.defaultView.getComputedStyle(penultimate, 
'').whiteSpace, 'pre-wrap', "found unexpected computed style");
       return 7;
     },



> But really you can go in any order you like as long as we're making progress.

[Edbrowse-dev] test #0

[Karl Dahlke]

Well for starters we don't have a defaultView or a defaultView.computedStyle.
Hopefully these can all be written injavascript in startwindow.js. Easy peasy.
But I have no idea what they are or what they're suppose to do.

Karl Dahlke

Re: [Edbrowse-dev] test #0

[Kevin Carhart]

Wait, we do though.  I wrote this.  I think in that big one I committed on 
June 30 of last year.  (I know the day because that's my birthday.)

I am not positive that it's correct, but there is something implemented 
for this, around line 758-768 of startwindow.js.


On Sun, 13 Aug 2017, Karl Dahlke wrote:

> Well for starters we don't have a defaultView or a defaultView.computedStyle.
> Hopefully these can all be written injavascript in startwindow.js. Easy peasy.
> But I have no idea what they are or what they're suppose to do.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] explanation of patch 20170813

[Kevin Carhart]

On Sun, 13 Aug 2017, Karl Dahlke wrote:

> Indeed you do, but yours takes no arguments, and the one in acid is given 2 arguments.
> Something doesn't line up.
>
> Karl Dahlke
>

Ok, I researched this a little and wrote a patch.  Here are some notes on 
what is going on.

What's defaultView?

document.defaultView just returns window.

Why does the acid3 test say document.defaultView.getComputedStyle?

According to MDN, this is redundant.  So I just put in code so that
document.defaultView.getComputedStyle
will call window.getComputedStyle and proceed.

What is the point of window.getComputedStyle?

I think the point is that there is supposed to be a cascading effect in 
the values of styles.  As the comment says "whether removing an element 
that is the last child correctly recomputes styles for the new last child"

Why are there two arguments and what do the arguments do?

Here's the syntax for window.getComputedStyle, from MDN:
var style = window.getComputedStyle(element[, pseudoElt]);

The first argument is the element to return the styles for.  The second 
argument is optional.  It refers to pseudoelements.  I'm leaving aside 
what those are, for now.

Onwards and upwards.... this doesn't make test zero pass yet, but it's 
important to fix.  The element called 'penultimate' isn't working 
correctly, but there is no longer a syntactical problem trying to say:

document.defaultView.getComputedStyle(penultimate, '').whiteSpace

Kevin