[chromium-dev] Re: OS X Sandbox design doc updated
Awesome! Thanks! On Thu, Jan 14, 2010 at 3:13 AM, Jeremy Moskovich jer...@chromium.org wrote: Hi, I've updated the OS X Sandboxing design doc to better reflect the current state of affairs. Edits/corrections are welcome. Best regards, Jeremy -- Mike Pinkerton Mac Weenie pinker...@google.com -- 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: [Chrome-team] Re: [Mac] Something is eating the right mouse button events in the Toolbar. Help!
Can you compare what happens when you right-click on the omnibox vs. a bookmark button? It might be interesting to see where/how those stacks differ. On Mon, Jan 11, 2010 at 2:55 PM, Andrew Bonventre andyb...@chromium.org wrote: Wrong list. Oops. On Mon, Jan 11, 2010 at 2:50 PM, Andrew Bonventre (Bons) andyb...@google.com wrote: I'm attempting to add context menus to Browser Action buttons within the toolbar, but I've hit a snag and cannot for the life of me figure out what is happening with my events... - (void)onRightMouseDown:(NSEvent*)theEvent; is never being called within my NSButton subclass, and in fact, any other portion of the Toolbar controller except for the Omnibar. I've tried overloading the function within BrowserActionButton, ToolbarController and ToolbarView, only to never have it called. In order to track down the codepath for a right mouse down event that _does_ work in the toolbar, I got a stacktrace of the context menu code within the Omnibar: #0 0x001c7454 in -[AutocompleteTextFieldEditor menuForEvent:] at autocomplete_text_field_editor.mm:89 #1 0x92ecf0ae in -[NSView rightMouseDown:] #2 0x92e3e1ef in -[NSTextView rightMouseDown:] #3 0x929adfe0 in -[NSWindow sendEvent:] #4 0x001f6c58 in -[ChromeEventProcessingWindow sendEvent:] at chrome_event_processing_window.mm:101 #5 0x001f58a7 in -[ChromeBrowserWindow sendEvent:] at chrome_browser_window.mm:300 #6 0x928c6b2f in -[NSApplication sendEvent:] #7 0x0078b18a in -[CrApplication sendEvent:] at chrome_application_mac.mm:33 #8 0x9285a4ff in -[NSApplication run] ... I have confirmed that -[ChromeEventProcessingWindow sendEvent:] IS being called on right mouse clicks and therefore NSWindow's sendEvent is being called. Any ideas would be greatly appreciated. Something is eating them up and I don't know what's going on. A -- You received this message because you are subscribed to the Google Groups Chrome-team group. To post to this group, send email to chrome-t...@google.com. To unsubscribe from this group, send email to chrome-team+unsubscr...@google.com. For more options, visit this group at http://groups.google.com/a/google.com/group/chrome-team/?hl=en. -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Extensions and the Mac
One viewpoint I haven't seen mentioned on this thread is from that of the extension developer. Suppose they write, from their perspective, a perfectly good extension that uses binary components. After being around for a few weeks, they notice they have a 2-star rating and a lot of angry comments saying this extension doesn't work at all wh That doesn't really seem fair to the extension writer. People are complaining because they haven't been informed and we've not put a mechanism in place to inform them, and they take it out on the extension in terms of a really bad rating. On Fri, Dec 11, 2009 at 6:29 AM, PhistucK phist...@chromium.org wrote: I believe the most elegant and quick (seemingly) solution is to provide the extension developers a field (in the extension gallery, not in the extension itself) that will include the platform and the version. Going farther, you can add a check if the platform and the version (or even let the developer enter the search string) exist in the user agent or anywhere else you can think of and show a warning next to the install button. And an automatic quick solution can be to go over the manifest (which you already do to search for NPAPI to add it to the approval queue) and see if there is a DLL, SO or whatever Macintosh is using in them. If there is a DLL, add a Compatible with the Windows platform and so on, or the opposite, if it does not contain, then you surely know - Not compatible with the Macintosh or Linux platforms. ☆PhistucK On Fri, Dec 11, 2009 at 03:54, Aaron Boodman a...@google.com wrote: Yes, extensions that include NPAPI are a very small minority. Last time I checked there were something like 5. It is a way out for people who already have binary code that they would like to reuse, or who need to talk to the platform. I don't see what the big deal is about a few extensions only supporting a particular platform. As long as it is clear to users (you're right, we need to do this), I think this is ok. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] sheriff swap Dec 18/21?
Hey everyone, I noticed I'm on the hook for sheriff duty on Dec 18/21 (Friday/Monday) but I was hoping to be taking vacation during that time. Does someone want to swap with me? Thanks in advance! -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Need a linux-views build buddy.
I've got a cl that builds fine on win/mac/linux but I'm afraid I could impact views_linux. And, since there's no trybot, I have no way of knowing until I actually check in and break it. That's where you come in! Would someone mind trying http://codereview.chromium.org/465005/show for me with linux views and see if it's all ok? The only tricky part is that there's an svn move on 2 files in there, but the trybots seem able to figure it out. Would be much appreciated, thanks! -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Need a linux-views build buddy.
The same is true of view_chromeos, FWIW. On Thu, Dec 3, 2009 at 5:45 PM, Mike Pinkerton pinker...@chromium.org wrote: Yes, except it's down and hasn't worked in days. On Thu, Dec 3, 2009 at 5:44 PM, Jeremy Orlow jor...@chromium.org wrote: Isn't gcl try cl -b linux_view what you want? On Thu, Dec 3, 2009 at 1:46 PM, Mike Pinkerton pinker...@chromium.org wrote: I've got a cl that builds fine on win/mac/linux but I'm afraid I could impact views_linux. And, since there's no trybot, I have no way of knowing until I actually check in and break it. That's where you come in! Would someone mind trying http://codereview.chromium.org/465005/show for me with linux views and see if it's all ok? The only tricky part is that there's an svn move on 2 files in there, but the trybots seem able to figure it out. Would be much appreciated, thanks! -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Need a linux-views build buddy.
Yes, except it's down and hasn't worked in days. On Thu, Dec 3, 2009 at 5:44 PM, Jeremy Orlow jor...@chromium.org wrote: Isn't gcl try cl -b linux_view what you want? On Thu, Dec 3, 2009 at 1:46 PM, Mike Pinkerton pinker...@chromium.org wrote: I've got a cl that builds fine on win/mac/linux but I'm afraid I could impact views_linux. And, since there's no trybot, I have no way of knowing until I actually check in and break it. That's where you come in! Would someone mind trying http://codereview.chromium.org/465005/show for me with linux views and see if it's all ok? The only tricky part is that there's an svn move on 2 files in there, but the trybots seem able to figure it out. Would be much appreciated, thanks! -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Mike Pinkerton Mac Weenie pinker...@google.com -- 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: Changes to using threads in the browser process
Can you put this information, as well as some examples for proper usage, on dev.chromium.org. I doubt this stuff is very well documented from the perspective of someone trying to use it, and this looks like a great start!!! On Tue, Nov 3, 2009 at 12:50 AM, John Abd-El-Malek j...@chromium.org wrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Mac] Make sure you're working on M4 P1 bugs
Our goal for this Friday is to be able to count our Mac P1 M4 release blocker bugs on one hand (we're in the 20s now). To that end, everyone should have their P1 list practically at zero by the end of this week. If you are not going to be able to reach this, let me (or other triage folk) know ASAP so that we can get you some help. Letting us know on Friday doesn't do much good. Email if you have any questions! -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Why is Linux Chrome so fast?
When we were all out in MtnView last, one of the action items for some of the Mac QA folks was to get a machine that triple-boots (Mac/Win/Linux) so that we could run the same version of chrome on the same hardware and see the differences between platforms and then to run a bunch of tests (startup, new tab, page-cycler, etc). I'm pretty sure krisr got the machine created, but I don't think we ever ran any tests on it beyond that. Anyone know what happened our best laid plans? This seems like something we should be very active in tracking. On Wed, Oct 28, 2009 at 12:11 AM, Adam Barth aba...@chromium.org wrote: My three laptops have relatively comparable hardware and run Chrome on Windows, Mac, and Linux respectively. The Linux version of Chrome feels ridiculously faster than Windows and Mac. Do we understand why this is? Can we make Windows and Mac feel that fast too? General observations: 1) Scroll performance is extremely good. Even on Gmail, I can only get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, it doesn't even look like I can do that. 2) Tab creation is very fast. Maybe the zygote is helping here? Can we pre-render the NTP on other platforms? 3) Startup time is faster than calculator. Adam -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Improving our documentation
One of my personal OKRs for this quarter is to identify areas where we need better docs, especially on Mac where we've been so busy getting caught up that we haven't taken the time to explain how things work. To that end, I've started a doc on our public Google Code wiki: http://code.google.com/p/chromium/wiki/DesignDocsToWrite Feel free to add anything to it. It doesn't commit you to writing the doc, we can always find someone down the line to do the work, but knowing in what areas we need better coverage will help when we come time to do a doc fixit. Eventually, we'll add all of these docs to dev.chromium.org. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Code Yellow: Dev Channel Release On-Hold This Week
About the only one that I could think to be a blocker would be the CNN bug since it's probably in the top10 pages, but I heard it also happens in firefox as well, so it may not even be our regression. I think we also have a better handle on the ui_tests bug for Mac, at least in that we haven't seen it recently. I think that one can be downgraded to P1 if we want to keep it open for tracking. It doesn't seem to be causing the horrible ui_test failures it once was which makes it no longer a dev blocker. On Tue, Oct 27, 2009 at 4:49 PM, Peter Kasting pkast...@google.com wrote: On Mon, Oct 26, 2009 at 9:41 PM, Anthony LaForge lafo...@google.com wrote: http://code.google.com/p/chromium/issues/list?can=2q=pri:0colspec=ID+Stars+Pri+Area+Type+Status+Summary+Modified+Owner+Mstone+OSx=mstoney=areacells=tiles Most, if not all, of these, seem like P1 or lower to me. P0 is supposed to mean blocks work until it's fixed. Things like crashes and regressions are generally P1 unless they're things like 100% crash on start. PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Tab Thumbnails and Aero Peek (of Windows 7)
All the screenshots show this with a single window. What happens if you have multiple windows open? Does it only show the selected window? As an alternate suggestion, we have a mode in Camino2 called tabspose which is like OS X Expose, but shows the (large) thumbnails of all open tabs overlaying the content area of the browser. Allows much better visualization of the tabs because you're not limited to small squares but can use as much of the window as available. This does involve interacting with the window already, so it doesn't work until you have the window in the foreground, but I wanted to bring it up as an idea. http://www.flickr.com/photos/spaunsglo/987375693/ for an early screenshot (currently looks more polished, but same idea). 2009/10/23 Brett Wilson bre...@chromium.org: 2009/10/23 Hironori Bono (坊野 博典) hb...@google.com: Hi Brett, Thank you so much for noticing this. I'm integrating the ThumbnailGenertor class into my prototype now. :) By the way, I'm a little wondering if there is a function that changes the width and the height of a thumbnail image generated by the ThumbnailGenerator class at run time. If not, I would like to hear there is a plan to add it. When Windows 7 shows tab thumbnails, it automatically calculates the width and the height of a thumbnail image so that it can show all thumbnails in one line. (When we open too many tabs and Windows 7 cannot show their thumbnails, it shows a list of tab titles.) In brief, we cannot assume the width or the height of a thumbnail as constant values on Windows 7. So, it may be better for the ThumbnailGenerator class to have an interface that changes the width and the height of its thumbnails. (I has added code that resizes the thumbnails retrieved from the ThumbnailGenerator object and sends the resized thumbnails to Windows 7. So, I don't mind it at all.) There isn't a way to do this. The reason is that the thumbnail generator precalculates thumbnails in advance for many pages (for example, when we're discarding the backing store). This means we have to know basically when we start Chrome what the max thumbnail size will be. It uses power-of-two downsampling to be as fast as possible, so the actual thumbnails aren't guaranteed to be any particular size. I would just use the default size for now. If it doesn't look OK, we can add a future enhancement to request the size, so the ones it generates on-demand (the ones where there is a backing store) can have a larger size if needed. Brett -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: RFC: AutoFill++ Design Document
Mac browsers (Safari and Camino, at least) allow the user to auto-fill from their me card in the OS X Address Book application, containing name, address, and phone number. This would be a nice feature to provide to users who have grown accustomed to the functionality. Is there any mechanism to allow us to recognize and provide this info to the form instead of requiring the user to fill out the form completely? On Tue, Oct 20, 2009 at 1:13 PM, James Hawkins jhawk...@chromium.org wrote: Hi, please read the inlined proposed design for AutoFill++. Any feedback and comments are appreciated. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Who owns crash...@chromium.org and why is there so many updates from it?
I just had crashbot add a totally unrelated stack trace to a bug. I emailed anthony about it, we'll see. Something is clearly wrong. On Mon, Oct 12, 2009 at 12:41 PM, Scott Hess sh...@chromium.org wrote: Does this relate to receiving crashbot emails adding Crash labels on closed-out bugs where the backtrace doesn't apparently have any relevance to the original backtraces involved with the bug? I've gotten a couple of these in the past week. -scott [Unfortunately, I don't remember the earlier one, the latter is http://crbug.com/13113 ] On Tue, Oct 6, 2009 at 9:58 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge lafo...@chromium.org wrote: The short of it: People manually associated bugs in http:crash My tool creates its own map of signatures and for whatever reason that bug is on all of them It goes through each aggregate signature and updates the status of the bug (which is a flash crasher) It's made much worse because we are dealing w/ crashes that don't have symbols and cannot be aggregated... What went wrong: The limiting function (seeing if crash-VERSION) was applied does not happen for priority updates. This was actually intentional since we start looking at crash data early on. However this should no longer be needed since we wait for enough data that priority should no longer be shifting. What can be done about it? I will put a limiter on setting the priority Thanks. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson patr...@chromium.org wrote: John's question is about why it's generating so many issue updates. Patrick On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge lafo...@chromium.org wrote: It's the role account that manages crashes and crash related bugs. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson patr...@chromium.org wrote: [+laforge] On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Friendly reminder: don't let changes rot
On Thu, Oct 8, 2009 at 1:55 PM, Evan Martin e...@chromium.org wrote: My rationale is: someone sends me a code review when they think the code is done, which means they're further along in their project than I am in mine, and I am now in the critical path for them making progress. But I can also see the other side. The other way of looking at that is they're at a convenient stopping point, I'm still busy working on something. What's that quip about just because something is an emergency to you doesn't mean it is to me? :-) All that said, I do try to get to code reviews as soon as possible. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Mac] Tab animation improvements under heavy stress
I've spent some time banging my head against this issue on Mac where when we open a ton of tabs at the same time (15+, eg, mashing down cmd-t or opening all bookmarks as tabs) it looks janky because the tabs animate independently. As a result, we end up with the surfacing tabs stuck at various points in their animations until everything catches up, with this odd lumpy camel/snake effect. I tried a whole bunch of things with canceling pending animations when new tabs were created and only had marginal luck. My latest results no longer have the camel effect, but now we end up with small gaps at the end as new tabs are created a few pixels off from the previous tab. Everything eventually snaps into place, but I'm not sure if I've made things any better or worse. The time to create a new tab is unaffected. One (perhaps?) positive change I've made is that tabs now submarine more vertically than before since their width is correctly sized before they are animated (before it was doing width and origin animations). Others, of course, may disagree and think it looks horrible. I'm down to the point where I'm tweaking knobs in a vacuum. I can't tell if I've done anything worth checking in, so I'm taking a breather and asking folks to try the (rather simple) CL here: http://codereview.chromium.org/243049/show Luckily, this latest revision has only a couple of well-isolated blocks, so if we wanted to we could even check it in and then go remove it later if anyone complained. What do people think? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Question about linux pixel tests
Not sure if this answers the question or not, but recall that linux falls back to the windows expectations when there isn't a linux-specific override. That could explain why it's not there. On Tue, Oct 6, 2009 at 1:03 AM, Drew Wilson atwil...@chromium.org wrote: Are some pixel tests currently disabled on the linux release buildbots? I'm trying to rebaseline some tests that are currently marked as FAIL in test_expectations, but I can't grab linux images because the .png files don't exist in the archive grabbed by the rebaseline tool. As an example, I'm looking at http://build.chromium.org/buildbot/layout_test_results/webkit-rel-linux/28080/layout-test-results.zip and trying to find fast/css/last-of-type-pseudoclass-expected.png (it's not in there). -atw -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] OCMock landed in third_party
I just finished landing OCMock (http://www.mulle-kybernetik.com/software/OCMock/) into third_party. From their homepage: OCMock is an Objective-C implementation of mock objects. If you are unfamiliar with the concept of mock objects please visit mockobjects.com which has more details and discussions about this approach to testing software. This implementation fully utilises the dynamic nature of Objective-C. It creates mock objects on the fly and uses the trampoline pattern so that you can define expectations and stubs using the same syntax that you use to call methods. One big advantage is that we are now able to mock areas of Cocoa (such as global singletons) in unit tests without disturbing the surrounding machine. Please take advantage of it when writing unit tests for Mac OS X. Thanks to Paul Wicks for providing the CLs to get it building in our infrastructure. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Is that unimpossible to add a progress bar of page loading with webkit?
On Mon, Sep 28, 2009 at 12:21 PM, PhistucK phist...@gmail.com wrote: Yeah, but some indication will be helpful, even the one IE has been giving - ## images downloading or something. A count down for resources, even if the resource count changes every few seconds, it is still preferable against being lost in the dark in some way. Do you not agree? I do not agree. I doubt most users care that there are 37 images remaining to load, or 17 scripts. It's just more information to overload them with that they don't understand. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: gclient hang
To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Pasteboards and the mac valgrind builder
We've got a bug that covers some strange issues with pasteboards on the valgrind bot, but the exact bug escapes me. Were you seeing outright test failures or new leaks? I think Mark was poking into it at one point, but I don't think we got anywhere closer to resolving the underlying issue. On Thu, Sep 24, 2009 at 3:21 AM, Nico Weber tha...@chromium.org wrote: Hi, Chromium Mac (valgrind) and I just had a good time. The bot is green now, but some tests still finish as FAILED (they just don't leak). Most of them were in that state before my CL made me look into this. Most of the failing tests seem to be related to NSPasteboard. 1. Does the valgrind builder only become red on memory leaks but not on any test failures? 2. It looks like there was some trouble with NSPasteboards in the past. Do we know why these tests work fine locally and on the test bots, but fail on the valgrind bot? Thanks, Nico -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
WebKit gardening occurs more often than sheriff duties. afaik all WebKit gardeners also have sheriff duties. This implies there are people on the team who don't have gardening duties. We need to fix that ASAP. Nobody should get special dispensation. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Webkit merges and tree closures
It is hard to be a WebKit gardener if you do not have WebKit commit access. Sometimes the gardener has to commit a quick bustage fix upstream or roll back a fellow Chromium committers change to WebKit. -Darin Correct, it is hard, but many/most of us who are webkit sheriffs/gardeners are not webkit committers (for example, the entire mac group). I don't understand your point. Are you saying that only webkit committers should be on the webkit sheriff rotation? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Seeing a grey bar at the bottom of the 211 mac dev release? Read on.
I hope this serves to remind everyone that we need to keep the tree in a state where it is always shippable. If you're going to implement only a portion of a feature, make sure it's not visible to the user until it's fully operational. Even if you intend to flip the rest on in a few hours, something may go awry (tree closures, concerns raised about your cl, a new episode of My Antonio on VH1, etc) that prevents you from landing for a day or more. On Sat, Sep 19, 2009 at 2:37 PM, Nico Weber tha...@chromium.org wrote: By the way: After resizing the window, you can hit cmd-shift-b twice to move the bar back to the bottom of the window. On Sat, Sep 19, 2009 at 11:01 AM, Nico Weber tha...@chromium.org wrote: Hi, wondering why there's a grey, useless bar at the bottom of the latest mac dev release? It is not intentional, and is my fault – sorry. It will be gone again in next week's dev release. It was only active on trunk for a few hours, but this week's dev release was cut in that interval. If you see a bug filed for that, mark it as dupe of 19073 and write something like Bug 19073 landed prematurely and has been backed out. Unfortunately, the 211 build came from the tiny window when it was checked in. Nico -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: OSX cocoa_test_helper.mm and the like in browser.lib.
Remove it, see what happens? On Mon, Sep 21, 2009 at 12:47 PM, Scott Hess sh...@chromium.org wrote: Why is cocoa_test_helper.mm listed in the browser library? This results in the class being linked into Google Chrome Framework (meaning it ships). Doesn't seem appropriate to me. This came up because I have some helper code I was listing in the unit_tests section of chrome.gyp. Since it's in browser/cocoa/, it will already be excluded from other platforms correctly. I was wondering about test_support_unit or test_support_common, but AFAICT since the file is in chrome/browser/, that would not be appropriate for my file. [cocoa_test_helper.mm doesn't have any dependencies w/in browser, that I can see, so it could maybe move there.] Any thoughts? -scott -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
That's what ben meant by concepts that do not exist for the relevant platform. There are no preferences on windows or options on Mac. That's the one area where we will diverge. However, a menu item like Next Tab should be changed globally to Select Next Tab on all platforms, not just specifically on Mac to match Safari (case appropriate, of course). That's the kind of forking we will not be doing. On Wed, Sep 16, 2009 at 4:20 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Why scrollbars don't match on the Mac pixel tests
Interesting, and surprising. Have you spoken to the #webkit folks about this? Hyatt was the one that did all this re-factoring, maybe this is expected, or not. I'd drop him an email directly if you can't get anything out of #webkit. On Fri, Sep 4, 2009 at 5:17 PM, Avi Drissmana...@google.com wrote: Speculation here (while I'm not 100% convinced I'm 99.44% there), but... Scrollbar thumb size has always been fuzzy. On the original Mac there was no way to specify the thumb size, and even today HIThemeDrawTrack (which is the most modern Mac theme-drawing API) has a parameter |viewsize| which is under-specified. While the theory is to make thumb : track :: view : doc size the Mac scrollbar code passes in the page scroll size for the viewsize parameter. You can see the code in ScrollbarThemeMac for details, but as an example, for LayoutTests/css1/basic/inheritance.html, the WebCore Scrollbar that had values visible size = 600, total size = 724 turned into: scrollbar size: 15x585 (we lose 15px to the growbox) min: 0 max: 124 viewsize: 560 (visible size of 600 - cAmountToKeepWhenPaging; see ScrollView::updateScrollbars) Now the scrollbar isn't 560/585 (96%) of the track so it's not clear where the thumb size (as drawn) is coming from. But that's not the problem. The problem is that I was trying to track down the same numbers for the reference images so I could see where the metrics were diverging. And I couldn't. I got DumpRenderTree from WebCore loading in GDB, but breakpoints in ScrollbarThemeMac.mm wouldn't hit. Nor would breakpoints in Scrollbar.cpp or ScrollView.cpp. In desperation I breakpointed on HIThemeDrawTrack. And that didn't hit either. What did hit was -[NSScroller drawRect:] at this damning backtrace: #0 0x96143759 in -[NSScroller drawRect:] #1 0x9605fbf8 in -[NSView _drawRect:clip:] #2 0x9605e6ef in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #3 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #4 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #5 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #6 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #7 0x9605ea86 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #8 0x9605d045 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #9 0x96145385 in -[NSNextStepFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #10 0x960594ab in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] #11 0x95f99e7b in -[NSView displayIfNeeded] #12 0x00011ab4 in -[FrameLoadDelegate webView:didFinishLoadForFrame:] at FrameLoadDelegate.mm:207 That's why the scrollbars are different. I thought that they'd moved from using the Cocoa scroll code in WebCore, but it doesn't seem so. Options: 1. Tweak ScrollbarThemeMac to generate values that make HIThemeDrawTrack draw identically to Cocoa (or fork it; same diff) 2. Rebaseline all images that only involve scrollbar diffs without mercy. Avi -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Chrome has started crashing like CRAZY since 4.0.203.2
I've noticed this as well, but there's no rhyme or reason besides go to a web page, watch entire browser crash. There doesn't seem to be any way to repro it or repeat it, nor does the specific page seem to matter. Unfortunately I'm running continuous builds which don't have breakpad, so I'm not able to see a stack. Just wanted to say I have seen a drastic increase in crashes so we should be on the lookout and probably expect higher crash reports in 203 if/when it goes out. On Sat, Aug 29, 2009 at 11:53 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for that. I will try and reproduce it and get back to you. On Aug 30, 2:27 am, Jim Roskind j...@chromium.org wrote: In answer to your what would constitute a good bug report? At a minimum, add any plausibly significant details. For instance, rather than saying I'm browsing the same site as I do every day, consider saying what site you are browsing, or possibly, list the exact URL sequence you go through (especially if the cause is entirely reproducible). if you can't repro it, try to talk about what it is that you are doing, explicitly. Do you start with 1 tab open, or 40? What are some/all of the tabs?? What is the site that seems to induce the crash? What sort of things are you doing on that site? Reading a certain set of blogs? Reading articles? Posting? etc. The best bug report is a completely reproducible set of actions. The worst bug report doesn't give a clue as to what the user was doing near the bug event. You want to be as close as possible to the first. Anything that gives a tester a shot at tickling the bug is a giant step toward a bug getting attention, and getting fixed asap. Sometimes we see a common thread among a pile of bugs... and that gives us a clue. ...but we need some threads to consider ;-). Thanks in advance, Jim On Sat, Aug 29, 2009 at 3:37 PM, Gobbledegook aftabkha...@gmail.com wrote: so far so good. so if i'm browsing the same site i browse everyday, and suddently chrome starts dunking, and i want to file a bug report, what would constitute a good report? On Aug 29, 11:24 pm, Marc-Antoine Ruel mar...@chromium.org wrote: We do look at bug reports; higher quality reports (with facts and context) will be triaged faster. M-A On Sat, Aug 29, 2009 at 6:19 PM, Gobbledegookaftabkha...@gmail.com wrote: thanks. i'll give that a spin. no one ever seems to repsond on crbug.com so this is just an amazing place to come for debugging and instant advice. On Aug 29, 11:17 pm, Marc-Antoine Ruel mar...@chromium.org wrote: Still, we are getting a lot of sqlite3 crashes in this revision, you may want to start with --user-data-dir=c:\test to see if it fixes the problem. M-A On Sat, Aug 29, 2009 at 6:11 PM, Peter Kastingpkast...@chromium.org wrote: On Sat, Aug 29, 2009 at 2:58 PM, Gobbledegook aftabkha...@gmail.com wrote: every 10 minutes i'm getting one crash. It was rock solid till earlier today. Don't send this to chromium-dev. File bugs at crbug.com. PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Major tab cold regression on mac around r24415
If you look at http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150 You'll see a pretty big spike in new tab performance between r24415 and r24419 http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcmode=htmlrange=24415:24419 Anyone know what's going on? This is a very serious regression and there were no Mac-specific changes anywhere in the vicinity that I could see. I filed http://code.google.com/p/chromium/issues/detail?id=20312 to cover the regression. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Major tab cold regression on mac around r24415
I don't think that's it, because it's just one test that's affected. If it were the epoch change, I'd expect more tests to show similar bumps. On Wed, Aug 26, 2009 at 9:28 AM, Evan Martine...@chromium.org wrote: PS Every time I want to call it the EPIC CHANGE. On Wed, Aug 26, 2009 at 9:27 AM, Evan Martine...@chromium.org wrote: Here's a guess: the history file is restored each time the test runs, and Brett's epoch change means that we need to re-migrate the history file every time we start. (I don't recall how this test works, but it seems logical to test NTP performance you'd want some data that the NTP would make use of...) On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkertonpinker...@chromium.org wrote: If you look at http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150 You'll see a pretty big spike in new tab performance between r24415 and r24419 http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcmode=htmlrange=24415:24419 Anyone know what's going on? This is a very serious regression and there were no Mac-specific changes anywhere in the vicinity that I could see. I filed http://code.google.com/p/chromium/issues/detail?id=20312 to cover the regression. -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Chromium / Google Summer of Code
I'll let Paul Wicks chime in on his own experience, but we've been able to successfully integrate the Mac OS X spell checker with the Chromium infrastructure, including introducing platform support for a spelling window. Paul is also in the process of adding OCMock to our build, which we desperately need for many of our unit tests. I'd say it was a smashing success! On Sun, Aug 23, 2009 at 11:05 AM, Joel Stanleyj...@jms.id.au wrote: On Sat, Aug 22, 2009 at 07:31, Lei Zhangthes...@chromium.org wrote: With the Google Summer of Code program winding down, I'm curious how our GSoC participants are doing. Can the students and their mentors share their experiences? (Assuming you're all done with evaluations and all that.) My project was 'Forging a better Cr on Linux', and Dean was my mentor. I had an eye on doing performance/memory usage work motivated by my attempts to run Chromium on the Beagleboard; an ARM system with 128MB of RAM. Chromium works and you can come along to OSDC (http://2009.osdc.com.au) for my talk There's something on my ARM for all the details :) I didn't get as much done as I would have liked as I was attending classes and sitting exams throughout my Summer of Code, a downside of being a student from the southern hemisphere. This means I'm going to stick around the project to continue working on things I'm interested in. (For my record as much as anyone else) here is a summary of the patches I wrote, in chronological order: == Scale backing store cache size == This would scale the number of DIBs stored based on the system RAM. It's since been replaced by a more complex algorithm. == Set process name on Linux == This was to help distinguish the renderer from the browser (and the zygote, which was just appearing at the time). It was reverted as it broke the UI tests which iterate over the process name. I did not resubmit as 'ps f' provides the same information for less lines of code. == Jankfs == An idea Dean had; write a FUSE filesystem to simluate slow and unreliable storage. See http://groups.google.com/group/chromium-dev/browse_thread/thread/59b0440255c87ed3 == ARM build == The tree had built for ARM at some point in the past but had since bitrotted. I went through building a toolchain, and then a root filesystem, and found 3 gcc ICE (internal compiler errors) on the way. I then made a bunch of changes in working towards building and running Chromium on the Beagleboard: * Hide x86 assembly in the seccomp and chroot sandboxes from the ARM build * A Skia build fix * v8 patch for targeting the ARMv7 Cortex-A8 (found on the beagleboard) * Most significantly, re-wrote v8.gyp to make cross-compiling possible For instructions on building see http://code.google.com/p/chromium/wiki/LinuxChromiumArm == Memory usage in task manager on Linux == Calculates the memory usage of each process. This is committed and working, but the API needs to be re-worked to be less Windows-like before about:memory is ready for Linux. See http://codereview.chromium.org/159777 == Fix proxy settings for Gnome =2.26 == Newer versions of Gnome use a different binary name, this made the Change proxy settings button work for both. == Add ctrl+w accelerator to close bookmark manager for linux == == Fix PR_ImplodeTime for Linux x64 == This was one of the last patches to make the chrome tree compile for x64 without patches, building on Dean's work. Beware the 2038 bug. == One liners == * gcc-4.3 / 4.4 build fixes * gitignore updates * window icons According to the logs I wrote 22 patches. Despite having been around open source projects for a number of years, Chroimum's development process taught me many new things. Having code review for all changes made was a new to me, and line by line review is great at ensuring I got detailed feedback. Dean's mentoring was the most valuable part of the experience. He was great at answering questions and explaining the concepts I was not familiar with. Having the ability to communicate via IM made this very easy and I would encourage mentors and students to follow this setup in future years. Thanks to Dean for mentoring me, and everyone else who reviewed and committed my patches. Cheers, Joel -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
Safari, Camino, and Mac Chromium place the cursor on a single click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
One other note: the other Mac browsers in question (Safari, Camino, etc) provide a page proxy icon which can be clicked to select the entire contents of the url bar (in case you don't want to use cmd-L). Mac Chromium is lacking that as we put the favicon in the tab not the url bar, though we have a bug filed to provide one (as it's also an affordance for dragging the page URL and Title to other applications, which I sorely miss). This puts Chromium slightly behind in the click-to-select wars that the other browsers provide as an alternative. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac Debug is hosed, needs an owner
Over the weekend, we developed an assert loading any page, even the NTP ASSERTION FAILED: m_clients.contains(renderer) (/Users/pinkerton/src/chromium/src/webkit/../third_party/WebKit/WebCore/css/CSSGradientValue.cpp:109 virtual WebCore::Image* WebCore::CSSGradientValue::image(WebCore::RenderObject*, const WebCore::IntSize)) Discussions in IRC this morning have linked it to WebKit merge r23527. This appears to only hit Mac debug, but it makes it impossible to do any work with a trunk debug build. I think we should hold the tree closed until we can get this resolved. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac History Menu
The few times I've needed to use the history menu (gak, i just closed something by accident, let me get it back), re-using the current tab is exactly what i don't want, as it clobbers something totally unrelated that I had open. That's what prompted this discussion. I agree that it should behave like bookmarks in theory, since it's effectively the same presentation, but it seems to get in the way of my workflow when I try to actually use it. On Wed, Aug 12, 2009 at 3:33 PM, Scott Violets...@chromium.org wrote: I would suggest you create something like browser/views/event_utils on the Mac (and Linux) side. Any place you're opening a URL from a user gesture you map the event to a WindowOpenDisposition. This way the UI is consistent with regards to what user gestures do. As to this particular case, I believe the default should be current tab. -Scott On Wed, Aug 12, 2009 at 12:23 PM, Brett Wilsonbre...@chromium.org wrote: On Wed, Aug 12, 2009 at 12:18 PM, Avi Drissmana...@chromium.org wrote: Brett— Are we talking about the history page, or history items? The history page gets its own tab, sure. But when someone picks an item from the history menu, where does it go? I think current foreground tab is right, with command for background tabs. Yes, I was confused. I think clobbering is OK in that case. My new improved opinion is it should act like the drop-down on the back/forward menus. Brett -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: How to attach to Renderer Process in XCode
It creates a new process because you're navigating to a new domain. cnn.com and the New Tab Page are in different domains, and thus use different render processes. Annoying to debug, yes, but there you go. You'll just need to have a couple terminal gdb windows open at a time to bounce between processes. I asked about this before and there doesn't seem to be much motivation to special case this logic to re-use the process. On the surface, certainly creating a new process is heavy-weight and appears like it should be avoided at all costs, but on today's hardware/OS's, it's barely noticed in the real world application of web surfing. If someone can provide hard numbers about what it does to page load times, we might look into it, but it's pretty low on the priority list right now, especially without any data. On Tue, Jul 28, 2009 at 10:41 PM, n179911n179...@gmail.com wrote: On Sun, Jul 26, 2009 at 3:52 PM, Jeremy Moskovichjer...@chromium.org wrote: Command line gdb is one way to go... I always use the XCode IDE gdb integration, as documented on the wiki. While trying to attach to the Chrome process directly from the IDE can get funky, the method documented on the wiki always works for me. XCode attaches itself to a running renderer which is paused [by calling pause() ] so you need to click continue in the IDE to get it to keep running and render a webpage. It's possible that the broken pipe you're seeing is the result of killing the renderer from the debugger. Thank you for the help. I did what you suggest. And I attached gdb to 2516 via command line. Chromium does start and I see the 'New tab page'. Like this: $ ~/chromium/src/xcodebuild/Debug/Chromium.app/Contents/MacOS/Chromium --renderer-stp-dialog [2516:2055:3122095122007:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (2516) paused waiting for debugger to attach @ pid Then I go to the URL text box of chromium and type in 'http://www.cnn.com' But what I get is I see this but with a new pid (2220). [2516:2055:3122095122007:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (2220) paused waiting for debugger to attach @ pid But question is why chromium starts a new Renderer process when I just trying to load my first URL (http://www.cnn.com). Why it does not re-used 2516 before? Thanks in advance. Best regards, Jeremy On Sun, Jul 26, 2009 at 9:23 PM, n179911 n179...@gmail.com wrote: On Thu, Jul 16, 2009 at 12:46 AM, Jeremy Moskovichjer...@chromium.org wrote: You can find instructions here: http://dev.chromium.org/developers/debugging-on-os-x Ultimately, we should really combine all the platform debugging articles into one page :| Best regards, Jeremy Thanks. I tried it. I saw this in the shell: [460:2055:4872081828141:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (460) paused waiting for debugger to attach @ pid And then I got XCode and Attached to '460'. But i see this in my shell, and chromium never get launched. [460:11783:4914670085769:ERROR:/Users/n179911/chromium/src/ipc/ipc_channel_posix.cc(649)] pipe error on 3: Broken pipe Thank you for any help. On Thu, Jul 16, 2009 at 9:29 AM, hap497 hap...@gmail.com wrote: Hi, chromium.org has this http://dev.chromium.org/developers/how-tos/debugging for debugging renderer process on Windows. My question is how can I do the same in XCode on MacOS X? I go to Run-Attach To Process, all the menu item entries are disabled. Thank you for any tip. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Design Doc: out of process (v8) proxy resolving
Don't we farm out a separate process for favicon decoding? And for theme image decoding as well? On Wed, Jul 29, 2009 at 11:44 AM, Jeremy Orlowjor...@chromium.org wrote: Are there other things currently done in the browser process that'd be nice to do in a sandboxed utility process like this? Is there any work that the browser farms out to renderer processes that might be cleaner to do in a utility process? If so, I'd propose making the design for this new process a bit more general purpose. Honestly, I don't think there's much to do. And I think it'd be OK to say that all work done by this process would need to be stateless (so we can kill it and spin it back up at will). I'm not necessarily saying you need to do the work to make it general purpose now, but I definitely think it should be kept in mind while working on this. That way we don't need to worry about finding ourselves designed into a corner (and needing to create another another helper process). J On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman ero...@chromium.org wrote: Here is a design document for http://crbug.com/11746 http://sites.google.com/a/chromium.org/dev/developers/design-documents/out-of-process-v8-pac Feedback welcome. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Duplicate expectations?
We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Duplicate expectations?
I'm almost positive we made it so because we had so much trouble when we were bringing up the mac and linux ports. I could be on crack tho On Tue, Jul 28, 2009 at 3:41 PM, Jeremy Orlowjor...@chromium.org wrote: Was it ever a pre-submit check? I filed http://crbug.com/15883 against myself a bit ago, but had trouble making it work. I was going to work with Marc-Antoine this week to figure it out. J On Tue, Jul 28, 2009 at 11:13 AM, Darin Fisher da...@chromium.org wrote: No idea. I was similarly burned by this. I wish it could be run as a presubmit check. -Darin On Tue, Jul 28, 2009 at 11:01 AM, Mike Pinkerton pinker...@chromium.org wrote: We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 2000 errors building WebCore bindings!
When I try to build today, I get 2000 errors of the form: command line:1:1: error: macro names must be identifiers when building WebCore bindings. Others have complained of similar errors on Linux. What's going on here? Reports are that it seems to still build correctly, but this really throws XCode for a loop. This was introduced at r19816. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Clobber probably needed
I had to do a full clobber this morning after last night's tree activity. Otherwise I got errors building V8. This is on Mac, but I assume other platforms would be similar. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: middle click on home
Middle-click always opens a new tab in the background and making exceptions is just likely to confuse users. Except when middle-clicking on a tab means close the tab. So it means both open and close, depending on the context. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Important: Porting bits of UI by subclassing is now banned.
Is there a plan to rewrite Browser, probably the biggest application of the create the shared object via a factory pattern in our code, or is our focus just moving forward with the correct patterns and leaving existing code as-is? On Tue, Jun 23, 2009 at 1:27 AM, Peter Kastingpkast...@google.com wrote: On Mon, Jun 22, 2009 at 10:22 PM, Ben Goodger (Google) b...@chromium.org wrote: If you are creating UI on another platform and want to reuse common code, please move the common code into a separate object that the platform specific UI owns. Note that this is a specific application of a general good-C++-coding principle: prefer composition to inheritance. Ignore this at your peril, or like me you may end up forced to rewrite big chunks of your code when you later realize that inheritance does not extend to some future change you wanted to make nearly as flexibly as composition would have. (For the curious, this is why I spent the last week rewriting the cross-platform WebKit ICO and BMP decoders I just checked in.) PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
This is awesome! A great read and a good use of examples from our code. Is it worth being more explicit about using MVC to design a new component? Right now it's exemplified in the context of how to allocate memory for the various objects, but a concrete example (the TabStripModel is a good one) might be helpful too. On Fri, Jun 19, 2009 at 12:42 PM, Brett Wilsonbre...@chromium.org wrote: Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the Engineering design documents page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. Thanks! Brett -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 2:11 PM, Peter Kastingpkast...@google.com wrote: On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.org wrote: We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN. In general, you should always prefer #if defined(FOO) over #ifdef FOO, e.g. because you can add || defined(BAR) to the former later. PK This is already documented in our Chromium coding style guide. Do we need to replicate it? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Login name auto-fill code
Because Stuart is in the middle of rewriting the backend to use Keychain, and that part hasn't yet been adapted. On Fri, Jun 12, 2009 at 2:11 PM, Lucius Foxlucius.fo...@gmail.com wrote: I just want to see why chrome on macos preview 'auto-fill' works (it suggests my login name for gmail) in the beginning (after i first install), then it stopd working (i have to type in my login name every time). -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Naming things _views
FWIW, we don't use _cocoa or _mac in browser/cocoa at all, assuming it was implied. I assumed gtk was doing the same. On Thu, Jun 11, 2009 at 11:53 AM, Ben Goodger (Google)b...@chromium.org wrote: Well, class name is supposed to match the file name in Google style. -Ben On Thu, Jun 11, 2009 at 11:22 AM, Erik Kayerik...@chromium.org wrote: So the class name is the same too in this case? (InfoBubble and InfoBubble) Erik On Thu, Jun 11, 2009 at 10:46 AM, Ben Goodger (Google) b...@chromium.org wrote: sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Resurrecting the JSC build.
IIRC from the Mac porting effort (a year ago now), the JSC build relies significantly on objective-C dom bindings which we neither want to use nor are easy to get working in our build system. We jettisoned them for a reason and my guess is that it would be a non-trivial effort to re-instate them (if at all, things were pretty scary before). Not trying to shirk work or responsibility, just pointing out there be dragons there and my +2 Sword of Build Wrangling is in the shop for repair. On Thu, Jun 11, 2009 at 4:06 PM, Dimitri Glazkovdglaz...@google.com wrote: Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :DG -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Where is the code to pop up dialog
chrome/browser/app_modal_dialog_mac.mm Once we figure out the right way to do these as per-tab sheets, they'll no longer be app-modal. I found this with a quick spotlight search for NSAlert. On Wed, Jun 3, 2009 at 3:05 AM, Daniel Dreiberg daniel.dreiber...@gmail.com wrote: Hi, I am looking for pointers tor the code which pop up dialog in chromium? e.g. JavaScript alert dialog or confirm dialog? I am specifically looking how that is done on MacOS. Thank you. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac History Menu Implementation
On Tue, May 26, 2009 at 12:59 AM, Ben Goodger (Google) b...@chromium.org wrote: Wash your mouth out with soap. The availability of real estate is never an excuse to use it in Chrome :-P Ok, we'll just go without because it doesn't exist in windows. :P -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Is there any way to profile chromium on MacOS?
You can always attach to the appropriate renderer with Shark. Does that not fit the bill? On Sat, May 23, 2009 at 3:53 AM, lucius lucius.fo...@gmail.com wrote: Hi, Does chromium have build in profiling? e.g. can I find out the break down in html processing, css processing, js processing for each page load? or can i run chromium with some profiling tool on MacOS to understand the bottleneck? Thank you. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Renderers Not Responding
Does the problem go away if we disable the sandbox? On Fri, May 22, 2009 at 2:02 PM, Jeremy Moskovich jer...@chromium.org wrote: I just pinged Avi about us, my guess is that the Sandbox is blocking connections ot the Window Server. Adding (debug deny) to the sandbox spec file will print messages to console when things like this happen, I'll add a note about that to the Wiki (http://dev.chromium.org/developers/debugging-on-os-x). Best regards, Jeremy On Fri, May 22, 2009 at 10:54 AM, Avi Drissman a...@google.com wrote: A visitor to IRC pointed me today to http://crbug.com/11319 , where renderers are marked as not responding. He pointed out that this is not just a cosmetic issue, since things like spindump run which kills performance on non-quad core machines (that we all have). I thought about just pumping events on a non-main thread, but it turns out that NSApp nextEventMatchingMask returns nil when you don't run it on the main thread and doesn't pull any windowserver events. I thought about going for LSBackgroundOnly, but 1) we don't have a separate bundle for the renderer and 2) I don't know if that fixes our problem. The only thing I can think of now is to create the MessageLoopForIO in renderer_main in a non-main thread and make a MessageLoopForUI on the main thread. Any thoughts on how to better do this? Avi -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: CIA-bot on #chromium?
Please please please no. It's the most annoying thing about #webkit and is mostly noise with very little signal. We already have a mailing list for all checkins and the waterfall. We don't need something interrupting our only form of real-time communication with redundant data. On Tue, May 12, 2009 at 1:38 AM, Mohamed Mansour m0.interact...@gmail.com wrote: I would say we do it. I would like to see statuses of checkins live. Instead of no sort of notifications in the build bot page other than the auto refresh. I personally like to learn from others on how they do their fixes. And it is kinda cool to see it in the channel (like most other open source projects) and #chromium is a development channel, so it fits its description. -- Mohamed Mansour On Mon, May 11, 2009 at 9:53 PM, Adam Barth aba...@chromium.org wrote: On Mon, May 11, 2009 at 6:49 PM, Brett Wilson bre...@chromium.org wrote: I think it's noise and I suspect we have even more checkin traffic than they do. We have roughly a factor of two more checkins than they do, according to: http://cia.vc/stats/project/Chromium http://cia.vc/stats/project/WebKit There would be about 25 minutes (on average) between messages, but of course clustered during US business hours. Adam -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Tab-modal dialogs on the Mac
I dig it! NICE! It's similar to the overlay window trick we use for tab dragging between windows. Maybe for consistency you should call the hanger window the overlay window? Is there any way we can keep this generic and put it into GTM? On Thu, May 7, 2009 at 8:46 AM, Amanda Walker ama...@chromium.org wrote: That's cleaner than I expected, and the behavior looks right. Nice job! I vote for continuing with this approach. --Amanda On Thu, May 7, 2009 at 12:17 AM, Avi Drissman a...@google.com wrote: OK, so attached is my proof of concept. The code is pretty clear, though if you have questions, please let me know. +maf: Your offhand comment about tabs being subwindows led me to this implementation; thanks! +dmac: What do you think? I'll send the DTS incident back to you tomorrow. Avi On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Need help in finding a performance problem...
I was able to get very consistent results before with just TestShell on Mac running the mozilla page-cycler test locally. Would using TestShell instead of Chromium help, or do you want me to try your patch on Mac? Let me know. On Tue, May 5, 2009 at 2:08 PM, Marc-Andre Decoste m...@chromium.org wrote: Salut, I've been trying to locally collect performance data to confirm whether this was a good enough improvement or not and I can't seem to get consistent enough results on my machine to draw a conclusion... Some things look faster, and others look slower, but I sometimes get faster results with the resize corner enabled, compare to disabled (which doesn't really make sense)... So I don't think I can rely on these numbers... So I decided that I will go through with the code review of the changes, and if Adam and Darin are happy with it, I will commit and monitor the performance dashboard to see how it goes there... If it goes bad, I'll revert... And if it goes well... I'll scream my happiness as loud as I can (and those who know me a bit, know that I CAN be pretty LOUD!!! ;-)... BYE MAD On Fri, May 1, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Fri, May 1, 2009 at 9:06 AM, Marc-Andre Decoste m...@chromium.org wrote: Salut Evan, thanks, I will do that... And the results seems better than I initially thought... If you get performance improvements, please do commit :) Evan is correct that Darin needs to check this over, but I'll happy code review everything where I can. AGL -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Discussion to take over #chrome on irc
I think part of Peter's point is that we *don't want* people looking for support in #chromium. It's a developer channel. Our ad-hoc filtering to keep support-seekers out seems to be working fine. I have no desire to change that. On Fri, May 1, 2009 at 1:41 AM, Jason A. Spiro jasonspi...@gmail.com wrote: We don't need to make people to look on the Web to find out what channel to join. We should make #chrome Just Work, especially since it is so easy to do. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Why are pref keys wchar_t's?
Why are our internal pref keys all wchar_t strings? That's pretty wasteful for something the user never sees and doesn't need to be localized. It's really wasteful on Mac and Linux (32bit wchar_t). Is this on anyone's radar to fix? Should I file a bug? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Why are pref keys wchar_t's?
Well, in this case they're not user-visible, so there's no reason for them to not be char*s. Unless I'm missing something obvious. On Fri, May 1, 2009 at 3:02 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: Is there a place that actually describes when it's appropriate to use which string type, and how to know if we should be fixing code we run across? Is everything just supposed to be string16? -Albert On Fri, May 1, 2009 at 11:59 AM, Evan Martin e...@chromium.org wrote: We have a bunch of places where wchar_ts still exist, and none of them are correct. I think this isn't particular instance isn't likely to b *that* much waste but it definitely would be nice to fix. I fixed command line switch names to be ASCII on the train into work once just 'cause it was bothering me. On Fri, May 1, 2009 at 11:42 AM, Mike Pinkerton pinker...@chromium.org wrote: Why are our internal pref keys all wchar_t strings? That's pretty wasteful for something the user never sees and doesn't need to be localized. It's really wasteful on Mac and Linux (32bit wchar_t). Is this on anyone's radar to fix? Should I file a bug? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: How can I run TestShell in Xcode on MacOS
src/webkit/tools/test_shell/test_shell.xcodeproj On Wed, Apr 29, 2009 at 9:53 PM, daniel daniel.dreiber...@gmail.com wrote: How can I run TestShell in Xcode on MacOS? Which xcode project I should use? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: chromium resources always rebuilding
Yes, this is certainly a direct cause of making a null build on mac take far, far longer than it should. Can we just back out Tony's change that was made in the rules to go back to the way things were in the short term? On Tue, Apr 28, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org wrote: You really should take a look ASAP because yesterday, the mac try slaves were like 35+ jobs being. That makes mac testing inexistent and will just cause more mac breakage. I assume today, tomorrow, etc will be as bad. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
On Sun, Apr 26, 2009 at 5:50 PM, Amanda Walker ama...@chromium.org wrote: Application startup is one of the areas where we count every millisecond, and try to touch the disk as little as possible. I don't think it's safe to assume that the cost of creating and writing to a file is negligible in this context without actually measuring it. Just curious, how many files are read/written loading a profile: history, bookmarks, cache, last session, preferences, cookies, etc? I imagine it's non-trivial and happens at every startup. I agree that the proposal just for the sake of consolidating code may not be warranted, but to jump all over it because a file has to be written seems like premature optimization in light of everything else that happens on the disk at app startup. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Please use BUG and TEST in changelists
On Thu, Apr 23, 2009 at 11:16 AM, Sverrir Á. Berg sver...@chromium.org wrote: C) Used bugs to track releases. Since bugs are pretty good at tracking lifetime you can in one place check status of testing and see what issues (tracked through blocking bugs) have come up. Builds are then marked as will-not-fix or fixed depending on if they are released or not. While I tend to preach this process when I can, and practice it in other projects, we have two platforms that still have a significant amount of remaining work ahead of them. To dump *everything* into the bug system at this point may be a bit premature as it leads to bug slog where everyone eventually gets demoralized from just fixing bugs all day, every day, bugs bugs bugs! Nothing on the horizon but more and more bugs. I've seen it happen on other projects. I'm not sure when that right point is, but I think we've still got plenty of big rocks on each platform to keep us busy without everything being a bug. Spreadsheets aren't always 4-letter words, and they can have pretty colors!!! :-) -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: URLRequestMockHTTPJob?
The problem I'm seeing is that this is getting called before the ChromePathProvider has been registered with the path service in the browser, so it doesn't get any path. I'll keep digging as to why. On Tue, Apr 21, 2009 at 6:11 PM, Tony Chang t...@chromium.org wrote: It tries to get it from PathService::Get(chrome::DIR_TEST_DATA). Is that variable set for mac? (see chrome/browser/automation/automation_provider.cc:2117) On Tue, Apr 21, 2009 at 2:49 PM, Mike Pinkerton pinker...@chromium.org wrote: Anyone familiar with how URLRequestMockHTTPJob is supposed to locate files? The UI tests just pass it a filename (no path, no nothing) and expect it to be found. On Mac, at least, this just ends up passing straight through so the FilePath looks like /filename.html which is clearly isn't going to find the Debug directory. It's looking for things in chrome/test/data. How does this extra mapping get done? Am I missing something obvious? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] URLRequestMockHTTPJob?
Anyone familiar with how URLRequestMockHTTPJob is supposed to locate files? The UI tests just pass it a filename (no path, no nothing) and expect it to be found. On Mac, at least, this just ends up passing straight through so the FilePath looks like /filename.html which is clearly isn't going to find the Debug directory. It's looking for things in chrome/test/data. How does this extra mapping get done? Am I missing something obvious? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Mac] Use scoped_ptr and scoped_nsobject
We discovered this morning (almost by accident) that the gcc setting GCC_OBJC_CALL_CXX_CDTORS has been enabled for us since our switch to 4.2 last summer. This means that destructors on C++ objects will be called when the objective-c object containing it goes away (this wasn't the case with past Objective-C runtimes). I am about to check in a CL that makes it explicit across our xcode configs so we don't repeat the argument Mark and I had this morning :-) This means that we are now free to use scoped_ptr, scoped_array, scoped_nsobject, etc in our @interfaces to syntactically identify strong references and prevent memory leaks due to programmer error. I encourage people to use these in their code, and fix them when they run across strong references that would benefit from a simple conversion. I converted BrowserWindowController and verified that indeed both dtors and deallocs are correctly called. It took like 2 minutes. Let me know if you have any questions, and be sure to remind your fellow coders about these classes when doing code reviews. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: [Mac] Use scoped_ptr and scoped_nsobject
There is one caveat here that I found after running into some issues with the unit tests. When you convert members from pointers to scoped pointers, even if you keep the destruction ordering consistent (by re-ordering the members in the @interface decl), the objects are destructed much later than before. eg, before when things being cleaned up from, say BrowserWindowController dealloc (ie, before the call to super dealloc), now the destruction chain looks like (from the bottom up): ... now things owned by scoped_ptrs are destroyed here 5 org.chromium.Chromium 0x00152f4a -[BrowserWindowController .cxx_destruct] + 48 6 libobjc.A.dylib 0x94a709d0 object_cxxDestructFromClass + 111 7 libobjc.A.dylib 0x94a71683 _internal_object_dispose + 34 8 com.apple.Foundation0x95996570 NSDeallocateObject + 224 9 com.apple.AppKit0x93d31ba6 -[NSResponder dealloc] + 130 10 com.apple.AppKit0x93ebad26 -[NSWindowController dealloc] + 449 ... before things were destroyed here... 11 org.chromium.Chromium 0x00153e88 -[BrowserWindowController dealloc] + 62 12 com.apple.AppKit0x93dcdb22 -[NSWindowController release] + 158 Note that the C++ objects are being released long *after* the window controller is already gone. If anything was holding a weak reference to the NSWindow, they're in big trouble unless they've retained it (which was the bug I discovered earlier). So these classes are still wonderful and self-documenting and full of goodness, but you should make double-sure you understand what's going on when you do a conversion. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Lots of IPC errors this morning
I sync'd my tree this morning and all i have to do is click a page off NTP to get a stream of: [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found errors. Things aren't really happy. Anyone touching stuff that might be IPC related yesterday? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Lots of IPC errors this morning
FYI: This was resolved earlier this morning. I guess I got unlucky and sync'd at a bad time. It was an issue with the devtools_agent_filter. On Thu, Apr 9, 2009 at 11:24 AM, Mike Pinkerton pinker...@chromium.org wrote: I sync'd my tree this morning and all i have to do is click a page off NTP to get a stream of: [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found [9905:2055:10870232140893:FATAL:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_proxy.cc(158)] Check failed: false. filter to be removed not found errors. Things aren't really happy. Anyone touching stuff that might be IPC related yesterday? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Moving to single toolbar instance (per window) on mac
Just a heads-up for folks. After thinking more about it, and talking with Avi/Cole/Scott at lunch, I'm going to spend next week collapsing our view hierarchy such that we will only have a single toolbar/urlbar/bookmarkbar per window, rather than the separate instances per tab we have now. The original design was an attempt to make tab detaching easier, but in the end it doesn't buy us anything based on how things ended up. We figured we'd leave it until we had a reason to make a change one way or the other, but after some more thought, it seriously complicates managing UI focus between tabs. The presence of multiple toolbars/bookmarks bars would also suck with extensions, as they'd have a multiplicative effect on the number of subprocesses created. Since windows already has this single bar per window model (we've been faking it under the hood up to this point), this should actually be a simplification. It will mean that we'll need to use more of the OmniBox code for stashing/retrieving state on tab switches, but again that code should hopefully be factored for cross-platform use anyway. Let me know if you have any issues or complaints, though I don't expect any. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac work plan - Implementing about:memory etc tasks
How about you file a bug for it and send me the number and i'll update the site to refer to the bug#. That way, if we re-assign it, we haven't lost any of the history. As far as getting started, if it works on linux, then it should be pretty easy to figure out what is stubbed out on mac by tracing through the linux side and mac side in parallel. There are probably some NOTIMPLEMENTEDs or ifdefs around the appropriate code. If it doesn't work on either, then it might be more difficult if you don't have a windows box to do the same. When I try to load about:memory, i get: [65682:267:129430955317560:ERROR:/src/chromium/src/chrome/common/temp_scaffolding_stubs.cc(330)] Not implemented reached in MemoryDetails::MemoryDetails() [65682:267:129430955364350:ERROR:/src/chromium/src/chrome/common/temp_scaffolding_stubs.cc(334)] Not implemented reached in void MemoryDetails::StartFetch() Which looks relevant :-) Most of the mac group is traveling this week so we're off IRC more than we're on, but next week things should be back to normal. Catch us in IRC if you want, or send more email to this list. Thanks! On 4/1/09, viksit vik...@gmail.com wrote: Hi all, I'm new to the Chromium community, and was in the process of picking up a couple of introductory tasks that would help me get started. I found one that talks about adding support for about:memory, etc stats in the browser. I was wondering whether this feature would need to get tracked as a bug, as well as any comments on getting started with work on the feature - perhaps design discussions through email or IRC, or pointers to relevant parts of code? (I've got source trees compiled on both OS X and Linux, so I'm good to go with the implementations itself) Cheers Viksit -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac Work Plan
After chatting with folks, we decided that we need both a way to organize who is working on particular tasks and identify all the big pieces that need to get done in order to get us to a more usable product. To that end, I've created a public doc: http://sites.google.com/a/chromium.org/dev/developers/mac-work-plan This gives us a place to mark what we're working on, and having things in buckets by estimated time is helpful for both people who want to contribute and devs just looking for a small task to fill the gaps in their week. We'd rather not just lump these high-level tasks into the buglist, though we will continue to keep our dogfood bugs there (and referenced as an on-going line-item in the doc). Feel free to email me with questions or find us on IRC. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Omnibox q around Mac+Chromium best-practices.
The rest of the UI so far is trending towards the reverse, thin C++ and thick objc controllers (usually subclasses of NSViewController). If you're debugging at the UI layer, there's going to be plenty of cocoa and objective-c, I don't think you can avoid it. Even a C++ class is going to have obj-c in it if it talks to the UI at all. I'm fine with a mix, personally. Draw the line where you think it's most appropriate. On Thu, Mar 19, 2009 at 7:08 PM, Brett Wilson bre...@chromium.org wrote: I would do the thin Objective C mode, partially since all Chrome developers know C++. I could debug that code or make changes to it if I was doing something that affected it, but I would have a much harder time with Objective-C. Brett On Thu, Mar 19, 2009 at 4:00 PM, Scott Hess sh...@chromium.org wrote: I'm refactoring my Omnibox code towards something I'm willing to put up for review, and am realizing that I need to find a way to rule on whether I should have thick Objective-C helpers or thin ones. Say for instance that I have an NSTableView, I'll need a data source for that, which needs to be an Objective-C object. At the thin extreme, I can put the minimum amount of code in that object to fulfill the data source protocol, plus anything I need for handling delegation or target/action type things, which leaves setup and wiring in the C++ code. At the thick extreme I would push most of the Objective-C code into the Objective-C object, and have the C++ code call into that. Or there's something in the middle. WDYT? Right now it's somewhere in the middle. I don't create Objective-C methods solely to be called from C++, nor C++ methods solely to be called from Objective-C, except for cases where either would need to poke through the encapsulation boundary. Thanks, scott -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac Dogfood Planning
I've been adding more things to the label:dogfood query that prevent me from using Chromium as my primary browser. We should try to get things off that list that aren't really dogfood. On Wed, Mar 4, 2009 at 6:05 PM, Mike Pinkerton pinker...@chromium.org wrote: On Mon, Mar 2, 2009 at 2:27 PM, Mike Pinkerton pinker...@chromium.org wrote: Let's hold off picking what we're working on until we've agreed this is the right list. I've turned this list into bugs in our bugtracker with a label of Dogfood http://code.google.com/p/chromium/issues/list?q=label:mac%20label:dogfood This way it's pretty easy to see what we have left. Feel free to claim something if it has no owner, those haven't been spoken for. -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac builds crash on every page
This morning's Mac build is a train wreck :( Every tab crashes while loading. [52334:19459:1323448372606907:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52334:19459:1323448373087271:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52334:19459:1323448373829541:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52334:19459:1323448378028354:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52335:2055:1323448378336616:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(386)] pipe error (3): Operation not permitted [52334:19459:1323448378479984:WARNING:/Users/pinkerton/src/trunk/src/chrome/common/file_descriptor_set_posix.cc(17)] FileDescriptorSet destroyed with unconsumed descriptors [52334:19459:1323448378507560:WARNING:/Users/pinkerton/src/trunk/src/chrome/common/file_descriptor_set_posix.cc(17)] FileDescriptorSet destroyed with unconsumed descriptors It was ok yesterday afternoon. Does this look familiar to anyone? Anyone know something that went in that might affect IPC channels? None of that code appears to have changed in at least a week. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac Dogfood Planning
On Mon, Mar 2, 2009 at 2:27 PM, Mike Pinkerton pinker...@chromium.org wrote: Let's hold off picking what we're working on until we've agreed this is the right list. I've turned this list into bugs in our bugtracker with a label of Dogfood http://code.google.com/p/chromium/issues/list?q=label:mac%20label:dogfood This way it's pretty easy to see what we have left. Feel free to claim something if it has no owner, those haven't been spoken for. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac Dogfood Planning
As we're making rapid progress, I wanted to start to organize a little more around the 5 minute browser goal for the end of the quarter and see if we can better define what we want for our dogfood milestone. Here's a very quick list of things that I see us as needing in order to get to something that we can call dogfood: - bookmark bar - class/nib infrastructure for tab dragging, even if we don't drag tabs - history - cut/copy/paste - breakpad - HTML SELECT popups - page-cycler tests running on a bot and collecting stats - plug-ins in-process (out-of-process will probably be more difficult) Some other nice to have's, but I wouldn't consider these blocking for dogfood (probably a followup milestone, listed only to show I thought of them but didn't deem them important enough for inclusion in the primary dogfood milestone), include: - keychain integration - preferences - fancy omnibox functionality - improved UI from Cole - tab dragging - IME - out-of-process-plugins - ...the list goes on (printing, etc etc) First off, does the first list sound like the right list of things to be focusing on? Are there obvious things I'm missing? I'm sure there are. If these are the right things, we should probably reflect this work somewhere. The linux folks are using the bug system for their tasks. Some people don't mind this, others dislike the everything is a bug mentality. How do we want to capture the work so it's trackable externally? Personally I'm happy with bugs, I just know there are others that can't stand it. I went through the buglist of label:mac this morning and there's not too much on there that's top priority. I suggest we have a meeting tomorrow, similar to what the linux folks did, and triage the bugs (P1 = blocking dogfood, P2 = important for later, P3 = we'll get to it one day). Let's hold off picking what we're working on until we've agreed this is the right list. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac Dogfood Planning
As we're making rapid progress, I wanted to start to organize a little more around the 5 minute browser goal for the end of the quarter and see if we can better define what we want for our dogfood milestone. Here's a very quick list of things that I see us as needing in order to get to something that we can call dogfood: - bookmark bar - class/nib infrastructure for tab dragging, even if we don't drag tabs - history - cut/copy/paste - breakpad - HTML SELECT popups - page-cycler tests running on a bot and collecting stats - plug-ins in-process (out-of-process will probably be more difficult) Some other nice to have's, but I wouldn't consider these blocking for dogfood (probably a followup milestone, listed only to show I thought of them but didn't deem them important enough for inclusion in the primary dogfood milestone), include: - keychain integration - preferences - fancy omnibox functionality - improved UI from Cole - tab dragging - IME - out-of-process-plugins - ...the list goes on (printing, etc etc) First off, does the first list sound like the right list of things to be focusing on? Are there obvious things I'm missing? I'm sure there are. If these are the right things, we should probably reflect this work somewhere. The linux folks are using the bug system for their tasks. Some people don't mind this, others dislike the everything is a bug mentality. How do we want to capture the work so it's trackable externally? Personally I'm happy with bugs, I just know there are others that can't stand it. I went through the buglist of label:mac this morning and there's not too much on there that's top priority. I suggest we have a meeting tomorrow, similar to what the linux folks did, and triage the bugs (P1 = blocking dogfood, P2 = important for later, P3 = we'll get to it one day). Let's hold off picking what we're working on until we've agreed this is the right list. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac Dogfood Planning
I'll take a look through and followup with creating new bugs. The other thing that came up in our meeting was startup-tests, which should be added to that dogfood list. On Mon, Mar 2, 2009 at 2:40 PM, Thomas Van Lenten thoma...@chromium.org wrote: Did you happen to audit what we're currently logging w/ NOTIMP() and/or DCHECKs? Seems like anything that shows up loading basic pages should also go on the list for close out (either do it, or remove the log and open a bug for follow up like the linux folks have done). -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Google Chrome's Most visited page is inferior to Apple Safari 4 (beta) Top Sites page
+1 meetoo On Wed, Feb 25, 2009 at 12:43 AM, Peter Kasting pkast...@google.com wrote: On Tue, Feb 24, 2009 at 6:34 PM, Evan Martin e...@chromium.org wrote: Yes, I would suggest it is urgent that we improve all of Chromium as rapidly as possible. I AGREE THINGS THAT ARE BAD SHOULD BE LESS BAD PLEASE TO BE FIX THIS NOW I CANOT TELL ALL MY FREIND TO SWITCH FROM FOXFIRE PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Mac chrome from the tree
Actually, http://dev.chromium.org wasn't ever a problem. More importantly: We can now render http://www.google.com without crashing!!! :-D On Wed, Feb 25, 2009 at 12:32 AM, John Grabowski j...@chromium.org wrote: For Mac Chrome multiprocess bringup a group of us had been throwing diffs around. There were various reasons for this; e.g. hacks which can't be landed without more work, changes that need to be upstreamed, and so on. The last of these has landed with http://codereview.chromium.org/27108. In short, this means a build of Chromium.app from an unmodified tree can now render http://dev.chromium.org without crashing. MacChromeTastic! jrg -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Qt now a possibility?
Just to add to what Ben said earlier in the thread, the Cocoa front-end is progressing quite well even though the Win UI is very different from Cocoa in terms of the interaction models and how the toolkits are designed (C++ vs Objective-C). The Model-View-Controller design of the shared code is proving that we can slap just about any UI we want on top of it (so far). This bodes well for some other group doing a Qt version. Just wanted to provide something tangible to the it should be possible argument. On Thu, Feb 19, 2009 at 5:55 AM, Ben Goodger (Google) b...@chromium.org wrote: I'll just repeat (since these threads seem to be linked from many places) - a Qt version for Linux is not impossible, it just requires a dedicated set of folk to work on it and maintain it. The design of Chromium is such that N front ends are possible. The team is most familiar with GTK and so that's where they'll be focusing their energy. -Ben On Wed, Feb 18, 2009 at 9:59 PM, inaneframe inane...@gmail.com wrote: I'm not understanding the animosity shown toward GTK in this thread thus far. A majority of GNU/Linux distros are now using GNOME as the default distro, I use and nearly every Free Software user that I know IRL uses and prefers it. I'm not going to bad mouth QT, I used it predominately a couple years ago in the 3.2 days and used it up until the betas of 3.5. All I want is a fast browser and I for one am happy about the choice to use GTK, not only because I use GNOME but also because I've noticed quite a bit of difference between loading QT in a non-QT environment vs loading GTK in a non-GTK environment, GTK is faster. Try loading Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany from KDE and it's apparent. Dolphin is a very fast application, pretty darn slow to load in GNOME, Thunar is comparable directly, fast as hell to load in either environment. All I know is that there shouldn't be this kind of hate in the Free Software community. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: how keyboard input works
keyDown and keyUp may post a single character, but how does IME enter into this? How are those sent to us? A single character at a time in a loop after the user confirms the entry? On Thu, Feb 19, 2009 at 2:46 PM, Avi Drissman a...@google.com wrote: Some research (where I found http://wilshipley.com/blog/2005_08_01_archive.html ) indicates that events are basically one character. I think I'll cap it at, say, four, and LOG(ERROR) if we get more than that. Sound good? Avi On Thu, Feb 19, 2009 at 2:37 PM, Avi Drissman a...@google.com wrote: On Thu, Feb 19, 2009 at 2:35 PM, Darin Fisher da...@chromium.org wrote: std::vectorunsigned short text; std::vectorunsigned short unmodified_text; std::vectorunsigned short key_identifier; Their equivalents, yes. Is it really the case that those are unbounded in length? Or, is there some small max length that they can be? There's no theoretical limit on the Mac. I don't know what the practical limit is. Why isn't this a problem for Windows and Linux since they also have to populate the PlatformKeyboardEvent's m_text, m_unmodifiedText, and m_keyIdentifier fields. AFAICT, they guarantee one character per input event. The Mac doesn't. I can see doing a cap, though it doesn't thrill me. Avi -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Layout test expectations and fallbacks
V8 differences from JSCore are really the only area where some extra effort is needed. As Mark said, for the vast majority of tests we want to use the WebCore from webkit.org, not chromium-win. Yes, it sucks we have to put stuff in two places (chromium-win and chromium-mac) but I don't see any other way around it. Also, the test results should be more or less identical (at least they have been in the cases I've seen), so it really is just copying the same file to two places in the tree. The V8 differences are far far fewer in number than the general pixel results. What else would you propose? On Thu, Jan 29, 2009 at 10:53 AM, Dean McNamee de...@chromium.org wrote: I guess Mads's point here was that he works on V8, and when he wants to fix something for V8 (rebaseline), it's not clear to him where it should go. Should he copy it into all 3 places? The idea was maybe there should be a chromium-common (which is not chromium-win), where we can stick fallbacks where we know all platforms should match. It gets difficult to manage expectations across 3 platforms, especially when you think they should be the same. We've had that a lot now, someone stumbles over a broken test on Linux, and finds out that it was rebaselined on Windows already, etc. It's just confusing / a lot of work for someone like Mads's on the V8 team to know how to handle all 3 platforms differently... On Thu, Jan 29, 2009 at 4:50 PM, Thomas Van Lenten thoma...@chromium.org wrote: On Thu, Jan 29, 2009 at 10:44 AM, Dean McNamee de...@chromium.org wrote: On Thu, Jan 29, 2009 at 4:43 PM, Mark Mentovai m...@chromium.org wrote: On the Mac, I think we want to match Apple WebKit baselines. I don't know if there are any baselines currently in chromium-win that we should share. All of the V8 differences, for example. We copy those into chromium-mac as needed. But the majority of the expected files come down to fonts and the windows files wouldn't be of any use there. In the pixel dumps, again, font and controls pretty much make using the windows ones pointless. TVL Mark Dean wrote: I talked to Mads a bit, basically: 1) I think the Mac expected result fallback is currently wrong, it doesn't seem to look in chromium-win correctly. This is probably causing a lot of failures. 2) We should move chromium-win to chromium (or chromium-common), and then chromium-win should not be a fallback. This might be more confusing to manage, but it's also less confusing to understand that everything should / can fallback to the Windows expectations. On Thu, Jan 29, 2009 at 2:49 PM, Mads Sig Ager a...@chromium.org wrote: It seems that when running layout tests on linux, if there are no special expected results for linux in chromium-linux, we fallback to the special expected results for windows in chromium-win. This is not the case on mac if there are no results in chromium-mac, we take the expectations that are next to the test even if there are other expectations in chromium-win. Is that on purpose? A related question: what is the intention with our custom expected resulsts? If we need to change the expectation for all three platforms, should we only add the new expectations in chromium-win? That sounds confusing to me. Maybe we should have a chromium-common? Cheers,-- Mads -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Browser Bootstrapping Plan
We had a meeting last week to talk about how to get to a running multi-process browser by mid-Feb. I was asked to follow-up with a document where we could collaborate, and have done so: http://sites.google.com/a/chromium.org/dev/developers/browser-bootstrapping Let me know if you have any feedback. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: stubbing out code
What I started doing over in the browser side is minimizing the ifdefs with stub classes and functions. That way, the code is left mostly unchanged and compiles as-is except you also have a record, in a separate file called something like temp_browser_scaffolding.h, that lists every class that's been mocked this way. It's easy to see at a glance what still needs filling in because it's still in that file. The result has worked nicely, allowing browser_main() to compile with only a small handful of idefs. This may not work with other files bottom-up, it's clearly a top-down porting style. On Thu, Jan 15, 2009 at 9:01 PM, Evan Martin e...@chromium.org wrote: When you #ifdef around some code to make things temporarily link, but know that you'll need to bring that code (or its functional equivalent) back at some point, please mark those points carefully. I fear that we'll eventually have everything building and linking together at some point and it'll crash and there will be 30,000 #ifdef OS_WIN where 20 of them were temporary hacks. Here's the pattern I use: #if defined(OS_WIN) // code as before #else // TODO(port): explanation of what is wrong with the above NOTIMPLEMENTED(); // so you get a run time error message rather than mystery crash #endif -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: OSX 10.4 and PPC support?
The sandbox support isn't supported on 10.4. I know our linux brethren are still debating sandboxing for their release, but I don't think we'd want any Mac version to not have it. On Thu, Jan 15, 2009 at 6:42 PM, Dean McNamee de...@chromium.org wrote: On Fri, Jan 16, 2009 at 12:38 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: On Thu, Jan 15, 2009 at 3:26 PM, Amanda Walker ama...@chromium.org wrote: Also, on a related note, are there also any plans for supporting the PPC architecture in the future? Not currently. It would require, among other things, a PPC code generator for V8. While this is not impossible, it's enough work that it's not part of our current plans. Wouldn't it be possible to fall back to the other javascript engine on non-x86 platforms? No, not really. Long story short, we have completely different binding layers. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Rebaselinig a layout test
Just duplicating the relevant parts of the irc conversation: - Both Safari and Firefox on mac default to not tabbing through all elements. This is consistent with the rest of the OS. - Both have a pref for the users who do want that behavior (sorry, no numbers for how many change it). On Tue, Jan 13, 2009 at 5:53 PM, Amanda Walker awal...@google.com wrote: Generally speaking, on a Mac, only text fields are keyboard focusable. If we have to pick a single behavior without a pref, that should be it. Ideally, we should pick up the system-level accessibility prefs and/or an application-level pref. Unless a user has turned it on, hitting tab and not getting to the next editable text field will cause a WTF exception in most Mac users... --Amanda On Tue, Jan 13, 2009 at 5:44 PM, Ojan Vafai o...@chromium.org wrote: -chromium-reviews, +chromium-dev Yeah, I buy that. I think the default should be to tab through all focusable elements. With Safari, it's off by default, which I think means it tabs through form controls only, not really sure. In either case, I don't think that matchs web developer expecations very well. Ojan On Tue, Jan 13, 2009 at 2:36 PM, Mike Pinkerton pinker...@chromium.org wrote: It should, but probably only if the user has turned it on in the accessibility prefs. Otherwise it gets in the way. Safari has some extra user prefs for this. On Tue, Jan 13, 2009 at 4:49 PM, o...@chromium.org wrote: LGTM Amanda, Mike, CCing you here to get started a discussion on what tab/option+tab should do in our Mac port. Have you all made a decision as to whether it should iterate though all focusable elements? http://codereview.chromium.org/17399 -- Mike Pinkerton Mac Weenie pinker...@google.com -- --Amanda -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: building with shared libraries
Mozilla has this flexibility (for all platforms) and it's a very nice feature in their build system. I think ultimately we should aspire to do this on mac and windows too (hopefully when we're all unified on [insert newfangled build system here]). On Sun, Dec 28, 2008 at 11:47 AM, skana...@gmail.com skana...@gmail.com wrote: Just added 'SHARED=1': http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem On Dec 26, 6:24 am, Evan Martin e...@chromium.org wrote: I've checked in some changes that make it so you can build (on Linux) with shared libraries. This significantly reduces link times and overall build times at the cost of slower code and slower startup (i.e., you shouldn't use it for user-facing builds). == Background Chromium has historically built as one huge shared object (.dll/.so), which means the linker can make more intelligent decisions (like eliminating dead code across modules) at the cost of making link times significantly slower. For example, a debug build of test_shell on linux is currently 400+ megabytes (!) and part of the way scons builds involves copying that file once upon successful linking (!!). A shared-library version of test_shell produces a 232kb executable along with 26 .so files. In theory, if you don't touch code within one of the chrome submodules, then its .so doesn't need to be relinked. == How to use it $ normal_hammer_command_line SHARED=1 Source files used in libraries should compile to .os rather than .o (they're different outputs -- e.g. position-independent code with -fPIC). If you have .so files in Hammer/dbg/lib/ , it appears to always produce shared executables regardless of your SHARED setting (?). I need to investigate further why. You can rm Hammer/dbg/lib/*.so to stop that for now. == Link time numbers Editing one test_shell file, rebuilding: 46s. Null build after that: 40s. This implies that the compile+link+copy time of test_shell was 6 seconds and the other 40 is scons-related overhead (including stat()ing a bunch of files, etc.). For comparison, linking test_shell statically takes 124s on my laptop, with 42 second null build time. So it saves about 78 seconds to dynamically link, or it's roughly 13 times faster. (Note that above numbers are with the slow standard binutils linker, rather than gold, and with my slow laptop, so your times may vary.) == Grungy details The scons build scripts do most of the work, including setting RPATH on the resulting binary, so you don't need to mess with LD_LIBRARY_PATH. We now use ChromeLibrary (rather than ChromeStaticLibrary) for all build commands, and should also use it in the future. Stuff that always needs to be shared (i.e. plugins) can continue using ChromeSharedLibrary. == Fixing modules that are missing symbols when built shared The dynamic linker refuses to build shared libraries that are missing symbols. It turns out in our code since we have traditionally statically linked everything, we've been ok with missing symbols as long as those functions/data are never referenced. I had to make some changes to bring in or stub out missing bits of code; in a static build they should be eliminated by the linker as before. I expect the shared build to occasionally break in the future due to this difference. It might be worth making a builder for it, or just switching the Linux debug build to it. Another difference with shared code is dependency chains matter more. googleurl's unittest uses libbase, which officially depends on libevent despite the googleurl unittest not making use of libevent. So for a static build, it links fine, but for a dynamic build you'll get missing symbol errors when linking. The fix is to change anybody who uses libbase to pull in libevent as well (on platforms that use libevent). The proper way to do this is to modify using_base.scons to pull in libevent, and then change anyone who uses libbase to use using_base.scons instead of referring to base directly. Check out build/googleurl_unittests.scons and build/using_googleurl.scons for an example. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: webkit/port is moving into third_party/WebKit/WebCore
Awesome!
Now that so much of our code is in the webkit tree, is there a
(public) wiki page describing the steps necessary to make changes to
anything within third_party/WebKit/WebCore? i.e, does everything have
to go upstream, are there any circumstances when forking is allowed on
a vendor branch, when should DEPS be rolled in this new world, etc?
Seems like things have changed so quickly over the last few months (in
a good way), it might be helpful to lay out the current state of
things for everyone to re-baseline their knowledge.
On Wed, Dec 24, 2008 at 3:46 PM, Dimitri Glazkov dglaz...@google.com wrote:
As of Christmas Eve, we have:
webkit/port/bindings/{scripts,v8}
webkit/port/platform/image-decoders
webkit/port/platform/graphics/mac
webkit/port/DerivedSources.make
Merry Christmas and/or Festivus, everyone!
Oh, and I broke the build yesterday, and eroman fixed it. He da man.
:DG
On Tue, Dec 23, 2008 at 3:48 PM, Darin Fisher da...@chromium.org wrote:
For now, just operate the same as you would had these files still resided in
webkit/port. Just don't forget to roll DEPS :)
We'll eventually be updating the merge tracker
(http://build.chromium.org/merge) to indicate the set of files and diffs
that have yet to be upstreamed.
-Darin
On Tue, Dec 23, 2008 at 2:51 PM, Adam Barth aba...@chromium.org wrote:
I see. Can I make changes to them in third_party, or should I wait
for them to appear upstream?
Adam
On Tue, Dec 23, 2008 at 1:35 PM, Dimitri Glazkov dglaz...@google.com
wrote:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/
These haven't been yet upstreamed. We just started by moving them into
our vendor branch.
:DG
On Tue, Dec 23, 2008 at 1:31 PM, Adam Barth aba...@chromium.org wrote:
I'm confused. I need to fix a bug in ImageSourceSkia.cpp, but I can't
find it
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/graphics/
or
http://trac.webkit.org/browser/trunk/WebCore/platform/graphics
Where did it go?
Adam
On Mon, Dec 22, 2008 at 8:42 PM, Darin Fisher da...@chromium.org
wrote:
OK, much of webkit/port now lives in third_party/WebKit.
All that remains is:
webkit/port/bindings/{scripts,v8}
webkit/port/bridge/chromium
webkit/port/page/chromium
webkit/port/page/inspector
webkit/port/platform/image-decoders
webkit/port/platform/mac
webkit/port/platform/graphics/mac
webkit/port/DerivedSources.make
We should be able to finish moving most of the rest of these files
tomorrow.
-Darin
On Mon, Dec 22, 2008 at 11:48 AM, Mohamed Mansour
m0.interact...@gmail.com
wrote:
I guess I will stop till your done!
On Mon, Dec 22, 2008 at 2:42 PM, Darin Fisher da...@chromium.org
wrote:
FYI
Please expect conflicts if you are trying to make changes to
webkit/port.
-Darin
--
Mike Pinkerton
Mac Weenie
pinker...@google.com
--~--~-~--~~~---~--~~
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: run_webkit_tests changes
The mac test buildbot was broken twice in the last 12 hours because of changes that easily could have been identified by running the new lint tool. Please try to remember to do this before checking in. I don't think we want to make this a checkin hook, but if it keeps happening, we may need to. On Wed, Dec 10, 2008 at 2:17 PM, Ojan Vafai o...@chromium.org wrote: Firstly, there is now a lint option that will parse the test list for each platform (win/mac/linux) and each build target (debug/release). This way you can know that you at least got the syntax right. So, please consider running this when you make test list changes. It takes ~30 seconds on my machine and saves you from closing the tree. Also, if you feel moved to improve our tools a bit, add a pre-commit hook to gcl/git-cl to do this for us (please!). $ ./run_webkit_tests.sh --lint-test-files 081210 11:04:34 run_webkit_tests.py:142 INFO Found: 10244 tests 081210 11:04:59 run_webkit_tests.py:614 INFO SUCCESS -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Bookmark Added! GUI redesign ideas
On Wed, Dec 10, 2008 at 9:56 AM, Sverrir Á. Berg [EMAIL PROTECTED] wrote: Attached is yet another mock - this suggestion feels more like a dialog to me. Regarding Mike's comment on buttons vs links - I agree but in my mock its used for an advanced link (that would bring up the edit bookmark dialog) - which I find OK personally (since my guess is that this feature is not heavily used). Advanced or not this would be really weird on the Mac. Users don't expect links to open dialogs; they expect them to go to the web. Maybe on Windows it's more common, but certainly not so in Cocoa. -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Please announce via email when clobbers are required
Given that clobbers are sometimes a necessary and required part of our build process, we as a team need to do a better job communicating when they're required. IRC and the waterfall are one step, but for those that don't build on all platforms every day, a passing status message may go un-noticed. As a result, I'm asking folks to please send out an email to this list when a clobber is required. By the way, I forgot to mention that a change requiring a clobber was checked in yesterday (monday), so folks building on Windows will need to clobber in order to build. This has been a public service announcement :-) -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Please announce via email when clobbers are required
Mac did not need a clobber, nor does it generally. Windows certainly required a clobber. On Tue, Dec 9, 2008 at 12:55 PM, Evan Martin [EMAIL PROTECTED] wrote: Do we need to clobber Mac builds on these announcements? (The SCons build has only needed clobbering once so far.) On Tue, Dec 9, 2008 at 9:34 AM, Mike Pinkerton [EMAIL PROTECTED] wrote: Hey everyone! Given that clobbers are sometimes a necessary and required part of our build process, we as a team need to do a better job communicating when they're required. IRC and the waterfall are one step, but for those that don't build on all platforms every day, a passing status message may go un-noticed. As a result, I'm asking folks to please send out an email to this list when a clobber is required. Why is this a big deal? The way our build is configured (at least on windows), the solution doesn't stop building if it encounters errors. As a result, you can easily spend a full hour doing a depend build (that's how long it takes on my 3yrold PC, for example) on a tree that's not very old and at the end be left with nothing but an error somewhere in the build output. Sure, you still have to pitch the build and start over, but at least you didn't waste the hour to get to this point. When you're trying to build quickly to test on other platforms, the setback is annoying and wasteful of valuable developer time. Let me know if you can think of better ways to improve this communication for everyone's benefit. Thanks! -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] anyone started porting chrome_dll_main/browser_main/etc?
Hey folks. I just wanted to check that nobody in the porting effort was looking at the app infrastructure (chrome_dll_main, browser_main, renderer_main, etc) as I've started ripping bits of that apart. It's going to take several iterations, but I wanted to make sure I wasn't duplicating effort with someone out in the community. Let me know. -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Issues Assigned To Me show fixed bugs?
Unlike any other bug tracker I've worked with, the code bugtracker includes Fixed bugs in the issues assigned to me query by default. That makes it quite difficult to work with as it's not a realistic list of what I have to do. Do others find this weird? How do other people work with the bugtracker? Do you reassign bugs to nobody once you fix them, so they stay off your list? Do you have to create an advanced query excluding them? If so, shouldn't we have the default switched so we don't have to do this? Tools should work for us, not against us. Suggestions welcome. -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] common/ipc_* and renderer
Just wondering if anyone involved in the porting effort has started poking around common/ipc_* and the channel/message objects. I started looking into what it would take to build a real render process and very quickly hit a slew of Win32 dependencies in the IPC code that need some serious untangling. It also appears that the differences between the MessagePumps on Posix v. Win are going to spill over into these classes, and their uses upstream. One key example is IPC::Channel, a critical class in both the renderer and the browser, which subclasses MessageLoopForIO::IOHandler. IOHandler doesn't even exist for posix, so more significant thought is going to need to be applied to do the right thing for each platform. Is this already on someone's radar, or should we talk next week about a plan of attack? -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: OS X Sandboxing design
It's hard to say how much of the scheme-like language is supported.
There are some provided examples, but they all say things like this
is an example, don't try to use it. In addition, several modules of
the TrustedBSD code aren't present (Apple hand-rolled several of their
own) so it's not like we have access to the full power even if we do
manage to get under the hood and use something other than the default
profiles.
It's feels to me like Apple is intending developers to use (right now,
in Leopard) only the supported profiles in the API. We can talk to
them more if we need to go off the reservation, but let's see if we
can stick within that bound until we need it.
On Fri, Nov 21, 2008 at 6:56 PM, Adam Langley [EMAIL PROTECTED] wrote:
Definitely we would need a way to give more resources to the renderer
after the process has been locked down. In windows we also have the
fonts issue but we do a neat trick to get them working. That is to say
that we should try hard to use the most restrictive setting ('pure
computation').
There are some default profiles for the sandbox, but it's the
TrustedBSD code: basically there's a full Scheme like language for
defining exactly what the sandboxed process can do which is compiled
down to a bytecode. You should be able to craft any contours of
control with that.
AGL
--
Mike Pinkerton
Mac Weenie
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Chromium-dev group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTests results under Linux
Awesome work! Probably just some re-basing needed to get the
font/layout metrics correct for linux and you'll be right up where Mac
is!
On Tue, Nov 18, 2008 at 6:41 PM, Michael Moss [EMAIL PROTECTED] wrote:
(Note: Running the layout tests currently requires changelist 11455,
reapplying mmoss's revision 5567 which added lighthttpd binaries, and
commenting out some cygwin specific stuff in http_server.py,
specifically, the line env['PATH'] = '%s;%s' %
(PathFromBase('third_party', 'cygwin', 'bin'), env['PATH']). I'm
going to work on getting everything working out of trunk on an
unmodified build next.)
I think everything needed to run the tests is on trunk now.
Michael
--
Mike Pinkerton
Mac Weenie
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Chromium-dev group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] Current Mac layout test results
(Whoops, gmail loves sending things to chromium-dev no matter what i choose) After Pam's re-factoring of the expectation files (thank you Pam!!!), here's the current output: = Tests we want to pass (8432): 7020 test cases (83.3%) Passed 223 test cases (2.6%) Skipped 1124 test cases (13.3%) Text diff mismatch 751 test cases (8.9%) Simplified text diff mismatch 32 test cases (0.4%) Test timed out 15 test cases (0.2%) Test shell crashed 18 test cases (0.2%) No expected results found That's right, 83% passing! Most of the failures appear to be clipboard/pasteboard related or with our known bug of text fields not sizing correctly. We'll continue investigating. -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
