[Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Chuck Hallenbeck]

Good morning,

There is a front end to Google at www.startpage.com where the mozjs-24
version of edbrowse seems unable to activate the submit buttton.  I no
longer have a copy of the program which uses the older js libraries, so I
can't say if it works or not. But elinks works, returning reasonable search
results.

I had a similar failure yesterday on www.vtech.com, where the "add to cart"
button could not be activated with edbrowse 3.5.1, although I did not try
doing it with elinks.

Chuck

-- 

 Chuck in Ghent, just northeast of Hudson on the Hudson.

Re: [Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Adam Thompson]

On Sun, Feb 09, 2014 at 10:37:54AM -0500, Chuck Hallenbeck wrote:
> There is a front end to Google at www.startpage.com where the mozjs-24
> version of edbrowse seems unable to activate the submit buttton.  I no
> longer have a copy of the program which uses the older js libraries, so I
> can't say if it works or not. But elinks works, returning reasonable search
> results.

I think this has something to do with the fact that it's an image input type
rather than a submit one.

> I had a similar failure yesterday on www.vtech.com, where the "add to cart"
> button could not be activated with edbrowse 3.5.1, although I did not try
> doing it with elinks.

Couldn't test this as trying to click on one of the product categories caused a segfault.

Cheers,
Adam.

Re: [Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Chuck Hallenbeck]

Hi Adam,

Here is what it looks like here:

Script started on Sun 09 Feb 2014 11:07:03 AM EST
[chuxroom@dj ~]$ e www.startpage.com
no trailing newline
33074
1550
/<>
<><Go secure>
i1?
text query
i=small squirrels
<small squirrels><Go secure>
db8
i2*
scmd = *
findField returns 2.92
undoCompare no undo map
jSyncup starts
jSyncup ends
www.startpage.com/: 1: TypeError: document.blah.submit is not a function
qsort 71 71
undoCompare strip 0
.
<small squirrels><Go secure>
qt
[chuxroom@dj ~]$ exit

Script done on Sun 09 Feb 2014 11:08:59 AM EST


Sorry I've not retained debug symbols. But the i1? command says the input
field is a text query. Not sure at all about the messages following the i2*
command, except to notice that the line pointer has not changed after
trying to submit the query.

Chuck


-- 

 Chuck in Ghent, just northeast of Hudson on the Hudson.

Re: [Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Adam Thompson]

On Sun, Feb 09, 2014 at 11:15:37AM -0500, Chuck Hallenbeck wrote:
> Here is what it looks like here:
> 
> Script started on Sun 09 Feb 2014 11:07:03 AM EST
> [chuxroom@dj ~]$ e www.startpage.com
> no trailing newline
> 33074
> 1550
> /<>
> <><Go secure>
> i1?
> text query
> i=small squirrels
> <small squirrels><Go secure>
> db8
> i2*
> scmd = *
> findField returns 2.92
> undoCompare no undo map
> jSyncup starts
> jSyncup ends
> www.startpage.com/: 1: TypeError: document.blah.submit is not a function
> qsort 71 71
> undoCompare strip 0
> .
> <small squirrels><Go secure>
> qt
> [chuxroom@dj ~]$ exit
> 
> Script done on Sun 09 Feb 2014 11:08:59 AM EST
> 

Thanks, the important thing in this output is to notice that it's complaining
about something not being a function (document.blah.submit) which should be.
Looks like my initial guess was wrong and that edbrowse is submitting the form,
but the js used to submit it isn't running.

We need to look at how the form class is being defined to see what's happened 
here.

Cheers,
Adam.

[Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Karl Dahlke]

Well this is some of the dom stuff that I want to fix up and enhance.
The troublesome line in startpage.com is here.

<input type='image' src='/graphics/stp_search.gif' id='submit' style='width:35px;height:34px;'/>

It has an ID set to submit.
I remember this confusion from ten years ago, what does that really mean?
It means I put this tag with label submit in the ID array, and that's all ok,
but it also meant, for some websites at that time,
that the tag was also suppose to be linked to the form,
which is named blah in this case, under the name submit.
I do this, and it displaces the function submit, which you are trying to call.
The submit function is lost.
It is possible that I shouldn't be doing this at all,
or I shouldn't be doing it any more, perhaps it is deprecated.
I remember at one time there were websites that needed this behavior,
but here is one that cannot tolerate this behavior.
I could probably turn it off by commenting out one line of code,
jsdom.cpp line 1234

JS_DefineProperty(cw->jss->jcx, owner_root, idname, vv,
NULL, NULL, attr);

But should I?
I will say that this small change allows startpage submit button
to work again, although I then receive a message from them
about blocking my isp due to high usage, so I don't know what that means.

So short term, I might comment out that line of code,
and hope it fixes more websites than it breaks -
and long term, I need to understand the complete dom model,
all its functions, its side effects, its interactions.
And it has plenty of side effects.
Defining an input field in a form automatically puts links
here and there and adds this to that array and puts this in the id master list
and so on.
So there's plenty of work here, perhaps more
in the understanding of the model than in its actual implementation.

Karl Dahlke

Re: [Edbrowse-dev] Edbrowse 3.5.1 unable to activate submit button

[Adam Thompson]

On Sun, Feb 09, 2014 at 12:19:51PM -0500, Karl Dahlke wrote:
> Well this is some of the dom stuff that I want to fix up and enhance.
> The troublesome line in startpage.com is here.
> 
> <input type='image' src='/graphics/stp_search.gif' id='submit' style='width:35px;height:34px;'/>
>
> It has an ID set to submit.

Ah, I missed the id, that's unfortunate.

> I remember this confusion from ten years ago, what does that really mean?
> It means I put this tag with label submit in the ID array, and that's all ok,
> but it also meant, for some websites at that time,
> that the tag was also suppose to be linked to the form,
> which is named blah in this case, under the name submit.
> I do this, and it displaces the function submit, which you are trying to call.
> The submit function is lost.

Ugh, that sounds like an interesting js error.
> It is possible that I shouldn't be doing this at all,
> or I shouldn't be doing it any more, perhaps it is deprecated.
> I remember at one time there were websites that needed this behavior,
> but here is one that cannot tolerate this behavior.
> I could probably turn it off by commenting out one line of code,
> jsdom.cpp line 1234
> 
> JS_DefineProperty(cw->jss->jcx, owner_root, idname, vv,
> NULL, NULL, attr);
> 
> But should I?
> I will say that this small change allows startpage submit button
> to work again, although I then receive a message from them
> about blocking my isp due to high usage, so I don't know what that means.

Ah ok, though I suspect that change is going to have unfortunate side-effects.

> So short term, I might comment out that line of code,
> and hope it fixes more websites than it breaks -
> and long term, I need to understand the complete dom model,
> all its functions, its side effects, its interactions.
> And it has plenty of side effects.
> Defining an input field in a form automatically puts links
> here and there and adds this to that array and puts this in the id master list
> and so on.
> So there's plenty of work here, perhaps more
> in the understanding of the model than in its actual implementation.

I also need to get a better understanding of how the dom model and id attribute
interact, and what this means with regards to already-existing js methods.
I'd hope that there is some mechanism (which we're not currently implementing)
to prevent this from happening (standard methods being overwritten with
user-defined properties).

Cheers,
Adam.