/). TestShell wouldn't be able to use that.
-Darin
On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee de...@chromium.org wrote:
I am pretty out of things these days, but will a DOM UI file://
listing work for test_shell?
On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote:
Right
I am pretty out of things these days, but will a DOM UI file://
listing work for test_shell?
On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote:
Right, that's the tricky part. You'd need to do something creative.
-Darin
On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine
Traceline is a good way to see how this happens. We generally name
all of the Chrome threads (base::Thread), but the system is allowed to
create threads of its own. Loads of APIs create threads, along with
the windows worker pool (which we make good use of to help reuse
threads). For example,
I will investigate this today.
On Thu, Sep 3, 2009 at 4:29 AM, James Hawkinsjhawk...@chromium.org wrote:
No, and it's only invoked during tab dragging.
On Wed, Sep 2, 2009 at 7:20 PM, Michael Nordmanmicha...@google.com wrote:
There's is nothing platform specific about r25099, since other
Ug, I can't reproduce this on my desktop. If I had to take a guess, I
would guess Brett's gfx::Font change.
TOT:
*RESULT warm: t=
[134.82,133.98,135.04,134.37,134.95,135.01,134.78,134.69,134.55,134.21,134.27,137.12,134.31,134.20,134.56,135.37,135.02,134.68,134.22,134.58,]
ms
r25120:
*RESULT
Looking at the graphs this would seem to make sense. All of the tests
except the one using 'typical_history' have regressed. That's because
Brett checked in the upgraded database for typical_history, but not
for the other themes. We should just upgrade those and check them in.
On Wed, Aug 26,
To answer the technical (non-political) part of this question.
Create a SkBitmap which backs to some pixels. Create a SkCanvas on
top of it. Call drawPaint or more directly drawColor.
On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber tha...@chromium.org wrote:
When I talked with Aaron, he said
On Wed, Aug 26, 2009 at 4:14 PM, Elliot Glaysher (Chromium)
e...@chromium.org wrote:
See what I do in GtkThemeProvider::LoadThemeBitmap:
SkBitmap* bitmap = new SkBitmap;
bitmap-setConfig(SkBitmap::kARGB__Config,
kToolbarImageWidth, kToolbarImageHeight);
Yes, this can be reformulated easier as
i * 257 = i * 256 + i
and i / 256 will always be zero for i 256. Anyway, I suppose it
doesn't matter. The question is what to do for mapping 16-bit back to
8-bit, when it wasn't necessarily originally produced from 8-bit. I
suppose that dividing by
interest from several parties in getting Chrome to
cross-compile onto linux/ARM. Let's make sure everyone is on the same
page so that we don't duplicate efforts.
I understand that Joel Stanley, Dean McNamee and Lei Zhang have
already been doing a lot of work towards that. There's a wiki page
input URLs.
On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote:
On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote:
This thread is massive. Having been the one who wrote the majority of
the Omnibox code on Linux, I can promise you that this debate has
already
sense for how people input URLs.
On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote:
On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote:
This thread is massive. Having been the one who wrote the majority of
the Omnibox code on Linux, I can promise you
Joel had some ideas about doing something like thing for power saving.
On Thu, Aug 20, 2009 at 12:51 PM, Adam Langley a...@chromium.org wrote:
On Thu, Aug 20, 2009 at 9:38 AM, n179911n179...@gmail.com wrote:
I don't want the renderer process to die. I just want it 'locked' so
that i can dump
On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour pi...@google.com wrote:
There's growing interest from several parties in getting Chrome to
cross-compile onto linux/ARM. Let's make sure everyone is on the same
page so that we don't duplicate efforts.
I understand that Joel Stanley, Dean
make sure everyone is on the same
page so that we don't duplicate efforts.
I understand that Joel Stanley, Dean McNamee and Lei Zhang have
already been doing a lot of work towards that. There's a wiki page
there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm
I've identified a few
Note: Firefox on OSX selects all on single click. So there isn't a
clear answer on OSX either.
On Fri, Aug 21, 2009 at 2:52 PM, Dean McNamee de...@chromium.org wrote:
On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock alenlpeac...@gmail.com wrote:
On Aug 21, 10:17 am, Dean McNamee de
On Fri, Aug 21, 2009 at 2:34 PM, Lei Zhang thes...@chromium.org wrote:
On Fri, Aug 21, 2009 at 2:25 PM, Dean McNameede...@chromium.org wrote:
On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour pi...@google.com wrote:
- Gyp uses pkg-config to find includes/lib dependencies, i.e. it's
going to
On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock alenlpeac...@gmail.com wrote:
On Aug 21, 10:17 am, Dean McNamee de...@chromium.org wrote:
The Omnibox widget code is already very involved, and I don't think it
is a good idea to add any more complexity or additional modes.
...but, wait a sec
On Fri, Aug 21, 2009 at 4:01 PM, Stuart Morgan
stuartmor...@chromium.org wrote:
On Fri, Aug 21, 2009 at 3:36 PM, Dean McNameede...@chromium.org wrote:
Note: Firefox on OSX selects all on single click. So there isn't a
clear answer on OSX either.
Firefox has historically tended to favor do
The v8 team did some amazing work this quarter building a working
64-bit port. After a handful of changes on the Chromium side, I've
had Chromium Linux building on 64-bit for the last few weeks. I
believe mmoss or tony is going to get a buildbot running, and working
on packaging.
You can
That is just a utility program, no?
On Thu, Aug 20, 2009 at 12:06 PM, Michael Moss mm...@chromium.org wrote:
Anybody working on 64-bit breakpad yet?
src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code
has not been ported to your platform yet
I guess worst case, I can turn
This thread is massive. Having been the one who wrote the majority of
the Omnibox code on Linux, I can promise you that this debate has
already happened about 15 times previously. I'm not sure there is any
more information here, we've already decided how we want things to
work.
On Thu, Aug 20,
we could go with like _nix or something, and consider OSX to not be
unix (which is kinda isn't). Really, in theory, we should have more
granular ifdefs ./configure style, but that is also really a pain in
my opinion.
On Wed, Aug 19, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote:
On
I kinda feel like this is one of those things you can try hard to
premeditate, but in the end you'll just have to deal with it being
ugly for a while and hope it eventually converges to something better.
Sort of a non-answer, but I'd be happy to see this running on a BSD
first, and then we can
Mads is working on something for this.
On Wed, Aug 12, 2009 at 12:58 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
It appears from looking at the worker code that if worker script enters into
an infinite loop, the associated worker thread/process will never exit. The
JavaScriptCore
Do we have numbers on how the 4 allocates compare on those tests (page
cycler, etc)?
On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote:
In an effort to make it easier to test debugging heaps and allocators, I
just landed a changelist which makes our allocators switchable at
I've never seen valgrind have problems with memory mapped files.
On Mon, Aug 3, 2009 at 1:14 AM, Brett Wilsonbre...@chromium.org wrote:
On Sat, Aug 1, 2009 at 4:34 PM, Dan Kegeld...@kegel.com wrote:
I suppose you could try running the hunspell test suite itself
under valgrind. Their README
Any idea on how much this increase the size of chrome.dll?
On Wed, Jul 22, 2009 at 9:51 PM, Nicolas Sylvainnsylv...@chromium.org wrote:
On Wed, Jul 22, 2009 at 11:47 AM, Greg Spencer gspen...@google.com wrote:
On Wed, Jul 22, 2009 at 11:27 AM, Nicolas Sylvain nsylv...@chromium.org
wrote:
-100 million to changelogs.
On Wed, Jul 22, 2009 at 8:28 AM, Anthony LaForgelafo...@google.com wrote:
It also strikes me that we'd have have trouble filtering out reverts using
the RELEASE_NOTE tag. Since the original change with the RELEASE_NOTE tag
and the reverted change would be in
I feel like people are using tabs as a replacement for a good history
system. At least in all current browser implementations, tabs are
running. Even if we can make the UI scale to 1000 tabs, the 500
flash instances that are likely running aren't really going to
perform. The making tab
was wrong. What they did
now is closer, but still wrong.
On Tue, Jul 14, 2009 at 8:22 PM, Peter Kastingpkast...@chromium.org wrote:
On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote:
We weren't spec compliant:
http://dev.w3.org/html5/spec/Overview.html
The lineTo(x
https://bugs.webkit.org/show_bug.cgi?id=27187
-- dean
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
We weren't spec compliant:
http://dev.w3.org/html5/spec/Overview.html
The lineTo(x, y) method must do nothing if the context has no subpaths.
On Tue, Jul 14, 2009 at 8:13 PM, Peter Kastingpkast...@chromium.org wrote:
On Tue, Jul 14, 2009 at 3:11 AM, Dean McNamee de...@chromium.org wrote
My point was the behavior before the patch was wrong. What they did
now is closer, but still wrong.
On Tue, Jul 14, 2009 at 8:22 PM, Peter Kastingpkast...@chromium.org wrote:
On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote:
We weren't spec compliant:
http://dev.w3
I got it.
Thanks
On Wed, Jul 8, 2009 at 12:49 AM, Thiago Farinathiago.far...@gmail.com wrote:
Lei can you review this patch for me?
http://codereview.chromium.org/155078
On Jul 6, 11:56 pm, Lei Zhang thes...@chromium.org wrote:
You didn't give enough context. It'll be more helpful if you
CXX /.../out/Debug/obj/webkit/glue/temporary_glue.o
In file included from ./base/timer.h:49,
from ./webkit/glue/resource_fetcher.h:19,
from ./webkit/glue/image_resource_fetcher.h:9,
from ./webkit/glue/webview_impl.h:16,
from
2009/7/6 Rosail Davis sitan2...@sina.com:
From the main waterfall, the experimental link takes to you the fyi one.
The fyi waterfall lists the bots that we run, but don't close the tree for.
The bots on main waterfall are critical bots, the bots on fyi waterfall are
not so importan, right?
I didn't either at first, and then Lei pointed out it's using
set/longjmp. Gnarly.
On Mon, Jul 6, 2009 at 4:26 PM, Evan Martine...@chromium.org wrote:
I don't understand this bug report. Where is the code path that
allocates memory but doesn't free it? You just wrote if error
happens in
If it detaches from the terminal this probably means you have
another instance of Chromium already running. We check the profile
lock on startup, and if there is already a running process holding
that lock, we message it to create a new window.
This might not be it, but it kinda sounds like it.
the following characters cannot appear in solution folder
names:
/ ? : \ *| # %
Let me know if you run into any more problems with this.
Also definitely let me know if someone thinks of something less ugly.
-BradN
On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote
On Tue, Jun 30, 2009 at 10:29 PM, n179911n179...@gmail.com wrote:
On Tue, Jun 30, 2009 at 12:31 PM, Adam Langleya...@chromium.org wrote:
On Tue, Jun 30, 2009 at 12:29 PM, n179911n179...@gmail.com wrote:
How does Chromium handling font loading?
Which platform?
MacOS X and Linux.
I don't
Patches are welcome. It looks like maybe in chrome.gyp, the debugger
target should also debug on chrome_strings ?
On Wed, Jul 1, 2009 at 12:50 PM, Ben Laurieb...@google.com wrote:
On Wed, Jul 1, 2009 at 11:11 AM, Ben Laurieb...@google.com wrote:
On Wed, Jul 1, 2009 at 8:22 AM, Ben Goodger
On Wed, Jul 1, 2009 at 2:21 PM, Dean McNameede...@chromium.org wrote:
Patches are welcome. It looks like maybe in chrome.gyp, the debugger
target should also debug on chrome_strings ?
Er, it should also _depend_ on. Anyway, the Makefiles are generated
from the gyp files. There could be a
I believe it's used for printing on Windows. The idea is to capture
the API call so the vector info can be turned into a WMF or GDI-style
command buffer or whatever for printing on Windows.
If you need the details Marc-Antoine would know.
On Wed, Jul 1, 2009 at 1:34 PM,
On Fri, Jun 26, 2009 at 11:24 AM, Non-Stickkevin.ra...@ntlworld.com wrote:
OK. Thanks for the information.
Before I proceed to build an independent installer, please can you
advise
whether or not there are any plans for Chrome to provide such a
mechanism
for automatic NPAPI Plugin
Yeah, this is great, thanks.
On Fri, Jun 26, 2009 at 5:28 PM, Evan Martine...@chromium.org wrote:
Thanks for writing this! I would personally use this feature
frequently. The code looks good too.
On Fri, Jun 26, 2009 at 4:35 AM, nakroyoav.zilberb...@gmail.com wrote:
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio
I just committed a change that converted our
I just took a look at what was happening on one of the Linux
buildbots. It looks like we completely clear the env and just
explicitly set a few things. We need to add LANG=en_US.UTF-8 to that
list of things. Any takers?
Thanks
On Thu, Jun 25, 2009 at 2:12 PM, Dean McNameede...@chromium.org
Have you tried running with --memory-model=high ?
2009/6/23 PhistucK phist...@gmail.com:
This explanation actually shows me the source of this serious jank (I hope I
am using the term in the right context) I am having all of the time.
I am getting back to Chrome after a few minutes of dealing
Last week I updated our DEPS to pull in a newer version of Skia. I
was stumped at a few cases where the checked in PNG looked completely
wrong, but yet it was passing on the buildbots. There was no way that
image could have been the output.
It just dawned on me today, but I haven't verified
This also broke building from the command line.
I usually never open Visual Studio as an IDE. I build on the command
line with something like:
devenv chrome\\chrome.sln /Build release /Project test_shell
It looks like project names like test_shell now have complicated names
like test_shell
Additionally it seems like I'm getting no parallelism. I checked my
visual studio settings and everything seems fine. Attached is a
screenshot of how my CPU usage has looked for the entire processing of
building test_shell (from chrome.sln).
-- dean
On Fri, Jun 19, 2009 at 12:10 PM, Dean
Skia is already enabled in Chrome. We are not using the GL backend (it's not
really finished). Thanks -- dean On Wed, Jun 17, 2009 at 1:43 PM,
mailandroid wrote: I was looking at the support of skia backend for
rendering (OpenGL/ OpenVG). How and where can we enable these backend in
skia for
You could answer a lot of these questions yourself, with a little bit
of digging or a Google search. I'll try to give you a boost though.
2009/6/15 sitan2...@sina.com:
I began to read chromium's source codes, and got caught in these trival
questions:
1. what's gfx? I always see that.
At least for me, I'm hitting an error with generate_stubs.py. Will
try to figure out the proper fix, in the mean time I fixed up the
paths manually and ran the following from my source root. I was able
to successfully build. This is for a debug build, replace Debug w/
Release for a release
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
Hey Nicolas,
Did these symbols ever get uploaded?
Thanks
On Sun, Jun 7, 2009 at 2:55 AM, yuhongyuhongbao_...@hotmail.com wrote:
SYMSRV:
http://build.chromium.org/buildbot/symsrv/chrome_exe.pdb/0C57BF1B1D3D48
49B3037D4FE9424CCC2/chrome_exe.pdb not found
DBGHELP: chrome - no symbols
Yeah, I just took a poke at this, it seems that
zygote
\ browser
\ renderer
\ renderer ...
Is there a design document or anything somewhere?
Also, did we get an measurements on tab startup performance, memory
sharing, etc?
On Tue, Jun 9, 2009 at 10:57 AM, Lei Zhangthes...@chromium.org
On Tue, May 26, 2009 at 10:54 PM, Evan Martine...@chromium.org wrote:
On Tue, May 26, 2009 at 1:06 PM, Adam Langley a...@chromium.org wrote:
But we've gone over this before? Zygotes disable ASLR, make debugging harder
etc. They might have some performance benefits, but I don't believe that
I'm really curious of why that would be. I realize the old code was a
bit buggy, but I wonder exactly where the startup improvement came in.
I think it would be pretty important to understand...
Any takers?
On Thu, Jun 4, 2009 at 1:34 AM, Nicolas Sylvainnsylv...@chromium.org wrote:
On Wed,
Seems there are some bugs relating to which files count. For example:
http://build.chromium.org/buildbot/coverage/linux-debug/17471/CHROMIUM/base/index.html
It counts files like wmi_util, which is Windows specific and not
compiled on Linux.
On Wed, Jun 3, 2009 at 9:12 PM, Paweł Hajdan
My spidey sense would guess that you set the breakpoint in the Browser
process, when V8 and WebKit run in the Renderer process.
Good luck
-- dean
2009/5/29 Lucius Fox lucius.fo...@gmail.com:
Thank you.
I tried your suggestion on XCode on MacOS. But it still does not break for me.
I set a
I just re-read your post and realized you were using test_shell, which
is single process. In that case, I am not sure what the problem is,
and have no experience with xcode.
Sorry, good luck
On Fri, May 29, 2009 at 11:06 AM, Dean McNameede...@chromium.org wrote:
My spidey sense would guess
Yes, this is legacy. You'll see that new code uses (at least should
use) a single trailing underscore:
cpu.h:#ifndef BASE_CPU_H_
cpu.h:#define BASE_CPU_H_
cpu.h:#endif // BASE_CPU_H_
It should be an easy mass replace, but it's not really more than an
ideological concern. We've just been
On Mon, May 4, 2009 at 12:15 AM, Darin Fisher da...@chromium.org wrote:
Painting is not the only issue. On Windows there are several ways in which
the thread responsible for a HWND can block waiting for the thread
responsible for a child HWND to respond. Are you sure there are no X calls
On Mon, May 4, 2009 at 5:48 PM, Darin Fisher da...@chromium.org wrote:
On Mon, May 4, 2009 at 1:08 AM, Dean McNamee de...@chromium.org wrote:
On Mon, May 4, 2009 at 12:15 AM, Darin Fisher da...@chromium.org wrote:
Painting is not the only issue. On Windows there are several ways in
which
If people need things moved to base, you can file a bug against me.
During this refactor, it would be nice to also have the opposite, a
clean dependencies on what uses views. For Linux we would like to
build without views. Right now there are dependencies from outside of
views/ to views/.
Looks like it's missing -ldl, but I haven't looked closely.
On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote:
hi there,
thanks for working on getting the shared lib of libraries! I was
pointed to this work by Evan Martin as well and he pointed me to this
/harfbuzz-tibetan.c
scons: building terminated because of errors.
On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote:
Looks like it's missing -ldl, but I haven't looked closely.
On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote:
hi there,
thanks for working
PM, Dean McNamee de...@chromium.org
wrote:
The obvious fix would be to add -ldl, but I don't see why libxml
should be using it...
From a quick peek at the code, I saw xmlmodules.c using dlerror /
etc
for dynamic module support. Since libxml is running sandboxed,
do we
really want dynamic
Not to make more things complicated, but shouldn't it be possible to
only use gconf if it's available, otherwise don't get the proxy
settings?
I am just worried that we are slowing sucking in the whole world into
our dependency list.
I guess we obviously need the headers for building, but at
On Fri, Apr 17, 2009 at 8:25 PM, Stephane Doyon sdo...@chromium.org wrote:
On Fri, 17 Apr 2009, Dean McNamee wrote:
Not to make more things complicated, but shouldn't it be possible to
only use gconf if it's available, otherwise don't get the proxy
settings?
I am just worried that we
Word on the street is that the ccflags are all wrong, and that release
builds aren't being built release properly.
On Thu, Apr 2, 2009 at 7:23 AM, Mark Mentovai m...@chromium.org wrote:
Awesome. This is seriously good news. Thanks!
Mark
Steven Knight wrote:
Linux builds have been
I can't actually get it to build (trying Release for now), I am
getting linker errors for X calls, we are probably not linking
correctly. I will debug it :\
On Thu, Apr 2, 2009 at 12:11 PM, Dean McNamee de...@chromium.org wrote:
Word on the street is that the ccflags are all wrong
On Thu, Apr 2, 2009 at 12:43 PM, Dean McNamee de...@chromium.org wrote:
-lX11 -lXrender -lXext (at least) was dropped in the switch to gyp. I
tried to understand how gyp worked or where these were coming from,
but no luck.
On Thu, Apr 2, 2009 at 12:35 PM, Dean McNamee de...@chromium.org wrote
-lX11 -lXrender -lXext (at least) was dropped in the switch to gyp. I
tried to understand how gyp worked or where these were coming from,
but no luck.
On Thu, Apr 2, 2009 at 12:35 PM, Dean McNamee de...@chromium.org wrote:
I can't actually get it to build (trying Release for now), I am
(this isn't just V8, all of chromium is built without optimization in
release). There are lots of other issues all over the place.
On Thu, Apr 2, 2009 at 1:14 PM, Dean McNamee de...@chromium.org wrote:
Notice the lack of -O2, etc. This also broke SYMBOLS= PROFILE=, COVERAGE=,
etc.
I am
...@gmail.com wrote:
And it seems to be built without debugging flags in debug mode.
At least, I can't single-step through code on Linux.
On Thu, Apr 2, 2009 at 4:18 AM, Dean McNamee de...@chromium.org wrote:
(this isn't just V8, all of chromium is built without optimization in
release
On Thu, Apr 2, 2009 at 7:48 PM, Mark Mentovai m...@chromium.org wrote:
Steven Knight wrote:
'official': {
'defines': ['OFFICIAL_BUILD'],
# Make sure units of code and data go in their own section,
# and then GC them in the linker to remove unreferenced data
Something important would be to understand the overhead for a shared
library (fpic, relocation, etc).
On Tue, Mar 24, 2009 at 7:45 PM, Thomas Van Lenten
thoma...@chromium.org wrote:
The Windows product builds a small executable that then loads the main
chromium dll, and hands off control to
It looks similar to:
http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/builds/2466/steps/purify%20test:%20unit/logs/stdio
Which is what caused hclam's patch to reverted previously.
On Wed, Mar 18, 2009 at 7:55 PM, Adam Langley a...@chromium.org wrote:
On Wed, Mar 18,
Usually when I create a new file, I just copy some old one, but then I
get the copyright date wrong, or forget to update the include guards.
I just fixed a lot of incorrect include guards in our code, which were
clearly mistakes from manually typing out the names. It could be much
easier, so
I had a discussion about Views with Scott. I think I am on the side
of the fence that porting views it not a good idea. One of the things
that came up is remote X, would it be possible to ever have good
remote X performance with the Views panting model? I wouldn't want to
paint ourselves into
On Sat, Mar 14, 2009 at 12:59 AM, Ben Goodger (Google) b...@chromium.org
wrote:
Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met
briefly earlier today to discuss Linux UI and Gtk.
What we agreed is that next week Elliot and I will spend some time
researching what it
level
window, but I think that's ok.
I wonder if the situation is at all similar on Mac.
On Fri, Mar 13, 2009 at 1:02 PM, Dean McNamee de...@chromium.org wrote:
Hey Darin,
I'm a bit familiar with this problem. From what I understand, the
window manager doesn't get a chance to handle popup
I would have to guess that if there was, it would be some window
message (WM_THEMECHANGED ?) sent to our top level window, and the
plumbing would be annoying for it.
On Mon, Mar 9, 2009 at 10:21 AM, Jeremy Moskovich jer...@chromium.org wrote:
(mailed to random people who I thought might know
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching the tree go red after it.
Appreciation from another time zone,
-- dean
On Thu, Mar 5,
. I don't know.
On Thu, Mar 5, 2009 at 5:34 PM, Dean McNamee de...@chromium.org wrote:
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching
be to not have sheriffs,
and to have a system that can handle itself.
Nicolas
On Thu, Mar 5, 2009 at 8:47 AM, Amanda Walker ama...@chromium.org wrote:
On Thu, Mar 5, 2009 at 11:41 AM, Dean McNamee de...@chromium.org wrote:
Maybe we need to limit the hours people are commit, if a sheriff isn't
On Thu, Mar 5, 2009 at 7:03 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote:
2009/3/5 Amanda Walker ama...@chromium.org
On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com
wrote:
everytime I do a checkin I do a sync and send it
to the try server, which really takes
I am working on Linux omnibox, and chasing a stupid crash into
temp_scaffolding_stubs.cc (TabContents).
Every method I looked at was just a copy and paste from
tab_contents.cc, without any modifications. Why? Why are we not just
using the code in tab_contents.cc ? There is just a massive
It's been red for a while:
[--] 15 tests from GKURL
[ RUN ] GKURL.SameGetters
[ OK ] GKURL.SameGetters (82 ms)
[ RUN ] GKURL.DifferentGetters
ASSERTION FAILED: isMainThread()
(/b/slave/linux/build/src/third_party/WebKit/WebCore/platform/text/TextEncodingRegistry.cpp:172
I realize our checkouts are big, but there is a ton of other stuff
besides NSS. I don't really see the point in trying to do this just
now, it's seems likely to break a bunch of other platforms and be a
bit of a mess. If you feel that it's that important, ok, don't break
anything :)
On Thu,
I don't understand why we need to import all of this code just so we
can build an .so.
Why don't we just take the .so's from the 32-bit package we're already
using, and stick them into our .deb? We can check them into svn if
don't want developers to have to have it, but that problem is already
When we spot cases like this, can't we fix the makefiles / build files
so that the dependencies are properly described?
On Thu, Feb 19, 2009 at 12:31 AM, Dimitri Glazkov dglaz...@google.com wrote:
As it turns out, the clobber applies to Mac and possibly Linux builds.
Basically, clobber all.
I've started working on a GTK omnibox widget. I'll let you know when
I have some more progress.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
I was just reminded of this thread. I'm not sure if it was
premeditated, but having the mime-types be a function
(NP_GetMIMEDescription) is actually important for a specific Linux
use-case. nspluginwrapper is a single plugin that proxies access to
other plugins (for example, 64bit - 32bit). It
I thought the js debugger was out of process (or trying to be)?
On Mon, Feb 16, 2009 at 1:29 PM, Marc-Antoine Ruel mar...@chromium.org wrote:
the js debugger
On Mon, Feb 16, 2009 at 5:53 AM, Dean McNamee de...@chromium.org wrote:
What for?
On Mon, Feb 16, 2009 at 12:18 AM, Erik Kay erik
I just spot checked one of these (size15) and the new image looks
better than the old. I can rebaseline these quick and I will TBR you.
On Sun, Feb 15, 2009 at 10:27 AM, Mark Larson (Google) m...@chromium.org
wrote:
I broke the following layout tests on Linux:
Regressions: Unexpected
worry about the case where GDK is not running on top of X :-)
It would probably take some considerable work to stop passing HWNDs / X
window IDs through the renderer on behalf of plugins.
-Darin
On Wed, Feb 11, 2009 at 6:51 AM, Dean McNamee de...@chromium.org wrote:
On Windows, pretty much
1 - 100 of 128 matches
Mail list logo