Not to beat a dead horse, but looking at these tables, it seems that
the decision to go one way or another can be made simply by looking at
the 3 bottom rows. However, I'm pretty sure you won't find any
existing messages that go over a few KBs. For any large data
transfer, we use shared memory
This happened to me over the last few days with building Webkit's
tree. It was driving me nuts, until I also saw it with Chrome. I
rebooted and then it magically worked. My guess is that it was cygwin's fault.
On Wed, Nov 26, 2008 at 12:08 PM, Mike Belshe [EMAIL PROTECTED] wrote:
Today my
:00 PM, John Abd-El-Malek [EMAIL PROTECTED] wrote:
(It's been suggested that I send this out to a large audience, so here you
go)
Most of the Rietveld problems that I see in the logs or that people
complain about has been with regards to either very large changelists
(i.e. 100 files
On Thu, Dec 11, 2008 at 1:03 AM, John Abd-El-Malek [EMAIL PROTECTED] wrote:
On Thu, Dec 11, 2008 at 12:07 AM, e. roman [EMAIL PROTECTED] wrote:
Glad to hear this.
However I just tried building some webkit-merge changelists and
rietveld continues to have problems.
(upload would succeed
. The script doesn't catch all style violations, but it
should cover enough to save reviewers tedious nitting.
On Tue, Dec 16, 2008 at 11:20 PM, Adam Barth aba...@chromium.org wrote:
Awesome! Thanks John. Trailing whitespace be gone!
On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek j
On Mon, Dec 15, 2008 at 4:58 PM, Nicolas Sylvain nsylv...@chromium.org wrote:
Hello,
As you all know, our tests are really flaky and are causing the tree to be
red too often.
I took a quick look at the test logs and compiled the stats about all the
flakyness.
UI TESTS:
In the last 7
On Tue, Jan 13, 2009 at 2:25 PM, Elliot Glaysher (Chromium)
e...@chromium.org wrote:
Background: For the last couple of months, there have been requests
from external contributors for a style linting tool. I've just finish
cleaning Google's cpplint.py up for public release.
cpplint.py
Just a heads up about a very small gcl change which allows a description to
be added on an upload. This doesn't work on the first upload (since that
uses the description). You might find this useful when uploading new
versions of a change, to let the reviewer know what changed.
gcl upload
in
the code base.
On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek j...@chromium.orgwrote:
It seems that the only reason this code is needed is to get the function
pointers for the internal plugin. Perhaps the PluginVersionInfo
InternalPluginInfo stuff could be taken out of the platform independent
,
NP_ShutdownFunc
np_shutdown);
This would be functionally equivalent to adding an entry to the
existing g_internal_plugins array, but would be run-time accessible from
elsewhere in the code base.
On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El
and only use for the dynamically registered internal
plugins.
On Tue, Jan 20, 2009 at 3:27 PM, John Abd-El-Malek j...@chromium.orgwrote:
Perhaps something like PluginList::AddExtraPluginPath can be added which
takes the parameters you mentioned. This should be easy to do, I'd be happy
On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin e...@chromium.org wrote:
I'd been sending this sort of stuff to Dean and John but maybe other
people will find it interesting.
Plugin loading works in two phases:
- at startup, we scan the plugin directories for metadata, like plugin
names and
One of my goals with the out of process worker code is it to make it easier
to have many different types of child processes. Perhaps it makes sense to
have the linux port do this stuff in a child process once that code is
ready.
On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher da...@chromium.org
I've gone through the code and removed all such occurrences. This
speeds up the build from 15 to 13 minutes (using /MP on quadcore with
SSD). It also means that editing that file only rebuilds 36 files
instead of 200.
There shouldn't be any reason to include that file from a header. The
reason
On Fri, Feb 6, 2009 at 10:54 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Thu, Feb 5, 2009 at 10:56 AM, John Abd-El-Malek j...@chromium.orgwrote:
One idea I've been thinking about is timing how long a clean build
takes, and tracking that just as we do with other performance tests
(CCing chrome-dev so that others who don't know can search for this later.
Using Erik's Huan's chromium emails so reply get sent to the list).
I submitted some refactoring and now I'm seeing the reliability and purify
tests are red, which I think is a false alarm due to callstacks changing.
, Feb 21, 2009 at 12:12 PM, John Abd-El-Malek j...@chromium.org
wrote:
(CCing chrome-dev so that others who don't know can search for this
later.
Using Erik's Huan's chromium emails so reply get sent to the list).
I submitted some refactoring and now I'm seeing the reliability and
purify
I was looking at the second top crasher in 2.0.166.1, and it turned out that
these users are running with --in-process-plugins. This turns off the
sandbox and runs plugins in the renderer process.
So far we've exposed all the internal command line switches to all users,
but I'm wondering if that
currently have an archive of debug builds, but we do have that for
Chromium release builds.
--Mark
On Mon, Mar 2, 2009 at 16:16, John Abd-El-Malek j...@chromium.org wrote:
I was looking at the second top crasher in 2.0.166.1, and it turned out
that these users are running with --in-process
wrote:
+1. We absolutely should do this.
-- Elliot
On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek j...@chromium.org
wrote:
I was looking at the second top crasher in 2.0.166.1, and it turned out
that
these users are running with --in-process-plugins. This turns off the
sandbox
Also, I don't feel that strongly regarding Chrome vs Chromium or Debug vs
Release. The only thing I'm strongly against is having this in Chrome
Release :)
On Mon, Mar 2, 2009 at 4:33 PM, John Abd-El-Malek j...@chromium.org wrote:
On Mon, Mar 2, 2009 at 4:31 PM, Erik Kay erik...@google.com
these flags in release builds when necessary.
On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek j...@chromium.org
wrote:
I was looking at the second top crasher in 2.0.166.1, and it turned out
that
these users are running with --in-process-plugins. This turns off the
sandbox and runs
The point I was trying to make was that this isn't just about crash dumps.
For example, engineering effort will have to be done to filter them out of
UMA statistics. Also, there are reentrancy issues with plugins as Darin
mentioned. We know of them, but haven't bothered spending time chasing
Just a heads up for others who find it annoying when svn st always shows the
vcproj.GOOGLE.username.user files. You can put *.user in the global-ignores
setting in svn's config file to avoid this.
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
On Thu, Mar 5, 2009 at 8:59 PM, eager_learner
vijay.sankar.ra...@gmail.comwrote:
Hello Plugin Gurus
The following link is very well written and I hope it still holds good
http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture
I have some followup
I'm guessing I'm not the only one who's irritated by it. Can we make it so
that only members can post to chromium-reviews? We can automatically
subscribe everyone who's sent a review in the last month or something.
What do people think?
--~--~-~--~~~---~--~~
Hi Vijay,
It sounds like reading up on NPAPI and how Windows applications paint is in
order :)
Here are some documents:
Here's the high level link about NPAPI on the Mozilla docs, links to samples
etc: https://developer.mozilla.org/en/Plugins
This is the reference for NPAPI:
The only place that calls it in the browser process is
BrowserAccessbilityManager, which I'm guessing isn't critical for the ports
(it's actually disabled by default on our shipping builds).
success = members-render_widget_host_-process()-channel()-
SendWithTimeout(msg,
One comment regarding synchronous IPC (I presume this is from the extension
process to the renderer\browser process): I agree that synchronous IPC is
slower, and better to be async when possible. However, if it's used for
APIs that aren't called frequently (100 calls/s, as opposed to thousands or
I think it'd be very helpful to just copy paste it here:
http://dev.chromium.org/developers/design-documents/plugin-architecture
On Thu, Mar 12, 2009 at 3:38 PM, Evan Martin e...@chromium.org wrote:
John graciously explained all this to me so I thought I'd write what I
know before I forget.
On Fri, Mar 20, 2009 at 10:23 AM, Jeremy Orlow jor...@google.com wrote:
Are there any plans (long term or short) to render stuff like iframes with
a different origin inside a different process? Does the story get more
complicated with plugs and extensions?
*More background:*
I'm looking at
On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow jor...@chromium.org wrote:
*If you don't care where various bits of the localStorage implementation
live and you aren't scared about letting stuff out of the sandbox, you can
stop reading now.*
*
*
Background:
For those who don't know the
2009/3/24 Thomas Van Lenten thoma...@chromium.org
A bunch of process handle code is something we're gonna need to look very
carefully at. The filtering via names may be valid on Windows, but on
Linux, a user could have Chromium running twice (with different
profiles/user data dirs) pointing
On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote:
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade est...@chromium.org wrote:
a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
the calls thread safe, but it does so by locking a process-wide mutex,
Does this also
include third_party\WebKit\WebKit\chromium\public\WebKitClient.h? I'm
guessing not, since none of those files are in the WebKit repository yet,
but just want to double check.
On Fri, May 1, 2009 at 8:35 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
We are very, very close to
You can file a bug at http://code.google.com/p/rietveld/issues/list, and cc
me.
On Mon, May 11, 2009 at 9:36 AM, Darin Fisher da...@chromium.org wrote:
In some cases, I suspect I may need to file the issue against upstream
Reitveld... any guidance?
Thanks,
-Darin
the javascript document.location does not correctly result in
a string. I probably need to dig in more. Does this exact sequence
work correctly for you?
Thanks for all your time btw!
Vijay
On Jun 8, 11:15 am, John Abd-El-Malek j...@chromium.org wrote:
Are you sure this is broken? Flash
On Wed, Jun 10, 2009 at 12:30 AM, Adam Barth aba...@chromium.org wrote:
I'm hesitant to say because I don't want Vijay to treat this as advice
on the right way to determine which page included his plug-in. The
approach of trying to read the document's location via JavaScript is
fundamentally
about:ipc is only implemented on Windows.
For Mac/Linux, you need to set the CHROME_IPC_LOGGING environment variable.
All the messages will be dumped to stderr.
On Wed, Jun 10, 2009 at 8:34 PM, Meryl Silverburgh
silverburgh.me...@gmail.com wrote:
Thank you. I try and successfully build
Just wanted to give a friendly warning, the same I gave to Nirnimesh, that
we don't want to do any extra processing in Rietveld. Otherwise it'll lead
to the 500s that people (don't) miss.
On Fri, Jun 12, 2009 at 12:40 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:
- chromium-dev
On Fri,
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this
Another missing dependency, in the runtime sense, is unit_tests
on test_chrome_plugin. Right now if you just compile that project from a
clean build, it'll crash.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote:
+1 this is affecting a lot of people.
On Thu, Jun 18
this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
I
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote:
Yeah it happened to me before as well, I just figured I'd complain now..
Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear
accelerated my work on it as we wind down to the last few targets.
--SK
On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.orgwrote:
Yeah it happened to me before as well, I just figured I'd
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part:
2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
On Thu, Jun 25, 2009 at 1:54 AM, Non-Stick kevin.ra...@ntlworld.com wrote:
OK. Thanks for that Matt. At least now I know I was using the wrong
mechanism.
So what is the recommended way to download and install an NPAPI Plugin
over the internet under Chrome ?
There's no way to make Chrome
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
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
There isn't a way to index data at the moment through the public API,
although I have seen hacks on the google group for app engine.
On Mon, Jul 6, 2009 at 7:54 PM, Marshall Greenblatt
magreenbl...@gmail.comwrote:
On Mon, Jul 6, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote
Just a heads up that you can now reply to code review emails and your reply
will show up on Rietveld.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
Note: this finds the Rietveld issue number by looking for the last
http://codereview.chromium.org/ url in the email. So make sure to leave
that url in the email, and if you add another url to a different issue,
don't put it at the end.
On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek j
Google tool) does it...
Maybe the chromium-revi...@googlegroups.com could be changed to
chromium-reviews+the review number@googlegroups.com and that could be
used instead?
On Wed, Jul 8, 2009 at 5:44 PM, John Abd-El-Malek j...@chromium.orgwrote:
Note: this finds the Rietveld issue number
On Fri, Jul 17, 2009 at 10:45 AM, Daniel Wagner-Hall dawag...@gmail.comwrote:
Hi,
Can anyone help me with this? How can I get the window handle of an
element from its JS DOM node?
DOM elements, with the exception of plugins and select controls, don't have
window handles because they're not
On Fri, Jul 17, 2009 at 12:06 PM, Daniel Wagner-Hall dawag...@gmail.comwrote:
I can happily get the plugin's window handle using standard NPAPI
calls, I'm trying to get the window handle of arbitrary tabs (and
indeed frames) which my extension has loaded
Specifically, I am opening pages, at
I have a leak after a check-in. I tried following the instructions on my
Linux box, but couldn't (I hardly develop on Linux).
jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh
tools/valgrind/chrome_tests.sh --generate_suppressions -t ui
Usage: chrome_tests.py -b dir -t test [-t test ...]
On Mon, Jul 20, 2009 at 7:31 PM, Thomas Van Lenten thoma...@chromium.orgwrote:
On Mon, Jul 20, 2009 at 10:04 PM, John Abd-El-Malek j...@chromium.orgwrote:
I have a leak after a check-in. I tried following the instructions on my
Linux box, but couldn't (I hardly develop on Linux
The plug-in sandbox is too weak to be robust, see the other thread about it.
As long as it has access to HWNDs, it's very easy to break out of it.
On Wed, Jul 29, 2009 at 10:43 AM, Adam Barth aba...@chromium.org wrote:
I wonder if we could use something like the plug-in sandbox for the
main
On Tue, Jul 28, 2009 at 8:40 PM, Jeremy Orlow jor...@chromium.org wrote:
I'm starting to think ahead to how quotas will work with LocalStorage (and
I assume database and maybe even AppCache). To begin with, I'll probably
just set a fixed quota (5mb is pretty standard), but some apps will
whoa, please revert this change. if I have a big changelist, now every time
I run gcl I have to expend effort to make sure no new files crept in. this
will lead to more build failures as people check in other files accidently.
On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.
Traceback (most recent call last):
File
Intentional but I have a TODO in the Chromium branch of Rietveld to update
this. I just synced ~60 changes from trunk to our branch, and now we get a
close button to the left of each issue. Since everyone with a @chromium
account could edit an issue, I thought it was too easy to accidentally
, 2009 at 3:14 PM, Mark Mentovai m...@chromium.org wrote:
John Abd-El-Malek wrote:
Intentional but I have a TODO in the Chromium branch of Rietveld to
update
this. I just synced ~60 changes from trunk to our branch, and now we get
a
close button to the left of each issue. Since everyone
On Mon, Aug 17, 2009 at 11:43 AM, bsmedberg bsmedb...@gmail.com wrote:
At Mozilla we're currently working on implementing multi-process
plugin hosts similar to the model used by Chromium. However, we're
having trouble working through the many potential race conditions
introduced by having
On Tue, Aug 18, 2009 at 5:37 AM, Evan Martin e...@chromium.org wrote:
On Sat, Aug 15, 2009 at 11:44 PM, Nico Webertha...@chromium.org wrote:
`git cl patch` reuses existing issues, so when landing stuff for other
people, I used to edit the issue on codereview to add Patch by
The information on how to do this is currently on the internal wiki,
although it seems there's no reason it shouldn't be moved to the public wiki
(not it :) ).
http://wiki.corp.google.com/twiki/bin/view/Main/ChromeDebuggingChromeBotCrashes
On Tue, Aug 18, 2009 at 3:42 PM, James Hawkins
Including files like render_messages.h and automation_messages.h from other
header files is unnecessary and slows down the build (adds about ~100K lines
of headers to each cc file). Last time I removed all these occurrences, it
improved the build time by 15%. Looks like a few more crept in now,
going to write a presubmit check for that.
On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote:
Including files like render_messages.h and automation_messages.h from
other header files is unnecessary and slows down the build (adds about ~100K
lines of headers to each cc
at once) it miight be faster.
That said, it would surprise me if this was adding more than a second or
two
to the time. I bet most of it is waiting on other servers and such.
On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek j...@chromium.org
wrote:
Great! Please try to add
and such.
This gives me an idea: I'll add the time it takes to run presubmit checks to
the output, so we can see how long it's taking.
On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek j...@chromium.orgwrote:
Great! Please try to add this to an existing check, or do it in a way
that doesn't involve
There's one ResourceDispatcherHost for all renderers (but there is one
ResourceMessageFilter per renderer process).
That graph shows a connection between the filter (ResourceMessageFilter) and
the ResourceDispatcherHost, but it's the former that has a pointer to the
latter. RDH doesn't have a
On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.org wrote:
On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote:
Thanks. But the picture in the document shows there is only 1
ResourceDispatcherHost and there are 2 Renderer Processes:
This is very cool work, it'll especially be useful for outside developers
who don't have our beefy machines :)
Would it be possible to get a sense of what percentage of chrome.dll is due
to our code (i.e. base, net, chrome) vs third party (i.e. everything in
\third_party including webkit)?
I think this is one of those things that aren't worth the effort. Brett's
change was also to fix other bugs, so it wasn't just for this. I'd be
surprised if people spend time to fix bugs solely for this.
On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman a...@google.com wrote:
I've heard people
On Wed, Aug 26, 2009 at 12:41 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson bre...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissmana...@google.com wrote:
I've heard people proclaim the principle of being able to copy a profile
On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel d...@kegel.com wrote:
On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlowjor...@chromium.org wrote:
I really like the idea of being able to move people between
operating systems and just bringing the profile along
without having to export and
On Thu, Aug 27, 2009 at 11:57 AM, hap 497 hap...@gmail.com wrote:
On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.orgwrote:
On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote:
Thanks
Can't we blacklist nspluginwrapper, and use the same logic that it uses to
find the real plugins?
On Fri, Aug 28, 2009 at 11:01 AM, Evan Martin e...@chromium.org wrote:
Right now our plugin loading code matches Firefox in the search path order.
1 $MOZ_PLUGIN_PATH
2 ~/.mozilla/plugins
3
On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess sh...@chromium.org wrote:
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote:
Well, that annoying throbber is still chewing up time, causing some
amount of UI loop contention while the images, thumbnails, and icons
are
On Mon, Aug 31, 2009 at 9:57 AM, John Abd-El-Malek j...@chromium.orgwrote:
On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess sh...@chromium.org wrote:
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote:
Well, that annoying throbber is still chewing up time, causing some
amount
These leaks have always existed in the unit tests. They don't happen in
Chrome builds since the posted tasks always get a chance to run on different
thread where they clean up. But in unit tests that doesn't (always) happen.
It's been low priority for me to look at because it's not a real leak,
.
Thanks.
On Thu, Sep 3, 2009 at 10:53 AM, John Abd-El-Malek j...@chromium.orgwrote:
These leaks have always existed in the unit tests. They don't happen in
Chrome builds since the posted tasks always get a chance to run on different
thread where they clean up. But in unit tests that doesn't
talking about when it is viewed in Rietveld?What about when it
is actually committed, can the change log be tweaked that way,
automatically, too?
That would be nice when reading change logs.
Thank you!
☆PhistucK
On Thu, Sep 10, 2009 at 05:01, John Abd-El-Malek j...@chromium.org wrote
For reference, something similar is done for popups:
void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled);
void NPN_PopPopupsEnabledState(NPP instance);
Perhaps we can do the same thing here:
void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled);
void NPN_Pop
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote:
On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.orgwrote:
I presume you're referring to Chrome extensions? I don't see the
advantage of making this depend on the plugin being distributed via
extensions
On Fri, Sep 11, 2009 at 4:01 PM, Mike Morearty m...@morearty.com wrote:
On Fri, Sep 11, 2009 at 3:54 PM, John Tamplin j...@google.com wrote:
On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek j...@chromium.orgwrote:
For reference, something similar is done for popups:
void
On Fri, Sep 11, 2009 at 4:32 PM, John Tamplin j...@google.com wrote:
On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek j...@chromium.orgwrote:
If this sounds good to you, the next step would be getting a broader
discussion with other browser vendors on the plugin-futures mailing list
Abd-El-Malek j...@chromium.orgwrote:
On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty m...@morearty.com wrote:
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote:
On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek
j...@chromium.orgwrote:
I presume you're referring
On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote:
I think we need to re-consider our practice of shipping beta/stable
browsers with experimental features hidden behind flags--at least when they
have any side-effects in JavaScript. An example of where this has bitten us
On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.orgwrote:
I think we need to re-consider our practice of shipping beta/stable
On Mon, Sep 21, 2009 at 3:59 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Sep 21, 2009 at 3:51 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek j
It only takes a few moments to figure out this information, and ensures that
the bug lands on the right person's desk.
http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the
initial test
For commits before we moved to the open source repository, look at
Agreed, we should have a --browser-startup-dialog that's added to
BrowserMain. ui_tests can then pass it and --renderer-startup-dialog,
plugin-startup-dialog, in-process-plugins, --single-process along if they're
specified.
On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote:
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.comwrote:
Today wasn't a happy day for p...@. He did a seemingly innocuous roll
that broke the world: selenium, ui tests, layout tests. I am sure it
was stressful and probably added unnecessary gray to his hair.
Stuff like
! Do we have a Python/gcl/rietveld expert
who can tackle this?
:DG
On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org
wrote:
I didn't know this was possible. It seems it will get a lot more usage
if
it just works, i.e. the try script grabs these settings automatically
are generates when in the
WebKit directory. Marc-Antoine knows this best, so I'm handing it off.
On Wed, Sep 23, 2009 at 10:13 AM, Dimitri Glazkov dglaz...@google.comwrote:
BTW, I trying to be snarky in my request. More like begging :)
:DG
On Wed, Sep 23, 2009 at 10:08 AM, John Abd-El-Malek j
Every time v8 team updates which branch is the one that's used in Chrome,
gclient sync fails on Windows. The error is below.
running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2'
At revision 3275.
Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966;
I built using the instructions on Windows 7 64 bit without installing
another cygwin.
On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote:
So it looks like I need to install Cygwin separately before I can
build Chrome? If so this should be added to the Windows build
instruction
(1.5.25-15), copying sh.exe
and bash.exe over to src\third_party\cygwin\bin.
So it may be a good idea to check in this Cygwin version.
On Oct 1, 2009 4:43pm, John Abd-El-Malek j...@chromium.org wrote:
I built using the instructions on Windows 7 64 bit without installing
another cygwin
1 - 100 of 158 matches
Mail list logo
