Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #32794 > unrolled thread

Javascript seems to be giving different answers on some devices

Back to article view | Back to comp.lang.javascript

Contents

  Javascript seems to be giving different answers on some devices tadamsmar@gmail.com - 2017-03-18 05:57 -0700
    Re: Javascript seems to be giving different answers on some devices Julio Di Egidio <julio@diegidio.name> - 2017-03-18 06:11 -0700
      Re: Javascript seems to be giving different answers on some devices Tom Adams <tadamsmar@gmail.com> - 2017-03-18 06:50 -0700
    Re: Javascript seems to be giving different answers on some devices "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-03-18 14:33 +0100
      Re: Javascript seems to be giving different answers on some devices Tom Adams <tadamsmar@gmail.com> - 2017-03-18 06:48 -0700
        Re: Javascript seems to be giving different answers on some devices "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-03-18 15:13 +0100
      Re: Javascript seems to be giving different answers on some devices Tom Adams <tadamsmar@gmail.com> - 2017-03-18 06:52 -0700
        Re: Javascript seems to be giving different answers on some devices "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-03-18 14:58 +0100
          Re: Javascript seems to be giving different answers on some devices Tom Adams <tadamsmar@gmail.com> - 2017-03-18 09:08 -0700
            Re: Javascript seems to be giving different answers on some devices "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-03-18 18:34 +0100
              Re: Javascript seems to be giving different answers on some devices Tom Adams <tadamsmar@gmail.com> - 2017-03-18 10:39 -0700
                Re: Javascript seems to be giving different answers on some devices "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-03-18 21:13 +0100

#32794 — Javascript seems to be giving different answers on some devices

I have an app here:

http://www.poologic.com/poolcalc/Poolcalc.html

You have to hit the Calculate Now button to see the bug.

One user is reporting that it shows Dayton instead of Wichita St in the lower right (above Kentucky).  It should show Wichita St.

The javascript is generated by GWT 2.6.1.  That's an old version, but I am not sure that has anything to do with the problem.  All devices should be running the same javascript.

He saw the bug on an Iphone 7+ and 6+ and he tested Chrome.  I think he also test Safari.

But I tested on an Iphone 5s and it works properly on Safari and Chrome.  Also works on all our other devices (older Ipad, Windows 10, Windows 7).

I am stumped.  I don't see how it could be a caching problem because I am sure I never put a version of the program on the web that would show Dayton.

[toc] | [next] | [standalone]

#32795

On Saturday, March 18, 2017 at 1:57:13 PM UTC+1, Tom Adams wrote:
> I have an app here:
> 
> http://www.poologic.com/poolcalc/Poolcalc.html
> 
> You have to hit the Calculate Now button to see the bug.
> 
> One user is reporting that it shows Dayton instead of Wichita St in the lower right (above Kentucky).  It should show Wichita St.
> 
> The javascript is generated by GWT 2.6.1.  That's an old version, but I am not sure that has anything to do with the problem.  All devices should be running the same javascript.
> 
> He saw the bug on an Iphone 7+ and 6+ and he tested Chrome.  I think he also test Safari.
> 
> But I tested on an Iphone 5s and it works properly on Safari and Chrome.  Also works on all our other devices (older Ipad, Windows 10, Windows 7).
> 
> I am stumped.  I don't see how it could be a caching problem because I am sure I never put a version of the program on the web that would show Dayton.

Do you have any hunch as to what might be going wrong?
And, can't you really just get hold of an iphone 6+?

Anyway, user reports are not 100% reliable, so the outcome could even be a
"cannot reproduce"...

BTW, for issues of caching, usually it is enough to clear the browser's
cache.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#32798

On Saturday, March 18, 2017 at 9:11:45 AM UTC-4, Julio Di Egidio wrote:
> On Saturday, March 18, 2017 at 1:57:13 PM UTC+1, Tom Adams wrote:
> > I have an app here:
> > 
> > http://www.poologic.com/poolcalc/Poolcalc.html
> > 
> > You have to hit the Calculate Now button to see the bug.
> > 
> > One user is reporting that it shows Dayton instead of Wichita St in the lower right (above Kentucky).  It should show Wichita St.
> > 
> > The javascript is generated by GWT 2.6.1.  That's an old version, but I am not sure that has anything to do with the problem.  All devices should be running the same javascript.
> > 
> > He saw the bug on an Iphone 7+ and 6+ and he tested Chrome.  I think he also test Safari.
> > 
> > But I tested on an Iphone 5s and it works properly on Safari and Chrome.  Also works on all our other devices (older Ipad, Windows 10, Windows 7).
> > 
> > I am stumped.  I don't see how it could be a caching problem because I am sure I never put a version of the program on the web that would show Dayton.
> 
> Do you have any hunch as to what might be going wrong?
> And, can't you really just get hold of an iphone 6+?
> 
> Anyway, user reports are not 100% reliable, so the outcome could even be a
> "cannot reproduce"...
> 
> BTW, for issues of caching, usually it is enough to clear the browser's
> cache.
> 
> HTH,
> 
> Julio

