Re: [Edbrowse-dev] XHR

[Kevin Carhart <kevin@carhart.net>]

>> Great, here is a zip of startwindow.js and jseng-moz.cpp.
>
> Kevin this is definitely blazing a trail.
> If you don't mind I'm going to postpone looking at it,
> for a time, while I rebundle things,
> because it seems we all agree that much of http.c should be shared

Thanks Karl!  Yes, any usage, whatever works.
It's going to be superceded by the ability to call http.c
and have a better foundation.

> Meantime there are still plenty of small bugs to fix in the existing js
> and cookies and so on.

Yes, one thing I think I noticed in the output from fastmail
is a JS runtime where it tried to find nextSibling or previousSibling.
I think that is another way of moving among nodes,
comparable to child and parent moves.

> I really thought I had read somewhere that id= stands in for name=,
> but Chris says maybe it doesn't, so IDK.

Hmmmm.  So here are some thoughts on fastmail and the
issues raised:
- According to Chuck, basic actions in fastmail work now!
- In retrospect, I'm not sure if the use_classic cookie and
the way it gets into document.cookie was the culprit, because
I think the two hiddens without a name were the cause of the
session key mismatch error.
- I reported a doubling at one point (use_classic; use_classic;)
but I never hit this again so it was probably a sidetrack.
- Possibly the two hiddens without a name have their name
attribute grafted in by javascript.  That would be
a plausible reason
for why this popular, robust website has something illegal
just laying around.  That it actually isn't illegal, but
there is JS that is supposed to deal with it and isn't
running.
We could keep this formulation in mind - it seems
like something I have stumbled on before: in the rendered
html, the user might hit something incongruous like
<Log in><Log out>
Combined with the fact that it doesn't work right.
One reason it could be this way is that site
authors have coded a
superset in their server-side code, and are intending
on using JS to always take away one of those on the
client side before it reaches the user.  But then maybe
if the JS file breaks on something else (like Sibling
or other things), the JS file bails out and the code
responsible for the take-away is never reached.  I
think maybe the candy-store website has this too.

happy holidays,
Kevin