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


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

Debugging Errors -- a conundrum -- I think

Started by"Mel Smith" <med_cutout_syntel@aol.com>
First post2014-01-20 09:48 -0700
Last post2014-01-20 21:37 +0100
Articles 18 — 6 participants

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


Contents

  Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-20 09:48 -0700
    Re: Debugging Errors -- a conundrum -- I think Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-20 17:59 +0100
      Re: Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-20 10:45 -0700
        Re: Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-20 12:50 -0700
          Re: Debugging Errors -- a conundrum -- I think Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-20 21:01 +0100
            Re: Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-20 13:22 -0700
              Re: Debugging Errors -- a conundrum -- I think Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-20 21:33 +0100
                Re: Debugging Errors -- a conundrum -- I think Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-20 21:42 +0100
                Re: Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-20 15:33 -0700
                  Re: Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-20 16:02 -0700
                    Re: Debugging Errors -- a conundrum -- I think Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-21 00:28 +0100
                      Re: Debugging Errors -- a conundrum -- I think Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-21 06:01 +0100
                        Re: Debugging Errors -- a conundrum -- I think "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-21 08:47 +0100
                          Re: Debugging Errors -- a conundrum -- I think Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-21 13:01 +0100
                            Re: Debugging Errors -- a conundrum -- I think John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-22 15:18 +0000
                  Re: Debugging Errors -- a conundrum -- I think Norman Peelman <npeelman@cfl.rr.com> - 2014-01-21 06:13 -0500
                    Re: Debugging Errors -- a conundrum -- I think "Mel Smith" <med_cutout_syntel@aol.com> - 2014-01-21 10:01 -0700
            Re: Debugging Errors -- a conundrum -- I think Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-20 21:37 +0100

#22721 — Debugging Errors -- a conundrum -- I think

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-20 09:48 -0700
SubjectDebugging Errors -- a conundrum -- I think
Message-ID<bk52b9F3d4mU1@mid.individual.net>
Hi:

    I use the alert() function to track down errors in the JS/ES portions of 
my developing page.

    But, I now have an error that *disappears* if I place an alert() at the 