I don't have any good leads.

I need to find a way to reproduce the bug or evidence.

[toc] | [prev] | [next] | [standalone]

#32796

tadamsmar@gmail.com wrote on 18 Mar 2017 in comp.lang.javascript:

> I have an app here:
> 
> http://www.poologic.com/poolcalc/Poolcalc.html
> 
> You have to hit the Calculate Now button to see the bug.
> 
> One user is reporting that it shows Dayton instead of Wichita St in the
> lower right (above Kentucky).  It should show Wichita St. 
> 
> The javascript is generated by GWT 2.6.1. 

???

> That's an old version, but I
> am not sure that has anything to do with the problem.  All devices
> should be running the same javascript. 

Well, Javascript is NOT a 'script of Java', so:
 
'Javascript' is the programming language,
the 'javascript-engine' is [here] the clientside interpreter,
the 'javascript-script' is the script code.

Do you mean:
"All devices should be running the same javascript-script." ?


> He saw the bug on an Iphone 7+ and 6+ and he tested Chrome.  I think he
> also test Safari. 

The Javascript source is not humanly-readable, but I expect the bug is in 
this 'javascript-script', if it acts as you describe.
 
> But I tested on an Iphone 5s and it works properly on Safari and Chrome.
>  Also works on all our other devices (older Ipad, Windows 10, Windows
> 7). 

"Properly" as in "the way I want it"?

> I am stumped. 

I am not.

The joy [or the curse, depending on your point of view] of clientside 
Javascript, is that it runs on different 'javascript-engines' so you should 
optimalize for all the engines you want the script to run.

As this seems to be a very old script, the programmer could not test it on 
the more modern ones.

So, it stands to reason that unexpected behavour can be expected.

Some internal functions could have different definitions in more modern 
versions, or the whole script could have been designed for 'jscript' 
[meaning M-soft-Javascript].

> I don't see how it could be a caching problem because I
> am sure I never put a version of the program on the web that would show
> Dayton. 

Eh, did you change the script recently?

Well, catching can easily be avoided by testing on the neighbour's machine,
certainly not just by naming your js-file "hello.nocache.js".


I would suggest you rewrite your script in humanly-readable code,
and then have us have a look.

PS: if you do not want to have to bother with different execution-engines,
use serverside-programming, as I doubt it poses a heavy load on your server.

Serverside-javascript is on-topic here.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32797

I mean all devices should be running the same javascript-script.

I am just doing math.

The guy sent me a screen shot so I don't think he is confused.  It like the math calculations are giving different answers.  I know these are
different engines, but one would think math would work.

He also tested on Windows 8 and got the same result.  So he has tested
3 different engines (or at least 3 different OSes).

I tested on Windows 7 and 10 and found no problem.

On Saturday, March 18, 2017 at 9:33:29 AM UTC-4, Evertjan. wrote:
> tadamsmar@gmail.com wrote on 18 Mar 2017 in comp.lang.javascript:
> 
> > I have an app here:
> > 
> > http://www.poologic.com/poolcalc/Poolcalc.html
> > 
> > You have to hit the Calculate Now button to see the bug.
> > 
> > One user is reporting that it shows Dayton instead of Wichita St in the
> > lower right (above Kentucky).  It should show Wichita St. 
> > 
> > The javascript is generated by GWT 2.6.1. 
> 
> ???
> 
> > That's an old version, but I
> > am not sure that has anything to do with the problem.  All devices
> > should be running the same javascript. 
> 
> Well, Javascript is NOT a 'script of Java', so:
>  
> 'Javascript' is the programming language,
> the 'javascript-engine' is [here] the clientside interpreter,
> the 'javascript-script' is the script code.
> 
> Do you mean:
> "All devices should be running the same javascript-script." ?
> 
> 
> > He saw the bug on an Iphone 7+ and 6+ and he tested Chrome.  I think he
> > also test Safari. 
> 
> The Javascript source is not humanly-readable, but I expect the bug is in 
> this 'javascript-script', if it acts as you describe.
>  
> > But I tested on an Iphone 5s and it works properly on Safari and Chrome.
> >  Also works on all our other devices (older Ipad, Windows 10, Windows
> > 7). 
> 
> "Properly" as in "the way I want it"?
> 
> > I am stumped. 
> 
> I am not.
> 
> The joy [or the curse, depending on your point of view] of clientside 
> Javascript, is that it runs on different 'javascript-engines' so you should 
> optimalize for all the engines you want the script to run.
> 
> As this seems to be a very old script, the programmer could not test it on 
> the more modern ones.
> 
> So, it stands to reason that unexpected behavour can be expected.
> 
> Some internal functions could have different definitions in more modern 
> versions, or the whole script could have been designed for 'jscript' 
> [meaning M-soft-Javascript].
> 
> > I don't see how it could be a caching problem because I
> > am sure I never put a version of the program on the web that would show
> > Dayton. 
> 
> Eh, did you change the script recently?
> 
> Well, catching can easily be avoided by testing on the neighbour's machine,
> certainly not just by naming your js-file "hello.nocache.js".
> 
> 
> I would suggest you rewrite your script in humanly-readable code,
> and then have us have a look.
> 
> PS: if you do not want to have to bother with different execution-engines,
> use serverside-programming, as I doubt it poses a heavy load on your server.
> 
> Serverside-javascript is on-topic here.
> 
> -- 
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32802

