[chromium-dev] Re: How do I fix the cookie DB problem?
Thank you for your help!! Actually, my chrome source downed at Sep 03 , 2008. I Just want to compare KJS with V8. On 3월10일, 오전3시34분, Marc-Antoine Ruel mar...@chromium.org wrote: Try --user-data-dir=c:\temp2 assuming you are on windows. Anyway the KJS/JSC build is badly broken these days. I don't think anyone took care of it. I'm surprised it actually built. M-A On Mon, Mar 9, 2009 at 2:55 AM, Shaila dorud0...@infraware.co.kr wrote: When i compile the chrome with KJS. I got the runtime error like this. [3840:3856:23286500:FATAL:cookie_monster_sqlite.cc(275)]Check failed:false.Unable to initialize cookie DB. How can i fix the error?? Help me.- 따온 텍스트 숨기기 - - 따온 텍스트 보기 - --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 sure if it's really something to close the tree for or not. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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, 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
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? 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 -~--~~~~--~~--~--~---
[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 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). --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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
On Wed, Mar 11, 2009 at 10:45 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Wed, Mar 11, 2009 at 10:40 AM, Amanda Walker awal...@google.comwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
On Wed, Mar 11, 2009 at 10:45 AM, Thomas Van Lenten thoma...@chromium.org 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 to not include *any* of the webkit symbols so the system one could load to support NSAttributedString? That's an interesting idea. Can we do it easily? --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 mmento...@google.com wrote: 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 multi-process mode. This approach won't solve the single-process case. Option 6: finish porting WebKit the right way so that it's not exposing any Obj-C that might conflict with interfaces that Cocoa expects system WebKit to provide. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 awal...@google.com 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? --Amanda On Wed, Mar 11, 2009 at 10:49 AM, Mark Mentovai mmento...@google.com wrote: 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 multi-process mode. This approach won't solve the single-process case. Option 6: finish porting WebKit the right way so that it's not exposing any Obj-C that might conflict with interfaces that Cocoa expects system WebKit to provide. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
On Wed, Mar 11, 2009 at 10:55 AM, Mark Mentovai mmento...@google.com 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 be too careful... Heh. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
On Wed, Mar 11, 2009 at 10:55 AM, Mark Mentovai mmento...@google.comwrote: 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::HashTableint, int, WTF::IdentityExtractorint, WTF::IntHashint, WTF::HashTraitsint, WTF::HashTraitsint ::containsint, WTF::IdentityHashTranslatorint, int, WTF::IntHashint () #1 0x90183d69 in WebCore::TimerBase::isActive () #2 0x90183cdd in WebCore::FrameLoader::stopRedirectionTimer () #3 0x90183c2c in WebCore::FrameLoader::cancelRedirection () #4 0x90183b89 in WebCore::FrameLoader::provisionalLoadStarted () #5 0x90181651 in WebCore::FrameLoader::init () #6 0x9471164c in -[WebFrameBridge finishInitializingWithPage:frameName:frameView:ownerElement:] () #7 0x947114f3 in -[WebFrameBridge initMainFrameWithPage:frameName:frameView:] () #8 0x94710384 in -[WebView _commonInitializationWithFrameName:groupName:] () #9 0x9470ff1a in -[WebView initWithFrame:frameName:groupName:] () #10 0x94759306 in -[WebView initWithFrame:] () #11 0x95e9904a in -[NSHTMLReader _loadUsingWebKit] () #12 0x95e98c95 in -[NSHTMLReader attributedString] () #13 0x95e97930 in _NSReadAttributedStringFromURLOrData () #14 0x95e94943 in -[NSAttributedString(NSAttributedStringKitAdditions) initWithData:options:documentAttributes:error:] () #15 0x95e948b6 in -[NSAttributedString(NSAttributedStringKitAdditions) initWithHTML:options:documentAttributes:] () #16 0x960c9cc8 in -[NSAttributedString(NSAttributedStringKitAdditions) initWithHTML:documentAttributes:] () #17 0x962f1c38 in -[NSTextView(NSPasteboard) _readHTMLIntoRange:fromPasteboard:] () #18 0x960167b7 in -[NSTextView(NSPasteboard) readSelectionFromPasteboard:type:] () #19 0x96015f9a in -[NSTextView(NSPasteboard) _readSelectionFromPasteboard:types:] () #20 0x9605fca5 in -[NSTextView(NSPasteboard) readSelectionFromPasteboard:] () #21 0x9605fc37 in -[NSTextView(NSPasteboard) paste:] () #22 0x95df653b in -[NSApplication sendAction:to:from:] () #23 0x95ea517c in -[NSMenu performActionForItemAtIndex:] () #24 0x95ea4e81 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #25 0x95ea4b07 in -[NSMenu performKeyEquivalent:] () #26 0x95ea33ac in -[NSApplication _handleKeyEquivalent:] () #27 0x95dc016b in -[NSApplication sendEvent:] () #28 0x95d1d69f in -[NSApplication run] () #29 0x0047f415 in base::MessagePumpNSApplication::DoRun (this=0x57313c0, delegate=0xbfffee7c) at /Users/avi/Source/chrome/src/base/ message_pump_mac.mm:337 #30 0x0047f22f in base::MessagePumpCFRunLoopBase::Run (this=0x57313c0, delegate=0xbfffee7c) at /Users/avi/Source/chrome/src/base/ message_pump_mac.mm:90 #31 0x0047438e in MessageLoop::RunInternal (this=0xbfffee7c) at /Users/avi/Source/chrome/src/base/message_loop.cc:197 #32 0x004743a9 in MessageLoop::RunHandler (this=0xbfffee7c) at /Users/avi/Source/chrome/src/base/message_loop.cc:180 #33 0x00474434 in MessageLoop::Run (this=0xbfffee7c) at /Users/avi/Source/chrome/src/base/message_loop.cc:154 #34 0x0010a299 in (anonymous namespace)::RunUIMessageLoop (browser_process=0x5730070) at /Users/avi/Source/chrome/src/chrome/browser/browser_main.cc:182 #35 0x0010c07c in BrowserMain (paramete...@0xb49c) at /Users/avi/Source/chrome/src/chrome/browser/browser_main.cc:559 #36 0x34fc in ChromeMain (argc=1, argv=0xb6d0) at /Users/avi/Source/chrome/src/chrome/app/chrome_dll_main.cc:379 #37 0x3e7b in main (argc=1, argv=0xb6d0) at /Users/avi/Source/chrome/src/chrome/app/chrome_exe_main.mm:33 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman a...@google.com 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 more efficient than doing status updates that are going to be ignored 99.44% of the time, I'm not sure they have incentive. I'm not sure what you mean by this. What is everyone OK with? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 decoupling the UI from WebCore to the extent that we disallow blocking. With that design, we're forced to have WebCore (or at least glue/) bubble up state changes. Compared to just asking WebCore at the time of need, having state change notifications is more inefficient. I think it's worth paying the price. But it might be a harder sell to upstream. Avi On Wed, Mar 11, 2009 at 1:21 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman a...@google.com 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 more efficient than doing status updates that are going to be ignored 99.44% of the time, I'm not sure they have incentive. I'm not sure what you mean by this. What is everyone OK with? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 10:01 AM, Avi Drissman a...@google.com 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 canCopy(), canPaste(), etc. 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. We're pretty much the only ones decoupling the UI from WebCore to the extent that we disallow blocking. With that design, we're forced to have WebCore (or at least glue/) bubble up state changes. Compared to just asking WebCore at the time of need, having state change notifications is more inefficient. I think it's worth paying the price. But it might be a harder sell to upstream. State changes won't fix the problem either. There is no way in the browser to know about the current state of the renderer without one or the other one blocking. State change notifications don't address this problem. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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 trying to brainstorm a way around it. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker ama...@chromium.org wrote: On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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 trying to brainstorm a way around it. This seems like it is not worth worrying about until the mac browser is as good as the Windows one. We have this bug on Windows, and it's not held anything up so far. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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 would be fine (since, without process separation, there's a million ways for the renderer to hose the browser, and this is the least of their concerns). State changes won't fix the problem either. There is no way in the browser to know about the current state of the renderer without one or the other one blocking. State change notifications don't address this problem. I fail to see your problem. The renderer sends notifications about its state, and the browser uses the last (cached) value to present its menus as correctly as it can to the user. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
I'm not trying to turn this into a huge deal. I've already filed a bughttp://crbug.com/8662and 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 rather than a Windows one On Wed, Mar 11, 2009 at 2:12 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker ama...@chromium.org wrote: On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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 trying to brainstorm a way around it. This seems like it is not worth worrying about until the mac browser is as good as the Windows one. We have this bug on Windows, and it's not held anything up so far. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 libraries. This will give you correct line number information when tracing through system libraries (e.g. GTK or SSL). In some cases, this will also give you correct stack traces where you weren't able to get these earlier. You can even see the source code for the system libraries in GDB. Just use apt-get source to download the sources to anywhere on your system, and then point GDB to it using the dir command. You can put this command into your ~/.gdbinit file. So, you don't have to do that each time you start GDB. As before, the script only works on Ubuntu. It probably works on any Debian based system, but that is untested. Please note that Ubuntu does not by default ship 32bit versions of all the system libraries, if you are running a 64bit operating system. The script knows about this and downloads the Debian packages for the 32bit distribution and then repackages the library files on the fly. This temporarily requires downloading a lot of data. You might not want to do this, if you are on a slow Internet connection. The script prompts you and you can opt out. Markus --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 just call Job::UserHandleGrantAccess() and pass a handle returned from ::GetDesktopWindow(). This will allow access to only the desktop; which is what I want for MessageBox(). There doesn't appear to be any way to do this via the policy. Any suggestions? Thanks, D --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 dpc...@hotmail.com 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::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 just call Job::UserHandleGrantAccess() and pass a handle returned from ::GetDesktopWindow(). This will allow access to only the desktop; which is what I want for MessageBox(). There doesn't appear to be any way to do this via the policy. Any suggestions? Thanks, D --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Sandbox Policy and MessageBox
Where might I find an sample demonstrating this? On Mar 11, 4:42 pm, Darin Fisher da...@chromium.org 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 dpc...@hotmail.com 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::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 just call Job::UserHandleGrantAccess() and pass a handle returned from ::GetDesktopWindow(). This will allow access to only the desktop; which is what I want for MessageBox(). There doesn't appear to be any way to do this via the policy. Any suggestions? Thanks, D --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Sandbox Policy and MessageBox
On Wed, Mar 11, 2009 at 4:47 PM, DanielC dpc...@hotmail.com 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 macros). The message is sent via chrome/renderer/render_thread.h::Send. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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-interactive desktop (as I simply won't call TargetPolicy::SetDesktop()). I like the power of the chromium's policy based sandboxing, so i'd like to use it (i especially like the hooks for unloading blacklisted DLLs and and function patching). that said, maybe there's a better/ simpler way? On Mar 11, 5:02 pm, cpu c...@chromium.org wrote: 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 chrome. Not only you would need to access to the desktop window but before that have a handle to the interactive desktop. That is, the entire renderer is connected to a desktop that is not winsta0\default. In other words even JOB_OBJECT_UILIMIT_HANDLES is not sufficient. Finally, you don't want to call MessageBox from one of chrome's threads. This would enter the thread in a nested message loop that the rest of chrome is not aware of. Bad stuff would happen in short order. This also applies if you are using --no-sandbox. On Mar 11, 4:50 pm, Adam Langley a...@chromium.org wrote: On Wed, Mar 11, 2009 at 4:47 PM, DanielC dpc...@hotmail.com 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 macros). The message is sent via chrome/renderer/render_thread.h::Send. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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! This change affects the following modules: base icu38 zlib libpng libjpeg gtest If you are just building these components, everything should work as it did before. vcproj files will be generated at checkout. If you need to make a change to one of these modules, you will need to modify the gyp file in the associated directory. The related vcproj files are no longer in the repo, so don't modify them directly. Please consult the gyp documentation (or bug mmentovai, sgk, or myself): http://code.google.com/p/gyp/wiki/InputFormatReference You can force regeneration of the project files with: gclient runhooks --force Right now several sln files in higher level components point to old vcproj files (so momentarily there are two sources of truth for icu38 and a few others). This will be corrected shortly. Debug builds are solely generated from gyp/gypi files, Release still have some vsprops dependency. Again please do not hesitate to let me know if you encounter any problems. -BradN --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
