[Edbrowse-dev] suggested additions

[Edbrowse-dev] suggested additions

[Kevin Carhart]

Here are some notes on the 7 things where nasa.gov works if you implement 
them all.  I'd like to get your remarks before making a patch, though I 
don't think any of them will cause any problems.  There's one in decorate 
and the rest are javascript.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(1) give a CSSStyleDeclaration attributes
CSSStyleDeclaration = function(){
         this.element = null;
         this.style = this;
         this.attributes = new Array;
};

Justification:
http://code.jquery.com/jquery.js at line 6787 or thereabouts says
  style.removeAttribute( "filter" );

So it is expecting that a style will have attributes.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(2) Give an iframe a contentWindow in addition to a contentDocument in 
decorate.c:
// special code for frame.contentDocument.
                         if (t->parent->action == TAGACT_FRAME)
                                 set_property_object(t->parent->jv,
                                                     "contentDocument", 
t->jv);
                         if (t->parent->action == TAGACT_FRAME)
                                 set_property_object(t->parent->jv,
                                                     "contentWindow", 
cf->winobj);


Justification: the latest jquery at 6046 or thereabouts says this:

doc = ( iframe[ 0 ].contentWindow || iframe[ 0 ].contentDocument 
).document

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(3) Bring back the following definition for Event.   I am getting this 
from Chris Thatcher's DOM project.  There is a link below.

Event = function(options){
     // event state is kept read-only by forcing
     // a new object for each event.  This may not
     // be appropriate in the long run and we'll
     // have to decide if we simply dont adhere to
     // the read-only restriction of the specification
     this._bubbles = true;
     this._cancelable = true;
     this._cancelled = false;
     this._currentTarget = null;
     this._target = null;
     this._eventPhase = Event.AT_TARGET;
     this._timeStamp = new Date().getTime();
     this._preventDefault = false;
     this._stopPropogation = false;
};

Justification: This is in the env DOM implementation.  Event handlers are 
(often?  or always?)  expecting to be passed an Event object as an 
argument.  You can go to the source if you would like to review this piece 
of code:

git clone https://github.com/thatcher/env-js.git

and then go to env-js/src/event/event.js

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(4) Apply the Event definition from (3) to the addEventHandler and 
attachEvent too.  So the firing of the handler code will accept an Event 
object as an argument.

Inside of the eval() command , this:
a[i]();

Would be changed so that now we would say
var tempEvent = new Event;
tempEvent.type = name of the event that was passed in, like click;
a[i](tempEvent);

Justification: I just found this out from trial and error back when I was 
playing with an edbrowse 3.3.1.  It may be that it's just a jQuery 
convention.  It definitely makes a lot of handlers work correctly when you 
have this.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(5) Implement childNodes.item.  Pages want to be able to reference a set 
of childNodes by an index.  I don't know the best place to put this. 
What I did so far is to define it on document,
document.childNodes.item = function (x) { return this[x]; }

Justification: This is referenced in the nasa.gov file, vendor.js.  (see 
esbrowse.git to deminify and get good line numbers.)
  (vendor.js is minified, annoyingly.  But, if you wish to play along you 
can deminify it using esprima.parse followed by escodegen.generate in 
succession.  I bundled this up at 
https://github.com/KevinCarhart/esbrowse.git)

So, at roughly 8260 in the de-minified line numbering, vendor.js contains 
this line:
           r = r.childNodes.item(t[n]);

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(6)
I also added childNodes.item to the default case of the createElement 
switch statement.  Maybe there is a better way to do this.  Only 
properties are there right now.  Not functions also.  But that's where I 
put it currently:

c.childNodes.item = function (x) { return this[x]; }

Justification:  Same as (5)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(7) Following on from Karl's exclusion of @ from the CSS selectors, I 
added some more of these exclusions of CSS constructs that were causing a 
runtime error when I was debugging nasa. 
I used split as a crude form of existence check.  Please change to regular 
expression if you prefer.  This is a proposed section from the 'certain 
modifiers' comment all the way to the querySelectorAll.  (In the CSS code 
in startwindow.)

// certain modifiers not supported in this static view.
// @directives are not selectors.

if(sel.match(/^@/))
continue;

