Display a message each time functions are called

  • Thread starter sabine.michael.ratcliffe
  • Start date
S

sabine.michael.ratcliffe

Is there any way to display an alert every time any function including
onclick events is called from a web page?

I would need a way that can be ran from the onload handler ... to make
it clear:

function f1() {
dosomething();
}

function f2() {
dosomething2();
}

Would need to be dynamically changed onload to:
function f1() {
alert("f1 called");
dosomething();
}

function f2() {
alert("f2 called");
dosomething2();
}
 
S

sabine.michael.ratcliffe

Maybe it helps if I explain more:
I need a call stack from within an onerror handler. If you search
Google you will read that it is not possible because a stack trace
from within the onerror handler is outside of my codes execution
context because it is actually triggered by the User Agent. Because
this is used for logging errors on my clients PCs using Firebug is not
a possibility.

I have a workaround that I can use that would get around this issue.

On each call to any function I would like to write the stack trace to
a text file (this can be done using HTML5 sessionStorage) and then
read the contents of this file from within the onerror handler.
Obviously adding some kind of onCall handler to all functions at body
onload would allow me to do this easily ... with this method I could
even log every function call with passed params. I know that there
would be quite a performance hit but the option would be configurable.
 
T

Thomas 'PointedEars' Lahn

Maybe it helps if I explain more:
I need a call stack from within an onerror handler. If you search
Google you will read that it is not possible because a stack trace
from within the onerror handler is outside of my codes execution
context because it is actually triggered by the User Agent.

Yes, I told you.
this is used for logging errors
on my clients PCs using Firebug is not
a possibility.

Firebug Lite might be a possibility.
I have a workaround that I can use that would get around this issue.

On each call to any function I would like to write the stack trace to
a text file (this can be done using HTML5 sessionStorage) and then
read the contents of this file from within the onerror handler.

That's hardly a workaround as sessionStorage would be limited; HTML 5 is
only an inofficial Working Draft at this point, BTW). As I told you, you
only get the stack trace (in some implementations) when you create an
Error object or have one created (by making a non-fatal mistake). And
this stack trace is only not empty when your code directly called the
method in which this object is created, so NOT in an event listener
(because the UA calls it).
Obviously adding some kind of onCall handler to all functions at body
onload would allow me to do this easily ...

Obviously NOT. You don't seem to want a stack trace but an event
sniffer. Firebug provides one, I don't know if Firebug Lite does.

But I'm beginning to think that you have been asking the wrong questions
so far. Why do you think you need to do all this in the first place?


PointedEars
 
S

sabine.michael.ratcliffe

Why do you think you need to do all this in the first place?

I am a web developer of a very complex web app (over 975000 - 1000000
lines of code). This app is basically an e-Learning and content
management system. Part of the admin interface is used to create Tests
and Surveys that can be performed over the internet.

The problem that we have is that some of our customers have had
strange problems. Here are some examples:
1) On a Spanish PC the layout of a web page was a slightly different
size than on English PCs.
2) Some buttons used to navigate through an online test were not
enabled in a very specific situation on a French PC.
3) Occasionally in our Admin interface when creating questions users
would complain that items would randomly be selected from dropdowns
twice.

It is very, very common for us not to be able to reproduce these
issues so it would be fantastic to be able to catch those issues in
the wild as they happen.

Some issues that we have had are JS problems caused by HTTPS, browser
implementations, number / date formats in regional settings, well
known anti virus apps, etc., etc. There can be hundreds of ways to
arrive at the particular code that could be causing the error and
circumstances would often need to be very, very specific. If it was as
easy as visiting a corporation in Spain or the USA we would do that
but the problem is that these issues often arise on PCs owned by
members of the public ... it is obviously not feasible to have the
public look at the errors reported in Firebug Lite.

Because of these problems I decided to add Javascript logging. It
works very well for reporting:
o Error message
o Line number
o User agent
o Code section (the section of the code that contains the error).
o Referrer
o URL
o Client IP

The things that would really help us would be to include the call
stack, particularly the values that have been passed. Of course I
understand the problem with the execution context and onerror and of
course HTML5 methods are limited. sessionStorage is pretty well
implemented in the latest versions of most browsers and I would skip
it on browsers that do not support it. This is only for us to use as a
last resort in extremely awkward situations to trap very hard to find
bugs.

I have a great method of getting a stack trace including passed
parameters and values that takes you all the way back to the event
that was triggered. All I would need to do to get the stack tracing to
work properly is to store the stack trace each time a function is
called (excluding the onerror handler) and retrieve it from within the
onerror handler.

