#9 — Encoding error when rsvpable interface is active on IE and webkit browsers

by Jesse Snyder last modified May 20, 2009 04:54 AM
State Rejected
Version: 1.0
Area Functionality
Issue type Bug
Severity Medium
Submitted by Jesse Snyder
Submitted on May 19, 2009
Responsible
Target release:
In IE6, IE7, and WebKit-based browsers, activating the rsvpable interface triggers an encoding error when rendering the page:

Traceback (innermost last):
  Module ZPublisher.Publish, line 122, in publish
  Module ZServer.HTTPResponse, line 262, in setBody
  Module ZPublisher.HTTPResponse, line 324, in setBody
  Module ZPublisher.HTTPResponse, line 476, in _encode_unicode
UnicodeEncodeError: 'latin-1' codec can't encode character u'\u201c' in position 31294: ordinal not in range(256)

It's possible that this only occurs if the activated object is the default view object for its container, but this is unconfirmed.

A possible fix/workaround is to set the encoding in the render() method of the rsvp form viewlet class:

self.request.response.setHeader('content-type',"text/html; charset=utf-8")
Steps to reproduce:
- Activate rsvpable interface on object
- View in one of the aforementioned browsers
Added by David Glick on May 19, 2009 11:26 PM
Could not reproduce in Safari 3.2.1 / Plone 3.3 / collective.salesforce.rsvp 1.0

What versions of the above are you using?
Does it break no matter where you do it or only for one particular item or content type?
Added by Jesse Snyder on May 19, 2009 11:51 PM
I experienced the problem with IE6 and Safari 3.2.3 in combination with Plone.3.1.7 and c.s.rsvp 1.0.

We have also had reports of the problem in IE7.

After investigating further, the problem only seems to arise in a custom view; applying /base_view or /document_view fails to trigger the error.

I'll try to isolate what aspect of the view is causing the bad interactions. Consider this issue report revoked, at least for now. ;-)
Added by David Glick on May 20, 2009 04:54 AM
Issue state: UnconfirmedRejected
Actually I was mistaken, I was able to reproduce this issue in Safari.

It turns out it's a general Zope/formlib bug affecting any browser that doesn't include an HTTP_ACCEPT_CHARSET header in the request; for more information see:

https://bugs.launchpad.net/zope2/+bug/160968
https://bugs.launchpad.net/zope2/+bug/143873

The latter suggests that the bug is fixed in Zope 2.10.8; I tried that out and it seemed to fix the issue for me.

No responses can be added.