if (sel.substr(0,1) == '}')
{
sel = sel.substr(1,sel.length-1);
}
if (sel.split('-moz-').length > 1)
continue;
if (sel.split('-webkit-').length > 1)
continue;
if (sel.split('-ms-').length > 1)
continue;
if (sel.split(':before').length > 1)
continue;
if (sel.split(':after').length > 1)
continue;
if (sel.split(':active').length > 1)
continue;

// a:link is the same as a.
sel = sel.replace(/:link$/, "");
// :hover :visited etc are dynamic an not relevant here.
if(sel.match(/:(hover|visited|active)$/))
continue;

sel = sel.trim();
a = querySelectorAll(sel);

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This is all you have to do for nasa.gov to render!!

[Edbrowse-dev] suggested additions

[Karl Dahlke]

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

(1) give a CSSStyleDeclaration attributes

Sure.

(2) Give an iframe a contentWindow in addition to a contentDocument

Yes but not as simple as it seems.
The linkage in decorate.c is merely a placeholder until the frame is expanded.
Look for contentDocument in http.c.
Then, I'm not sure what contentWindo means, but I suppose the window of the frame, rather than the document of the frame, check for specifications.
Even that doesn't work with your example js.

doc = ( iframe[ 0 ].contentWindow || iframe[ 0 ].contentDocument
).document

So we're grabbing window.document or document.document, the latter doesn't make any sense.

Also beware, I do some magic with content$Document which is how we expand frames automatically when their objects are referenced.
Do we need to do the same for contentWindow? Probably.
This should probably be its own patch; it's a bit more involved.

(3) Bring back the following definition for Event.

Sure I guess.

(4) Apply the Event definition from (3) to the addEventHandler

Ok.

(5) Implement childNodes.item.

Sure. Probably down in Array.prototype. Then it's part of every childNodes, and every other array, but I don't think that's a problem.
Otherwise you have to make it part of every childNodes, including those in decorate.c.

(6)

Covered by Array.prototype.item.

(7) Following on from Karl's exclusion of @ from the CSS selectors,

Yeah this is ugly but I started it, so you may as well continue it.
I do think regular expressions are more readable / intuitive, and powerful.


Karl Dahlke

[Edbrowse-dev] suggested additions

[Karl Dahlke]

Curious. Would the acid tests uncover these 7 things?
The jury is still out on whether we should follow the acid tests, or find&fix, or both.

Karl Dahlke

[Edbrowse-dev] suggested additions

[Karl Dahlke]

I implemented #2, because it's tricky and involves getters and setters.
You can do the other 6 if you wish.
Please check my changes and make sure I didn't screw something up.
I did some testing on it, including autoexpand of a frame when contentWindow is accessed, and it seems to work.

Karl Dahlke

Re: [Edbrowse-dev] suggested additions

[Kevin Carhart]

Thanks for the feedback.
>
> Yes but not as simple as it seems.

Thank you for implementing (2).  Yes, I take your point that it goes 
deeper than the place I wanted to put my one-liner in decorate.c.

> Then, I'm not sure what contentWindo means, but I suppose the window of the frame, rather than the document of the frame, check for specifications.
> Even that doesn't work with your example js.
>
> doc = ( iframe[ 0 ].contentWindow || iframe[ 0 ].contentDocument
> ).document
>
> So we're grabbing window.document or document.document, the latter doesn't make any sense.

I know, I don't understand the idiom.  I basically said "the latter 
doesn't make any sense, but if we can supply the former, that appears to 
be one of the two things it will accept."  How does the parsing work if 
you have a control structure that tests (a || b) and a is true and b is 
illegal or raises a runtime?  I sort of recall that this varies by 
language, but is it plausble that some languages would test 'a', get a 
true, and proceed?

I have one idea for why this code would be this way.  Could it be a 
superset of two mutually-exclusive browser-DOMs that the jquery author is 
handling all in one line?  For instance, you can't be both a firefox and 
an IE/Edge at once.  Maybe that line is designed as a catch-all that will 
end up covering multiple client implementations.  This still doesn't make 
document.document make sense.  I don't know.

>
> (7) Following on from Karl's exclusion of @ from the CSS selectors,
>
> Yeah this is ugly but I started it, so you may as well continue it.
> I do think regular expressions are more readable / intuitive, and powerful.

