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] XHR - link to patch
Date: Mon, 12 Feb 2018 01:43:39 -0800 (PST)	[thread overview]
Message-ID: <alpine.LRH.2.03.1802120108250.21557@carhart.net> (raw)



I worked on two things that have been showing up in nasa.gov. 
The only file I modified is startwindow- please grab it from:
http://carhart.net/~kevin/startwindow_20180212.zip

Here are the two topics.

I. The INVALID_STATE console log message that shows up in XHR actions. 
Basically, to fix this I addressed two things.

A. Deal with encodeURI.  It was double-encoding.  I found a trick for 
preventing this.   Test if (URL == decode(URL)).  Since you can 
decode(decode(decode)))  any number of times and not make additional 
changes, you can use this to verify that your 
starting point is non-encoded, and only encode if it is necessary. This 
took care of one of the JSON requests which was returning an HTTP "400 Bad 
Request".  It works now, so more content can flow in.

B. Clean up the use of onreadystatechange() and onload().They are used 
in the XHR implementation, but to do the same thing.  I believe they're 
mutually exclusive and onload has been brought in as a replacement for 
onreadystatechange.  So it's a mistake to call them both, I think, and 
this was causing problems.  My remedy was to wrap each in a try-catch.

II. There is some widget code that gets added dynamically to nasa.gov and 
raises a runtime.  It's possible we could just ignore the runtime, but 
when I checked into it, it looked broadly useful to address this.

The error is:
widgets.js line 2661: TypeError: cannot read property 'prototype' of 
undefined

The code is expecting a type of element, HTMLElement, (and then it tries 
to access its prototype, etc.)

So I added HTMLElement in startwindow.  In three places where we establish 
a long litany of element types and then when it loops over them to put all 
of the functions on their prototypes, I added HTMLElement to the lists.

------

Here's a related subject that I noticed while working.  I think it 
involves the URL class.  I think there's an issue with scripts that do 
not have an src.  What should we do with those?  It should at least have 
an empty string rather than undefined, right?  There are a lot of console warnings 
in nasa, saying "hrefset boolean".  I didn't quite want to mess with that 
eval... but I think that may be the place to fix it.


thanks
Kevin


                 reply	other threads:[~2018-02-12  9:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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.1802120108250.21557@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).