Dear diary, on Sun, Feb 20, 2005 at 10:06:15PM CET, I got a letter,
where Witold Filipczyk <[EMAIL PROTECTED]> told me, that...
> > >
> > > Index: elinks/src/ecmascript/spidermonkey.c
> > > diff -u elinks/src/ecmascript/spidermonkey.c:1.193
> > > elinks/src/ecmascript/spidermonkey.c:1.194
> > > --- elinks/src/ecmascript/spidermonkey.c:1.193 Sun Feb 20 21:07:24 2005
> > > +++ elinks/src/ecmascript/spidermonkey.c Sun Feb 20 21:24:50 2005
> > > @@ -2158,7 +2158,7 @@
> > > setup_safeguard(interpreter, ctx);
> > > ret = JS_EvaluateScript(ctx, JS_GetGlobalObject(ctx),
> > > code->source, code->length, "", 0, &rval);
> > > - if (ret == 2) {
> > > + if (ret == 2) { /* onClick="history.back()" */
> > > return 0;
> > > };
> > > if (ret == JS_FALSE) {
> >
> > I'm sorry but I fear there is a misunderstanding here. I wanted you to
> > describe why such a special hack for the history.back() case is needed.
>
> It's difficult to say why. It's must be so to let
> <a href="javascript:history_back()> and onClick="history_back()" work.
> history_back must return 0 to render previous page for onClick.
> and history_back must return non zero for "javascript:history_back()"
> to prevent calculating new link from returned *rval.
> In short: simply it must be so.
Excellent. Could you please stick this long explanation you just wrote
to the return 2; statement in history_back()?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
_______________________________________________
ELinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
