On Wed, Mar 11, 2009 at 10:45 AM, Thomas Van Lenten
<thoma...@chromium.org>wrote:
>
>
> On Wed, Mar 11, 2009 at 10:40 AM, Amanda Walker <awal...@google.com>wrote:
>
>>
>> For the URL field, I think that (1) is the best solution until we
>> replace it with a "real" omnibox, at which point things could get
>> complicated (since it'll need attributes for color etc. at the very
>> least).
>
>
> What happens when we want to paste into an html edit area?
>
> Do we need to core browser binary to not include *any* of the webkit
> symbols so the system one could load to support NSAttributedString?
>
[hit send to fast]
Input managers can be written by third parties, and who know what they will
use w/in our browser process.
The host we use for plugins is likely to have similar problems, we can't
keep plugins from using NSAttributed string.
TVL
>
> TVL
>
>
>>
>> --Amanda
>>
>>
>> On Wed, Mar 11, 2009 at 10:29 AM, Avi Drissman <a...@google.com> wrote:
>> > Now that the Clipboard change is in, I was about to land a quick, small
>> > patch to turn on copy/paste, when I ran into an interesting problem. If
>> you
>> > copy something from the webpage you're viewing, and try to paste it into
>> the
>> > URL box, we die. In digging, I found out what's going on.
>> >
>> > When we copy, WebKit puts an HTML flavor onto the clipboard. That's what
>> we
>> > want.
>> >
>> > When we paste into our URL box (which allows rich text), Cocoa sees the
>> HTML
>> > flavor and decides that it wants to turn it into an attributed string.
>> Cocoa
>> > has a really bad HTML reader called NSHTMLReader. But that was
>> retrofitted a
>> > few system releases ago to call WebKit. System WebKit then starts
>> fighting
>> > with our WebCore, and things asplode.
>> >
>> > #11 0x95e9904a in -[NSHTMLReader _loadUsingWebKit] ()
>> > #12 0x95e98c95 in -[NSHTMLReader attributedString] ()
>> > #13 0x95e97930 in _NSReadAttributedStringFromURLOrData ()
>> >
>> > There are several options here.
>> >
>> > 1. Turn off rich text support in the URL field. That's the easiest fix,
>> and
>> > if we want to enforce a rule throughout Chromium that we aren't allowed
>> any
>> > rich text fields editable by the user, that might be enough.
>> >
>> > 2. Patch out the Cocoa impl in the right place (the definition of which
>> is
>> > TBD). This would gain us the freedom of not having to worry about this
>> > problem, but cost us worry about that patch.
>> >
>> > 3. Not put HTML on the clipboard. I don't see that as viable.
>> >
>> > 4. Figure out why system WebKit doesn't get along with our WebCore. I'm
>> not
>> > sure where to start.
>> >
>> > 1 is obviously the most expedient, but is it the right solution? I think
>> it
>> > is, for now.
>> >
>> > Avi
>> >
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
