On Sun, 2009-07-26 at 00:58 -0400, Craig Andrews wrote: > I ran across an interesting bug where WebKit throws an exception when > invalid XHTML (but, notably valid HTML) is written to the DOM using > javascript. The problem is that oohembed.com returns valid HTML, but > invalid XHTML, for youtube urls. When laconica creates the jOverlay, > invalid markup is written to the DOM, so the browser throws an error. This > effects all webkit browsers, including Safari, Midori, Chrome, etc
Issue occurs when an XHR response is sent as text/html and it is being inserted into a page that is sent as */*xml. Occurs in browsers that use the Webkit engine, and even Gecko (Firefox 2 prefers application/xhtml +xml). > http://laconi.ca/trac/ticket/1734 is the bug - I have a more detailed > explanation there. > > If we return the content-type as "text/html" instead of "application/xml" > or "application/xhtml+xml" webkit works fine, as laconica is now writing > valid markup to the DOM. We could use the HTML_Safe PEAR library or Tidy to clean up what we get and set the response mimetype to text/xml. Zach actually tested this, but, I can't recall what was the final status. This will also require us to update the attachment JavaScript to use xbImportnode.js (helps injecting text/xml into text/html pages for IE). > I suggest laconica stop serving xhtml mime types, and only serve > "text/html" for web pages. About a month ago, I've tested this in my dev: 1) When we had output that was not well-formed XML, application/*xml was causing trouble in some browsers (Webkit) that preferred it over text/html. 2) I wanted to remove jquery.form.js and xbImportNode.js plugins and use straight-up jQuery. So, here is what I have on my dev: * Pages are sent as text/html * XHR Responses for forms like subscribe, unsubscribe, join, leave, favor, disfavor are sent as text/html * Refactored above forms * Removed xbImportnode.js * Restructured the script to be more JSON-like Some notes: * Tested and works in Safari, Chrome, Epiphany (WebKit), Firefox, IE, Opera. * I was very close to leaving out the jquery.form.js plugin. It wasn't necessary until I discovered that it helped a ton for sending multipart/form-data (for file attachments) forms. AFAIK, Safari 4, Chrome (WebKit) and Firefox 2 are the only desktop-browsers, that we support prefer application/*xml over text/html. Firefox 3 and Opera 9/10 prefer text/html even though they can handle application/*xml. And IE6,7,8 prefers text/html and can't handle application/*xml. So, options for going with text/html: a) hardcode and always send text/html (super easy and no need to check the accept headers for preferred content-type) b) In lib/util.php I mentioned this and I think we should do this: Setting bestq=1 here (instead of 0) is a temporary solution. Ideally, we should send text/html to UAs that can handle it (including */*) regardless of the q-value. If a UA strictly avoids text/html, we should send them whatever they prefer. If we want to play it safe, option b will leave room for UAs that specifically ask for something other than text/html. Our current setup (negotiating the preferred content-type) is ideal, it respects the XHTML spec, and gets us majority of the way. I don't think a perfect technical solution exists here. IMO, we have to compromise whichever approach we take. -Sarven _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
