[chromium-dev] Re: Thoughts on copy/paste

I added a comment to the bug describing how we have solved problems like this in the past. -Darin On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman wrote: > Working through crbug.com/8384 (copy/paste), I've had a chance to look at > Chromium's current copy/paste system. > > For those unfamiliar, the

[chromium-dev] Re: gyp for windows base is live!

Hooray! Congrats. -Ben On Wed, Mar 11, 2009 at 9:09 PM, Bradley Nelson wrote: > Hi All, > I've just rolled out a switchover of several components on Windows to > gyp (generate your project), > the new cross platform build tool to which chromium is migrating. > gyp is now the official build tool

[chromium-dev] gyp for windows base is live!

Hi All, I've just rolled out a switchover of several components on Windows to gyp (generate your project), the new cross platform build tool to which chromium is migrating. gyp is now the official build tool for mac. Consider this a trial period for windows. IF THE ARE PROBLEMS, PLEASE LET ME KNOW

[chromium-dev] Re: Sandbox Policy and MessageBox

I'm not actually trying to spin off a renderer. I'm creating a watchdog program that acts as a crash service for creating dumps, logging to a file, and informing the user via a msg box (based on crash_service.cc). It then restarts the process that crashed. i don't have to worry about the non-inter

[chromium-dev] Re: Sandbox Policy and MessageBox

As darin/adam said, the right way is with an ipc message. But I am curious, what do you want to do? If it is for debugging purposes you can just start chrome with --no- sandbox. If you want to have dialog boxes pop directly controlled by the renderer, you will be fighting the architecture of chr

[chromium-dev] Re: Sandbox Policy and MessageBox

On Wed, Mar 11, 2009 at 4:47 PM, DanielC wrote: > Where might I find an sample demonstrating this? The messages are defined in chrome/common/render_messages_internal.h. The message ends up in chrome/browser/renderer_host/browser_render_process_host.cc (look for the dispatch table, full of macro

[chromium-dev] Re: Sandbox Policy and MessageBox

Where might I find an sample demonstrating this? On Mar 11, 4:42 pm, Darin Fisher wrote: > you have to send an IPC to the browser to ask it to show a MessageBox for > you.-darin > > On Wed, Mar 11, 2009 at 4:27 PM, Daniel wrote: > > > Hi guys, > > > Is there any way to display a message box wit

[chromium-dev] Re: Sandbox Policy and MessageBox

you have to send an IPC to the browser to ask it to show a MessageBox for you.-darin On Wed, Mar 11, 2009 at 4:27 PM, Daniel wrote: > > Hi guys, > > Is there any way to display a message box within an sandboxed process > without adding JOB_OBJECT_UILIMIT_HANDLES to > sandbox::TargetPolicy::SetJo

[chromium-dev] Sandbox Policy and MessageBox

Hi guys, Is there any way to display a message box within an sandboxed process without adding JOB_OBJECT_UILIMIT_HANDLES to sandbox::TargetPolicy::SetJobLevel()? The JOB_OBJECT_UILIMIT_HANDLES ui exception is a pretty broad sword for just displaying a popup dialog. Ideally, I'd like to be able to

[chromium-dev] Debugging symbols for system libraries

Yesterday, I updated the install script at http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh Please let me know, if you encounter any problems and I'll fix them. It now installs not only the libraries necessary to build Chromium, it also installs the debugging symbols for these li

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Thoughts on copy/paste

I'm not trying to turn this into a huge deal. I've already filed a bugand am likely to move on for now. But for me it's just another issue that users are going to complain about that I'm going to need to fix someday. Avi /who bets the first complaint will be from a Mac user

[chromium-dev] Re: Copy/Paste, Cocoa, and you

> 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

[chromium-dev] Re: Thoughts on copy/paste

On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson wrote: > Do you mean when you click on the menu, blocking the browser until the > renderer responds with whether the menus can be enabled? I would be > opposed to that. > Right, that would be bad for us. But for most users of WebCore, such a thing wo

[chromium-dev] Re: Thoughts on copy/paste

On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker wrote: > On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson wrote: >> Do you mean when you click on the menu, blocking the browser until the >> renderer responds with whether the menus can be enabled? I would be >> opposed to that. > > So are we, but th

[chromium-dev] Re: Thoughts on copy/paste

On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson wrote: > Do you mean when you click on the menu, blocking the browser until the > renderer responds with whether the menus can be enabled? I would be > opposed to that. So are we, but that's what WebKit currently assumes. That's why we've been tryin

[chromium-dev] Re: Thoughts on copy/paste

On Wed, Mar 11, 2009 at 10:01 AM, Avi Drissman wrote: > Most platforms (meaning not Chrome) have the ability, when the user pulls > down a menu, to adjust the states of the menu items within. For them, when > the user selects the Edit menu, they're OK calling into WebCore and asking > the Editor

[chromium-dev] Re: Thoughts on copy/paste

Most platforms (meaning not Chrome) have the ability, when the user pulls down a menu, to adjust the states of the menu items within. For them, when the user selects the Edit menu, they're OK calling into WebCore and asking the Editor canCopy(), canPaste(), etc. We're pretty much the only ones dec

[chromium-dev] Re: How do I fix the cookie DB problem?

If you just want to run V8 benchmark tests, you can get the details for that under the V8 Google code hosting page: http://code.google.com/p/v8/wiki/Testing On Mar 10, 11:18 pm, Shaila wrote: > Thank you for your help!! > Actually, my chrome source downed at Sep 03 , 2008. > > I Just want to co

[chromium-dev] Re: Thoughts on copy/paste

On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman wrote: > I actually don't know. It seems like just simple state gathering but it > might be more. > > The big concern is that it fits our model but no one else's. Everyone else > is OK with the UI asking the renderer questions directly, and as that's

[chromium-dev] Re: transform-replaced-shadows.html layout test

A single test is probably not cause to close the tree, but we don't want it to be red all the time, because that leads people to overlook other new errors that pop up. So if the change doesn't get rolled back, we want to file a bug and add the test to tests_fixable.txt promptly (on the order of min

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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,

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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,

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Re: Copy/Paste, Cocoa, and you

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

[chromium-dev] Copy/Paste, Cocoa, and you

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, W

[chromium-dev] transform-replaced-shadows.html layout test

Looks like transform-replaced-shadows.html has been failing since last night? A quick scan of the waterfall history seems to indicate it started w/ http://codereview.chromium.org/43058, which was reverting http://codereview.chromium.org/21192. But folks seemed to ignore it for a while, so I'm not