Actually... 3.0.190.4 is the current (Windows) developer channel build (my
About says so and I did not manually build or install any other Google
Chrome release).And the release notes were not updated for this patch (last
update - 2009-6-23, the version was apparently locked at 2009-6-24 -
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
The problem is security. NPAPI plug-ins can run arbitrary code on
your machine. If we made it easier to install NPAPI plug-ins than to
run EXEs, all the malware authors would flock to NPAPI just like
they've flocked to ActiveX in the past, which used to be (still is?)
easier to install
It looks like it had trouble writing to /tmp. I don't think there are
missing binaries, looks like a space/permission issue. Is there enough
space available?
2009/6/29 David Jones ds...@163.com
I reviewed my layout-tests' output, and found some errors like:
090629 14:28:30 __init__.py:1032
I have the same problem when running the layout tests from WinXP inside a
VMware image. My host machine is a Vista64 box. I haven't been able to
track down the problem, so I'm hopeful that someone else might also know the
fix :-)
-Darin
2009/6/30 John Abd-El-Malek j...@chromium.org
It looks
set CYGWIN=nontsec
?
2009/6/30 Darin Fisher da...@chromium.org:
I have the same problem when running the layout tests from WinXP inside a
VMware image. My host machine is a Vista64 box. I haven't been able to
track down the problem, so I'm hopeful that someone else might also know the
fix
Thanks for sending this out, I'm excited to see i18n happen for
extensions. Here are some thoughts:
* I think it makes sense to use a flat file for the message
definitions. They don't have any structure, they are just a list of
name/value pairs. Each line could just be of the form
In general, this is a bad plan. The translated strings are designed to be
used in a particular context, and while the words themselves might make
sense in multiple contexts in one language, the same wouldn't be true for
another. Encouraging people outside of the project to make the call
Hi,
How does Chromium handling font loading?
For example, the following css, each element has it own font, can you
please point me to the code where chromium loads up each font? And
then use each font's font matrix (with height/width of each
character) during layout?
h4 { font-family:
On Tue, Jun 30, 2009 at 12:29 PM, n179911n179...@gmail.com wrote:
How does Chromium handling font loading?
Which platform?
AGL
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or
I ran it, and got this (I've chosen to install gold - look for the errors):
if g++ -DHAVE_CONFIG_H -I. -I.././gold -I. -I.././gold
-I.././gold/../include -I.././gold/../elfcpp
-DLOCALEDIR=\/usr/local/gold/share/locale\
-DBINDIR=\/usr/local/gold/bin\
Hi cira,
Thank you for getting things going :-)
2009/6/30 Aaron Boodman a...@chromium.org
Thanks for sending this out, I'm excited to see i18n happen for
extensions. Here are some thoughts:
* I think it makes sense to use a flat file for the message
definitions. They don't have any
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.
Thank you.
AGL
--~--~-~--~~~---~--~~
On Tue, Jun 30, 2009 at 1:13 PM, Jungshik Shin (신정식,
申政湜)js...@chromium.org wrote:
I like this way of avoiding having to ALL_ALL. On the other hand, stowing
away all the resource files somewhere below root might be a good idea ?
Maybe not because existing extensions have them in the root and
This page seems to list this property as supported in Safari, but not IE or
Firefox:http://aptana.com/reference/html/api/HTML.field.pluginspage.html
I'm not sure what relevance that page is ...
* Who published the page ?
* How old is the information contained in it ?
* What is the
That's good news then. And it sounds like you've used it in IE as well?
-Nick
On Tue, Jun 30, 2009 at 2:44 PM, Non-Stick kevin.ra...@ntlworld.com wrote:
This page seems to list this property as supported in Safari, but not IE
or
Can you create a test page that works differently in Firefox and
Chrome? If so, that's a strong argument that we should change our
behavior to match Firefox.
Yes, I have been using such pages for the past 2 weeks in an endeavour
to get my NPAPI Plugin to download over the internet under
Currently chromium compiles and uses its own libjpeg. There is a
typedef type boolean which defaults to unsigned char. On linux we've
run into a problem with this because GTK is also compiled against
libjpeg, but expects boolean to be int. GTK ends up using our libjpeg,
and that causes problems.
On Tue, Jun 30, 2009 at 3:07 PM, Evan Stadeest...@chromium.org wrote:
Currently chromium compiles and uses its own libjpeg. There is a
typedef type boolean which defaults to unsigned char. On linux we've
run into a problem with this because GTK is also compiled against
libjpeg, but expects
On Tue, Jun 30, 2009 at 3:09 PM, Evan Martine...@chromium.org wrote:
a) using the system libjpeg (at least on linux, if not the other
platforms as well)
Distros want this too. The reasons *not* to do this are:
1) We'd be at the mercy of distros with respect to image decoder bugs.
And it sounds like you've used it in IE as well?
No.
For IE, I use the HTML OBJECT tag and the codebase property, to load
an ActiveX control equivalent of my NPAPI Plugin.
For Firefox (and hopefully Chrome at some point), I use the HTML EMBED
tag and the pluginspage property, to load my NPAPI
Chrome and Safari don't support the pluginspage attribute. The best way to
get this small feature request on our radar is to file a bug.
On Tue, Jun 30, 2009 at 3:04 PM, Non-Stick kevin.ra...@ntlworld.com wrote:
Can you create a test page that works differently in Firefox and
Chrome? If
b) compiling our libjpeg with boolean = int (at least on linux)
This seems the simplest to me. It's not like we're saving 3 bytes of
memory using a char instead of an int for these booleans -- they're
likely passed around in 4-byte registers and 4-byte unpacked structs
anyway.
But I'm
2009/6/30 Aaron Boodman a...@chromium.org
Thanks for sending this out, I'm excited to see i18n happen for
extensions. Here are some thoughts:
* I think it makes sense to use a flat file for the message
definitions. They don't have any structure, they are just a list of
name/value pairs.
On Tue, Jun 30, 2009 at 3:23 PM, Evan Stadeest...@chromium.org wrote:
d) somehow use the system libjpeg for gtk, and our libjpeg for chrome
e) rename all symbols in our version of libjpeg, like was done in
libpng (see third_party/libpng/pngusr.h)
And this one seems the safest to me.
I
On Tue, Jun 30, 2009 at 3:24 PM, Nebojša Ćirićc...@chromium.org wrote:
2009/6/30 Aaron Boodman a...@chromium.org
Thanks for sending this out, I'm excited to see i18n happen for
extensions. Here are some thoughts:
* I think it makes sense to use a flat file for the message
definitions. They
Ok, on second thought, I guess JSON is more consistent. If we want to
allow ourselves extensibility in the future, we need to have an
nesting level in the format. So it can't just be, eg,
{
greeting: hallo!,
exit: goodbye
}
It needs to be:
{
strings: {
greeting: hallo!,
On Tue, Jun 30, 2009 at 4:58 PM, Nebojša Ćirićc...@chromium.org wrote:
* This document should propose a specific JavaScript API for
programmatically resolving messages.
What do you thing about having a getMsg(key, optional_namespace) function
for JavaScript API (similar to gadgets api)?
So
28 matches
Mail list logo
