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.
Definitely not said:
Inherently unreliable.
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.
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