[chromium-dev] Re: WebKit Chromium Port Update Sep 29th
Sounds like a good idea.-Darin
On Tue, Sep 29, 2009 at 10:53 PM, David Levin wrote:
> On Tue, Sep 29, 2009 at 10:41 PM, Darin Fisher 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 they aren't, it turns "orange" to
> indicate some action should be taken.
>
>
>
>> -Darin
>>
>>
>> On Tue, Sep 29, 2009 at 10:26 PM, Dmitry Titov wrote:
>>
>>> It seems that if the deps were the same though, the rolls would be on
>>> average less breaking because at least it would test WebKit on WebKit bots
>>> with same versions of V8, Skia etc as post-roll. So single DEPS could make
>>> gardening simpler but other changes (like update Skia for UI) harder. I see
>>> the point. Yeah, it is optional for gardener to roll WebKit DEPS,
>>> although someone will have to do this periodically so why not?
>>>
>>>
>>>
>>> On Tue, Sep 29, 2009 at 9:08 PM, Darin Fisher wrote:
>>>
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 help non-Chromium
WebKit contributors build and repair the PLATFORM(CHROMIUM) port. So, all
we need for that is a stable set of dependencies. They don't strictly
speaking need to be up-to-date unless there is an interface change of
course.
-Darin
On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov wrote:
> I guess WebKit gardener will need to bump the WebKit DEPS to the
> version numbers from Chromium if Chromium's go ahead... To have more
> predictable result of roll and to keep them more or less in sync...
>
> On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
>
>> 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"). Originally, chrome's DEPS file
>> lived
>> in chrome/DEPS instead of src/, and the submodules were the ones that
>> were
>> siblings to the chrome directory.
>> There's a lot of shared dependencies. I'm not sure that for trunk
>> development, it makes sense to require a WebKit roll to update DEPS for
>> all
>> of those shared dependencies. I'm concerned that will slow us down.
>>
>> Can we try having separate sets of dependencies for now? I think the
>> point of the WebKit standalone build is to help vet changes to WebCore.
>> It
>> is less about vetting changes to the modules. The canary bot can cover
>> those.
>>
>> We could write a tool to sync deps, which we run periodically. I
>> think the Chromium repository should probably hold the truth.
>>
>> -Darin
>>
>>
>>
>> On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
>>
>>> 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 wrote:
>>>
On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes
>> the way
>> > webkit interacts with it, or fixes a bug in the webkit layout
>> tests.
>> > However, if the change is only relevant to chromium, than
>> webkit's DEPS need
>> > not be updated. If that change breaks webkit, we will surely
>> find it when we
>> > build chromium.
>>
>
> This seems like a mistake having out of sync rev may cause all
> sorts of issues. Here's a simple one suppose there is a rev that
> fixes some
> issue and adds an assert and it is only done in chromium.
>
> Now code is changed in webkit which would trigger this assert. This
> increases the pain for rolls and seems like a mistake.
>
>
Ask anyone who was around when we had transitive deps. It royally
sucked. I really do not want to go there again ;-)
Once we finish the WebKi
[chromium-dev] Re: WebKit Chromium Port Update Sep 29th
On Tue, Sep 29, 2009 at 10:41 PM, Darin Fisher 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 they aren't, it turns "orange" to
indicate some action should be taken.
> -Darin
>
>
> On Tue, Sep 29, 2009 at 10:26 PM, Dmitry Titov wrote:
>
>> It seems that if the deps were the same though, the rolls would be on
>> average less breaking because at least it would test WebKit on WebKit bots
>> with same versions of V8, Skia etc as post-roll. So single DEPS could make
>> gardening simpler but other changes (like update Skia for UI) harder. I see
>> the point. Yeah, it is optional for gardener to roll WebKit DEPS,
>> although someone will have to do this periodically so why not?
>>
>>
>>
>> On Tue, Sep 29, 2009 at 9:08 PM, Darin Fisher wrote:
>>
>>> 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 help non-Chromium
>>> WebKit contributors build and repair the PLATFORM(CHROMIUM) port. So, all
>>> we need for that is a stable set of dependencies. They don't strictly
>>> speaking need to be up-to-date unless there is an interface change of
>>> course.
>>>
>>> -Darin
>>>
>>>
>>> On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov wrote:
>>>
I guess WebKit gardener will need to bump the WebKit DEPS to the version
numbers from Chromium if Chromium's go ahead... To have more predictable
result of roll and to keep them more or less in sync...
On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
> 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"). Originally, chrome's DEPS file lived in
> chrome/DEPS instead of src/, and the submodules were the ones that were
> siblings to the chrome directory.
> There's a lot of shared dependencies. I'm not sure that for trunk
> development, it makes sense to require a WebKit roll to update DEPS for
> all
> of those shared dependencies. I'm concerned that will slow us down.
>
> Can we try having separate sets of dependencies for now? I think the
> point of the WebKit standalone build is to help vet changes to WebCore.
> It
> is less about vetting changes to the modules. The canary bot can cover
> those.
>
> We could write a tool to sync deps, which we run periodically. I think
> the Chromium repository should probably hold the truth.
>
> -Darin
>
>
>
> On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
>
>> 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 wrote:
>>
>>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes
> the way
> > webkit interacts with it, or fixes a bug in the webkit layout
> tests.
> > However, if the change is only relevant to chromium, than
> webkit's DEPS need
> > not be updated. If that change breaks webkit, we will surely find
> it when we
> > build chromium.
>
This seems like a mistake having out of sync rev may cause all sorts
of issues. Here's a simple one suppose there is a rev that fixes some
issue
and adds an assert and it is only done in chromium.
Now code is changed in webkit which would trigger this assert. This
increases the pain for rolls and seems like a mistake.
>>> Ask anyone who was around when we had transitive deps. It royally
>>> sucked. I really do not want to go there again ;-)
>>>
>>> Once we finish the WebKit API, we'll be able to make Chromium
>>> tip-of-tree use a snapshot of WebKit. However, we might need to rev
>>> Skia
>>> independently to pick up features for the Chrome UI. We shouldn't have
>>> to
>>> br
[chromium-dev] Re: WebKit Chromium Port Update Sep 29th
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 wrote:
> It seems that if the deps were the same though, the rolls would be on
> average less breaking because at least it would test WebKit on WebKit bots
> with same versions of V8, Skia etc as post-roll. So single DEPS could make
> gardening simpler but other changes (like update Skia for UI) harder. I see
> the point. Yeah, it is optional for gardener to roll WebKit DEPS, although
> someone will have to do this periodically so why not?
>
>
>
> On Tue, Sep 29, 2009 at 9:08 PM, Darin Fisher wrote:
>
>> 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 help non-Chromium
>> WebKit contributors build and repair the PLATFORM(CHROMIUM) port. So, all
>> we need for that is a stable set of dependencies. They don't strictly
>> speaking need to be up-to-date unless there is an interface change of
>> course.
>>
>> -Darin
>>
>>
>> On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov wrote:
>>
>>> I guess WebKit gardener will need to bump the WebKit DEPS to the version
>>> numbers from Chromium if Chromium's go ahead... To have more predictable
>>> result of roll and to keep them more or less in sync...
>>>
>>> On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
>>>
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"). Originally, chrome's DEPS file lived in
chrome/DEPS instead of src/, and the submodules were the ones that were
siblings to the chrome directory.
There's a lot of shared dependencies. I'm not sure that for trunk
development, it makes sense to require a WebKit roll to update DEPS for all
of those shared dependencies. I'm concerned that will slow us down.
Can we try having separate sets of dependencies for now? I think the
point of the WebKit standalone build is to help vet changes to WebCore. It
is less about vetting changes to the modules. The canary bot can cover
those.
We could write a tool to sync deps, which we run periodically. I think
the Chromium repository should probably hold the truth.
-Darin
On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
> 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 wrote:
>
>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes
the way
> webkit interacts with it, or fixes a bug in the webkit layout
tests.
> However, if the change is only relevant to chromium, than webkit's
DEPS need
> not be updated. If that change breaks webkit, we will surely find
it when we
> build chromium.
>>>
>>> This seems like a mistake having out of sync rev may cause all sorts
>>> of issues. Here's a simple one suppose there is a rev that fixes some
>>> issue
>>> and adds an assert and it is only done in chromium.
>>>
>>> Now code is changed in webkit which would trigger this assert. This
>>> increases the pain for rolls and seems like a mistake.
>>>
>>>
>> Ask anyone who was around when we had transitive deps. It royally
>> sucked. I really do not want to go there again ;-)
>>
>> Once we finish the WebKit API, we'll be able to make Chromium
>> tip-of-tree use a snapshot of WebKit. However, we might need to rev Skia
>> independently to pick up features for the Chrome UI. We shouldn't have
>> to
>> branch WebKit just to update Skia. Same goes for the majority of the
>> shared
>> dependencies.
>>
>> I think it is better if we have two separate configurations. Testing
>> WebKit in isolation just depends on some reasonable set of dependencies.
>> Then, we'll also test Chromium+WebKit(head) using the canary bots. This
>> will test with dependencies matchin
[chromium-dev] Re: WebKit Chromium Port Update Sep 29th
It seems that if the deps were the same though, the rolls would be on
average less breaking because at least it would test WebKit on WebKit bots
with same versions of V8, Skia etc as post-roll. So single DEPS could make
gardening simpler but other changes (like update Skia for UI) harder. I see
the point.Yeah, it is optional for gardener to roll WebKit DEPS, although
someone will have to do this periodically so why not?
On Tue, Sep 29, 2009 at 9:08 PM, Darin Fisher wrote:
> 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 help non-Chromium
> WebKit contributors build and repair the PLATFORM(CHROMIUM) port. So, all
> we need for that is a stable set of dependencies. They don't strictly
> speaking need to be up-to-date unless there is an interface change of
> course.
>
> -Darin
>
>
> On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov wrote:
>
>> I guess WebKit gardener will need to bump the WebKit DEPS to the version
>> numbers from Chromium if Chromium's go ahead... To have more predictable
>> result of roll and to keep them more or less in sync...
>>
>> On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
>>
>>> 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"). Originally, chrome's DEPS file lived in
>>> chrome/DEPS instead of src/, and the submodules were the ones that were
>>> siblings to the chrome directory.
>>> There's a lot of shared dependencies. I'm not sure that for trunk
>>> development, it makes sense to require a WebKit roll to update DEPS for all
>>> of those shared dependencies. I'm concerned that will slow us down.
>>>
>>> Can we try having separate sets of dependencies for now? I think the
>>> point of the WebKit standalone build is to help vet changes to WebCore. It
>>> is less about vetting changes to the modules. The canary bot can cover
>>> those.
>>>
>>> We could write a tool to sync deps, which we run periodically. I think
>>> the Chromium repository should probably hold the truth.
>>>
>>> -Darin
>>>
>>>
>>>
>>> On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
>>>
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 wrote:
> On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes the
>>> way
>>> > webkit interacts with it, or fixes a bug in the webkit layout
>>> tests.
>>> > However, if the change is only relevant to chromium, than webkit's
>>> DEPS need
>>> > not be updated. If that change breaks webkit, we will surely find
>>> it when we
>>> > build chromium.
>>>
>>
>> This seems like a mistake having out of sync rev may cause all sorts
>> of issues. Here's a simple one suppose there is a rev that fixes some
>> issue
>> and adds an assert and it is only done in chromium.
>>
>> Now code is changed in webkit which would trigger this assert. This
>> increases the pain for rolls and seems like a mistake.
>>
>>
> Ask anyone who was around when we had transitive deps. It royally
> sucked. I really do not want to go there again ;-)
>
> Once we finish the WebKit API, we'll be able to make Chromium
> tip-of-tree use a snapshot of WebKit. However, we might need to rev Skia
> independently to pick up features for the Chrome UI. We shouldn't have to
> branch WebKit just to update Skia. Same goes for the majority of the
> shared
> dependencies.
>
> I think it is better if we have two separate configurations. Testing
> WebKit in isolation just depends on some reasonable set of dependencies.
> Then, we'll also test Chromium+WebKit(head) using the canary bots. This
> will test with dependencies matching those used by
> Chromium+WebKit(stable).
> So, I think we'll get the coverage we need.
>
> Another choice is to have a shared master location for dependencies.
> However, both svn.webkit.org and svn.chromium.org would need to
> hardcode the revision of that master lo
[chromium-dev] Re: [Memory] Help with v8::Context::DetachGlobal, please
When are you proposing trashing the global object? I don't think there's any particular time when we know this is safe. Recall that someone can call a function from an inactive document whenever they have a pointer to that function. Adam On Tue, Sep 29, 2009 at 10:48 AM, Jens Alfke wrote: > > > 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 pointer referencing that context, and that it takes a number > of GCs for those to be evicted from the cache. > > The newer (two-file) test case in the bug report I linked to > demonstrates the problem. The symptom is the second instance of > WebCore::Document, the one corresponding to the closed tab, not being > freed. You may want to set a breakpoint on the destructor, or add a > printf, to watch this. > >> The only hypothesis I immediately have >> a long chain of JS wrapper - native something: wrapper gets collected, >> releases native wrapper which makes another JS wrapper collectable... > > I don't think that's the case. There are very few DOM objects left > around in this test case, mostly just the Documents themselves. > Running with the --print_global_handles flag, I didn't see handles > going away after each collection, only after the fifth. > >> There are indeed two global objects (and it is explicitly required by >> HTML 5 and it's the way most of browser implements it): global object >> proxy which forwards everything to a 'real' global object which is a >> window. If you can give more explanations which of properties should >> be retained after context disposal and when it's free to clear them, >> that'd be really helpful. > > This relates to the WebCore::V8Proxy object, which manages V8 global > state for a document. It keeps a persistent handle to a v8::Context > and another to its globals. In some cases I don't entirely understand > (when navigating to a new page?) it's told to dispose the context, but > it detaches the globals and keeps the handle. Then later, I think, it > can be told to regenerate a context using those globals, maybe when > the user goes back to that page. But when the tab is closed or the > frame is otherwise disposed, the V8Proxy is also disposed, and its > destructor disposes the handle to the globals as well as the context. > > So at the point that the V8Proxy disposes its context handle, I would > like the v8::Context object not to have any more references to the > globals, so that if the frame is closed (and the proxy deleted) the > DOM objects pointed to by the globals can be collected. > > I don't think it's safe to selectively pull properties out of the > globals, because the globals might be re-used later for a new context > and they need to be in the same shape they were in before. The only > point where I know it's safe to delete properties is in the V8Proxy's > destructor, because I know it's not going to be re-used; but by that > point there is no context anymore so it's difficult to invoke V8 calls > to modify the global properties. > > —Jens > > > --~--~-~--~~~---~--~~ 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 Chromium Port Update Sep 29th
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 help non-Chromium
WebKit contributors build and repair the PLATFORM(CHROMIUM) port. So, all
we need for that is a stable set of dependencies. They don't strictly
speaking need to be up-to-date unless there is an interface change of
course.
-Darin
On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov wrote:
> I guess WebKit gardener will need to bump the WebKit DEPS to the version
> numbers from Chromium if Chromium's go ahead... To have more predictable
> result of roll and to keep them more or less in sync...
>
> On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
>
>> 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"). Originally, chrome's DEPS file lived in
>> chrome/DEPS instead of src/, and the submodules were the ones that were
>> siblings to the chrome directory.
>> There's a lot of shared dependencies. I'm not sure that for trunk
>> development, it makes sense to require a WebKit roll to update DEPS for all
>> of those shared dependencies. I'm concerned that will slow us down.
>>
>> Can we try having separate sets of dependencies for now? I think the
>> point of the WebKit standalone build is to help vet changes to WebCore. It
>> is less about vetting changes to the modules. The canary bot can cover
>> those.
>>
>> We could write a tool to sync deps, which we run periodically. I think
>> the Chromium repository should probably hold the truth.
>>
>> -Darin
>>
>>
>>
>> On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
>>
>>> 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 wrote:
>>>
On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes the
>> way
>> > webkit interacts with it, or fixes a bug in the webkit layout tests.
>> > However, if the change is only relevant to chromium, than webkit's
>> DEPS need
>> > not be updated. If that change breaks webkit, we will surely find it
>> when we
>> > build chromium.
>>
>
> This seems like a mistake having out of sync rev may cause all sorts of
> issues. Here's a simple one suppose there is a rev that fixes some issue
> and
> adds an assert and it is only done in chromium.
>
> Now code is changed in webkit which would trigger this assert. This
> increases the pain for rolls and seems like a mistake.
>
>
Ask anyone who was around when we had transitive deps. It royally
sucked. I really do not want to go there again ;-)
Once we finish the WebKit API, we'll be able to make Chromium
tip-of-tree use a snapshot of WebKit. However, we might need to rev Skia
independently to pick up features for the Chrome UI. We shouldn't have to
branch WebKit just to update Skia. Same goes for the majority of the
shared
dependencies.
I think it is better if we have two separate configurations. Testing
WebKit in isolation just depends on some reasonable set of dependencies.
Then, we'll also test Chromium+WebKit(head) using the canary bots. This
will test with dependencies matching those used by Chromium+WebKit(stable).
So, I think we'll get the coverage we need.
Another choice is to have a shared master location for dependencies.
However, both svn.webkit.org and svn.chromium.org would need to
hardcode the revision of that master location, so you are back to having to
rev a number in two locations. We don't want to have either repository
pointing to the head of the master location since that would make it
difficult to cut branches or refer to a particular revision of the
repository.
-Darin
>>>
>>>
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
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 Chromium Port Update Sep 29th
I guess WebKit gardener will need to bump the WebKit DEPS to the version
numbers from Chromium if Chromium's go ahead... To have more predictable
result of roll and to keep them more or less in sync...
On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher wrote:
> 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"). Originally, chrome's DEPS file lived in
> chrome/DEPS instead of src/, and the submodules were the ones that were
> siblings to the chrome directory.
> There's a lot of shared dependencies. I'm not sure that for trunk
> development, it makes sense to require a WebKit roll to update DEPS for all
> of those shared dependencies. I'm concerned that will slow us down.
>
> Can we try having separate sets of dependencies for now? I think the point
> of the WebKit standalone build is to help vet changes to WebCore. It is
> less about vetting changes to the modules. The canary bot can cover those.
>
> We could write a tool to sync deps, which we run periodically. I think the
> Chromium repository should probably hold the truth.
>
> -Darin
>
>
>
> On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
>
>> 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 wrote:
>>
>>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes the
> way
> > webkit interacts with it, or fixes a bug in the webkit layout tests.
> > However, if the change is only relevant to chromium, than webkit's
> DEPS need
> > not be updated. If that change breaks webkit, we will surely find it
> when we
> > build chromium.
>
This seems like a mistake having out of sync rev may cause all sorts of
issues. Here's a simple one suppose there is a rev that fixes some issue
and
adds an assert and it is only done in chromium.
Now code is changed in webkit which would trigger this assert. This
increases the pain for rolls and seems like a mistake.
>>> Ask anyone who was around when we had transitive deps. It royally
>>> sucked. I really do not want to go there again ;-)
>>>
>>> Once we finish the WebKit API, we'll be able to make Chromium tip-of-tree
>>> use a snapshot of WebKit. However, we might need to rev Skia independently
>>> to pick up features for the Chrome UI. We shouldn't have to branch WebKit
>>> just to update Skia. Same goes for the majority of the shared dependencies.
>>>
>>> I think it is better if we have two separate configurations. Testing
>>> WebKit in isolation just depends on some reasonable set of dependencies.
>>> Then, we'll also test Chromium+WebKit(head) using the canary bots. This
>>> will test with dependencies matching those used by Chromium+WebKit(stable).
>>> So, I think we'll get the coverage we need.
>>>
>>> Another choice is to have a shared master location for dependencies.
>>> However, both svn.webkit.org and svn.chromium.org would need to
>>> hardcode the revision of that master location, so you are back to having to
>>> rev a number in two locations. We don't want to have either repository
>>> pointing to the head of the master location since that would make it
>>> difficult to cut branches or refer to a particular revision of the
>>> repository.
>>>
>>> -Darin
>>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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 Chromium Port Update Sep 29th
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"). Originally, chrome's DEPS file lived in
chrome/DEPS instead of src/, and the submodules were the ones that were
siblings to the chrome directory.
There's a lot of shared dependencies. I'm not sure that for trunk
development, it makes sense to require a WebKit roll to update DEPS for all
of those shared dependencies. I'm concerned that will slow us down.
Can we try having separate sets of dependencies for now? I think the point
of the WebKit standalone build is to help vet changes to WebCore. It is
less about vetting changes to the modules. The canary bot can cover those.
We could write a tool to sync deps, which we run periodically. I think the
Chromium repository should probably hold the truth.
-Darin
On Tue, Sep 29, 2009 at 4:46 PM, David Levin wrote:
> 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 wrote:
>
>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes the
way
> webkit interacts with it, or fixes a bug in the webkit layout tests.
> However, if the change is only relevant to chromium, than webkit's
DEPS need
> not be updated. If that change breaks webkit, we will surely find it
when we
> build chromium.
>>>
>>> This seems like a mistake having out of sync rev may cause all sorts of
>>> issues. Here's a simple one suppose there is a rev that fixes some issue and
>>> adds an assert and it is only done in chromium.
>>>
>>> Now code is changed in webkit which would trigger this assert. This
>>> increases the pain for rolls and seems like a mistake.
>>>
>>>
>> Ask anyone who was around when we had transitive deps. It royally sucked.
>> I really do not want to go there again ;-)
>>
>> Once we finish the WebKit API, we'll be able to make Chromium tip-of-tree
>> use a snapshot of WebKit. However, we might need to rev Skia independently
>> to pick up features for the Chrome UI. We shouldn't have to branch WebKit
>> just to update Skia. Same goes for the majority of the shared dependencies.
>>
>> I think it is better if we have two separate configurations. Testing
>> WebKit in isolation just depends on some reasonable set of dependencies.
>> Then, we'll also test Chromium+WebKit(head) using the canary bots. This
>> will test with dependencies matching those used by Chromium+WebKit(stable).
>> So, I think we'll get the coverage we need.
>>
>> Another choice is to have a shared master location for dependencies.
>> However, both svn.webkit.org and svn.chromium.org would need to hardcode
>> the revision of that master location, so you are back to having to rev a
>> number in two locations. We don't want to have either repository pointing
>> to the head of the master location since that would make it difficult to cut
>> branches or refer to a particular revision of the repository.
>>
>> -Darin
>>
>
>
--~--~-~--~~~---~--~~
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 Keyboard Access, opinions?
Thanks for all the suggestions, I will try to work on it this weekend. -Mohamed On Tue, Sep 29, 2009 at 8:42 PM, Jonas Klink (Google) wrote: > 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 wrote: > >> 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) > > 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 bar->infobar (restore tabs etc, if visible)->Extensions >>> toolstrips). Does that makes sense to everyone? The shortcut is not ideal, >>> but it might be the best we've got... >>> >>> >>> On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet wrote: >>> 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 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 toolbar, > we can tab through the widgets. > -Mohamed > > > On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting wrote: >> >> On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet 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, into >>> > the >>> > chrome, and eventually back into the page. >>> >>> I don't think most folks want tab from the omnibox to take you through >>> the menus, then bookmark buttons. I know that would drive me batty. I >>> could see some users wanting it, but I don't think it should be the >>> default. >> >> I admit that I totally failed to think through "tab in the omnibox" -- I >> was thinking about all the other cases. >> That said, we've had TONS of requests to make tab from the omnibox work >> differently (i.e. "like how other browsers do it"): >> * When the popup is open, tab rotates through its items >> * Otherwise, tab moves to the next focusable element >> I kind of regret that we picked tab for "tab to search" because it >> prevents both of these, and I'm not sure we can change it now. It does seem >> like a bug somehow that you can tab into the omnibox but not out, but I >> don't know how to fix :( >>> >>> Perhaps we >>> also need the ability to assign accelerators to individual >>> bookmarks/extensions. >> >> This has been requested a few times, and brakowski suggested it long ago >> as a replacement for the "home" button -- if you can drag a bookmark onto >> your main toolbar, and give it an alt-home shortcut, then you have your own >> "home" button. >> PK > >>> >>> >> > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
>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 wrote: > 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) > 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 bar->infobar (restore tabs etc, if visible)->Extensions >> toolstrips). Does that makes sense to everyone? The shortcut is not ideal, >> but it might be the best we've got... >> >> >> On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet wrote: >> >>> 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 >>> 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 >>> toolbar, >>> > we can tab through the widgets. >>> > -Mohamed >>> > >>> > >>> > On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting >>> wrote: >>> >> >>> >> On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet >>> wrote: >>> >>> >>> >>> On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting >> > >>> >>> 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, >>> into >>> >>> > the >>> >>> > chrome, and eventually back into the page. >>> >>> >>> >>> I don't think most folks want tab from the omnibox to take you >>> through >>> >>> the menus, then bookmark buttons. I know that would drive me batty. I >>> >>> could see some users wanting it, but I don't think it should be the >>> >>> default. >>> >> >>> >> I admit that I totally failed to think through "tab in the omnibox" -- >>> I >>> >> was thinking about all the other cases. >>> >> That said, we've had TONS of requests to make tab from the omnibox >>> work >>> >> differently (i.e. "like how other browsers do it"): >>> >> * When the popup is open, tab rotates through its items >>> >> * Otherwise, tab moves to the next focusable element >>> >> I kind of regret that we picked tab for "tab to search" because it >>> >> prevents both of these, and I'm not sure we can change it now. It >>> does seem >>> >> like a bug somehow that you can tab into the omnibox but not out, but >>> I >>> >> don't know how to fix :( >>> >>> >>> >>> Perhaps we >>> >>> also need the ability to assign accelerators to individual >>> >>> bookmarks/extensions. >>> >> >>> >> This has been requested a few times, and brakowski suggested it long >>> ago >>> >> as a replacement for the "home" button -- if you can drag a bookmark >>> onto >>> >> your main toolbar, and give it an alt-home shortcut, then you have >>> your own >>> >> "home" button. >>> >> PK >>> > >>> >> >> > --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 5:38 PM, Mohamed Mansour wrote: > How about in kiosk mode, we only hide the "status bubble", > I don't see why we even hide the status bubble. PK --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
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, tabs, close, etc. I believe it is a correct way to follow, its not illegal or anything to follow something that is good and working. And it will make the patch easy and simple. -Mohamed On Tue, Sep 29, 2009 at 8:27 PM, Marc-Antoine Ruel wrote: > 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 things. For example, quitting the > browser is probably a no-op, the script managing the browser life-time > it should just restart it. It would be required anyway in case of a > browser crash. > > Tabs aren't a big deal either. Can you can hook into tabs with > extensions but I don't know if you can block their creation though. > > If this could be done with almost only pure javascript (in addition to > --fullscreen or --app), that would be awesome, especially unit test > wise. > > M-A > > On Tue, Sep 29, 2009 at 7:45 PM, Jacob Mandelson > wrote: > > > > On Tue, Sep 29, 2009 at 04:37:46PM -0700, Jeremy Orlow wrote: > >> On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson > wrote: > >> > On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow > 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" Wiki > >> > page? > >> > > >> > I think the reasoning for allowing this feature is that some minority > >> > would find it helpful and it wouldn't hurt much. I'm concerned that it > >> > is getting much too complicated. I think we shouldn't do it if it is > >> > going to be this complicated. > >> > > >> > >> Would multiple command line flags rather than one really complicate the > >> design? Mohamed's original patch was just a bunch of if statements > keying > >> off of one flag. Seems like the same amount of work to have each if > >> statement key off of a different one. Or am I missing something? > > > > If nothing else, it grows the configuration space. > > Supporting a kiosk mode seems like a good idea. > > Supporting 2^N different flavors of kiosk mode sounds dicier. > > > > -- Jacob > > > > > > > > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
Building on what we already have sounds good to me. -Ben On Tue, Sep 29, 2009 at 5:03 PM, Jonas Klink (Google) 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 bar->infobar (restore tabs etc, if visible)->Extensions > toolstrips). Does that makes sense to everyone? The shortcut is not ideal, > but it might be the best we've got... > > On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet wrote: >> >> 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 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 >> > toolbar, >> > we can tab through the widgets. >> > -Mohamed >> > >> > >> > On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting >> > wrote: >> >> >> >> On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet >> >> wrote: >> >>> >> >>> On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting >> >>> 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, >> >>> > into >> >>> > the >> >>> > chrome, and eventually back into the page. >> >>> >> >>> I don't think most folks want tab from the omnibox to take you through >> >>> the menus, then bookmark buttons. I know that would drive me batty. I >> >>> could see some users wanting it, but I don't think it should be the >> >>> default. >> >> >> >> I admit that I totally failed to think through "tab in the omnibox" -- >> >> I >> >> was thinking about all the other cases. >> >> That said, we've had TONS of requests to make tab from the omnibox work >> >> differently (i.e. "like how other browsers do it"): >> >> * When the popup is open, tab rotates through its items >> >> * Otherwise, tab moves to the next focusable element >> >> I kind of regret that we picked tab for "tab to search" because it >> >> prevents both of these, and I'm not sure we can change it now. It does >> >> seem >> >> like a bug somehow that you can tab into the omnibox but not out, but I >> >> don't know how to fix :( >> >>> >> >>> Perhaps we >> >>> also need the ability to assign accelerators to individual >> >>> bookmarks/extensions. >> >> >> >> This has been requested a few times, and brakowski suggested it long >> >> ago >> >> as a replacement for the "home" button -- if you can drag a bookmark >> >> onto >> >> your main toolbar, and give it an alt-home shortcut, then you have your >> >> own >> >> "home" button. >> >> PK >> > > > > > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
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) 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 bar->infobar (restore tabs etc, if visible)->Extensions > toolstrips). Does that makes sense to everyone? The shortcut is not ideal, > but it might be the best we've got... > > > On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet wrote: > >> 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 >> 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 >> toolbar, >> > we can tab through the widgets. >> > -Mohamed >> > >> > >> > On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting >> wrote: >> >> >> >> On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet >> wrote: >> >>> >> >>> On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting >> >>> 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, >> into >> >>> > the >> >>> > chrome, and eventually back into the page. >> >>> >> >>> I don't think most folks want tab from the omnibox to take you through >> >>> the menus, then bookmark buttons. I know that would drive me batty. I >> >>> could see some users wanting it, but I don't think it should be the >> >>> default. >> >> >> >> I admit that I totally failed to think through "tab in the omnibox" -- >> I >> >> was thinking about all the other cases. >> >> That said, we've had TONS of requests to make tab from the omnibox work >> >> differently (i.e. "like how other browsers do it"): >> >> * When the popup is open, tab rotates through its items >> >> * Otherwise, tab moves to the next focusable element >> >> I kind of regret that we picked tab for "tab to search" because it >> >> prevents both of these, and I'm not sure we can change it now. It does >> seem >> >> like a bug somehow that you can tab into the omnibox but not out, but I >> >> don't know how to fix :( >> >>> >> >>> Perhaps we >> >>> also need the ability to assign accelerators to individual >> >>> bookmarks/extensions. >> >> >> >> This has been requested a few times, and brakowski suggested it long >> ago >> >> as a replacement for the "home" button -- if you can drag a bookmark >> onto >> >> your main toolbar, and give it an alt-home shortcut, then you have your >> own >> >> "home" button. >> >> PK >> > >> > > --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
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 things. For example, quitting the browser is probably a no-op, the script managing the browser life-time it should just restart it. It would be required anyway in case of a browser crash. Tabs aren't a big deal either. Can you can hook into tabs with extensions but I don't know if you can block their creation though. If this could be done with almost only pure javascript (in addition to --fullscreen or --app), that would be awesome, especially unit test wise. M-A On Tue, Sep 29, 2009 at 7:45 PM, Jacob Mandelson wrote: > > On Tue, Sep 29, 2009 at 04:37:46PM -0700, Jeremy Orlow wrote: >> On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: >> > On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow 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" Wiki >> > page? >> > >> > I think the reasoning for allowing this feature is that some minority >> > would find it helpful and it wouldn't hurt much. I'm concerned that it >> > is getting much too complicated. I think we shouldn't do it if it is >> > going to be this complicated. >> > >> >> Would multiple command line flags rather than one really complicate the >> design? Mohamed's original patch was just a bunch of if statements keying >> off of one flag. Seems like the same amount of work to have each if >> statement key off of a different one. Or am I missing something? > > If nothing else, it grows the configuration space. > Supporting a kiosk mode seems like a good idea. > Supporting 2^N different flavors of kiosk mode sounds dicier. > > -- Jacob > > > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
So, to clarify, we would then use ALT+SHIFT+T (currently focusing the toolbar), to cycle keyboard focus through any open toolbars (toolbar->bookmark bar->infobar (restore tabs etc, if visible)->Extensions toolstrips). Does that makes sense to everyone? The shortcut is not ideal, but it might be the best we've got... On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet wrote: > 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 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 > toolbar, > > we can tab through the widgets. > > -Mohamed > > > > > > On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting > wrote: > >> > >> On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet > wrote: > >>> > >>> On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting > >>> 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, > into > >>> > the > >>> > chrome, and eventually back into the page. > >>> > >>> I don't think most folks want tab from the omnibox to take you through > >>> the menus, then bookmark buttons. I know that would drive me batty. I > >>> could see some users wanting it, but I don't think it should be the > >>> default. > >> > >> I admit that I totally failed to think through "tab in the omnibox" -- I > >> was thinking about all the other cases. > >> That said, we've had TONS of requests to make tab from the omnibox work > >> differently (i.e. "like how other browsers do it"): > >> * When the popup is open, tab rotates through its items > >> * Otherwise, tab moves to the next focusable element > >> I kind of regret that we picked tab for "tab to search" because it > >> prevents both of these, and I'm not sure we can change it now. It does > seem > >> like a bug somehow that you can tab into the omnibox but not out, but I > >> don't know how to fix :( > >>> > >>> Perhaps we > >>> also need the ability to assign accelerators to individual > >>> bookmarks/extensions. > >> > >> This has been requested a few times, and brakowski suggested it long ago > >> as a replacement for the "home" button -- if you can drag a bookmark > onto > >> your main toolbar, and give it an alt-home shortcut, then you have your > own > >> "home" button. > >> PK > > > --~--~-~--~~~---~--~~ 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: script for converting sln and vcproj to gyp
Sadly to my knowledge no-one has such a script.-BradN On Mon, Sep 28, 2009 at 11:25 AM, Marshall Greenblatt < magreenbl...@gmail.com> wrote: > Hi All, > > Does anyone happen to have a script for generating more-or-less complete > .gyp configurations given an .sln or .vcproj input? > > Thanks, > Marshall > > > > --~--~-~--~~~---~--~~ 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: [linux] even faster builds: webkit without debug symbols
On Tue, Sep 29, 2009 at 4:55 PM, Evan Stade 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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] even faster builds: webkit without debug symbols
hahaha "Scons Tricks Avoid Scons entirely" -- Evan Stade On Tue, Sep 29, 2009 at 4:03 PM, Evan Martin 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 works if you're not debugging WebKit. > http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Build_WebKit_without_debug_symbols > Thanks for Tony and Dave for doing the work; I just wrote the doc. > > > > --~--~-~--~~~---~--~~ 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 Chromium Port Update Sep 29th
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 wrote: > On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes the way >>> > webkit interacts with it, or fixes a bug in the webkit layout tests. >>> > However, if the change is only relevant to chromium, than webkit's DEPS >>> need >>> > not be updated. If that change breaks webkit, we will surely find it >>> when we >>> > build chromium. >>> >> >> This seems like a mistake having out of sync rev may cause all sorts of >> issues. Here's a simple one suppose there is a rev that fixes some issue and >> adds an assert and it is only done in chromium. >> >> Now code is changed in webkit which would trigger this assert. This >> increases the pain for rolls and seems like a mistake. >> >> > Ask anyone who was around when we had transitive deps. It royally sucked. > I really do not want to go there again ;-) > > Once we finish the WebKit API, we'll be able to make Chromium tip-of-tree > use a snapshot of WebKit. However, we might need to rev Skia independently > to pick up features for the Chrome UI. We shouldn't have to branch WebKit > just to update Skia. Same goes for the majority of the shared dependencies. > > I think it is better if we have two separate configurations. Testing > WebKit in isolation just depends on some reasonable set of dependencies. > Then, we'll also test Chromium+WebKit(head) using the canary bots. This > will test with dependencies matching those used by Chromium+WebKit(stable). > So, I think we'll get the coverage we need. > > Another choice is to have a shared master location for dependencies. > However, both svn.webkit.org and svn.chromium.org would need to hardcode > the revision of that master location, so you are back to having to rev a > number in two locations. We don't want to have either repository pointing > to the head of the master location since that would make it difficult to cut > branches or refer to a particular revision of the repository. > > -Darin > --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 04:37:46PM -0700, Jeremy Orlow wrote: > On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: > > On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow 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" Wiki > > page? > > > > I think the reasoning for allowing this feature is that some minority > > would find it helpful and it wouldn't hurt much. I'm concerned that it > > is getting much too complicated. I think we shouldn't do it if it is > > going to be this complicated. > > > > Would multiple command line flags rather than one really complicate the > design? Mohamed's original patch was just a bunch of if statements keying > off of one flag. Seems like the same amount of work to have each if > statement key off of a different one. Or am I missing something? If nothing else, it grows the configuration space. Supporting a kiosk mode seems like a good idea. Supporting 2^N different flavors of kiosk mode sounds dicier. -- Jacob --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 4:37 PM, Jeremy Orlow wrote: > On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: >> >> On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow 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" Wiki >> > page? >> >> I think the reasoning for allowing this feature is that some minority >> would find it helpful and it wouldn't hurt much. I'm concerned that it >> is getting much too complicated. I think we shouldn't do it if it is >> going to be this complicated. > > Would multiple command line flags rather than one really complicate the > design? Mohamed's original patch was just a bunch of if statements keying > off of one flag. Seems like the same amount of work to have each if > statement key off of a different one. Or am I missing something? The original patch was billed as "let's make full screen a command line switch" which people were generally OK with. This proposal touches a dozen subsystems for an unofficially supported feature, whether it's with different command line switches or not. If it's this complicated, it needs to be designed cleanly, tested, and with official support. Brett --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: > On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow 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" Wiki > page? > > I think the reasoning for allowing this feature is that some minority > would find it helpful and it wouldn't hurt much. I'm concerned that it > is getting much too complicated. I think we shouldn't do it if it is > going to be this complicated. > Would multiple command line flags rather than one really complicate the design? Mohamed's original patch was just a bunch of if statements keying off of one flag. Seems like the same amount of work to have each if statement key off of a different one. Or am I missing something? --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
This is my concern. I don't have a problem with a fullscreen launch switch - we already have other switches to start maximized or start with certain window size. But some of this other stuff seems ad hoc/scarier. It needs proper product definition and we need to decide whether or not we want to support all of it. It'd be a nice to understand how this is supported in other browsers (like IE). -Ben On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: > > On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow 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" Wiki page? > > I think the reasoning for allowing this feature is that some minority > would find it helpful and it wouldn't hurt much. I'm concerned that it > is getting much too complicated. I think we shouldn't do it if it is > going to be this complicated. > > Brett > > > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
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 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 toolbar, > we can tab through the widgets. > -Mohamed > > > On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting wrote: >> >> On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet wrote: >>> >>> On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting >>> 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, into >>> > the >>> > chrome, and eventually back into the page. >>> >>> I don't think most folks want tab from the omnibox to take you through >>> the menus, then bookmark buttons. I know that would drive me batty. I >>> could see some users wanting it, but I don't think it should be the >>> default. >> >> I admit that I totally failed to think through "tab in the omnibox" -- I >> was thinking about all the other cases. >> That said, we've had TONS of requests to make tab from the omnibox work >> differently (i.e. "like how other browsers do it"): >> * When the popup is open, tab rotates through its items >> * Otherwise, tab moves to the next focusable element >> I kind of regret that we picked tab for "tab to search" because it >> prevents both of these, and I'm not sure we can change it now. It does seem >> like a bug somehow that you can tab into the omnibox but not out, but I >> don't know how to fix :( >>> >>> Perhaps we >>> also need the ability to assign accelerators to individual >>> bookmarks/extensions. >> >> This has been requested a few times, and brakowski suggested it long ago >> as a replacement for the "home" button -- if you can drag a bookmark onto >> your main toolbar, and give it an alt-home shortcut, then you have your own >> "home" button. >> PK > --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow 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" Wiki page? I think the reasoning for allowing this feature is that some minority would find it helpful and it wouldn't hurt much. I'm concerned that it is getting much too complicated. I think we shouldn't do it if it is going to be this complicated. Brett --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
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" Wiki page? On Tue, Sep 29, 2009 at 4:10 PM, Mohamed Mansour wrote: > 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 (should I block this) > - Open new page > - Open tabs > - Open Incognito windows > - Print page (should I block this) > - Browser Exits (except ALT+F4) > - Copy Links/Images (should I block this) > - Status bar > - Fullscreen popup > - Popups (should I block this) > > Any comments regarding the above? > > -Mohamed > > > > On Fri, Sep 25, 2009 at 1:51 PM, Jeremy Orlow wrote: > >> No objections. >> I think it's a good idea, you're not the only one who wants this, and it >> seems like it can be done very cleanly. >> >> >> On Fri, Sep 25, 2009 at 10:47 AM, Adam Barth wrote: >> >>> On Fri, Sep 25, 2009 at 10:43 AM, Mohamed Mansour >>> wrote: >>> > I could submit a cleaner patch (which does it right) that introduces >>> Kiosk >>> > mode for Chrome. Are there any objections? >>> >>> None from me. :) >>> >>> Adam >>> >> >> > --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
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 (should I block this) - Open new page - Open tabs - Open Incognito windows - Print page (should I block this) - Browser Exits (except ALT+F4) - Copy Links/Images (should I block this) - Status bar - Fullscreen popup - Popups (should I block this) Any comments regarding the above? -Mohamed On Fri, Sep 25, 2009 at 1:51 PM, Jeremy Orlow wrote: > No objections. > I think it's a good idea, you're not the only one who wants this, and it > seems like it can be done very cleanly. > > > On Fri, Sep 25, 2009 at 10:47 AM, Adam Barth wrote: > >> On Fri, Sep 25, 2009 at 10:43 AM, Mohamed Mansour >> wrote: >> > I could submit a cleaner patch (which does it right) that introduces >> Kiosk >> > mode for Chrome. Are there any objections? >> >> None from me. :) >> >> Adam >> > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [linux] even faster builds: webkit without debug symbols
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 Thanks for Tony and Dave for doing the work; I just wrote the doc. --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
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 wrote: > On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet wrote: > >> On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting >> 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, into >> the >> > chrome, and eventually back into the page. >> >> I don't think most folks want tab from the omnibox to take you through >> the menus, then bookmark buttons. I know that would drive me batty. I >> could see some users wanting it, but I don't think it should be the >> default. >> > > I admit that I totally failed to think through "tab in the omnibox" -- I > was thinking about all the other cases. > > That said, we've had TONS of requests to make tab from the omnibox work > differently (i.e. "like how other browsers do it"): > * When the popup is open, tab rotates through its items > * Otherwise, tab moves to the next focusable element > > I kind of regret that we picked tab for "tab to search" because it prevents > both of these, and I'm not sure we can change it now. It does seem like a > bug somehow that you can tab into the omnibox but not out, but I don't know > how to fix :( > > Perhaps we >> also need the ability to assign accelerators to individual >> bookmarks/extensions. > > > This has been requested a few times, and brakowski suggested it long ago as > a replacement for the "home" button -- if you can drag a bookmark onto your > main toolbar, and give it an alt-home shortcut, then you have your own > "home" button. > > PK > --~--~-~--~~~---~--~~ 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: Green tree task force: How to try upstream Windows layout tests?
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 Safari WebKit try bots would also be helpful. On Tue, Sep 29, 2009 at 3:50 PM, Marc-Antoine Ruel wrote: > > 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 > wrote: > > On Tue, Sep 29, 2009 at 3:35 PM, Marc-Antoine Ruel > > wrote: > >> > >> 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 comments about how to accomplish the same goal with what > we > > have today. > > PK > > > > --~--~-~--~~~---~--~~ 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: Green tree task force: How to try upstream Windows layout tests?
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 runs build.webkit.org to my knowledge. -eric On Tue, Sep 29, 2009 at 3:50 PM, Marc-Antoine Ruel wrote: > > 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 wrote: >> On Tue, Sep 29, 2009 at 3:35 PM, Marc-Antoine Ruel >> wrote: >>> >>> 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 comments about how to accomplish the same goal with what we >> have today. >> PK > > > > --~--~-~--~~~---~--~~ 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: Green tree task force: How to try upstream Windows layout tests?
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 wrote: > On Tue, Sep 29, 2009 at 3:35 PM, Marc-Antoine Ruel > wrote: >> >> 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 comments about how to accomplish the same goal with what we > have today. > PK --~--~-~--~~~---~--~~ 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] registerProtocolHandler HTML5 API
Thanks for the response, comments inline. On Tue, Sep 29, 2009 at 12:44 AM, brg 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 this > > will happen frequently enough to be annoying. > > This seems to be the consensus. > > > UI: Should there be user UI to manage this that doesn't require knowing a > > magic about:protocols url? > > More than happy to have one if the UI gurus have something in mind, I > was actively attempting to not change any UI element. > My guess is we'll need this, but good Chrome-y design attitude :) > > > API: Is there an API to unregister from a protocol? > > No, as spec'd a webapp only announces it's availability by calling > registerProtocolHandler when loaded. The UA must provide a mechanism > for removing/announcing registration. > If the app is providing in-page UI to set this, they might want to provide corresponding UI to un-set it. > > > API: How does the page know it's registered? > > Why would it need to know? There's nothing it can change. > If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. > > > We should probably have a > > separate API for this, so sites can display a more prominent call to > action > > when they're not registered. > > Beyond the infobar (which should be hidden on return navigations if > the user has previously declined,but always available from > about:protocols), what do you have in mind? Not having a means of > suppressing this will make the site annoying. > See Gmail example. BTW, I think the infobar should be yes, not now, never. > > > Misc: Should there be some way for native apps to register as protocol > > handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS > > provide this? > > The OS provides hooks for some protocols. I mentioned this in the > tail end of the script; I'm not sure how happy users would be to see > Chrome populating their registry with protocol handlers. > Fair enough. This seems to work on PC today, but not on Mac for some reason. --~--~-~--~~~---~--~~ 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: Green tree task force: How to try upstream Windows layout tests?
On Tue, Sep 29, 2009 at 3:35 PM, Marc-Antoine Ruel wrote: > 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 comments about how to accomplish the same goal with what we have today. PK --~--~-~--~~~---~--~~ 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: Green tree task force: How to try upstream Windows layout tests?
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 wrote: > 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. I asked why our trybots didn't work and he reminded me > that they run test_shell, which is fine for our downstream tests but doesn't > match how the upstream WebKit community runs Windows layout tests (i.e. by > using DRT). > Ojan said he'd be far more productive if there was an easy way to try a > patch and see how it would affect the Windows tests upstream. Anyone have > any suggestions, or willing to set something like this up? > PK > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Green tree task force: How to try upstream Windows layout tests?
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. I asked why our trybots didn't work and he reminded me that they run test_shell, which is fine for our downstream tests but doesn't match how the upstream WebKit community runs Windows layout tests (i.e. by using DRT). Ojan said he'd be far more productive if there was an easy way to try a patch and see how it would affect the Windows tests upstream. Anyone have any suggestions, or willing to set something like this up? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 27535
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 for "compile" on "Linux Builder (ChromeOS)" <=-- Revision: 27535 Blame list: thes...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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 Chromium Port Update Sep 29th
On Tue, Sep 29, 2009 at 1:12 PM, David Levin 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 dependency actually changes the way >> > webkit interacts with it, or fixes a bug in the webkit layout tests. >> > However, if the change is only relevant to chromium, than webkit's DEPS >> need >> > not be updated. If that change breaks webkit, we will surely find it >> when we >> > build chromium. >> > > This seems like a mistake having out of sync rev may cause all sorts of > issues. Here's a simple one suppose there is a rev that fixes some issue and > adds an assert and it is only done in chromium. > > Now code is changed in webkit which would trigger this assert. This > increases the pain for rolls and seems like a mistake. > > Ask anyone who was around when we had transitive deps. It royally sucked. I really do not want to go there again ;-) Once we finish the WebKit API, we'll be able to make Chromium tip-of-tree use a snapshot of WebKit. However, we might need to rev Skia independently to pick up features for the Chrome UI. We shouldn't have to branch WebKit just to update Skia. Same goes for the majority of the shared dependencies. I think it is better if we have two separate configurations. Testing WebKit in isolation just depends on some reasonable set of dependencies. Then, we'll also test Chromium+WebKit(head) using the canary bots. This will test with dependencies matching those used by Chromium+WebKit(stable). So, I think we'll get the coverage we need. Another choice is to have a shared master location for dependencies. However, both svn.webkit.org and svn.chromium.org would need to hardcode the revision of that master location, so you are back to having to rev a number in two locations. We don't want to have either repository pointing to the head of the master location since that would make it difficult to cut branches or refer to a particular revision of the repository. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 27528
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 "compile" on "Chromium Builder (dbg)" <=-- Revision: 27528 Blame list: e...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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: Try-ing WebKit patches (was WebKit Chromium Port Update Sep 29th)
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 wrote: > +Dimitri, who is doing that and didn't put Jeremy in the loop. > > On Tue, Sep 29, 2009 at 4:06 PM, Jeremy Orlow wrote: >> On Tue, Sep 29, 2009 at 12:52 PM, Jeremy Orlow wrote: >>> >>> On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel >>> wrote: On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman 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 > chromium > port layout tests and api unit tests. By "internal" do you mean that only Googlers can access it? Is there a command I could wire into bugzilla-toll post-diff which would post to this try-bot as well? Could you detail such a command? >>> >>> I believe that only people with @chromium.org accounts can currently use >>> try bots. I'm not aware of any discussion about whether or how we should >>> give access to @webkit.org people. >> >> Btw, I think it's fairly clear we should give access to WebKit developers; I >> just haven't seen/heard any discussions about it. And there might be >> security concerns that make it impossible to simply allow every WebKit >> contributor to use them without some additional sign up process. >> >> >> > --~--~-~--~~~---~--~~ 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 Chromium Port Update Sep 29th
> 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 bug in the webkit layout tests. > > However, if the change is only relevant to chromium, than webkit's DEPS > need > > not be updated. If that change breaks webkit, we will surely find it when > we > > build chromium. > This seems like a mistake having out of sync rev may cause all sorts of issues. Here's a simple one suppose there is a rev that fixes some issue and adds an assert and it is only done in chromium. Now code is changed in webkit which would trigger this assert. This increases the pain for rolls and seems like a mistake. > > Q: Why don't we control webkit's dependencies in a single place? > > A: Most of the dependencies that webkit uses are also used directly by > > chromium. Therefore, we will often find ourselves rolling webkit > revisions > > just because chromium needs a third party revision update. We have been > > there once, it was painful, we don't want to go there again. > Why not just allow an override in chromium's deps file? This way if one really needs to change a rev without doing a webkit roll there is a way but ideally there would be one place where the deps are specified. Everytime there is duplicate information that may get out of sync and cause wierd errors, it increases the complexity of the system which is a bad thing. dave > > --~--~-~--~~~---~--~~ 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 Chromium Port Update Sep 29th
That is one of the goals of creating and upstreaming the WebKit API. On Tue, Sep 29, 2009 at 1:01 PM, Evan Martin 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 > 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 and > some > > answers for frequently asked questions: > > Recent changes: > > 1. Chromium now builds using gyp files living on the webkit.org tree > > (WebCore.gyp & JavaScriptCore.gyp). > > 2. The Webkit Chromium Port has its own DEPS file, which lives on > > the webkit.org tree too (third_party/WebKit/WebKit/chromium/DEPS). This > DEPS > > file includes a minimal set of dependencies that our port requires in > order > > to be independently built outside of a full chromium checkout. > > 3. The useful update-webkit and build-webkit scripts now allow a > > "--chromium" argument which syncs and builds the chromium port with the > help > > of gclient and gyp. > > Next steps: > > 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 > chromium > > port layout tests and api unit tests. > > 2. Upstreaming chromium's webkit api to webkit.org, which will further > > reduce the need for 2-sides commits and blockage. > > 3. Upstreaming chromium's test_shell and layout tests, allowing us to > detect > > webkit-chromium breakage before we integrate into chromium. > > FAQs: > > Q: Which dependencies does webkit use when built into chromium? > > A: When built independently, webkit will link with revisions as specified > in > > the upstream DEPS file. When built as part of chromium, it will link with > > the revisions specified in the downstream DEPS. > > 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 bug in the webkit layout tests. > > However, if the change is only relevant to chromium, than webkit's DEPS > need > > not be updated. If that change breaks webkit, we will surely find it when > we > > build chromium. > > Q: Why don't we control webkit's dependencies in a single place? > > A: Most of the dependencies that webkit uses are also used directly by > > chromium. Therefore, we will often find ourselves rolling webkit > revisions > > just because chromium needs a third party revision update. We have been > > there once, it was painful, we don't want to go there again. As explained > > above, we don't mind upstream webkit builds using older deps. > > Q: Wouldn't dependencies be fetched twice because they are specified in > both > > upstream and downstream DEPS? > > A: No, because when synched as part of a full chromium checkout, all DEPS > > files under third_party are ignored. We only want the port's DEPS fetched > on > > a standalone webkit checkout. > > > > Q: We already have layout try bots. Why also have a webkit chromium port > try > > bots? > > A: The existing layout try bot builds webkit along with the rest of > > chromium. We want to be able to try an independent upstream-only build > and > > eventually contribute our try system to webkit.org so all webkit > developers > > can use it. This will help protect chromium from disruptive upstream > > changes. > > Q: Wait, do we have .gyp and DEPS files on the webkit tree? > > A: Yes. And we believe other webkit ports could follow our example and > use > > gclient and gyp too. > > > > > > > > > --~--~-~--~~~---~--~~ 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: [Memory] Help with v8::Context::DetachGlobal, please
It might be better to ask this on v8-dev. Erik On Tue, Sep 29, 2009 at 10:07 AM, Jens Alfke 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 been getting bored after two GCs, so it wasn't > till Ivan mentioned the stickiness of the generated-function caches that I > thought to turn it up to 5. > This still seems like an opportunity for optimization — the > WebCore::Document and WebCore::DOMWindow can have a lot of stuff hanging off > of them, so we should try to clean them up more quickly after a same-process > child tab closes. > The sticky reference is actually to the v8::Context. The DOM objects hang on > because they're pointed to by that context's globals. So if the context's > globals could be cleared when Chrome's V8Proxy disposes the context, the DOM > objects should go away at the next GC. > Good news: There is a v8::Context::DetachGlobal method that appears to > separate the globals from the context. Bad news: it doesn't appear to do > what I expected it to. After it's called the context still seems to have a > reference to the globals, because they still don't go away until later when > the context is collected. > I looked at the implementation, Bootstrapper::DetachGlobal > (bootstrapper.cc:361) but I don't really understand what it's doing. The > context internally has both a global() and a global_proxy() object, and this > method seems to detach the latter but not the former. From the way they're > created it looks like the global() points to the global_proxy(), explaining > why there's still a connection after detaching. > Is there a way I can sever the relationship from the context to the globals? > Would it require adding a new V8 API method similar to DetachGlobal? > (I did find one approach that sort of works: iterating over the global > object's properties and removing them all. Unfortunately I can't use this > because in some cases the V8Proxy requires the global object to stay intact > after disposing the context, so it can be used with a new context, and at > the point where the context is disposed I don't know whether that's going to > happen or not.) > Thanks, > —Jens > > > --~--~-~--~~~---~--~~ 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: Try-ing WebKit patches (was WebKit Chromium Port Update Sep 29th)
+Dimitri, who is doing that and didn't put Jeremy in the loop. On Tue, Sep 29, 2009 at 4:06 PM, Jeremy Orlow wrote: > On Tue, Sep 29, 2009 at 12:52 PM, Jeremy Orlow wrote: >> >> On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel >> wrote: >>> >>> On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman >>> 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 >>> > chromium >>> > port layout tests and api unit tests. >>> >>> By "internal" do you mean that only Googlers can access it? >>> >>> Is there a command I could wire into bugzilla-toll post-diff which >>> would post to this try-bot as well? Could you detail such a command? >> >> I believe that only people with @chromium.org accounts can currently use >> try bots. I'm not aware of any discussion about whether or how we should >> give access to @webkit.org people. > > Btw, I think it's fairly clear we should give access to WebKit developers; I > just haven't seen/heard any discussions about it. And there might be > security concerns that make it impossible to simply allow every WebKit > contributor to use them without some additional sign up process. > > > --~--~-~--~~~---~--~~ 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: Try-ing WebKit patches (was WebKit Chromium Port Update Sep 29th)
On Tue, Sep 29, 2009 at 12:52 PM, Jeremy Orlow wrote: > On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel wrote: > >> >> On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman >> 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 >> chromium >> > port layout tests and api unit tests. >> >> By "internal" do you mean that only Googlers can access it? >> >> Is there a command I could wire into bugzilla-toll post-diff which >> would post to this try-bot as well? Could you detail such a command? >> > > I believe that only people with @chromium.org accounts can currently use > try bots. I'm not aware of any discussion about whether or how we should > give access to @webkit.org people. > Btw, I think it's fairly clear we should give access to WebKit developers; I just haven't seen/heard any discussions about it. And there might be security concerns that make it impossible to simply allow every WebKit contributor to use them without some additional sign up process. --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 wrote: > 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 > wrote: > >> 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 PM, Thomas Van Lenten < >> thoma...@chromium.org> wrote: >> >>> 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ć wrote: >>> 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 wrote: > 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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 > Revision: 730 > Node Kind: directory > Schedule: normal > Last Changed Author: kschi...@google.com > Last Changed Rev: 728 > Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) > > How does that compare with your checkout? > > - nick > > On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: > >> Still the same message (after gclient sync --force). >> >> >> On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 >>> >> >> >> >> > >>> >>> >>> >> >> >> >> > --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 wrote: > 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 PM, Thomas Van Lenten > wrote: > >> 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ć wrote: >> >>> 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 wrote: >>> 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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 Revision: 730 Node Kind: directory Schedule: normal Last Changed Author: kschi...@google.com Last Changed Rev: 728 Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) How does that compare with your checkout? - nick On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: > Still the same message (after gclient sync --force). > > > On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 >> > > > > >>> >> >> >> > > > > --~--~-~--~~~---~--~~ 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 Chromium Port Update Sep 29th
Q. Does this mean you can build a libwebkit.so independently of Chrome? On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman 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 and some > answers for frequently asked questions: > Recent changes: > 1. Chromium now builds using gyp files living on the webkit.org tree > (WebCore.gyp & JavaScriptCore.gyp). > 2. The Webkit Chromium Port has its own DEPS file, which lives on > the webkit.org tree too (third_party/WebKit/WebKit/chromium/DEPS). This DEPS > file includes a minimal set of dependencies that our port requires in order > to be independently built outside of a full chromium checkout. > 3. The useful update-webkit and build-webkit scripts now allow a > "--chromium" argument which syncs and builds the chromium port with the help > of gclient and gyp. > Next steps: > 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 chromium > port layout tests and api unit tests. > 2. Upstreaming chromium's webkit api to webkit.org, which will further > reduce the need for 2-sides commits and blockage. > 3. Upstreaming chromium's test_shell and layout tests, allowing us to detect > webkit-chromium breakage before we integrate into chromium. > FAQs: > Q: Which dependencies does webkit use when built into chromium? > A: When built independently, webkit will link with revisions as specified in > the upstream DEPS file. When built as part of chromium, it will link with > the revisions specified in the downstream DEPS. > 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 bug in the webkit layout tests. > However, if the change is only relevant to chromium, than webkit's DEPS need > not be updated. If that change breaks webkit, we will surely find it when we > build chromium. > Q: Why don't we control webkit's dependencies in a single place? > A: Most of the dependencies that webkit uses are also used directly by > chromium. Therefore, we will often find ourselves rolling webkit revisions > just because chromium needs a third party revision update. We have been > there once, it was painful, we don't want to go there again. As explained > above, we don't mind upstream webkit builds using older deps. > Q: Wouldn't dependencies be fetched twice because they are specified in both > upstream and downstream DEPS? > A: No, because when synched as part of a full chromium checkout, all DEPS > files under third_party are ignored. We only want the port's DEPS fetched on > a standalone webkit checkout. > > Q: We already have layout try bots. Why also have a webkit chromium port try > bots? > A: The existing layout try bot builds webkit along with the rest of > chromium. We want to be able to try an independent upstream-only build and > eventually contribute our try system to webkit.org so all webkit developers > can use it. This will help protect chromium from disruptive upstream > changes. > Q: Wait, do we have .gyp and DEPS files on the webkit tree? > A: Yes. And we believe other webkit ports could follow our example and use > gclient and gyp too. > > > --~--~-~--~~~---~--~~ 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: using upstream webkit's git repo in chrome
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 wrote: > > 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: None". > > :DG< > > On Tue, Sep 29, 2009 at 12:06 PM, Drew Wilson > wrote: > > 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 > > '/Users/atwilson/chrome.git/src/third_party/WebKit/WebKitLibraries' if an > > unversioned directory is present. Delete the directory and try again. > > I can go through and individually add these directories to my .gclient > file, > > but after I added the 8th one it occurs to me that I'm probably Doing It > > Wrong. > > Do you guys have a bunch of exclusions in your .gclient, or is there > another > > way? > > -atw > > On Tue, Sep 8, 2009 at 12:07 PM, Evan Martin wrote: > >> > >> I checked in tools/sync-webkit-git.py as a stopgap. Description > >> pasted below; let me know if it works/doesn't work for you. > >> > >> === > >> > >> Under the assumption third_party/WebKit is a clone of git.webkit.org, > >> we can use git commands to make it match the version requested by DEPS. > >> > >> To use this: > >> 1) rm -rf third_party/WebKit > >> 2) git clone git://git.webkit.org/WebKit.git third_party/WebKit > >> 3) run ./tools/sync-webkit-git.py now, and again whenever you run > gclient > >> sync. > >> > >> FAQ: > >> Q. Why not add this functionality to gclient itself? > >> A. DEPS actually specifies to only pull some subdirectories of > >> third_party/WebKit. So even if gclient supported git, we'd still need > >> to special-case this. > >> > >> > > > > > > > > > > > > > --~--~-~--~~~---~--~~ 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: Try-ing WebKit patches (was WebKit Chromium Port Update Sep 29th)
On Tue, Sep 29, 2009 at 12:05 PM, Eric Seidel wrote: > > On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman > 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 > chromium > > port layout tests and api unit tests. > > By "internal" do you mean that only Googlers can access it? > > Is there a command I could wire into bugzilla-toll post-diff which > would post to this try-bot as well? Could you detail such a command? > I believe that only people with @chromium.org accounts can currently use try bots. I'm not aware of any discussion about whether or how we should give access to @webkit.org people. --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 PM, Thomas Van Lenten wrote: > 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ć wrote: > >> 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 wrote: >> >>> 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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 >>> Revision: 730 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: kschi...@google.com >>> Last Changed Rev: 728 >>> Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) >>> >>> How does that compare with your checkout? >>> >>> - nick >>> >>> On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: >>> Still the same message (after gclient sync --force). On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 > >>> >> > > > > --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 wrote: > 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 PM, Thomas Van Lenten > wrote: > >> 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ć wrote: >> >>> 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 wrote: >>> 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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 Revision: 730 Node Kind: directory Schedule: normal Last Changed Author: kschi...@google.com Last Changed Rev: 728 Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) How does that compare with your checkout? - nick On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: > Still the same message (after gclient sync --force). > > > On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 >> > > > > >>> >> >> >> >> > --~--~-~--~~~---~--~~ 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 fails to update gyp files
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ć wrote: > 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 wrote: > >> 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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 >> Revision: 730 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: kschi...@google.com >> Last Changed Rev: 728 >> Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) >> >> How does that compare with your checkout? >> >> - nick >> >> On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: >> >>> Still the same message (after gclient sync --force). >>> >>> >>> On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 >>> >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 wrote: > 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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 > Revision: 730 > Node Kind: directory > Schedule: normal > Last Changed Author: kschi...@google.com > Last Changed Rev: 728 > Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) > > How does that compare with your checkout? > > - nick > > On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: > >> Still the same message (after gclient sync --force). >> >> >> On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 >>> >> >> >> >> >> > --~--~-~--~~~---~--~~ 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: using upstream webkit's git repo in chrome
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: None". :DG< On Tue, Sep 29, 2009 at 12:06 PM, Drew Wilson wrote: > 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 > '/Users/atwilson/chrome.git/src/third_party/WebKit/WebKitLibraries' if an > unversioned directory is present. Delete the directory and try again. > I can go through and individually add these directories to my .gclient file, > but after I added the 8th one it occurs to me that I'm probably Doing It > Wrong. > Do you guys have a bunch of exclusions in your .gclient, or is there another > way? > -atw > On Tue, Sep 8, 2009 at 12:07 PM, Evan Martin wrote: >> >> I checked in tools/sync-webkit-git.py as a stopgap. Description >> pasted below; let me know if it works/doesn't work for you. >> >> === >> >> Under the assumption third_party/WebKit is a clone of git.webkit.org, >> we can use git commands to make it match the version requested by DEPS. >> >> To use this: >> 1) rm -rf third_party/WebKit >> 2) git clone git://git.webkit.org/WebKit.git third_party/WebKit >> 3) run ./tools/sync-webkit-git.py now, and again whenever you run gclient >> sync. >> >> FAQ: >> Q. Why not add this functionality to gclient itself? >> A. DEPS actually specifies to only pull some subdirectories of >> third_party/WebKit. So even if gclient supported git, we'd still need >> to special-case this. >> >> > > > > > --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 Revision: 730 Node Kind: directory Schedule: normal Last Changed Author: kschi...@google.com Last Changed Rev: 728 Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) How does that compare with your checkout? - nick On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić wrote: > Still the same message (after gclient sync --force). > > > On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 >> > > > > > --~--~-~--~~~---~--~~ 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 fails to update gyp files
Still the same message (after gclient sync --force). On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai 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 > --~--~-~--~~~---~--~~ 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: using upstream webkit's git repo in chrome
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 '/Users/atwilson/chrome.git/src/third_party/WebKit/WebKitLibraries' if an unversioned directory is present. Delete the directory and try again. I can go through and individually add these directories to my .gclient file, but after I added the 8th one it occurs to me that I'm probably Doing It Wrong. Do you guys have a bunch of exclusions in your .gclient, or is there another way? -atw On Tue, Sep 8, 2009 at 12:07 PM, Evan Martin wrote: > > I checked in tools/sync-webkit-git.py as a stopgap. Description > pasted below; let me know if it works/doesn't work for you. > > === > > Under the assumption third_party/WebKit is a clone of git.webkit.org, > we can use git commands to make it match the version requested by DEPS. > > To use this: > 1) rm -rf third_party/WebKit > 2) git clone git://git.webkit.org/WebKit.git third_party/WebKit > 3) run ./tools/sync-webkit-git.py now, and again whenever you run gclient > sync. > > FAQ: > Q. Why not add this functionality to gclient itself? > A. DEPS actually specifies to only pull some subdirectories of > third_party/WebKit. So even if gclient supported git, we'd still need > to special-case this. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebKit Chromium Port Update Sep 29th
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 & JavaScriptCore.gyp). 2. The Webkit Chromium Port has its own DEPS file, which lives on the webkit.org tree too (third_party/WebKit/WebKit/chromium/DEPS). This DEPS file includes a minimal set of dependencies that our port requires in order to be independently built outside of a full chromium checkout. 3. The useful update-webkit and build-webkit scripts now allow a "--chromium" argument which syncs and builds the chromium port with the help of gclient and gyp. *Next steps:* 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 chromium port layout tests and api unit tests. 2. Upstreaming chromium's webkit api to webkit.org, which will further reduce the need for 2-sides commits and blockage. 3. Upstreaming chromium's test_shell and layout tests, allowing us to detect webkit-chromium breakage before we integrate into chromium. *FAQs:* Q: Which dependencies does webkit use when built into chromium? A: When built independently, webkit will link with revisions as specified in the upstream DEPS file. When built as part of chromium, it will link with the revisions specified in the downstream DEPS. 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 bug in the webkit layout tests. However, if the change is only relevant to chromium, than webkit's DEPS need not be updated. If that change breaks webkit, we will surely find it when we build chromium. Q: Why don't we control webkit's dependencies in a single place? A: Most of the dependencies that webkit uses are also used directly by chromium. Therefore, we will often find ourselves rolling webkit revisions just because chromium needs a third party revision update. We have been there once, it was painful, we don't want to go there again. As explained above, we don't mind upstream webkit builds using older deps. Q: Wouldn't dependencies be fetched twice because they are specified in both upstream and downstream DEPS? A: No, because when synched as part of a full chromium checkout, all DEPS files under third_party are ignored. We only want the port's DEPS fetched on a standalone webkit checkout. Q: We already have layout try bots. Why also have a webkit chromium port try bots? A: The existing layout try bot builds webkit along with the rest of chromium. We want to be able to try an independent upstream-only build and eventually contribute our try system to webkit.org so all webkit developers can use it. This will help protect chromium from disruptive upstream changes. Q: Wait, do we have .gyp and DEPS files on the webkit tree? A: Yes. And we believe other webkit ports could follow our example and use gclient and gyp too. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Try-ing WebKit patches (was WebKit Chromium Port Update Sep 29th)
On Tue, Sep 29, 2009 at 11:53 AM, Yaar Schnitman 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 chromium > port layout tests and api unit tests. By "internal" do you mean that only Googlers can access it? Is there a command I could wire into bugzilla-toll post-diff which would post to this try-bot as well? Could you detail such a command? -eric --~--~-~--~~~---~--~~ 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: [Memory] Help with v8::Context::DetachGlobal, please
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 wrote: > > 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 pointer > referencing that context, and that it takes a number of GCs for those to be > evicted from the cache. > > The newer (two-file) test case in the bug report I linked to demonstrates > the problem. The symptom is the second instance of WebCore::Document, the > one corresponding to the closed tab, not being freed. You may want to set a > breakpoint on the destructor, or add a printf, to watch this. > >> The only hypothesis I immediately have >> a long chain of JS wrapper - native something: wrapper gets collected, >> releases native wrapper which makes another JS wrapper collectable... > > I don't think that's the case. There are very few DOM objects left around in > this test case, mostly just the Documents themselves. Running with the > --print_global_handles flag, I didn't see handles going away after each > collection, only after the fifth. > >> There are indeed two global objects (and it is explicitly required by >> HTML 5 and it's the way most of browser implements it): global object >> proxy which forwards everything to a 'real' global object which is a >> window. If you can give more explanations which of properties should >> be retained after context disposal and when it's free to clear them, >> that'd be really helpful. > > This relates to the WebCore::V8Proxy object, which manages V8 global state > for a document. It keeps a persistent handle to a v8::Context and another to > its globals. In some cases I don't entirely understand (when navigating to a > new page?) it's told to dispose the context, but it detaches the globals and > keeps the handle. Then later, I think, it can be told to regenerate a > context using those globals, maybe when the user goes back to that page. But > when the tab is closed or the frame is otherwise disposed, the V8Proxy is > also disposed, and its destructor disposes the handle to the globals as well > as the context. > > So at the point that the V8Proxy disposes its context handle, I would like > the v8::Context object not to have any more references to the globals, so > that if the frame is closed (and the proxy deleted) the DOM objects pointed > to by the globals can be collected. > > I don't think it's safe to selectively pull properties out of the globals, > because the globals might be re-used later for a new context and they need > to be in the same shape they were in before. The only point where I know > it's safe to delete properties is in the V8Proxy's destructor, because I > know it's not going to be re-used; but by that point there is no context > anymore so it's difficult to invoke V8 calls to modify the global > properties. > > —Jens --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 --~--~-~--~~~---~--~~ 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: [Memory] Help with v8::Context::DetachGlobal, please
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 pointer referencing that context, and that it takes a number of GCs for those to be evicted from the cache. The newer (two-file) test case in the bug report I linked to demonstrates the problem. The symptom is the second instance of WebCore::Document, the one corresponding to the closed tab, not being freed. You may want to set a breakpoint on the destructor, or add a printf, to watch this. > The only hypothesis I immediately have > a long chain of JS wrapper - native something: wrapper gets collected, > releases native wrapper which makes another JS wrapper collectable... I don't think that's the case. There are very few DOM objects left around in this test case, mostly just the Documents themselves. Running with the --print_global_handles flag, I didn't see handles going away after each collection, only after the fifth. > There are indeed two global objects (and it is explicitly required by > HTML 5 and it's the way most of browser implements it): global object > proxy which forwards everything to a 'real' global object which is a > window. If you can give more explanations which of properties should > be retained after context disposal and when it's free to clear them, > that'd be really helpful. This relates to the WebCore::V8Proxy object, which manages V8 global state for a document. It keeps a persistent handle to a v8::Context and another to its globals. In some cases I don't entirely understand (when navigating to a new page?) it's told to dispose the context, but it detaches the globals and keeps the handle. Then later, I think, it can be told to regenerate a context using those globals, maybe when the user goes back to that page. But when the tab is closed or the frame is otherwise disposed, the V8Proxy is also disposed, and its destructor disposes the handle to the globals as well as the context. So at the point that the V8Proxy disposes its context handle, I would like the v8::Context object not to have any more references to the globals, so that if the frame is closed (and the proxy deleted) the DOM objects pointed to by the globals can be collected. I don't think it's safe to selectively pull properties out of the globals, because the globals might be re-used later for a new context and they need to be in the same shape they were in before. The only point where I know it's safe to delete properties is in the V8Proxy's destructor, because I know it's not going to be re-used; but by that point there is no context anymore so it's difficult to invoke V8 calls to modify the global properties. —Jens --~--~-~--~~~---~--~~ 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 fails to update gyp files
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 wrote:
> 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ć wrote:
>
>> 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 78, in
>> sys.exit(gyp.main(args))
>> File "src/tools/gyp/pylib/gyp/__init__.py", line 406, in main
>> params, options.check)
>> File "src/tools/gyp/pylib/gyp/__init__.py", line 76, in Load
>> depth, generator_input_info, check)
>> File "src/tools/gyp/pylib/gyp/input.py", line 1844, in Load
>> depth, check)
>> File "src/tools/gyp/pylib/gyp/input.py", line 342, in
>> LoadTargetBuildFile
>> includes, depth, check)
>> File "src/tools/gyp/pylib/gyp/input.py", line 342, in
>> LoadTargetBuildFile
>> includes, depth, check)
>> File "src/tools/gyp/pylib/gyp/input.py", line 278, in
>> LoadTargetBuildFile
>> includes, True, check)
>> File "src/tools/gyp/pylib/gyp/input.py", line 170, in LoadOneBuildFile
>> raise Exception("%s not found (cwd: %s)" % (build_file_path,
>> os.getcwd()))
>> Exception:
>> /home/nebojsa/chromium/src/native_client/src/trusted/plugin/plugin_chrome.gyp
>> not found (cwd: /home/nebojsa/chromium) while loading dependencies of
>> /home/nebojsa/chromium/src/chrome/chrome.gyp while loading dependencies of
>> /home/nebojsa/chromium/src/build/all.gyp while trying to load
>> src/build/all.gyp
>> failed to run command: /usr/bin/python src/build/gyp_chromium
>>
>> I am on amd64 machine, Ubuntu 9.04.
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
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: [Memory] Help with v8::Context::DetachGlobal, please
from correct account, sorry. On Tue, Sep 29, 2009 at 9:31 PM, Anton Muhin wrote: > On Tue, Sep 29, 2009 at 9:07 PM, Jens Alfke 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 been getting bored after two GCs, so it wasn't >> till Ivan mentioned the stickiness of the generated-function caches that I >> thought to turn it up to 5. > > This 5 number looks really odd. Do you have a simple way to reproduce > it? I'd love to have a look. The only hypothesis I immediately have > a long chain of JS wrapper - native something: wrapper gets collected, > releases native wrapper which makes another JS wrapper collectable... > >> This still seems like an opportunity for optimization — the >> WebCore::Document and WebCore::DOMWindow can have a lot of stuff hanging off >> of them, so we should try to clean them up more quickly after a same-process >> child tab closes. >> The sticky reference is actually to the v8::Context. The DOM objects hang on >> because they're pointed to by that context's globals. So if the context's >> globals could be cleared when Chrome's V8Proxy disposes the context, the DOM >> objects should go away at the next GC. >> Good news: There is a v8::Context::DetachGlobal method that appears to >> separate the globals from the context. Bad news: it doesn't appear to do >> what I expected it to. After it's called the context still seems to have a >> reference to the globals, because they still don't go away until later when >> the context is collected. >> I looked at the implementation, Bootstrapper::DetachGlobal >> (bootstrapper.cc:361) but I don't really understand what it's doing. The >> context internally has both a global() and a global_proxy() object, and this >> method seems to detach the latter but not the former. From the way they're >> created it looks like the global() points to the global_proxy(), explaining >> why there's still a connection after detaching. >> Is there a way I can sever the relationship from the context to the globals? >> Would it require adding a new V8 API method similar to DetachGlobal? >> (I did find one approach that sort of works: iterating over the global >> object's properties and removing them all. Unfortunately I can't use this >> because in some cases the V8Proxy requires the global object to stay intact >> after disposing the context, so it can be used with a new context, and at >> the point where the context is disposed I don't know whether that's going to >> happen or not.) > > There are indeed two global objects (and it is explicitly required by > HTML 5 and it's the way most of browser implements it): global object > proxy which forwards everything to a 'real' global object which is a > window. If you can give more explanations which of properties should > be retained after context disposal and when it's free to clear them, > that'd be really helpful. > > yours, > anton. > >> >> >> > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet wrote: > On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting > 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, into > the > > chrome, and eventually back into the page. > > I don't think most folks want tab from the omnibox to take you through > the menus, then bookmark buttons. I know that would drive me batty. I > could see some users wanting it, but I don't think it should be the > default. > I admit that I totally failed to think through "tab in the omnibox" -- I was thinking about all the other cases. That said, we've had TONS of requests to make tab from the omnibox work differently (i.e. "like how other browsers do it"): * When the popup is open, tab rotates through its items * Otherwise, tab moves to the next focusable element I kind of regret that we picked tab for "tab to search" because it prevents both of these, and I'm not sure we can change it now. It does seem like a bug somehow that you can tab into the omnibox but not out, but I don't know how to fix :( Perhaps we > also need the ability to assign accelerators to individual > bookmarks/extensions. This has been requested a few times, and brakowski suggested it long ago as a replacement for the "home" button -- if you can drag a bookmark onto your main toolbar, and give it an alt-home shortcut, then you have your own "home" button. PK --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
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 wrote: > > On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting wrote: >> On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour 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 is reopen closed tab and >> ctrl-shift-b is open bookmarks manager. > > I agree with Peter here. > >> 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, into the >> chrome, and eventually back into the page. > > I don't think most folks want tab from the omnibox to take you through > the menus, then bookmark buttons. I know that would drive me batty. I > could see some users wanting it, but I don't think it should be the > default. > > If all we care about is keyboard accessibility, then we should make > the accelerator that gives focus to the location bar tab through all > open bars. This addresses the issue of making everything reachable via > the keyboard, but it definitely requires a lot of tabbing. Perhaps we > also need the ability to assign accelerators to individual > bookmarks/extensions. > > -Scott > > > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
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 wrote: > > On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting wrote: >> On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour 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 is reopen closed tab and >> ctrl-shift-b is open bookmarks manager. > > I agree with Peter here. > >> 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, into the >> chrome, and eventually back into the page. > > I don't think most folks want tab from the omnibox to take you through > the menus, then bookmark buttons. I know that would drive me batty. I > could see some users wanting it, but I don't think it should be the > default. > > If all we care about is keyboard accessibility, then we should make > the accelerator that gives focus to the location bar tab through all > open bars. This addresses the issue of making everything reachable via > the keyboard, but it definitely requires a lot of tabbing. Perhaps we > also need the ability to assign accelerators to individual > bookmarks/extensions. > > -Scott > > > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting wrote: > On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour 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 is reopen closed tab and > ctrl-shift-b is open bookmarks manager. I agree with Peter here. > 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, into the > chrome, and eventually back into the page. I don't think most folks want tab from the omnibox to take you through the menus, then bookmark buttons. I know that would drive me batty. I could see some users wanting it, but I don't think it should be the default. If all we care about is keyboard accessibility, then we should make the accelerator that gives focus to the location bar tab through all open bars. This addresses the issue of making everything reachable via the keyboard, but it definitely requires a lot of tabbing. Perhaps we also need the ability to assign accelerators to individual bookmarks/extensions. -Scott --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
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 key. (I'm apologize for not knowing much about a11y.) On Tue, Sep 29, 2009 at 10:11 AM, Jonas Klink (Google) wrote: > + 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 wrote: >> >> I agree with James, ALT keys should be only used for accessibility, if we >> want to be able to allow keyboard shortcuts to other toolbars, we need to >> reorganize our current ones. It would be nice to have the following >> combinations: >> CTRL+SHIFT+T --- Main Toolbar >> CTRL+SHIFT+B --- Main Bookmarks bar >> CTRL+SHIFT+E --- Extension bar >> I wish we could use shorter `shortcuts`. I am working with Mr Klink >> trying to improve the keyboard shortcuts and accessibility within Chrome, >> and currently Chrome is disabling keyboard users accessing other tool bars, >> which is a problem. >> Any suggestions is highly appreciated. >> -Mohamed >> >> >> On Sat, Sep 26, 2009 at 9:00 PM, James Su wrote: >>> >>> >>> 2009/9/26 Jacob Mandelson On Sat, Sep 26, 2009 at 11:40:07AM -0400, Mohamed Mansour wrote: > Hi all, (need UI team feedback and other keyboard guru's) > We need a more coherent story for accessing various toolbars. The > current > toolbars that exist right now are: > > - Toolbar > - Bookmark bar > - Extension bar > - More in the future > > Currently ALT + SHIFT + T brings your focus to the toolbar, but there > is no > way to get to the others. This blocks keyboard users accessing the > other > bars which is kind of annoying if your a keyboard user. According to > Jonas > Klink (Accessibility guru) he said that shortcut was only a temporary > solution and would like to get rid of it and replace it with something > more > generic. So we need to think of a uniform access solution to all these > toolbars. [...] Maybe we could treat them akin to menus, and have Alt-SomeLetter go move the active focus to the bar? Alt-T and Alt-B seem unbound, but Alt-E (and not Alt-D) opens the Document menu. Alt-F opens the Wrench menu. >>> >>> Can we use some other key bindings rather than Alt- something? Alt is >>> used for activating accesskeys and already caused conflicts between some >>> accelerators. See http://crbug.com/21624. >>> -- Jacob >>> >> > > --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour 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 is reopen closed tab and ctrl-shift-b is open bookmarks manager. 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, into the chrome, and eventually back into the page. PK --~--~-~--~~~---~--~~ 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 Keyboard Access, opinions?
+ 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 wrote: > I agree with James, ALT keys should be only used for accessibility, if we > want to be able to allow keyboard shortcuts to other toolbars, we need to > reorganize our current ones. It would be nice to have the following > combinations: > CTRL+SHIFT+T --- Main Toolbar > CTRL+SHIFT+B --- Main Bookmarks bar > CTRL+SHIFT+E --- Extension bar > > I wish we could use shorter `shortcuts`. I am working with Mr Klink trying > to improve the keyboard shortcuts and accessibility within Chrome, and > currently Chrome is disabling keyboard users accessing other tool bars, > which is a problem. > > Any suggestions is highly appreciated. > > -Mohamed > > > > On Sat, Sep 26, 2009 at 9:00 PM, James Su wrote: > >> >> >> 2009/9/26 Jacob Mandelson >> >> >>> On Sat, Sep 26, 2009 at 11:40:07AM -0400, Mohamed Mansour wrote: >>> > Hi all, (need UI team feedback and other keyboard guru's) >>> > We need a more coherent story for accessing various toolbars. The >>> current >>> > toolbars that exist right now are: >>> > >>> >- Toolbar >>> >- Bookmark bar >>> >- Extension bar >>> >- More in the future >>> > >>> > Currently ALT + SHIFT + T brings your focus to the toolbar, but there >>> is no >>> > way to get to the others. This blocks keyboard users accessing the >>> other >>> > bars which is kind of annoying if your a keyboard user. According to >>> Jonas >>> > Klink (Accessibility guru) he said that shortcut was only a temporary >>> > solution and would like to get rid of it and replace it with something >>> more >>> > generic. So we need to think of a uniform access solution to all these >>> > toolbars. >>> [...] >>> >>> Maybe we could treat them akin to menus, and have Alt-SomeLetter go move >>> the active focus to the bar? >>> Alt-T and Alt-B seem unbound, but Alt-E (and not Alt-D) opens the >>> Document >>> menu. Alt-F opens the Wrench menu. >>> >> Can we use some other key bindings rather than Alt- something? Alt is used >> for activating accesskeys and already caused conflicts between some >> accelerators. See http://crbug.com/21624. >> >> >>> -- Jacob >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Memory] Help with v8::Context::DetachGlobal, please
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 that I thought to turn it up to 5. This still seems like an opportunity for optimization — the WebCore::Document and WebCore::DOMWindow can have a lot of stuff hanging off of them, so we should try to clean them up more quickly after a same-process child tab closes. The sticky reference is actually to the v8::Context. The DOM objects hang on because they're pointed to by that context's globals. So if the context's globals could be cleared when Chrome's V8Proxy disposes the context, the DOM objects should go away at the next GC. Good news: There is a v8::Context::DetachGlobal method that appears to separate the globals from the context. Bad news: it doesn't appear to do what I expected it to. After it's called the context still seems to have a reference to the globals, because they still don't go away until later when the context is collected. I looked at the implementation, Bootstrapper::DetachGlobal (bootstrapper.cc:361) but I don't really understand what it's doing. The context internally has both a global() and a global_proxy() object, and this method seems to detach the latter but not the former. From the way they're created it looks like the global() points to the global_proxy(), explaining why there's still a connection after detaching. Is there a way I can sever the relationship from the context to the globals? Would it require adding a new V8 API method similar to DetachGlobal? (I did find one approach that sort of works: iterating over the global object's properties and removing them all. Unfortunately I can't use this because in some cases the V8Proxy requires the global object to stay intact after disposing the context, so it can be used with a new context, and at the point where the context is disposed I don't know whether that's going to happen or not.) Thanks, —Jens --~--~-~--~~~---~--~~ 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 fails to update gyp files
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ć wrote:
> 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 78, in
> sys.exit(gyp.main(args))
> File "src/tools/gyp/pylib/gyp/__init__.py", line 406, in main
> params, options.check)
> File "src/tools/gyp/pylib/gyp/__init__.py", line 76, in Load
> depth, generator_input_info, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 1844, in Load
> depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 342, in LoadTargetBuildFile
> includes, depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 342, in LoadTargetBuildFile
> includes, depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 278, in LoadTargetBuildFile
> includes, True, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 170, in LoadOneBuildFile
> raise Exception("%s not found (cwd: %s)" % (build_file_path,
> os.getcwd()))
> Exception:
> /home/nebojsa/chromium/src/native_client/src/trusted/plugin/plugin_chrome.gyp
> not found (cwd: /home/nebojsa/chromium) while loading dependencies of
> /home/nebojsa/chromium/src/chrome/chrome.gyp while loading dependencies of
> /home/nebojsa/chromium/src/build/all.gyp while trying to load
> src/build/all.gyp
> failed to run command: /usr/bin/python src/build/gyp_chromium
>
> I am on amd64 machine, Ubuntu 9.04.
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] gclient fails to update gyp files
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 78, in
sys.exit(gyp.main(args))
File "src/tools/gyp/pylib/gyp/__init__.py", line 406, in main
params, options.check)
File "src/tools/gyp/pylib/gyp/__init__.py", line 76, in Load
depth, generator_input_info, check)
File "src/tools/gyp/pylib/gyp/input.py", line 1844, in Load
depth, check)
File "src/tools/gyp/pylib/gyp/input.py", line 342, in LoadTargetBuildFile
includes, depth, check)
File "src/tools/gyp/pylib/gyp/input.py", line 342, in LoadTargetBuildFile
includes, depth, check)
File "src/tools/gyp/pylib/gyp/input.py", line 278, in LoadTargetBuildFile
includes, True, check)
File "src/tools/gyp/pylib/gyp/input.py", line 170, in LoadOneBuildFile
raise Exception("%s not found (cwd: %s)" % (build_file_path,
os.getcwd()))
Exception:
/home/nebojsa/chromium/src/native_client/src/trusted/plugin/plugin_chrome.gyp
not found (cwd: /home/nebojsa/chromium) while loading dependencies of
/home/nebojsa/chromium/src/chrome/chrome.gyp while loading dependencies of
/home/nebojsa/chromium/src/build/all.gyp while trying to load
src/build/all.gyp
failed to run command: /usr/bin/python src/build/gyp_chromium
I am on amd64 machine, Ubuntu 9.04.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
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 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. 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; > right-click to download) and our HTML-based extensions would integrate > better (no need to be stuck in an extra tab on the side with jarringly > different UI compared to native controls). > > On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek wrote: >> For reference: http://code.google.com/p/chromium/issues/detail?id=5973 >> I'd be interested in helping out with this on the Mac side. I filed a Camino >> bug a couple of years ago about something similar. Safari has a helpful tool >> in Window --> Activity that allows you to download all resources of a page >> (including XHR and others loaded through JS). DevTools does something >> similar, but compared to Safari's interface it's slower and harder to find >> things (the entries in the list take up more vertical space). >> rsesek / @chromium.org >> >> On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) >> wrote: >>> >>> BTW I should note what I mean by "Uber Page Info Window". >>> >>> For some time, we've talked about improving the page info window in >>> Chrome. Right now it shows only the security information for a SSL >>> page. In the future we'd like to extend this to show other >>> information. The idea is there'd be a few tabs showing things like: >>> >>> - general page info in addition to security info >>> - web capabilities/permissions used by the page, along with the >>> ability to control these, including the effect of any active blacklist >>> - media attached to the page, which a convenient way to download >>> - eventually an additional surface for extensions to add tabs/features >>> based on content-script scanning of the page >>> >>> The idea anyway is for any web capability there'd be a toggle in here. >>> We also envisage some kind of app/extension page where one can visit >>> the properties/capabilities for an individual installed app/extension >>> too. >>> >>> Anyway any time the notion of site-specific capability control comes >>> up, the response from the UX team tends to be "uber page info window". >>> It's on our list, we just have been busy with other stuff. >>> >>> I mocked this some years ago in Firefox as a bottom bar >>> >>> http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window >>> but I am not advocating that approach necessarily. >>> >>> -Ben >>> >>> On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) >>> wrote: >>> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow >>> > wrote: >>> >> I had the same thoughts. Does Firefox not implement anything like >>> >> this? >>> >> Another question that this brings up: how could a user un-register >>> >> something >>> >> even if the web site doesn't do anything to make it possible? In other >>> >> words, we might need some piece of UI to remove registrations even >>> >> beyond >>> >> having an API for it. >>> > >>> > Uber page info dialog. >>> > >>> > -Ben >>> > >>> >>> >> >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 27487
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: 27479, 27480, 27481, 27482, 27483, 27484, 27485, 27486, 27487 Blame list: davemo...@chromium.org,dglaz...@chromium.org,lafo...@chromium.org,pinker...@chromium.org,rse...@chromium.org,s...@chromium.org,thoma...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
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 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. 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; > right-click to download) and our HTML-based extensions would integrate > better (no need to be stuck in an extra tab on the side with jarringly > different UI compared to native controls). > > On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek wrote: >> For reference: http://code.google.com/p/chromium/issues/detail?id=5973 >> I'd be interested in helping out with this on the Mac side. I filed a Camino >> bug a couple of years ago about something similar. Safari has a helpful tool >> in Window --> Activity that allows you to download all resources of a page >> (including XHR and others loaded through JS). DevTools does something >> similar, but compared to Safari's interface it's slower and harder to find >> things (the entries in the list take up more vertical space). >> rsesek / @chromium.org >> >> On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) >> wrote: >>> >>> BTW I should note what I mean by "Uber Page Info Window". >>> >>> For some time, we've talked about improving the page info window in >>> Chrome. Right now it shows only the security information for a SSL >>> page. In the future we'd like to extend this to show other >>> information. The idea is there'd be a few tabs showing things like: >>> >>> - general page info in addition to security info >>> - web capabilities/permissions used by the page, along with the >>> ability to control these, including the effect of any active blacklist >>> - media attached to the page, which a convenient way to download >>> - eventually an additional surface for extensions to add tabs/features >>> based on content-script scanning of the page >>> >>> The idea anyway is for any web capability there'd be a toggle in here. >>> We also envisage some kind of app/extension page where one can visit >>> the properties/capabilities for an individual installed app/extension >>> too. >>> >>> Anyway any time the notion of site-specific capability control comes >>> up, the response from the UX team tends to be "uber page info window". >>> It's on our list, we just have been busy with other stuff. >>> >>> I mocked this some years ago in Firefox as a bottom bar >>> >>> http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window >>> but I am not advocating that approach necessarily. >>> >>> -Ben >>> >>> On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) >>> wrote: >>> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow >>> > wrote: >>> >> I had the same thoughts. Does Firefox not implement anything like >>> >> this? >>> >> Another question that this brings up: how could a user un-register >>> >> something >>> >> even if the web site doesn't do anything to make it possible? In other >>> >> words, we might need some piece of UI to remove registrations even >>> >> beyond >>> >> having an API for it. >>> > >>> > Uber page info dialog. >>> > >>> > -Ben >>> > >>> >>> >> >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
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; right-click to download) and our HTML-based extensions would integrate better (no need to be stuck in an extra tab on the side with jarringly different UI compared to native controls). On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek wrote: > For reference: http://code.google.com/p/chromium/issues/detail?id=5973 > I'd be interested in helping out with this on the Mac side. I filed a Camino > bug a couple of years ago about something similar. Safari has a helpful tool > in Window --> Activity that allows you to download all resources of a page > (including XHR and others loaded through JS). DevTools does something > similar, but compared to Safari's interface it's slower and harder to find > things (the entries in the list take up more vertical space). > rsesek / @chromium.org > > On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) > wrote: >> >> BTW I should note what I mean by "Uber Page Info Window". >> >> For some time, we've talked about improving the page info window in >> Chrome. Right now it shows only the security information for a SSL >> page. In the future we'd like to extend this to show other >> information. The idea is there'd be a few tabs showing things like: >> >> - general page info in addition to security info >> - web capabilities/permissions used by the page, along with the >> ability to control these, including the effect of any active blacklist >> - media attached to the page, which a convenient way to download >> - eventually an additional surface for extensions to add tabs/features >> based on content-script scanning of the page >> >> The idea anyway is for any web capability there'd be a toggle in here. >> We also envisage some kind of app/extension page where one can visit >> the properties/capabilities for an individual installed app/extension >> too. >> >> Anyway any time the notion of site-specific capability control comes >> up, the response from the UX team tends to be "uber page info window". >> It's on our list, we just have been busy with other stuff. >> >> I mocked this some years ago in Firefox as a bottom bar >> >> http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window >> but I am not advocating that approach necessarily. >> >> -Ben >> >> On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) >> wrote: >> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow >> > wrote: >> >> I had the same thoughts. Does Firefox not implement anything like >> >> this? >> >> Another question that this brings up: how could a user un-register >> >> something >> >> even if the web site doesn't do anything to make it possible? In other >> >> words, we might need some piece of UI to remove registrations even >> >> beyond >> >> having an API for it. >> > >> > Uber page info dialog. >> > >> > -Ben >> > >> >> > > > > > --~--~-~--~~~---~--~~ 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: src.chromium.org is down
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 wrote: > 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: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] src.chromium.org is down
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: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Webkit Builder (dbg), revision 27470
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" on "Webkit Builder (dbg)" <=-- Revision: 27470 Blame list: m...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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] registerProtocolHandler HTML5 API
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 UI to manage this that doesn't require knowing a > magic about:protocols url? More than happy to have one if the UI gurus have something in mind, I was actively attempting to not change any UI element. > API: Is there an API to unregister from a protocol? No, as spec'd a webapp only announces it's availability by calling registerProtocolHandler when loaded. The UA must provide a mechanism for removing/announcing registration. > API: How does the page know it's registered? Why would it need to know? There's nothing it can change. > We should probably have a > separate API for this, so sites can display a more prominent call to action > when they're not registered. Beyond the infobar (which should be hidden on return navigations if the user has previously declined,but always available from about:protocols), what do you have in mind? Not having a means of suppressing this will make the site annoying. > Misc: Should there be some way for native apps to register as protocol > handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS > provide this? The OS provides hooks for some protocols. I mentioned this in the tail end of the script; I'm not sure how happy users would be to see Chrome populating their registry with protocol handlers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