I agree, I just don't have all the tokens memorized so it slows me down. 
I'm not sure I was getting ^ to work right, so I bailed out to a 
different technique.  This is fine.  I think I'll submit 1,3,4,5 and 6 as 
one, and then deal with writing these properly using .match and do 7 as a 
second patch.  I like regex.  I'm not averse to it.

Re: [Edbrowse-dev] suggested additions

[Kevin Carhart]

Good question.  I think it's both.  It's because of the acid tests that we 
got into CSS, but at the same time, getting drescher and nasa has been 
based on find & fix.  I think both things amount to a large catalog of 
scenario-like puzzles that can be picked up when we have time to work, and 
which have all been vetted or ratified that they will help our coverage.

It's all the same DOM.  I would consider toggling back and forth.  If we 
are stuck with the one, go implement something raised by the other.

  On Mon, 4 Sep 2017, Karl Dahlke wrote:

> Curious. Would the acid tests uncover these 7 things?
> The jury is still out on whether we should follow the acid tests, or find&fix, or both.
>
> Karl Dahlke
> _______________________________________________

[Edbrowse-dev] contentWindow

[Kevin Carhart]

I think there is a divergence based on whether the iframe is coming from 
html or created within js.  If I use the iframe in jsrt, it works.  But if 
I play along with how an iframe is created in the jquery.js code that I 
referenced, I think the contentWindow is not a window and doesn't have 
.document.  Is it a goof that the line in jsNode uses t->jv?  Or not!  It 
could be deliberate and a part of the whole.  I can't tell.    Here's my 
transcript that shows not working, followed by working.  Asterisks added 
to offset my input from the responses.

* b {any website with JS and jquery}
...
* jdb
* x1 = jQuery( "<iframe frameborder='0' width='0' height='0'/>")
[object Object]
* ok(x1)
0,length
* x2 = x1[0]
[object Object]
* ok(x2)
childNodes,style,className,class,nodeValue,attributes,ownerDocument,nodeName,nodeType,innerHTML,inner$HTML,contentDocument,content$Document,contentWindow,content$Window,parentNode
* x2.contentWindow
[object Object]
* ok(x2.contentWindow)
childNodes,style,className,class,nodeValue,attributes,ownerDocument,nodeName,parentNode,innerHTML,inner$HTML
* x2.nodeName
iframe
* x1.contentWindow.document
jdb line 1: TypeError: cannot read property 'document' of undefined
* .
bye
* b jsrt
22878
628
* jdb
* x1 = document.getElementsByTagName("iframe")
[object Object]
* x1
[object Object]
* ok(x1)
0
* x2 = x1[0]
[object Object]
* ok(x2)
childNodes,style,className,class,nodeValue,attributes,ownerDocument,src,nodeName,onload,nodeType,parentNode,innerHTML,inner$HTML,contentDocument,content$Document,contentWindow,content$Window
* x2.contentWindow.document
fetch frame http://www.edbrowse.org/jsfrm {it succeeds from here}

[Edbrowse-dev] suggested additions

[Karl Dahlke]

doc = ( iframe[ 0 ].contentWindow || iframe[ 0 ].contentDocument
).document

Don't spend too much time on this confusion.
Most likely it's a bug in the code.
They're human, they have bugs too.
But this one would never be caught.
Every browser has a contentWindow, so contentDocument.document would never be tested, or discovered.

Karl Dahlke

Re: [Edbrowse-dev] contentWindow

[Kevin Carhart]

On Mon, 4 Sep 2017, Karl Dahlke wrote:

> Well your first example has nothing to fetch, no source html file.
> So naturally it doesn't fetch or expand.

Ahhh, got it.  No, I took it from http://code.jquery.com/jquery.js around 
6040.  So at least insofar as this library routine is worth doing, it 
appears that a dynamically created iframe with no body needs to be 
immediately fully fledged and useable.  So do you think we could do a 
dummy <body></body> if there isn't one?

thanks
Kevin

Re: [Edbrowse-dev] contentWindow

[Kevin Carhart]

That's great.  Thank you.

On Mon, 4 Sep 2017, Karl Dahlke wrote:

> Ok, empty frame is expanded, should work now.
>
> Karl Dahlke
>