* [Edbrowse-dev] suggested additions @ 2017-09-04 2:38 Kevin Carhart 2017-09-04 14:12 ` Karl Dahlke ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Kevin Carhart @ 2017-09-04 2:38 UTC (permalink / raw) To: Edbrowse-dev 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!! ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Edbrowse-dev] suggested additions 2017-09-04 2:38 [Edbrowse-dev] suggested additions Kevin Carhart @ 2017-09-04 14:12 ` Karl Dahlke 2017-09-05 1:16 ` Kevin Carhart 2017-09-04 15:06 ` Karl Dahlke 2017-09-04 17:10 ` Karl Dahlke 2 siblings, 1 reply; 10+ messages in thread From: Karl Dahlke @ 2017-09-04 14:12 UTC (permalink / raw) To: Edbrowse-dev [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Edbrowse-dev] suggested additions 2017-09-04 14:12 ` Karl Dahlke @ 2017-09-05 1:16 ` Kevin Carhart 2017-09-05 2:27 ` Karl Dahlke 0 siblings, 1 reply; 10+ messages in thread From: Kevin Carhart @ 2017-09-05 1:16 UTC (permalink / raw) To: Edbrowse-dev 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Edbrowse-dev] suggested additions 2017-09-05 1:16 ` Kevin Carhart @ 2017-09-05 2:27 ` Karl Dahlke 0 siblings, 0 replies; 10+ messages in thread From: Karl Dahlke @ 2017-09-05 2:27 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Edbrowse-dev] suggested additions 2017-09-04 2:38 [Edbrowse-dev] suggested additions Kevin Carhart 2017-09-04 14:12 ` Karl Dahlke @ 2017-09-04 15:06 ` Karl Dahlke 2017-09-05 1:32 ` Kevin Carhart 2017-09-04 17:10 ` Karl Dahlke 2 siblings, 1 reply; 10+ messages in thread From: Karl Dahlke @ 2017-09-04 15:06 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Edbrowse-dev] suggested additions 2017-09-04 15:06 ` Karl Dahlke @ 2017-09-05 1:32 ` Kevin Carhart 0 siblings, 0 replies; 10+ messages in thread From: Kevin Carhart @ 2017-09-05 1:32 UTC (permalink / raw) To: Edbrowse-dev 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 > _______________________________________________ ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Edbrowse-dev] suggested additions 2017-09-04 2:38 [Edbrowse-dev] suggested additions Kevin Carhart 2017-09-04 14:12 ` Karl Dahlke 2017-09-04 15:06 ` Karl Dahlke @ 2017-09-04 17:10 ` Karl Dahlke 2017-09-05 2:15 ` [Edbrowse-dev] contentWindow Kevin Carhart 2 siblings, 1 reply; 10+ messages in thread From: Karl Dahlke @ 2017-09-04 17:10 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Edbrowse-dev] contentWindow 2017-09-04 17:10 ` Karl Dahlke @ 2017-09-05 2:15 ` Kevin Carhart [not found] ` <20170804223729.eklhad@comcast.net> 0 siblings, 1 reply; 10+ messages in thread From: Kevin Carhart @ 2017-09-05 2:15 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev 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} ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <20170804223729.eklhad@comcast.net>]
* Re: [Edbrowse-dev] contentWindow [not found] ` <20170804223729.eklhad@comcast.net> @ 2017-09-05 2:58 ` Kevin Carhart [not found] ` <20170804232757.eklhad@comcast.net> 0 siblings, 1 reply; 10+ messages in thread From: Kevin Carhart @ 2017-09-05 2:58 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <20170804232757.eklhad@comcast.net>]
* Re: [Edbrowse-dev] contentWindow [not found] ` <20170804232757.eklhad@comcast.net> @ 2017-09-05 3:57 ` Kevin Carhart 0 siblings, 0 replies; 10+ messages in thread From: Kevin Carhart @ 2017-09-05 3:57 UTC (permalink / raw) To: Edbrowse-dev That's great. Thank you. On Mon, 4 Sep 2017, Karl Dahlke wrote: > Ok, empty frame is expanded, should work now. > > Karl Dahlke > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-09-05 3:57 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-04 2:38 [Edbrowse-dev] suggested additions Kevin Carhart 2017-09-04 14:12 ` Karl Dahlke 2017-09-05 1:16 ` Kevin Carhart 2017-09-05 2:27 ` Karl Dahlke 2017-09-04 15:06 ` Karl Dahlke 2017-09-05 1:32 ` Kevin Carhart 2017-09-04 17:10 ` Karl Dahlke 2017-09-05 2:15 ` [Edbrowse-dev] contentWindow Kevin Carhart [not found] ` <20170804223729.eklhad@comcast.net> 2017-09-05 2:58 ` Kevin Carhart [not found] ` <20170804232757.eklhad@comcast.net> 2017-09-05 3:57 ` Kevin Carhart
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).