3 Nov
2006
3 Nov
'06
3:33 p.m.
Yes, of course; any disciple of Knuth (or of his non-digital forebears,
such as my dad, who taught it to me) will agree heartily on the
divide-and-conquer strategy known as the binary search: start in the
middle.
I should have mentioned that I was indeed furiously scanning all script
and CSS to see if I could intuit anything - starting, of course, from
the browser's source display. The reason I didn't start by disabling
scripting in my browser(apart from not having thought of it) was that it
wouldn't have helped me, since I hadn't personally experienced a crash,
and rather than trying to see what would reduce the number of crashes -
which for me was zero so far - I was trying to see how I could aggravate
the condition so as to produce one that I could study.
But my knowledge of both Javascript and CSS is fairly thin, particularly
when it comes to issues of purity. That and knowing that good content
doesn't guarantee success with IE anyway didn't bode well for the
approach except as a last-ditch effort if I couldn't get anyone
experienced to help me.
The location information in the error message I got wasn't helpful - it
obviously wasn't on line 1 of the document - that was the XML prolog -
so I assumed that it was line 1 of a <script> tag. That, however, also
got me nowhere, so I started looking in all of the <link>ed scripts,
also without success.
By the way, I did find where that XML prolog came from - or rather, a
coworker did who wasn't as all afluster as I and didn't forget to look
in the templates - it's in httpheader.vm. As a very first step based on
my associate (David)'s message, we've commented that line, and are now
watching and waiting.
Anyone know a reason we shouldn't do this? It does appear to be
unequivocally wrong, since the doc isn't valid XML by any stretch, and
in fact, according to David, isn't XHTML either, though I can't vouch
for that, except that the validate links provided by the standard
templates produce a haughty message saying something like: dude, go and
fix your XML first, then talk to me about style.
The thing that is correct about that prolog - the character encoding -
is handled by the Content-Type: header, and even if not, the
http-equiv="Content-Type" META tag is there also, with a value of
"text/html; charset=ISO-8859-1", which is correct for this document. I
don't actually know whether this is what IE uses to set the encoding, or
whether HTTP has already set it correctly through XWiki's configuration
of the session, but IE's View->Encoding menu item declares it to be
"Western European(ISO)", which I believe is correct, no?
Also, the DOCTYPE header is troubling:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
which from David's message appears not to be correct.
XWiki developers: any comment? Time for JIRA? Do I get to report a
bug? Anyone working on getting valid XHTML/CSS out of XWiki? I noted
with some concern a while back that xwiki.com didn't display the
validate links that came with the default templates back when it was
still 0.9.840.
And thanks loads, Brandon, for your help, especially in such an
expeditious manner.
My word for the day:
Execration
An expression of profound loathing, contempt, or hatred,
or the object of such a sentiment.
Guess why I chose that one. Could it have been my experience with an
execrable product, i.e.: IE?
brain[sic]
-----Original Message-----
From: Esbach, Brandon [mailto:Esbachb@tycoelectronics.com]
Sent: Friday, November 03, 2006 3:16 AM
To: xwiki-users(a)objectweb.org
Subject: RE: [xwiki-users] FW: Don't click on the blue 'e'...
Didn't notice this one there... Might help to read all mail
when out for a day ;D
He does have a good point though, in that you should look
through any attached code to see if any unexpected or odd
bits are there.. The hard part, is knowing what will cause a
problem and what won't. What I usually do in this case
(warning: this is not the easiest way for most, just easier
for me); is to start by blanket disable of all script in the
page, to trace the error down to the closest spot. You can
disable chunks of jscript by using the /* comment inside here
*/ method.
It would be useful if you can put down all the modifications
you've made to the Xwiki (even if just for yourself), as this
gives you an indication of your own changes as well as a
starting point for debugging.
Do you have the script debugger installed by any chance?
Sometimes this can help give an indication of where the error
to start looking. It can be disabled if it becomes a
nuisance (point of interest: a fair chunk of Microsoft's web
pages will kick this debugger into overdrive).
http://www.microsoft.com/downloads/details.aspx?familyid=2f465
be0-94fd-4
569-b3c4-dffdf19ccd99&displaylang=en
-----Original Message-----
From: THOMAS, BRIAN M (SBCSI) [mailto:bt0008@att.com]
Sent: 02 November 2006 23:29
To: xwiki-users(a)objectweb.org
Subject: [xwiki-users] FW: Don't click on the blue 'e'...
Well, here's an interesting bit of news in response to my plea for help
locally from a coworker who is a web developer.
Any clues on where to go to remove this offending bit of code as a test,
or reasons it should be there? Brandon: does this ring any bells?
brain[sic]
-----Original Message-----
...
I know of no clever IE debugging techniques.
In my experience, however, IE's crashes normally occur when loading
embedded objects like applets, Flash, SVG, fonts, etc, or when people do
some unorthodox trickery in CSS or scripting. So when troubleshooting
problems like this, my instinct is to dig through the source to see if
there's anything odd going on.
(Having validating markup and CSS helps this process.)
My first observation is that the page is written in XHTML, and IE
doesn't support XHTML[1]. This isn't normally a problem, necessarily,
if the page is delivered as text/html (as these pages are), because IE
will look at it and treat it as HTML "tag soup", and ignore the non-HTML
XHTML stuff as bad markup to work around.
However, the site is also emitting an <?xml ... ?> prolog at the start
of the page. This has traditionally caused problems with IE in my
experience, because IE isn't sure if it should look at it as a raw XML
document or HTML. This issue is compounded by the fact that the page
isn't well-formed XML at all. (There are HTML-style <BR> tags in there,
for example.)