OK, that sounds pretty unfortunate.... The easy solution would be to assume some practical limits. If that is really a no-go, then another option would be to make WebKeyboardEvent be a variable length object, with the strings appended to the end, such that there is still just one contiguous blob of memory to serialize. If done right, that could localize the issue to render_widget_host_view_mac.mm. It would be pretty ugly though.
Other choices involve inventing IPC messages for each type of WebInputEvent so that we can use the typical ParamTraits-based approach to serializing structures. That is a more disruptive change, and only adds cost to Windows and Linux. -Darin On Thu, Feb 19, 2009 at 11:37 AM, Avi Drissman <[email protected]> wrote: > On Thu, Feb 19, 2009 at 2:35 PM, Darin Fisher <[email protected]> wrote: > >> std::vector<unsigned short> text; >> std::vector<unsigned short> unmodified_text; >> std::vector<unsigned short> key_identifier; >> > > Their equivalents, yes. > > >> Is it really the case that those are unbounded in length? Or, is there >> some small max length that they can be? >> > > There's no theoretical limit on the Mac. I don't know what the practical > limit is. > > >> Why isn't this a problem for Windows and Linux since they also have to >> populate the PlatformKeyboardEvent's m_text, m_unmodifiedText, >> and m_keyIdentifier fields. >> > > AFAICT, they guarantee one character per input event. The Mac doesn't. I > can see doing a cap, though it doesn't thrill me. > > Avi > >> --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