Guten Rutsch ;o)
 
J

Jeremy J Starcher

Is there any way to display an alert every time any function including
onclick events is called from a web page?

I would need a way that can be ran from the onload handler ... to make
it clear:

function f1() {
dosomething();
}

function f2() {
dosomething2();
}

Would need to be dynamically changed onload to: function f1() {
alert("f1 called");
dosomething();
}

function f2() {
alert("f2 called");
dosomething2();
}

I had a need for something very similar to this a while back. In my
case, I was working on some code that ran in an extension under IE7.
Because the code ran outside of IE's world, I could not find a debugging
tool that would give me anything useful.

My "solution" was ... crude. First I did a search and replace to find
all instances of "function * {" with "function * {myAlert(5, 'CHECKPOINT
XXXXX');"

Then I whipped up a script to replace the XXXXX with an auto-increment.
(I tried extracting the function name and putting it in the alert
statement, but it fell apart on anonymous functions.

The function myAlert took a 'logging level' and a string. I manually
raised the logging level of all my inner utility functions to cut down on
the chaff I had to weed through.

I didn't have a true stack trace since so much of my code used multiple
exit points, it wasn't so easy to flag exiting a function.
 
T

Thomas 'PointedEars' Lahn

Please always provide attribution of quoted material.
I am a web developer of a very complex web app (over 975000 - 1000000
lines of code). This app is basically an e-Learning and content
management system. Part of the admin interface is used to create Tests
and Surveys that can be performed over the internet.

The problem that we have is that some of our customers have had strange
problems. Here are some examples: 1) On a Spanish PC the layout of a web
page was a slightly different size than on English PCs.

This is not a problem that occurs because of or can reasonably be solved
with client-side scripting. Fonts are per-user setting.
2) Some buttons used to navigate through an online test were not enabled
in a very specific situation on a French PC.

That does not sound like a problem with client-side scripting either.
However, as you have an international audience of more or less experienced
Web developers here, it would be a better idea to ask them to test parts of
your application than your trying to hunt the bugs in it that may not even
exist.
3) Occasionally in our Admin interface when creating questions users
would complain that items would randomly be selected from dropdowns
twice.

Not a client-side script problem either, unless there was a bug in the user
agent that could be worked around, or, what is more likely, in a mouse or
keyboard event listener of the control as caused by the developer. If not
the former, it would be best to post that part of the code here.

Obtaining a stack trace on any client will not help to resolve the issue,
and certainly `onerror' would not help (it is certainly a bug, but not a
runtime error, so `onerror' will not be triggered).
It is very, very common for us not to be able to reproduce these issues
so it would be fantastic to be able to catch those issues in the wild as
they happen.

Why not think of this newsgroup as your experienced external QA team? If
you ask politely, and don't overestimate everybody's free time, I don't
think the question will be in vain. The record shows.
Because of these problems I decided to add Javascript logging. It works
very well for reporting:

It also makes the application considerably slower, if it works at all.
o Error message
o Line number
[o URL
o Code section (the section of the code that contains the error).]

