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
-~----------~----~----~----~------~----~------~--~---
