We attempt to render ridiculously large chunks of user input
Bug #73420 reported by
Stuart Bishop
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
We occasionally issues like OOPS-329C111 , where a user has dumped a huge
chunk of text into a text area, which we accepted, but are unable to render.
We should modify the text-to-html method to truncate its input to some large
but still sane upper limit as a safety net for those cases where we have
neglected to place an upper bound on the size of user input.
We should make it easy to set an upper limit on all our Text and String
schema fields (if it isn't already there), and set a large but still
renderable default (either by modifying all the interfaces, by monkey
patching, or adding a default setting upstream).
Revision history for this message
| James Henstridge (jamesh) wrote | #1 |
| Changed in launchpad: | |
| importance: | Undecided → High |
| description: | updated |
| Changed in launchpad-foundations: | |
| status: | New → Triaged |
Revision history for this message
| Robert Collins (lifeless) wrote | #2 |
| Changed in launchpad: | |
| importance: | High → Low |
To post a comment you must log in.
The performance problem in the word breaking algorithm has been fixed which gets rid of the mentioned OOPS.
However, this is still an issue: how ever fast we make the text formatting code there will be a point where we can't render the text in a reasonable time, so we should detect this case and handle it.