Tom Adams <tadamsmar@gmail.com> wrote on 18 Mar 2017 in
comp.lang.javascript: 

> I mean all devices should be running the same javascript-script.

Stop thinking in 'devices', concentrate on 'javascript-engines'.
[and possibly on different 'browser-DOMs'.

The same script can be interpreted differently depending on that.

> I am just doing math.

No, you are programming.
 
> The guy sent me a screen shot so I don't think he is confused.

???

> It like the math calculations are giving different answers.

No, your programme on different engines probably acts differently,
because your programme does not consider cross-browser, cross-version, 
cross-engine programming.

> I know these are 
> different engines, but one would think math would work.

Only if correctly interpreted, 'correctly' in the sense of programmed so.

> He also tested on Windows 8 and got the same result.  So he has tested
> 3 different engines (or at least 3 different OSes).
> 
> I tested on Windows 7 and 10

It os about browsers and their javascript-engines, 
not about operating-systems, imho.

> and found no problem.

Well, you posted because you had a problem.

I suggest the difference in outcome is in your code, that acts differently 
on different engines. So your code needs improving upon.

The first thing you do is debug imho. But your pathway to the final 
minimalized code makes that very difficult.

So back up, write a decent Javascript-script that does the job [or at least 
the math-part], you seem to know the required [by you] action.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32799

On Saturday, March 18, 2017 at 9:33:29 AM UTC-4, Evertjan. wrote:
> tadamsmar@gmail.com wrote on 18 Mar 2017 in comp.lang.javascript:
> 
> > I have an app here:
> > 
> > http://www.poologic.com/poolcalc/Poolcalc.html
> > 
> > You have to hit the Calculate Now button to see the bug.
> > 
> > One user is reporting that it shows Dayton instead of Wichita St in the
> > lower right (above Kentucky).  It should show Wichita St. 
> > 
> > The javascript is generated by GWT 2.6.1. 
> 
> ???
> 
> > That's an old version, but I
> > am not sure that has anything to do with the problem.  All devices
> > should be running the same javascript. 
> 
> Well, Javascript is NOT a 'script of Java', so:
>  
> 'Javascript' is the programming language,
> the 'javascript-engine' is [here] the clientside interpreter,
> the 'javascript-script' is the script code.
> 
> Do you mean:
> "All devices should be running the same javascript-script." ?
> 
> 
> > He saw the bug on an Iphone 7+ and 6+ and he tested Chrome.  I think he
> > also test Safari. 
> 
> The Javascript source is not humanly-readable, but I expect the bug is in 
> this 'javascript-script', if it acts as you describe.
>  
> > But I tested on an Iphone 5s and it works properly on Safari and Chrome.
> >  Also works on all our other devices (older Ipad, Windows 10, Windows
> > 7). 
> 
> "Properly" as in "the way I want it"?
> 
> > I am stumped. 
> 
> I am not.
> 
> The joy [or the curse, depending on your point of view] of clientside 
> Javascript, is that it runs on different 'javascript-engines' so you should 
> optimalize for all the engines you want the script to run.
> 
> As this seems to be a very old script, the programmer could not test it on 
> the more modern ones.
> 
> So, it stands to reason that unexpected behavour can be expected.
> 
> Some internal functions could have different definitions in more modern 
> versions, or the whole script could have been designed for 'jscript' 
> [meaning M-soft-Javascript].
> 
> > I don't see how it could be a caching problem because I
> > am sure I never put a version of the program on the web that would show
> > Dayton. 
> 
> Eh, did you change the script recently?
> 
> Well, catching can easily be avoided by testing on the neighbour's machine,
> certainly not just by naming your js-file "hello.nocache.js".
> 
> 
> I would suggest you rewrite your script in humanly-readable code,
> and then have us have a look.
> 
> PS: if you do not want to have to bother with different execution-engines,
> use serverside-programming, as I doubt it poses a heavy load on your server.
> 
> Serverside-javascript is on-topic here.
> 
> -- 
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

GWT is Google Windowing Toolkit.

I use it to convert Java to Javascript-script.

[toc] | [prev] | [next] | [standalone]

#32800

Tom Adams <tadamsmar@gmail.com> wrote on 18 Mar 2017 in comp.lang.javascript:

> GWT is Google Windowing Toolkit.

Did'nt know that.

> I use it to convert Java to Javascript-script.

Well, why would you do that?

Meseems it makes debugging so much more difficult, 
as the OP recently found out.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32803

On Saturday, March 18, 2017 at 9:58:47 AM UTC-4, Evertjan. wrote:
> Tom Adams <tadamsmar@gmail.com> wrote on 18 Mar 2017 in comp.lang.javascript:
> 
> > GWT is Google Windowing Toolkit.
> 
> Did'nt know that.
> 
> > I use it to convert Java to Javascript-script.
> 
> Well, why would you do that?

The app was originally developed and deployed as a Java applet.  But Java applets got a really bad rep for being hacked and Oracle upgraded them to make them almost unusable because of the need for security configuation.

So, I used GWT "complies" Java applets into javascript-script.

> 
> Meseems it makes debugging so much more difficult, 
> as the OP recently found out.

The code works on some engines and not others.

I can debug in Java.  javascript is playing the role of the object code, Java is compiled to javascript.

I have confirmed that it is not a caching problem. I uploaded a version with that displays "U of Dayton" and my volunteer tester got that on his phone.

> 
> -- 
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32804

Tom Adams <tadamsmar@gmail.com> wrote on 18 Mar 2017 in
comp.lang.javascript: 

>> > GWT is Google Windowing Toolkit.

>  Well, why would you do that?
> 
> The app was originally developed and deployed as a Java applet.  But
> Java applets got a really bad rep for being hacked and Oracle upgraded
> them to make them almost unusable because of the need for security
> configuation. 
> 
> So, I used GWT "complies" Java applets into javascript-script.

While it perhaps "compiles" it does not "comply" with those engines.

Perhaps GWT is not up to the job?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32805

On Saturday, March 18, 2017 at 1:34:44 PM UTC-4, Evertjan. wrote:
> Tom Adams <tadamsmar@gmail.com> wrote on 18 Mar 2017 in
> comp.lang.javascript: 
> 
> >> > GWT is Google Windowing Toolkit.
> 
> >  Well, why would you do that?
> > 
> > The app was originally developed and deployed as a Java applet.  But
> > Java applets got a really bad rep for being hacked and Oracle upgraded
> > them to make them almost unusable because of the need for security
> > configuation. 
> > 
> > So, I used GWT "complies" Java applets into javascript-script.
> 
> While it perhaps "compiles" it does not "comply" with those engines.
> 
> Perhaps GWT is not up to the job?
> 
> -- 
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Could be.  But kinda odd since I am not doing anything unusual.

At least that gives me something to try: Upgrade GWT to the latest.  I have been remiss in not upgrading for a couple of years.

[toc] | [prev] | [next] | [standalone]

#32808

Tom Adams <tadamsmar@gmail.com> wrote on 18 Mar 2017 in
comp.lang.javascript: 

>> > So, I used GWT "complies" Java applets into javascript-script.
>> 
>> While it perhaps "compiles" it does not "comply" with those engines.
>> 
>> Perhaps GWT is not up to the job?

[please do not quote signatures on usenet, signature removed]

> Could be.  But kinda odd since I am not doing anything unusual.

Well yes, you do, as you come to this NG [rightly so perhaps] complaining 
that some javascript script does not do what you expect, while you do not 
want us [javascript addicts] to discuss the script in question, discounting 
the compressed GWT output as discussable ;-).

> At least that gives me something to try: Upgrade GWT to the latest.  I
> have been remiss in not upgrading for a couple of years. 

That seems outside of our expertise on this NG, but who knows.

I for one would not want to use scripting, I do not understand, on my 
website, where I can rather do without.

What if some foreign or domestic power ...?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web