edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Kevin Carhart <kevin@carhart.net>
To: edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] questions about new finds
Date: Thu, 23 Jun 2016 04:22:41 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LRH.2.03.1606230329270.22893@carhart.net> (raw)




Predominantly for Karl , hi Karl:

I have several things to submit.  There are a couple of areas where I'd 
like to find out if you think the entire class of correction is a mistake 
and wouldn't be good, before I make a patch out of it.  Or I have 
discovered a couple of areas where I'd like to know if you think there 
would be a good approach.

(1) Not a JS problem for a change: Sites are creating kinds of tags with 
their own invented vocabulary as the type. These tag types are not in 
availableTags, so we get a message that the tag could not be created. 
For instance, Amazon and other pages want to create:
video
canvas
header
comment
fragment
nav
modernizr

Do we want to add these phrases to availableTags even though they are just 
made-up names?  Probably not, since it becomes silly to hardcode 
an endless number of them.  'video' and 'comment' seem 
plausible, but 'modernizr' is just some library.  Is there some way that 
availableTags could be amended on the fly and these and all future 
unencountered tag types would get a generic placeholder?  The reason I 
for wanting to support these things would be that maybe the site's 
javascript expects to address its own tag type and then write to it later 
on.

(2) Amazon has a strange <script> block.  It is not javascript.  It is 
just a bunch of json in script tags, and the type is specified.  This may 
be known as JSONP - I'm not sure.   So it is 
like <script type="abc">{a:1,b:2,c:3}</script>. 
In prepareScript, you have code to check that the language is 
"javascript".  What do you think about also testing the "type" attribute? 
If a script has a strange type specified, return without parsing.

(3) I think some page code within a timeout isn't getting to run, because 
it fails the strict test at the top of setTimeout where there must be 2 
arguments and the second one must be numeric.  Some of the jquery versions 
say this, for example:

setTimeout( callback );

It doesn't run, and good thing too, if the strictness is necessary. 
However, it seems like a lot of site developers consider just 1 argument 
to be legitimate.  Should we loosen the test?  I am worried 
about this either way.  I tried it more lenient, and bad code seemed to 
run.  It was hard to isolate but edbrowse was crashing - so I don't know 
what to do.  I was between a rock and a hard place, so I just went on to 
something else.  I bet this is a cause of some sites not working.

(4) I was wondering about a change in the event listener.  At least some 
of the time, I have gotten events to work by having a kind of object 
called Event.  Then you pass an object called 'click' or whatever it 
needs to be.  I had some success with this on the 
Drescher page from Sebastian, in fact.  (Sebastian points out that online 
banking is a higher priority to fix than Austrian metal with a sense of 
humor, but I happened to learn a lot from the Drescher site because they 
use jquery and xhr!)

So, in startwindow, the handler is currently fired off like a[i]();

But what if there was an argument inside the parentheses, which would be 
your event object.

So the eval block begins
eval('this.' + ev + ........................
var tempEvent = new Event
tempEvent.type = ev; // actually would be ev without the "on" prepended
a[i](tempEvent);} };');

That's enough for now, there are a lot of exciting areas to amend which I 
think will improve some sites.  We have that whole iframe question as 
well.  I also have some more normal additions I can submit soon for 
domLink and for the createElement switch statement in startwindow.  For 
instance, elements need to have nodeType.

thanks for reading
Kevin


             reply	other threads:[~2016-06-23 11:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 11:22 Kevin Carhart [this message]
2016-06-23 16:41 ` Karl Dahlke
2016-06-27  6:39   ` Kevin Carhart
2016-07-02 16:48     ` Adam Thompson
2016-07-02 17:29       ` Karl Dahlke
2016-07-03  9:54         ` Adam Thompson
2016-07-02 22:11       ` Kevin Carhart
2016-07-03 11:12         ` Adam Thompson

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=alpine.LRH.2.03.1606230329270.22893@carhart.net \
    --to=kevin@carhart.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).