suspected place in the suspected function !  The error occurs in IE8 but no 
error in Chrome

    (btw, the 'suspected place' is a function that is called by 'onclick' on 
an option in a <select> element. The symptom is that I must 'click' 
successively on two different options to activate the 'click' function. 
Clicking on just one option results in a 'hang' on every other field. )

    So, I'm damned if I do use alert() and damned if I don't.   :(

Question:

    What class of errors, or type of error, or simple error, is hidden or 
covered up by using the alert() function ?

Thank you.

-- 
Mel Smith

[toc] | [next] | [standalone]


#22722

FromChristoph Michael Becker <cmbecker69@arcor.de>
Date2014-01-20 17:59 +0100
Message-ID<52dd55dd$0$6554$9b4e6d93@newsspool4.arcor-online.net>
In reply to#22721
Mel Smith wrote:

>     I use the alert() function to track down errors in the JS/ES portions of 
> my developing page.
> 
>     But, I now have an error that *disappears* if I place an alert() at the 
> suspected place in the suspected function !  The error occurs in IE8 but no 
> error in Chrome
> 
>     (btw, the 'suspected place' is a function that is called by 'onclick' on 
> an option in a <select> element. The symptom is that I must 'click' 
> successively on two different options to activate the 'click' function. 
> Clicking on just one option results in a 'hang' on every other field. )
> 
>     So, I'm damned if I do use alert() and damned if I don't.   :(
> 
> Question:
> 
>     What class of errors, or type of error, or simple error, is hidden or 
> covered up by using the alert() function ?

Most likely all kinds of timing problems.

Anyway, you may consider using console.log & friends for debugging
purposes.[1]

[1] <http://devtoolsecrets.com/>

-- 
Christoph M. Becker

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


#22723

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-20 10:45 -0700
Message-ID<bk55meF44sjU1@mid.individual.net>
In reply to#22722
Christoph said:

> Most likely all kinds of timing problems.
>
> Anyway, you may consider using console.log & friends for debugging
> purposes.[1]
>
> [1] <http://devtoolsecrets.com/>

Hi: Christoph:

    I do all my prelim building/testing with IE8, then I do final checking 
with IE9, IE10, Chrome, and FF)

    With IE8, I cannot get console.log to work (i.e., window.console == 
'undefined').  So, I've never been able to get it working on my IE8, and 
I've never seen it in action either.

    Is there a way for it to be used on IE8 ??

Thanks,

-Mel

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


#22724

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-20 12:50 -0700
Message-ID<bk5d0fF5n94U1@mid.individual.net>
In reply to#22723
Hi Christoph:

I found (on stackoverflow) the following script to activate console.log on 
my IE8 dev machine (a win xp (sp3) system).

    I place the code below (as console.js) just before </head>, then I 
tested.

    Console.log worked in my suspect onclick function, but I still can't 
find why my 'hang' occurs on IE8 and not on Chrome ??

Thanks,

-Mel Smith


*******************************************
// Avoid `console` errors in browsers that lack a console.
(function() {
    var method;
    var noop = function () {};
    var methods = [
        'assert', 'clear', 'count', 'debug', 'dir', 'dirxml', 'error',
        'exception', 'group', 'groupCollapsed', 'groupEnd', 'info', 'log',
        'markTimeline', 'profile', 'profileEnd', 'table', 'time', 'timeEnd',
        'timeStamp', 'trace', 'warn'
    ];
    var length = methods.length;
    var console = (window.console = window.console || {});

    while (length--) {
        method = methods[length];

        // Only stub undefined methods.
        if (!console[method]) {
            console[method] = noop;
        }
    }
}());

******************************************** 

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


#22725

FromChristoph Michael Becker <cmbecker69@arcor.de>
Date2014-01-20 21:01 +0100
Message-ID<52dd809b$0$6547$9b4e6d93@newsspool4.arcor-online.net>
In reply to#22724
Mel Smith wrote:

> I found (on stackoverflow) the following script to activate console.log on 
> my IE8 dev machine (a win xp (sp3) system).

AFAIK, the problem with console.log() on IE 8 is that it throws an
error, if the console window is not open; otherwise console.log() should
work fine.  It seems to me that the script just caters for this issue.

>     I place the code below (as console.js) just before </head>, then I 
> tested.
> 
>     Console.log worked in my suspect onclick function, but I still can't 
> find why my 'hang' occurs on IE8 and not on Chrome ??

Um, I've read your OP again, and noticed that you're using the onclick
attribute of a select element.  You may want to try using the onchange
attribute instead.

-- 
Christoph M. Becker

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


#22727

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-20 13:22 -0700
Message-ID<bk5es2F645gU1@mid.individual.net>
In reply to#22725
Christoph said:

> Um, I've read your OP again, and noticed that you're using the onclick
> attribute of a select element.  You may want to try using the onchange
> attribute instead.


Hi Christoph:

    After several problems a week ago with 'onchange', I switched to 
'onclick'.  Those probs were cleared up, and now I have the 'hang' on IE8 
unless I 'click' once, then click a different option next. Then it works.

    Arggg ...

-Mel


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


#22728

FromChristoph Michael Becker <cmbecker69@arcor.de>
Date2014-01-20 21:33 +0100
Message-ID<52dd8824$0$6563$9b4e6d93@newsspool4.arcor-online.net>
In reply to#22727
Mel Smith wrote:

> Christoph said:
> 
>> Um, I've read your OP again, and noticed that you're using the onclick
>> attribute of a select element.  You may want to try using the onchange
>> attribute instead.
> 
>     After several problems a week ago with 'onchange', I switched to 
> 'onclick'.  Those probs were cleared up, and now I have the 'hang' on IE8 
> unless I 'click' once, then click a different option next. Then it works.
> 
>     Arggg ...

Now I've read your OP again:

> btw, the 'suspected place' is a function that is called by 'onclick' >
on an option in a <select> element.

I suggest you don't use the onclick/onchange attribute of the option
elements, but instead use the onchange attribute of the select element.
 How to access the selected option is explained in the FAQ section "How
do I get the value of a form control?"[1].

[1] <http://pointedears.de/scripts/faq/cljs/#formControlAccess>

-- 
Christoph M. Becker

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


#22730

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-20 21:42 +0100
Message-ID<34762870.g84lkbnriq@PointedEars.de>
In reply to#22728
Christoph Michael Becker wrote:

> Mel Smith wrote:
>> btw, the 'suspected place' is a function that is called by 'onclick'
>> on an option in a <select> element.
> 
> I suggest you don't use the onclick/onchange attribute of the option
> elements, but instead use the onchange attribute of the select element.

I suggest that they do neither, unless the function does not cause 
navigation or would hinder the user when they change the select's value
(without its losing focus) in another way, in which case the latter 
attribute is preferable.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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


#22731

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-20 15:33 -0700
Message-ID<bk5mijF7pdgU1@mid.individual.net>
In reply to#22728
Christoph said:


> Now I've read your OP again:
>
>> btw, the 'suspected place' is a function that is called by 'onclick' >
> on an option in a <select> element.

    No, the 'onclick' function is in the <select> tag

>
> I suggest you don't use the onclick/onchange attribute of the option
> elements, but instead use the onchange attribute of the select element.
> How to access the selected option is explained in the FAQ section "How
> do I get the value of a form control?"[1].

    AISB,  I was getting errors (a week ago) using the onchange event. Then, 
(after googling 'IE8 and onchange problems'), I noted several search results 
that indicated onchange should be replaced with onclick.

    So, now I'm totally confused -- but at least I've got console.log to 
work -- with no helpful results. I still get the 'hang' -- but with an 
alert() planted in the onclick function everything's fine in IE.

Thanks all.

-Mel

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


#22732

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-20 16:02 -0700
Message-ID<bk5o7pF84cqU1@mid.individual.net>
In reply to#22731
Hi All:

    Except for some simplifying text and id changes, the code below 
represents the actual code I'm testing.

-Mel



**************************************
// Here is the <Select> element and its options
// Only the actual ids and text have been changed
// the function shoaccoptbutt() simply enables a disabled button
// the function setFocusColor() only sets the color and
// background of the <select> element.
// the var optselindex is a global.
//
// the onclick clause is what is killing my IE8 test.
// (unless I place a standard alert() in the function)
//
// the Alert() calls you see below are my own.  In the
// tests, I never act on them.
.
.
<select id="uselectclub" style="margin-top:8px" name="selectclub" size="4"
  onfocus="setFocusColor(this);shoaccoptbutt(true);"
  onclick="chkoptsel(this);">
  <option id="iopt1" value="41388">Test Option 0</option>
  <option id="iopt2" value="41419">Test Option 1</option>
  <option id="iopt3" value="56080">Test Option 2</option>
</select>
.
.
etc
.
.
function chkoptsel(elobj) {
var el ;
// alert("Commenting this reveals the 'hang' error for IE8") ;
if (!elobj) elobj = this;
el = elobj ;

optselindex = el.selectedIndex ;

if (!lgotdate) {
   Alert("~~~You must Select and Accept a DATE First. !") ;
   el = getobj("idate") ;
   el.focus() ;
   return false ;
   }

if (optselindex === -1 ) {
   Alert("~~~Please Select a Option before Continuing.") ;
   el.focus() ;
   return false;
   }

// when F12 brings up IE Dev Tools, this next shows in the log
// if it is not activated nothing is logged, and
// no crash or artifact is displayed.
console.log("optselindex="+clubselindex) ;

return true ;
}
************************** 

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


#22733

FromChristoph Michael Becker <cmbecker69@arcor.de>
Date2014-01-21 00:28 +0100
Message-ID<52ddb0fc$0$6549$9b4e6d93@newsspool4.arcor-online.net>
In reply to#22732
Mel Smith wrote:

> <select id="uselectclub" style="margin-top:8px" name="selectclub" size="4"
>   onfocus="setFocusColor(this);shoaccoptbutt(true);"
>   onclick="chkoptsel(this);">

If I'm not mistaken, the onclick and onfocus event handlers might
interfere; especially the order of firing the events seems to be
important.  You may check that with debug statements in the attribute's
values, e.g.

  onfocus="console.log('onfocus');setFocusColor(this);
           shoaccoptbutt(true);"
  onclick="console.log('onclick');chkoptsel(this);">

I don't know how the order of firing the events is specified, but it
seems prudent to look that up and cater for eventual exceptions.

See also Thomas' post: <news:34762870.g84lkbnriq@PointedEars.de>.

-- 
Christoph M. Becker

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


#22734

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-21 06:01 +0100
Message-ID<2206413.iZ0BqqUp4u@PointedEars.de>
In reply to#22733
Christoph Michael Becker wrote:

> Mel Smith wrote:
>> <select id="uselectclub" style="margin-top:8px" name="selectclub"
>> size="4"
>>   onfocus="setFocusColor(this);shoaccoptbutt(true);"
>>   onclick="chkoptsel(this);">
> 
> If I'm not mistaken, the onclick and onfocus event handlers might
> interfere; especially the order of firing the events seems to be
> important.  You may check that with debug statements in the attribute's
> values, e.g.
> 
>   onfocus="console.log('onfocus');setFocusColor(this);
                                    ^^^^^^^^^^^^^^^^^^^^
Unnecessary these days.  There is the “:focus” CSS pseudo-class, and it is 
observed by recent layout engines not only for “a” elements:

<http://www.w3.org/TR/2011/REC-CSS2-20110607/selector.html#dynamic-pseudo-classes>
<http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#the-user-action-pseudo-classes-hover-act>

<http://caniuse.com/#feat=css-sel2>

>            shoaccoptbutt(true);"
>   onclick="console.log('onclick');chkoptsel(this);">
> 
> I don't know how the order of firing the events is specified, but it
> seems prudent to look that up and cater for eventual exceptions.

The “focus” event is being dispatched when the control receives the focus.

The “click” event is being dispatched when the pointer is positioned on the 
element, and the user pushes and releases a button of the pointing device 
(the event is not dispatched if the button causes a context menu to be 
displayed, so this is usually limited to the primary and tertiary buttons).

<http://www.w3.org/TR/2013/WD-DOM-Level-3-Events-20131105/#event-type-focus>
<http://www.w3.org/TR/2013/WD-DOM-Level-3-Events-20131105/#event-type-click>

The HTML “select” element appears to be special in that the “click” event is 
not dispatched when the element is focused with the pointing device if the 
“select” element is displayed as a drop-down list.  This is different when 
it is displayed as a list box (size > 1), or when the non-menu button is 
pushed and released on the drop-down list.  (Tested in Chromium 31.)


With Firebug it is not necessary to call console.log() for testing events.  
You can context-click an element in the “HTML” panel and “Log Events”.

<https://getfirebug.com/wiki/index.php/HTML_Panel>

With Chrome Dev Tools you can context-click an element and “Force [an] 
Element State”, e.g. “:focus”; it is also possible to do that in the 
“Styles” tab of the “Elements” panel by selecting the “Toggle Element State” 
button (a pointer cursor on a dotted rectangle).  Previous versions lost the 
state when you navigated to another element; current versions pin the state 
and mark this with a(n orange) dot on the left-hand side of the element.

<http://devtoolsecrets.com/secret/editing-styling-active-hover-focus-visited-states.html>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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


#22735

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2014-01-21 08:47 +0100
Message-ID<XnsA2BC595A3D32Beejj99@194.109.133.133>
In reply to#22734
Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 21 jan 2014 in 
comp.lang.javascript:

>>   onfocus="console.log('onfocus');setFocusColor(this);
>                                     ^^^^^^^^^^^^^^^^^^^^
> Unnecessary these days.  There is the ƒ o:focusƒ   CSS pseudo-class,

Well, not entirely, 
one could imagine setFocusColor() to contain a conditional like:

if (myTimeOfDay == 'night') this.style.backgroundColor = '#555';

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

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


#22737

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-21 13:01 +0100
Message-ID<2109949.mQzNV4ct1s@PointedEars.de>
In reply to#22735
Evertjan. wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>>   onfocus="console.log('onfocus');setFocusColor(this);
>>                                     ^^^^^^^^^^^^^^^^^^^^
>> Unnecessary these days.  There is the � o:focus�   CSS pseudo-class,
> 
> Well, not entirely,
> one could imagine setFocusColor() to contain a conditional like:
> 
> if (myTimeOfDay == 'night') this.style.backgroundColor = '#555';

The corresponding stylesheet rule can be generated dynamically, server-side 
and client-side.

The From and Message-ID header field values of your postings are still in 
violation of network standards – see RFC 5536 – and probably the Acceptable 
Use Policy of your service provider.  The From header field value of your 
postings is also disregarding Netiquette.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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


#22748

FromJohn Harris <niam@jghnorth.org.uk.invalid>
Date2014-01-22 15:18 +0000
Message-ID<h8ovd99t9u6eq92430e350ui37v5961n4o@4ax.com>
In reply to#22737
On Tue, 21 Jan 2014 13:01:59 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Evertjan. wrote:
  <snip>
>The From and Message-ID header field values of your postings are still in 
>violation of network standards – see RFC 5536
  <snip>

Can Thomas *prove* that the Message-ID
  <XnsA2BC595A3D32Beejj99@194.109.133.133>
is not unique? If neither he, nor anyone else, can prove that it isn't
then that msg ID conforms to RFC 5536 and Thomas is talking nonsense.

  John

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


#22736

FromNorman Peelman <npeelman@cfl.rr.com>
Date2014-01-21 06:13 -0500
Message-ID<lblkp0$91k$1@dont-email.me>
In reply to#22731
On 01/20/2014 05:33 PM, Mel Smith wrote:
> Christoph said:
>
>
>> Now I've read your OP again:
>>
>>> btw, the 'suspected place' is a function that is called by 'onclick' >
>> on an option in a <select> element.
>
>      No, the 'onclick' function is in the <select> tag
>
>>
>> I suggest you don't use the onclick/onchange attribute of the option
>> elements, but instead use the onchange attribute of the select element.
>> How to access the selected option is explained in the FAQ section "How
>> do I get the value of a form control?"[1].
>
>      AISB,  I was getting errors (a week ago) using the onchange event. Then,
> (after googling 'IE8 and onchange problems'), I noted several search results
> that indicated onchange should be replaced with onclick.
>
>      So, now I'm totally confused -- but at least I've got console.log to
> work -- with no helpful results. I still get the 'hang' -- but with an
> alert() planted in the onclick function everything's fine in IE.
>
> Thanks all.
>
> -Mel
>
>

   You may want to take a look at 'stopPropagation' (or 'cancelBubble'):

http://msdn.microsoft.com/en-us/library/ie/ff975462(v=vs.85).aspx


-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

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


#22738

From"Mel Smith" <med_cutout_syntel@aol.com>
Date2014-01-21 10:01 -0700
Message-ID<bk7nejFkitaU1@mid.individual.net>
In reply to#22736
Hi:

    Norman: I tried the cancel bubble, etc with no effect

To All:

    I've tried so many things now, that I'm totally frustrasted and 
discouraged. My final change/test is below. Note the alert() message in the 
onclick event.

Result:  with the alert() placed in the onclick event, IE8 works perfectly. 
When it is removed, it takes *two* clicks to enter the onclick event handler 
for all options greater than the first option.  For the *first* option, if 
you click it first, it reacts correctly !

    (and of course, Chrome works perfectly in all cases.)

I'm going to leave this alone for awhile and go to a monastery and try to 
get rid of my new found hate for JS/ES :((

Thank you all for trying to help me.

-Mel

.
**************************
<select id="uselectclub" style="margin-top:8px" name="selectclub" size="4"
  onfocus="setFocusColor(this);shoaccoptbutt(true);"

  onclick="chkoptsel(this);alert('Got here on click.');"> // note change

  <option id="iopt1" value="41388">Test Option 0</option>
  <option id="iopt2" value="41419">Test Option 1</option>
  <option id="iopt3" value="56080">Test Option 2</option>
</select>

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


#22729

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-20 21:37 +0100
Message-ID<7950898.l2JLt48iak@PointedEars.de>
In reply to#22725
Christoph Michael Becker wrote:

> Mel Smith wrote:
>> I found (on stackoverflow) the following script to activate console.log
>> on my IE8 dev machine (a win xp (sp3) system).
> 
> AFAIK, the problem with console.log() on IE 8 is that it throws an
> error, if the console window is not open; otherwise console.log() should
> work fine.  It seems to me that the script just caters for this issue.

It has been too long with IE 8 for me to remember, and I cannot test right 
now.  However, another problem could be that they have been calling 
“window.console.log(…)” when it should have been “console.log(…)” – assuming 
an identity or a scope chain where it does not exist.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]


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


csiph-web