Low Search results in xhr response causing bizarre display bug in Internet Explorer
When low search results are included in an xhr response, IE 9 is displaying some bizarre combination of characters and other bits of code from assets in memory.
The results display fine in any other browser, IE does not show any JS errors, and even the response content (viewed with IE's built-in developer tools) show content that appears to be what was expected. Low search is used in another template that is not accessed through xmlhttprequest, and those results render fine in IE.
I know this sounds likely to be a bug in some other code -- css, js.. anything that isn't Low Search -- but I've spent days trying to debug this, and everything points to the Low Search results.
If you'd like, I can more thoroughly explain the myriad of failed attempts I've made to get around the problem. I can only guess that it has something to do with the character encoding of the search results or some session data being sent to the browser as directed by the add-on.
I've got a stripped-down test page that can better demonstrate the issue, if you have access to a computer with IE9. I don't want to post the link publicly, but I'll email it to you with your permission.
(Also, I mention IE9 specifically, but that doesn't necessarily mean older versions don't exhibit the same behavior. I just don't have easy access to older versions at the moment.)
Replies
Low 11 Oct 2011 07:45
Hi, you can email the link to hi at gotolow dot com. Thanks.
splitmetal 11 Oct 2011 20:48
Email sent earlier today. Thanks for looking into this.
splitmetal 20 Oct 2011 15:53
I found a temporary workaround, but I'm still hoping for an official fix. The problem is due to an odd character that's output at the beginning of every result loop. This character is added by the add-on itself, and is not in the template code. It seems that all browsers, IE included, are willing to ignore this character during normal rendering. However, IE gets a bit more sensitive when it tries to render that same character from a XHR response.
I'm not sure, but I believe it's a control character of some sort. It might be responsible for eating the first character that is written directly after the opening result tag, as well. No idea if this will post here or if it will be the same character that's sent to the browser, but it appears like this: �
You can verify this with Firefox and Firebug. Open up Firebug and select the Network panel. If needed, turn it on. Then load the test page I sent you, or (I believe) any other page that uses the results tag -- I'm guessing this will be true of any site that uses low search. The regular source of the page appears fine, but if you click on the page's request in the network panel, then click the response tab to see the actual html sent to the browser, you should see the character at the beginning of every result loop.
I hacked around it by adding some php to my template:
echo preg_replace('/[\x00-\x1F\x7F]/', '', '{exp:low_search:results}...{/exp:low_search:results}');