Not to gloat or anything, but Obj-C dynamic dispatch was responsible.
The solution is to "hide" the few remaining exposed bits of Obj-C from
our libwebcore by giving them names that won't conflict with those
used by the system-provided WebCore.framework. I'll send something
around later.
--~--~-
Yes, and that's what we've done in the short term, however, this won't
be the last time Cocoa or some 3rd party tries to do the same thing.
On Wed, Mar 11, 2009 at 2:16 PM, ghosttie wrote:
>
>> When we paste into our URL box (which allows rich text), Cocoa sees the HTML
>> flavor and decides tha
> 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.
Couldn't you just tell the URL box to only accept the plain text
clipboard format?
John
--~--~-~--~~~---~--~~
Ch
Avi Drissman wrote:
> Sure. I'm also curious about why we're dying in WTF::HashTable::contains.
> Are there some statics that are conflicting?
Not likely, those should all be bound at link time unless someone's
specifically doing a runtime lookup (à la dlsym()).
Mark
--~--~-~--~~---
On Wed, Mar 11, 2009 at 11:14 AM, Mark Mentovai wrote:
> Avi Drissman wrote:
> > #10 0x94759306 in -[WebView initWithFrame:] ()
>
> That's not one of our addresses. OK...
>
Well, that's an objc class |WebView| and definitely not ours (our WebView is
C++, recall).
> You can validate this theor
Avi Drissman wrote:
> #10 0x94759306 in -[WebView initWithFrame:] ()
That's not one of our addresses. OK...
To be sure, I looked for Obj-C in our libwebcore and didn't find very much.
07d4 t +[WebCoreControlTintObserver controlTintDidChange]
A .objc_class_name_WebCoreControlTintOb
On Wed, Mar 11, 2009 at 10:55 AM, Mark Mentovai wrote:
> Avi, do you think you can figure out if -[NSHTMLReader
> _loadUsingWebKit] is at or near objc_msgSend, and who it's trying to
> send to?
>
I sent a clip; here's the whole thing:
#0 0x901e8162 in WTF::HashTable,
WTF::IntHash, WTF::HashTrai
Amanda Walker wrote:
> Do we know it's obj-c collision? Or is it C++ types that are
> typedefed differently for us, but conveniently named-mangled the same
> so they link?
Binding C++ shouldn't be nearly as painful on the Mac: stuff is bound
into a two-level namespace at link time. The smart mo
Avi Drissman wrote:
> 4. Figure out why system WebKit doesn't get along with our WebCore. I'm not
> sure where to start.
Obj-C dynamic dispatch, I bet.
Option 5: don't bring *any* of our own WebKit into the browser
process. In theory, we shouldn't need WebKit in our browser process
anyway - for
On Wed, Mar 11, 2009 at 10:55 AM, Mark Mentovai wrote:
> Binding C++ shouldn't be nearly as painful on the Mac: stuff is bound
> into a two-level namespace at link time.
Ah, excellent point.
> The smart money's on Obj-C
> which binds at runtime every time, but in today's economy, you can't
> b
We're taking guesses at the moment. I look at the backtrace and see that
WebKit dies deep inside, but it's not obvious how we're killing it.
Avi
On Wed, Mar 11, 2009 at 10:50 AM, Amanda Walker wrote:
> Do we know it's obj-c collision? Or is it C++ types that are
> typedefed differently for us,
Let's be precise here. The problem is when an NSAttributedString is
initialized with HTML. It's not a general NSAttributedString problem.
Avi
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options,
Do we know it's obj-c collision? Or is it C++ types that are
typedefed differently for us, but conveniently named-mangled the same
so they link?
--Amanda
On Wed, Mar 11, 2009 at 10:49 AM, Mark Mentovai wrote:
> Avi Drissman wrote:
>> 4. Figure out why system WebKit doesn't get along with our
On Wed, Mar 11, 2009 at 10:45 AM, Thomas Van Lenten
wrote:
> What happens when we want to paste into an html edit area?
Well, at least last time I looked at editable areas, they weren't
handled via NSStrings, so I don't think we'd run into this problem
there.
> Do we need to core browser binary
On Wed, Mar 11, 2009 at 10:45 AM, Thomas Van Lenten
wrote:
>
>
> On Wed, Mar 11, 2009 at 10:40 AM, Amanda Walker 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 at
Just because it needs colors doesn't mean it needs attributes. Do we want it
to take any attributed string? Rather, omnibox is a non-rich edit field that
we display in a colorful way, and could just be dealt with by some careful
drawing routines...
Avi
On Wed, Mar 11, 2009 at 10:40 AM, Amanda Wal
On Wed, Mar 11, 2009 at 10:40 AM, Amanda Walker 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 w
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).
--Amanda
On Wed, Mar 11, 2009 at 10:29 AM, Avi Drissman wrote:
> Now that the Clipboar
18 matches
Mail list logo
