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.)
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=2f465be0-94fd-4 569-b3c4-dffdf19ccd99&displaylang=en -----Original Message----- From: THOMAS, BRIAN M (SBCSI) [mailto:[email protected]] Sent: 02 November 2006 23:29 To: [email protected] 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.)
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:[email protected]] Sent: Friday, November 03, 2006 3:16 AM To: [email protected] 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:[email protected]] Sent: 02 November 2006 23:29 To: [email protected] 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.)
participants (2)
-
Esbach, Brandon -
THOMAS, BRIAN M (SBCSI)