Yeah, the loader lock is held the entire time while in the DLL main. The
lock allows re-entrance, but if you do anything that starts another thread
and then tries to dynamically load a DLL you'll get a deadlock.
Unfortunately, it's very hard to predict what will cause a dynamic load (or
one of
That OleInitialize/Uninitialize business is there to prevent
unbalanced Ole init calls in some cases.
I did not realize DllMain was called with the loader lock held. Looks
like it could cause deadlocks.
I'll make move that code to a separate function invoked before the DLL
is unloaded .
Jay
On
Ah, that sounds great. Thanks!-Darin
On Mon, Sep 28, 2009 at 11:30 PM, Jay Campan jcam...@chromium.org wrote:
That OleInitialize/Uninitialize business is there to prevent
unbalanced Ole init calls in some cases.
I did not realize DllMain was called with the loader lock held. Looks
like it
Thanks for everyone's comments. I'm replying to Nick's message since
he had them rather collected and enumerated.
UI: I prefer the infobar, as per the arguments above. I don't think this
will happen frequently enough to be annoying.
This seems to be the consensus.
UI: Should there be user
Automatically closing tree for compile on Webkit Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Builder%20%28dbg%29/builds/16861
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Builder%20%28dbg%29
--= Automatically closing tree for compile
src.chromium.org is down for a few minutes... while we try to fix the disk
error.
Sorry for the inconvenience,
Nicolas
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
The server has been stable enough in the last 20 minutes, so I think it is
fixed now.
If you have problems with the server today, please let me know.
Thanks
Nicolas
On Tue, Sep 29, 2009 at 7:45 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
src.chromium.org is down for a few minutes...
I'd like to suggest early on that it's done in HTML for the usual
reasons. (And also that there are the usual negatives. Just wanna
plant the seed.)
In particular, a meta-page page would allow the typical operations on
subresource links (click to view; media playing would work in-browser;
Good point on HTML. Why not instead make DevTools
better/faster/do-what-you-want-them-to-do?
:DG
On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin e...@chromium.org wrote:
I'd like to suggest early on that it's done in HTML for the usual
reasons. (And also that there are the usual negatives.
Automatically closing tree for check deps on Chromium XP
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/7643
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP
--= Automatically closing tree for check deps on Chromium XP =--
Revision:
Depends if we want it to feel webby or dialoggy. Unsure yet. Good case
for either way. Will keep it in mind.
-Ben
On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin e...@chromium.org wrote:
I'd like to suggest early on that it's done in HTML for the usual
reasons. (And also that there are the
This is a (read-only) client that synced without problems 4 days ago. Today
gclient sync failed with:
running '/usr/bin/python src/build/gyp_chromium' in
'/home/nebojsa/chromium'
Updating projects from gyp files...
Traceback (most recent call last):
File src/build/gyp_chromium, line
Did you get any errors in the gclient sync? There is an entry for that dir
within the DEPs file.
TVL
On Tue, Sep 29, 2009 at 12:52 PM, Nebojša Ćirić c...@chromium.org wrote:
This is a (read-only) client that synced without problems 4 days ago. Today
gclient sync failed with:
A big V8/DOM memory leak I was chasing down turns out to be not a real
leak, it's just that it takes five full GCs after closing a document
for its resources to be freed. I'd been getting bored after two GCs,
so it wasn't till Ivan mentioned the stickiness of the generated-
function caches
+ CC Scott and Evan, to maintain a good story cross-platform. Any
suggestions for a keyboard model here?
I'd really like to stay away from the long, complex keyboard combos, also
because noone will ever discover that they are there...
- Jonas
On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour
On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour m...@chromium.org wrote:
CTRL+SHIFT+T --- Main Toolbar
CTRL+SHIFT+B --- Main Bookmarks bar
CTRL+SHIFT+E --- Extension bar
I really don't like this. These are hard to discover and use. Besides, you
can't use two of these three: ctrl-shift-t
I find our accessibility story a bit confusing since we don't allow
most of the browser UI to be focused. That is, pressing tab in the
URL bar doesn't do what tab normally does. I guess there's some other
key that puts the browser into accessible mode? In that case, I would
want to reuse that
On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting pkast...@google.com wrote:
On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour m...@chromium.org wrote:
CTRL+SHIFT+T --- Main Toolbar
CTRL+SHIFT+B --- Main Bookmarks bar
CTRL+SHIFT+E --- Extension bar
I really don't like this. These are hard
Indeed. We need to be very careful not to over-use keyboard shortcuts.
We will regret it later if we do.
-Ben
On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet s...@chromium.org wrote:
On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting pkast...@google.com wrote:
On Mon, Sep 28, 2009 at 10:51 PM,
FWIW, on OS X there's a system setting for Tab cycles through
everything or just important things in sysprefs-accessibility (I
think. Not at my mac right now).
On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet s...@chromium.org wrote:
On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting
On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet s...@chromium.org wrote:
On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting pkast...@google.com
wrote: It seems like when these bars are open, their contents should be in
the tab
order. You should be able to tab through the contents of a page,
The only error I get when invoking gclient sync is one I already posted.
I've tried updating depot_tools but it's already at the latest revision.
On Tue, Sep 29, 2009 at 9:56 AM, Thomas Van Lenten thoma...@chromium.orgwrote:
Did you get any errors in the gclient sync? There is an entry for
On Sep 29, 2009, at 10:31 AM, Anton Muhin wrote:
This 5 number looks really odd. Do you have a simple way to reproduce
it? I'd love to have a look.
Ivan suggested to me that it might take five to ten GCs; he said
something about cached generated (JITted?) functions that have a
context
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
Jens, thanks a lot, I'd have a look (most probably tomorrow). If
anyone would learn something new about this, please, let me know.
yours,
anton.
On Tue, Sep 29, 2009 at 9:48 PM, Jens Alfke s...@google.com wrote:
On Sep 29, 2009, at 10:31 AM, Anton Muhin wrote:
This 5 number looks really
On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman y...@chromium.org wrote:
1. An internal webkit chromium port try bot: Will help test webkit-only
patches. At first stage, it will test build failures (saving many of us the
need to manually test on 3 platforms), but later will also conduct
Hi,
As some of you probably noticed, fundamental changes are underway in how we
build and integrate webkit into chromium. Here is a status update and some
answers for frequently asked questions:
*Recent changes:*
1. Chromium now builds using gyp files living on the webkit.org tree
(WebCore.gyp
I'm trying to follow these suggestions, but I'm getting a ton of errors when
trying to do a gclient sync when third_party/WebKit is a clone of
git.webkit.org.
For example:
svn: '/Users/atwilson/chrome.git/src/third_party/WebKit/WebKitLibraries' is
not a working copy
Error: Can't update/checkout
Still the same message (after gclient sync --force).
On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai m...@chromium.org wrote:
gclient may have gotten confused in a previous run. Try gclient sync
--force and let us know if you still have a problem with that.
Mark
FWIW, on my (healthy) client, svn info inside of the native_client dir
looks like:
ncarter /cygdrive/d/src/crgit/src/native_client/src
$ svn info
Path: .
URL: http://nativeclient.googlecode.com/svn/trunk/src/native_client/src
Repository Root: http://nativeclient.googlecode.com/svn
Repository
You've hit the laziness landmine :) The instructions on
http://code.google.com/p/chromium/wiki/UsingWebKitGit go like this:
1) see how to change your .gclient on
http://dev.chromium.org/developers/contributing-to-webkit (that is,
add the big custom_deps hunk)
2) then change first line to Webkit:
Hi Nick, As Chris said, src/native_client is missing from the trunk (and I
don't have it in my client).
Cira
On Tue, Sep 29, 2009 at 12:28 PM, Nick Carter n...@chromium.org wrote:
FWIW, on my (healthy) client, svn info inside of the native_client dir
looks like:
ncarter
It's not in src.chromium.org, it comes in via DEPS:
src/native_client:
http://nativeclient.googlecode.com/svn/trunk/src/native_cli...@797;,
TVL
On Tue, Sep 29, 2009 at 3:32 PM, Nebojša Ćirić c...@chromium.org wrote:
Hi Nick, As Chris said, src/native_client is missing from the trunk
That was it. Removing the line from .gclient makes gclient work again (and
it sinks a lot of native_client code).
Cira
On Tue, Sep 29, 2009 at 12:45 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
you need to edit your .gclient and remove the line that says:
src/native_client:
None
Is
you need to edit your .gclient and remove the line that says:
src/native_client:
None
Is native_client really required? Why? We don't want to build this by
default, do we?
it's too big and it does not fit in the tarball, so it has been excluded
there.
Nicolas
On Tue, Sep 29, 2009 at 12:40
On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel esei...@chromium.org wrote:
On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman y...@chromium.org
wrote:
1. An internal webkit chromium port try bot: Will help test webkit-only
patches. At first stage, it will test build failures (saving many of
Evan, now that we have .gyp files living in the third_party/WebKit,
sync-webkit-git.py
will need to run the gyp_chromium or gclient runhooks --force when its done
updating webkit.
On Tue, Sep 29, 2009 at 12:31 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
You've hit the laziness landmine :)
Q. Does this mean you can build a libwebkit.so independently of Chrome?
On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman y...@chromium.org wrote:
Hi,
As some of you probably noticed, fundamental changes are underway in how we
build and integrate webkit into chromium. Here is a status update
The idea is that nacl will be baked in, and eventually be active by
default.They've
pared things down a good bit already. How far out of the ballpark is this on
size?
-BradN
On Tue, Sep 29, 2009 at 12:45 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
you need to edit your .gclient and
We could also make the tarball script remove the None dep at the end so on a
sync the person gets the bits?
TVL
On Tue, Sep 29, 2009 at 4:02 PM, Bradley Nelson bradnel...@google.comwrote:
The idea is that nacl will be baked in, and eventually be active by
default.They've pared things down a
On Tue, Sep 29, 2009 at 12:52 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel esei...@chromium.orgwrote:
On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman y...@chromium.org
wrote:
1. An internal webkit chromium port try bot: Will help test
+Dimitri, who is doing that and didn't put Jeremy in the loop.
On Tue, Sep 29, 2009 at 4:06 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Sep 29, 2009 at 12:52 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel esei...@chromium.org
wrote:
On
It might be better to ask this on v8-dev.
Erik
On Tue, Sep 29, 2009 at 10:07 AM, Jens Alfke s...@google.com wrote:
A big V8/DOM memory leak I was chasing down turns out to be not a real leak,
it's just that it takes five full GCs after closing a document for its
resources to be freed. I'd
That is one of the goals of creating and upstreaming the WebKit API.
On Tue, Sep 29, 2009 at 1:01 PM, Evan Martin e...@chromium.org wrote:
Q. Does this mean you can build a libwebkit.so independently of Chrome?
On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman y...@chromium.org
wrote:
Hi,
Q: When I change src/DEPS, do I also have to change upstream
third_party/WebKit/WebKit/chromium/DEPS?
A: It depends why you update src/DEPS. Theoretically, you should only
update
the upstream DEPS if the fix to the dependency actually changes the way
webkit interacts with it, or fixes a
Honestly -- haven't been actually doing anything in the past 3 weeks.
Still an AI to write up a proposal :)
:DG
On Tue, Sep 29, 2009 at 1:08 PM, Marc-Antoine Ruel mar...@chromium.org wrote:
+Dimitri, who is doing that and didn't put Jeremy in the loop.
On Tue, Sep 29, 2009 at 4:06 PM, Jeremy
Automatically closing tree for compile on Chromium Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/11187
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29
--= Automatically closing tree for
On Tue, Sep 29, 2009 at 1:12 PM, David Levin le...@google.com wrote:
Q: When I change src/DEPS, do I also have to change upstream
third_party/WebKit/WebKit/chromium/DEPS?
A: It depends why you update src/DEPS. Theoretically, you should only
update
the upstream DEPS if the fix to the
Automatically closing tree for compile on Linux Builder (ChromeOS)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3726
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29
--= Automatically closing tree
I figure this question is most suited for the Green Tree folks.
Ojan told me today that he had a patch to fix one of my pet peeve bugs in
WebKit, but he hadn't committed it because it would affect the results of
the Windows layout tests and he didn't have an easy way to test and
rebaseline them.
If I understand correctly, you're asking for a webkit try server? And
in particular a apple windows builder/tester.
M-A
On Tue, Sep 29, 2009 at 6:18 PM, Peter Kasting pkast...@google.com wrote:
I figure this question is most suited for the Green Tree folks.
Ojan told me today that he had a
Thanks for the response, comments inline.
On Tue, Sep 29, 2009 at 12:44 AM, brg b...@chromium.org wrote:
Thanks for everyone's comments. I'm replying to Nick's message since
he had them rather collected and enumerated.
UI: I prefer the infobar, as per the arguments above. I don't think
On Tue, Sep 29, 2009 at 3:35 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:
If I understand correctly, you're asking for a webkit try server? And
in particular a apple windows builder/tester.
I think so, something that builds the Apple Windows port and runs its layout
tests. Or else
I don't think it'd be very hard, I didn't know this was a wanted feature.
M-A
On Tue, Sep 29, 2009 at 6:47 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Sep 29, 2009 at 3:35 PM, Marc-Antoine Ruel mar...@chromium.org
wrote:
If I understand correctly, you're asking for a webkit try
WebKit has talked about try servers for a very long time. But none
have been made.
https://bugs.webkit.org/show_bug.cgi?id=29062
is the most recent discussion about this that I remember.
Mark Rowe mr...@apple runs build.webkit.org to my knowledge.
-eric
On Tue, Sep 29, 2009 at 3:50 PM,
This would be a VERY VERY VERY useful feature. Especially if we wanted to
open try server access up to other WebKit committers. Many Apple engineers
also have difficult testing their patches against Windows and simply commit,
watch the WebKit build bots, and iterate.
For that matter, having mac
What kind of accelerators do would you like to have? Maybe have
a accelerator that traverses only toolbars, and once we are in that toolbar,
we can tab through the widgets.
-Mohamed
On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Sep 29, 2009 at 10:25 AM,
I added a section to the LinuxFasterBuilds wiki on another trick for
faster builds.
This reportedly makes linking and starting gdb about twice as fast,
but only works if you're not debugging WebKit.
http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Build_WebKit_without_debug_symbols
Peter is giving excellent comments, and he raised an important question
regarding what makes me decide what gets blocked. I have some questions to
ask the group and others who are interested.
What would you want Kiosk to block? I am currently trying to block the
following areas:
- Save page
On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote:
I'm guessing different people/companies will have different needs for a
kiosk mode.
Maybe all of these should be separate flags rather than one kiosk flag?
We could then offer recommendations in a Chromium for kiosks
I would just use the existing accelerator we have to focus the toolbar.
-Scott
On Tue, Sep 29, 2009 at 3:58 PM, Mohamed Mansour m...@chromium.org wrote:
What kind of accelerators do would you like to have? Maybe have
a accelerator that traverses only toolbars, and once we are in that
On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson bre...@chromium.org wrote:
On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote:
I'm guessing different people/companies will have different needs for a
kiosk mode.
Maybe all of these should be separate flags rather than one
On Tue, Sep 29, 2009 at 4:37 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson bre...@chromium.org wrote:
On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote:
I'm guessing different people/companies will have different needs for a
On Tue, Sep 29, 2009 at 04:37:46PM -0700, Jeremy Orlow wrote:
On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson bre...@chromium.org wrote:
On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote:
I'm guessing different people/companies will have different needs for a
kiosk
What about the override approach that I mentioned?
Have the dependency listed in webkit alone. If you need to roll the deps
before rolling webkit, add a line in the chromium deps that overrides the
one from webkit.
On Tue, Sep 29, 2009 at 3:00 PM, Darin Fisher da...@chromium.org wrote:
On Tue,
hahaha
Scons Tricks
Avoid Scons entirely
-- Evan Stade
On Tue, Sep 29, 2009 at 4:03 PM, Evan Martin e...@chromium.org wrote:
I added a section to the LinuxFasterBuilds wiki on another trick for
faster builds.
This reportedly makes linking and starting gdb about twice as fast,
but only
On Tue, Sep 29, 2009 at 4:55 PM, Evan Stade est...@chromium.org wrote:
Scons Tricks
Avoid Scons entirely
Make build still isn't reliable enough to stick on a buildbot. :(
But now that gyp has a test suite progress is rapid!
--~--~-~--~~~---~--~~
Chromium
I think I'm right to say that a lot of the knobs stated by Mohamed
can be achieved with content script. Everything that can be done with
javascript for this particular use case should be done as javascript.
For example, destroying the window.print prototype.
I think you try to block to many
What would differentiate which toolbar is currently focused? Would it be
ideal to assume the first widget in that toolbar would be focused
(hotkeyed), or we would draw some sort of ring around the whole toolbar?
-Mohamed
On Tue, Sep 29, 2009 at 8:03 PM, Jonas Klink (Google)
Building on what we already have sounds good to me.
-Ben
On Tue, Sep 29, 2009 at 5:03 PM, Jonas Klink (Google)
kl...@chromium.org wrote:
So, to clarify, we would then use ALT+SHIFT+T (currently focusing the
toolbar), to cycle keyboard focus through any open toolbars
(toolbar-bookmark
How about in kiosk mode, we only hide the status bubble, control the
command dispatchers, and we leave the context menu as it is. That will solve
most of the issues and not complicate things.
Windows defined it pretty simple, http://support.microsoft.com/kb/154780,
they can open new windows,
From an accessibility point-of-view, I'd prefer having the first widget in
each toolbar focused when the toolbar itself gains focus (including
hottracked and displaying any tooltip that is displayed on mouseover of this
widget).
On Tue, Sep 29, 2009 at 5:28 PM, Mohamed Mansour m...@chromium.org
That's basically what we had before.
You can add entries to a DEPS file that have the value From(foo), and that
causes the value of the entry to be taken from the path foo/DEPS, where foo
is a directory at the same level as the directory containing the DEPS file
that mentioned From(foo).
That seems optional to me. I don't see why it matters that much. The
canary bots will still be using DEPS from svn.chromium.org, so we should get
sufficient coverage there. That will allow us to be confident about
updating WebKit, right?
The upstream builder is first and foremost designed to
Yeah, good point... this could be a good task for gardeners. Perhaps we
could have a tool help us here.-Darin
On Tue, Sep 29, 2009 at 10:26 PM, Dmitry Titov dim...@chromium.org wrote:
It seems that if the deps were the same though, the rolls would be on
average less breaking because at least
On Tue, Sep 29, 2009 at 10:41 PM, Darin Fisher da...@chromium.org wrote:
Yeah, good point... this could be a good task for gardeners. Perhaps we
could have a tool help us here.
Maybe there could be a test run on the canary that checks the DEPS to see if
they have the same versions, and if
76 matches
Mail list logo