None of the above applies for MSHTML-based user agents like IE, which,
according to the most reliable statistics I know (from Net Applications),
accounted for a market share of about 70% in November 2008. The error
messages it gives are pointless to wrong (`error code: 0' aso.), there is a
bug in the implementation that causes script errors to be reported in the
wrong files, and the reported line numbers can be slightly off as well.
o User agent

Definitely not said:
o Referrer

Inherently unreliable.
[...]
o Client IP

From within the sandbox? I have to see that before I can believe it.
The things that would really help us would be to include the call stack,
particularly the values that have been passed.

I would not help with the problems you mentioned, though.
Of course I understand the problem with the execution context and onerror
and of course HTML5 methods are limited.

"HTML 5", by WHATWG, has not even two interoperable implementations, else
maybe it would be on its way to a W3C Recommendation by now. (There are
also other issues to resolve, of course.)
sessionStorage is pretty well implemented in the latest versions of most
browsers and I would skip it on browsers that do not support it. This is
only for us to use as a last resort in extremely awkward situations to
trap very hard to find bugs.

You will have to deal with the inherent size limit nevertheless. I'm
talking error logs seemingly truncated in the middle, for example.
Some issues that we have had are JS problems caused by HTTPS, browser
implementations, number / date formats in regional settings, well
known anti virus apps, etc., etc. There can be hundreds of ways to
arrive at the particular code that could be causing the error and
circumstances would often need to be very, very specific.

The task at hand appears to be refactoring and unit testing of this 1M LOC
app, and employing all the other good things that software engineering
brings rather than just hacking some code together. (It's all the
predecessor's fault, right? BTDT.)
If it was as easy as visiting a corporation in Spain or the USA we would
do that but the problem is that these issues often arise on PCs owned by
members of the public ... it is obviously not feasible to have the public
look at the errors reported in Firebug Lite.

See above. If you really want it, it is feasible. Without posting company
secrets.
[...]
All I would need to do to get the stack tracing to work properly is
to store the stack trace each time a function is called (excluding the
onerror handler) and retrieve it from within the onerror handler.

You can NOT do that without changing the source code of all the functions
that are called.
Guten Rutsch ;o)

Thank you, I did, although it was somewhat weird this time ;-)
Dir auch ein gesundes neues Jahr! (Happy new year!)

BTW, there is also de.comp.lang.javascript, the German-speaking pendant of
this newsgroup.


PointedEars
 
L

Logos

Maybe it helps if I explain more:
I need a call stack from within an onerror handler. If you search
Google you will read that it is not possible because a stack trace
from within the onerror handler is outside of my codes execution
context because it is actually triggered by the User Agent. Because
this is used for logging errors on my clients PCs using Firebug is not
a possibility.

I have a workaround that I can use that would get around this issue.

On each call to any function I would like to write the stack trace to
a text file (this can be done using HTML5 sessionStorage) and then
read the contents of this file from within the onerror handler.
Obviously adding some kind of onCall handler to all functions at body
onload would allow me to do this easily ... with this method I could
even log every function call with passed params. I know that there
would be quite a performance hit but the option would be configurable.

The brute force method that I first thought of would be to use the DOM
and iterate over every function in the document and wrap it in a new
function that first calls your logging function, then calls the
original function. You'd need to keep a map of the wrapper functions
to original functions, and then iterate again over every element on
the page and add your logger to all on<Event> that apply to that
element and changing any original function calls to your wrapper
function.

Tyler Style
http://malthusian-solutions.com
http://nirdvana.com
 
J

Jeremy J Starcher

On Sat, 03 Jan 2009 05:46:32 -0800, Logos wrote:

[ Need for a DIY stack-trace snipped ]
The brute force method that I first thought of would be to use the DOM
and iterate over every function in the document and wrap it in a new
function that first calls your logging function, then calls the original
function. You'd need to keep a map of the wrapper functions to original
functions, and then iterate again over every element on the page and add
your logger to all on<Event> that apply to that element and changing any
original function calls to your wrapper function.

I tried that method once. I could get it to work for top-level
functions. (By top-level, those that are properties of the 'window'
object.) The parsing required hande inner functions or class methods got
overwhelming, very quickly.

Before going that route again, I'd look for a Javascript engine written
in Javascript. (I haven't seen one, but I've heard rumors of such a
beast.)
 
T

Thomas 'PointedEars' Lahn

Logos said:
Maybe it helps if I explain more:
I need a call stack from within an onerror handler. If you search
Google you will read that it is not possible because a stack trace
from within the onerror handler is outside of my codes execution
context because it is actually triggered by the User Agent. Because
this is used for logging errors on my clients PCs using Firebug is not
a possibility.

I have a workaround that I can use that would get around this issue.
Hardly.

The brute force method that I first thought of would be to use the DOM
and iterate over every function in the document [...]

Because user-defined methods do not show up in for..in iteration of the
window/Global object in MSHTML-based user agents (which have a ca. 70%
market share as of November 2008), you can NOT simply iterate over every
user-defined global functions in the document there. The alternatives are:

A) Parsing the source code for the `function' keyword
B) Declaring/defining all methods using a wrapper

Both approaches must then populate an Array of strings that are function
identifiers or an Object which property names are function identifiers.
Neither approach always works for anonymous function expressions (because
there may be no identifier for later reference), or works for locally
declared or locally created functions (because per Specification they are
declared when the wrapped execution context is entered, or the
AssignmentStatement is evaluated, not before).


PointedEars
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>, Sat,
3 Jan 2009 00:51:11 said:
Please always provide attribution of quoted material.

Please always provide thoughtful attribution of quoted material. Since
you cannot control your peculiar urge to revive threads that became
inactive over a month ago, it behoves you to include the relevant date
in ALL of your attributions. Little intelligence should be needed to
see that. Granted, more intelligence and knowledge is needed to
understand the complete benefit of giving a full attribution.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top