[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to gyp,
I'm going to (try to) land two changes now that you should be aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the new
'chrome' target instead of 'app', and Linux developers who have been typing
'hammer app' (or 'make app' if you're using the Makefile generator) will
need to type 'hammer chrome' ('make chrome'). The default behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any local
settings you've configured into the old 'chrome_exe' project will NOT be
transferred to the new 'chrome' project. You'll have to make a note of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have to be
reverted if unintended side effects pop up. I'll send out confirming email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Viewvc on src.chromium.org is down
Hello, we've had a couple of problems with viewvc on src.chromium.org in the last day, so I turned it off for now. I'll try to fix it in the next hours. in the mean time you can still use src.chromium.org to fetch your files, and http://src.chromium.org/svn to browse the repo. Thanks 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] Re: Viewvc on src.chromium.org is down
back online thanks Nicolas On Thu, Jun 18, 2009 at 10:56 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, we've had a couple of problems with viewvc on src.chromium.org in the last day, so I turned it off for now. I'll try to fix it in the next hours. in the mean time you can still use src.chromium.org to fetch your files, and http://src.chromium.org/svn to browse the repo. Thanks 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] 2.0.172 update next month
I plan to do a maintenance update to 172 on the Stable channel next month. If you know of bug fixes that should be included, please add the *Merge-Stable label* to the bug. I'll review fixes and pick up many as I can without adding too much risk. Thanks, 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: changing chrome_exe to chrome, converting chrome.exe to gyp
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to gyp,
I'm going to (try to) land two changes now that you should be aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the new
'chrome' target instead of 'app', and Linux developers who have been typing
'hammer app' (or 'make app' if you're using the Makefile generator) will
need to type 'hammer chrome' ('make chrome'). The default behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any local
settings you've configured into the old 'chrome_exe' project will NOT be
transferred to the new 'chrome' project. You'll have to make a note of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have to be
reverted if unintended side effects pop up. I'll send out confirming email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp
I'm also noticing that every time I do a build/debug, it's rebuilding
a LOT of the libraries even though nothing has changed.
On Jun 18, 12:43 pm, Daniel Cowx daniel.c...@gmail.com wrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to gyp,
I'm going to (try to) land two changes now that you should be aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator) will
need to type 'hammer chrome' ('make chrome'). The default behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any
local
settings you've configured into the old 'chrome_exe' project will NOT be
transferred to the new 'chrome' project. You'll have to make a note of
any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have to
be
reverted if unintended side effects pop up. I'll send out confirming
email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: What's the TabRestoreUITest bug 1215881?
Thank Nicolas for your clarify.
Today I find the exception in
AutocompleteEditViewWin::EraseTopOfSelection is caused by the rong
compiler option of 2.0.172.28 official build.
autocomplete_edit_view_win.cc:
HDC BeginPaintIntercept(HWND hWnd, LPPAINTSTRUCT lpPaint) {
BOOL EndPaintIntercept(HWND hWnd, const PAINTSTRUCT* lpPaint) {
These two intercepting win32 API are not explicitly defined as
__stdcall, and are wrongly compiled as __cdecl:
chrome_1c3!`anonymous namespace'::BeginPaintIntercept:
021ea88f
021ea8b5 c3 ret
021ea8c4 c3 ret
chrome_1c3!`anonymous namespace'::EndPaintIntercept:
021ea8c5
021ea8d7 c3 ret
021ea8e6 c3 ret
This is harmless on windows XP, because the corrupted esp is restored
by riched20!RichEditWndProc's leave instruction, and the corrupted esi/
edi/ebx are restored by USER32!InternalCallWinProc.
But it's a disaster on windows 2000, because the corrupted ebx (which
keeps the AutocompleteEditViewWin this point in
AutocompleteEditViewWin::OnPaint) is not restored by USER32!
UserCallWinProc or by USER32!CallWindowProcAorW.
Nicolas Sylvain wrote:
I filed this bug with this comment:--
TabRestoreUITest.RestoreToDifferentWindow fails on win2k debug. I disabled
it.
This is not reproducible outside the buildbot environment.
The problem seems to be that chrome cannot access a font. I was not able to
determine what the font was.
---
Later on I fixed it, but forgot to remove the comment.
This bug was only for debug mode, it should not matter for release mode.
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] sandboxing external libraries (like Growl)
Hi all, I'm working on a desktop notifications javascript API for web apps; on Mac these calls will go out to the Growl notification system if it's installed and user has granted permission to get notifications from that origin. I'm still trying to completely grasp the sandbox architecture, so the question I need some input on is how to design the integration with respect to sandboxing security. The Growl code that would be included in Chrome is just a stub that works by marshalling data over to a separate Growl process, so the surface area is small, but as a design question, is calling to a third-party library something that should happen in the sandboxed renderer process, or should it be kept in the browser process? One other factor is that the notification requires an icon to be downloaded, which should happen outside the sandbox. So there are two possible flows: A. renderer gets notification(iconURL, text) call = hop to browser to download icon = call Growl from browser B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer My instinct is that B is safer for the remote possibility that Growl chokes on the input and causes a crash. What do people think? Is there an existing precedent for similar library calls? Thanks, -John --~--~-~--~~~---~--~~ 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: sandboxing external libraries (like Growl)
The basic rule of thumb: minimize parsing of content downloaded from the web. So, for instance, we delegate to a renderer to download and decode favicons. We then send the resultant bitmap up to the browser so it can display it in the UI. In this case, what does it mean to call Growl from the renderer? Do the functions you would call require access to the system? If they do, then presumably the sandbox should not be allowing such access. -Darin On Thu, Jun 18, 2009 at 1:58 PM, John Gregg john...@google.com wrote: Hi all, I'm working on a desktop notifications javascript API for web apps; on Mac these calls will go out to the Growl notification system if it's installed and user has granted permission to get notifications from that origin. I'm still trying to completely grasp the sandbox architecture, so the question I need some input on is how to design the integration with respect to sandboxing security. The Growl code that would be included in Chrome is just a stub that works by marshalling data over to a separate Growl process, so the surface area is small, but as a design question, is calling to a third-party library something that should happen in the sandboxed renderer process, or should it be kept in the browser process? One other factor is that the notification requires an icon to be downloaded, which should happen outside the sandbox. So there are two possible flows: A. renderer gets notification(iconURL, text) call = hop to browser to download icon = call Growl from browser B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer My instinct is that B is safer for the remote possibility that Growl chokes on the input and causes a crash. What do people think? Is there an existing precedent for similar library calls? Thanks, -John --~--~-~--~~~---~--~~ 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: sandboxing external libraries (like Growl)
On Thu, Jun 18, 2009 at 4:58 PM, John Gregg john...@google.com wrote: Hi all, I'm working on a desktop notifications javascript API for web apps; on Mac these calls will go out to the Growl notification system if it's installed and user has granted permission to get notifications from that origin. I'm still trying to completely grasp the sandbox architecture, so the question I need some input on is how to design the integration with respect to sandboxing security. The Growl code that would be included in Chrome is just a stub that works by marshalling data over to a separate Growl process, so the surface area is small, but as a design question, is calling to a third-party library something that should happen in the sandboxed renderer process, or should it be kept in the browser process? One other factor is that the notification requires an icon to be downloaded, which should happen outside the sandbox. So there are two possible flows: A. renderer gets notification(iconURL, text) call = hop to browser to download icon = call Growl from browser B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer My instinct is that B is safer for the remote possibility that Growl chokes on the input and causes a crash. What do people think? Is there an existing precedent for similar library calls? B won't (shouldn't) work because of the sandboxing, if the renderer can talk to the Growl helper app, there's a vector open for talking to any application. TVL Thanks, -John --~--~-~--~~~---~--~~ 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: What's the TabRestoreUITest bug 1215881?
On Thu, Jun 18, 2009 at 1:53 PM, pi zhu.she...@gmail.com wrote:
Today I find the exception in
AutocompleteEditViewWin::EraseTopOfSelection is caused by the rong
compiler option of 2.0.172.28 official build.
autocomplete_edit_view_win.cc:
HDC BeginPaintIntercept(HWND hWnd, LPPAINTSTRUCT lpPaint) {
BOOL EndPaintIntercept(HWND hWnd, const PAINTSTRUCT* lpPaint) {
These two intercepting win32 API are not explicitly defined as
__stdcall, and are wrongly compiled as __cdecl:
chrome_1c3!`anonymous namespace'::BeginPaintIntercept:
021ea88f
021ea8b5 c3 ret
021ea8c4 c3 ret
chrome_1c3!`anonymous namespace'::EndPaintIntercept:
021ea8c5
021ea8d7 c3 ret
021ea8e6 c3 ret
This should be fixed regardless of win2k support. You should file a bug for
this. Feel free to attach a patch that adds stdcall declarations.
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: changing chrome_exe to chrome, converting chrome.exe to gyp
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in
the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure
the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to
gyp,
I'm going to (try to) land two changes now that you should be aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the
new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator)
will
need to type 'hammer chrome' ('make chrome'). The default behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any
local
settings you've configured into the old 'chrome_exe' project will NOT
be
transferred to the new 'chrome' project. You'll have to make a note of
any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have
to be
reverted if unintended side effects pop up. I'll send out confirming
email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: sandboxing external libraries (like Growl)
On Thu, Jun 18, 2009 at 1:58 PM, John Greggjohn...@google.com wrote: B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer Obviously on Linux we'll be using some DBus service for the notification rather than Growl, but this design (calling the service from the renderer) will /not/ work on Linux. AGL --~--~-~--~~~---~--~~ 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: sandboxing external libraries (like Growl)
Yes, on Linux the plan is the use the libnotify library, which is a DBus service. Thanks for all the responses; it's clear this needs to be thought of more like a system call than an untrusted library, and the better plan is to check inputs including icon data in the renderer as much as possible, than pass that to the browser to invoke the library. Thanks, -John On Thu, Jun 18, 2009 at 2:24 PM, Adam Langley a...@chromium.org wrote: On Thu, Jun 18, 2009 at 1:58 PM, John Greggjohn...@google.com wrote: B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer Obviously on Linux we'll be using some DBus service for the notification rather than Growl, but this design (calling the service from the renderer) will /not/ work on Linux. AGL --~--~-~--~~~---~--~~ 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: sandboxing external libraries (like Growl)
(resending from the right address) John, You definitely want to be careful with the image download. Since you'll be handing it off to another (not sandboxed) process (Growl for mac, DBus for Linux), you need to do some sanity checking on the image by transcoding it in a sandboxed process. Otherwise, an malicious image may be able to compromise the process you hand it off to and gain access to the machine. We're doing this transcoding for themes and extensions via the utility process (check out utility_process_host.cc as a starting point). The idea is that the image you get from the web may be malicious or just poorly formed, and by transcoding it, you can detect these problems and limit the damage to a sandboxed process. Erik On Thu, Jun 18, 2009 at 1:58 PM, John Gregg john...@google.com wrote: Hi all, I'm working on a desktop notifications javascript API for web apps; on Mac these calls will go out to the Growl notification system if it's installed and user has granted permission to get notifications from that origin. I'm still trying to completely grasp the sandbox architecture, so the question I need some input on is how to design the integration with respect to sandboxing security. The Growl code that would be included in Chrome is just a stub that works by marshalling data over to a separate Growl process, so the surface area is small, but as a design question, is calling to a third-party library something that should happen in the sandboxed renderer process, or should it be kept in the browser process? One other factor is that the notification requires an icon to be downloaded, which should happen outside the sandbox. So there are two possible flows: A. renderer gets notification(iconURL, text) call = hop to browser to download icon = call Growl from browser B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer My instinct is that B is safer for the remote possibility that Growl chokes on the input and causes a crash. What do people think? Is there an existing precedent for similar library calls? Thanks, -John --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
Another missing dependency, in the runtime sense, is unit_tests
on test_chrome_plugin. Right now if you just compile that project from a
clean build, it'll crash.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in
the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure
the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to
gyp,
I'm going to (try to) land two changes now that you should be aware
of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the
new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator)
will
need to type 'hammer chrome' ('make chrome'). The default behaviors
of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any
local
settings you've configured into the old 'chrome_exe' project will NOT
be
transferred to the new 'chrome' project. You'll have to make a note
of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have
to be
reverted if unintended side effects pop up. I'll send out confirming
email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: What's the TabRestoreUITest bug 1215881?
filed the bug: http://code.google.com/p/chromium/issues/detail?id=14631 --~--~-~--~~~---~--~~ 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: sandboxing external libraries (like Growl)
Note that libgrowl must at some point reach out to the system, either via an IPC to some process that can display notifications or to display the notifications itself, and both of those ought to be prevented by the sandobx. On Thu, Jun 18, 2009 at 2:33 PM, John Greggjohn...@google.com wrote: Yes, on Linux the plan is the use the libnotify library, which is a DBus service. Thanks for all the responses; it's clear this needs to be thought of more like a system call than an untrusted library, and the better plan is to check inputs including icon data in the renderer as much as possible, than pass that to the browser to invoke the library. Thanks, -John On Thu, Jun 18, 2009 at 2:24 PM, Adam Langley a...@chromium.org wrote: On Thu, Jun 18, 2009 at 1:58 PM, John Greggjohn...@google.com wrote: B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer Obviously on Linux we'll be using some DBus service for the notification rather than Growl, but this design (calling the service from the renderer) will /not/ work on Linux. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] chrome.bookmarks.remove will crash Chrome
[I duplicated this post in the transition period for the extension group. ] This problem seems fixed in 3.0.183.x, but returned in 3.0.189.0. Maybe add a regression test for it? Being unable to remove a bookmark item makes it clumsy to use bookmark to store user settings. Any comments? --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in
the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly, so
make sure you gclient sync after you git pull, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure
the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to
gyp,
I'm going to (try to) land two changes now that you should be aware
of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the
new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator)
will
need to type 'hammer chrome' ('make chrome'). The default behaviors
of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different, any
local
settings you've configured into the old 'chrome_exe' project will NOT
be
transferred to the new 'chrome' project. You'll have to make a note
of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have
to be
reverted if unintended side effects pop up. I'll send out confirming
email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp
Yeah it happened to me before as well, I just figured I'd complain now..
Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote:
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in
the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly,
so
make sure you gclient sync after you git pull, or whatever the
right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure
the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to
gyp,
I'm going to (try to) land two changes now that you should be aware
of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the
new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator)
will
need to type 'hammer chrome' ('make chrome'). The default behaviors
of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use
the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different,
any local
settings you've configured into the old 'chrome_exe' project will NOT
be
transferred to the new 'chrome' project. You'll have to make a note
of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have
to be
reverted if unintended side effects pop up. I'll send out confirming
email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp
2009/6/18 Jeremy Orlow jor...@google.com
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
I, too, had this problem (theme.dll not being built) _before_ this change
and I didn't bring it up for the same reason as Jeremy ;-)
Also, when I use increbuild (this is again before the change. and I haven't
updated my tree after sgk's checkin) to do a clobber-build, header files
supposed to be generated out of grd are not generated and I have to build
related projects manually.
Jungshik
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in
the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly,
so
make sure you gclient sync after you git pull, or whatever the
right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure
the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to
gyp,
I'm going to (try to) land two changes now that you should be aware
of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for the
new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator)
will
need to type 'hammer chrome' ('make chrome'). The default behaviors
of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use
the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different,
any local
settings you've configured into the old 'chrome_exe' project will NOT
be
transferred to the new 'chrome' project. You'll have to make a note
of any
custom settings before updating and re-apply them to the new 'chrome'
project.
There's always the chance that one or both of these changes will have
to be
reverted if unintended side effects pop up. I'll send out confirming
email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote:
Yeah it happened to me before as well, I just figured I'd complain now..
Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, these are missing dependencies on ui_tests.
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote:
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings in
the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work properly,
so
make sure you gclient sync after you git pull, or whatever the
right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make
sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe
to gyp,
I'm going to (try to) land two changes now that you should be aware
of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for
the new
'chrome' target instead of 'app', and Linux developers who have been
typing
'hammer app' (or 'make app' if you're using the Makefile generator)
will
need to type 'hammer chrome' ('make chrome'). The default behaviors
of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use
the
'chrome' project, instead of the former 'chrome_exe' project. NOTE:
because the underlying .vcproj file will be completely different,
any local
settings you've configured into the old 'chrome_exe' project will
NOT be
transferred to the new 'chrome' project. You'll have to make a note
of any
custom settings before updating and re-apply them to the new
'chrome'
project.
There's always the chance that one or both of these changes will
have to be
reverted if unintended side effects pop up. I'll send out
confirming email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp
I'll see if I can repro this again before filing a bug, but similar to what
Daniel and John reported, when I right click on test_shell and say Build it
builds the minimal set required to fully build+link test_shell.exe
However when I set test_shell as the start-up project and launch the
debugger, Visual Studio warns that every other project in chrome.sln must be
built before running (not true!). Is there a difference in build vs.
runtime dependencies?
Andrew
On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote:
All--
When you notice missing dependencies, pleased add them to the necessary
.gyp file(s)! One of the main reasons we've been trying to land all this
stuff is so that tracking down all these pieces isn't single-threaded
through one person (or two). If you're not comfortable making the change
yourself, then please file a bug so the dependency problems get tracked and
fixed in an organized fashion.
Re: unnecessary rebuilds: please file bugs so they don't get lost.
Please include the target you were building, and the the libs/targets that
were rebuilt unnecessarily. You don't have to be exhaustive about the list,
it's more important here that at least some information gets collected and
doesn't languish on the ML or get dropped on the floor.
I'm working on a buildbot script that will test for missing dependencies by
building every target from scratch individually, and will then test for
unnecessary rebuilds by rebuilding each target after no updates. That's
been taking a back seat to just getting the conversion completed, but I've
accelerated my work on it as we wind down to the last few targets.
--SK
On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.orgwrote:
Yeah it happened to me before as well, I just figured I'd complain now..
Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, these are missing dependencies on ui_tests.
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote:
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek
j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx
daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings
in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work
properly, so
make sure you gclient sync after you git pull, or whatever the
right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make
sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe
to gyp,
I'm going to (try to) land two changes now that you should be
aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for
the new
'chrome' target instead of 'app', and Linux developers who have
been typing
'hammer app' (or 'make app' if you're using the Makefile
generator) will
need to type 'hammer chrome' ('make chrome'). The default
behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use
the
'chrome' project, instead of the former 'chrome_exe' project.
NOTE:
because the underlying .vcproj file will be completely different,
any local
settings you've configured into the old 'chrome_exe' project will
NOT be
transferred to the new 'chrome' project. You'll have to make a
note of any
custom settings before updating and re-apply them to the new
'chrome'
project.
There's always the chance that one or both of these changes will
have to be
reverted if unintended side effects pop up. I'll send out
confirming email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or
[chromium-dev] Heads up: Clobber required for disabling TR1 in windows
I'll be upgrading googletest to r267 and googlemock to r173 in order to break our tr1 dependency on windows, and one rtti dependency in linux/mac. When I land the patch to set _HAS_TR1=0 on windows, it will necessitate a full clober to fix the precompiled headers. Over the last couple of weeks, Zhanyong added multiple patches to to hack around the tr1 issues on gcc and msvs. In r267, he added a subset of tr1::tuple so that we no longer need either boost or tr1 in visual studio. IN r265 of googlemock, he added a hack to disable a suprious include of tr1/functional from tr1/tuple (this is apparently fixed in later versions of gcc) that was forcing rtti to be enabled due to a use of typeid. This upgrade should fix the compatibility issues MSVS 2008 users hav been having due to bad tr1 interactions with various bits of code. It also moves us closer to killing rtti. I'm going to try to get this change landed tonight so it can bake over friday. If I don't get it in tonight, I'll wait until next week. Let me know if there are any questions or issues. -Albert --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
I'll add the dependencies I was complaining about :)
On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote:
All--
When you notice missing dependencies, pleased add them to the necessary
.gyp file(s)! One of the main reasons we've been trying to land all this
stuff is so that tracking down all these pieces isn't single-threaded
through one person (or two). If you're not comfortable making the change
yourself, then please file a bug so the dependency problems get tracked and
fixed in an organized fashion.
Re: unnecessary rebuilds: please file bugs so they don't get lost.
Please include the target you were building, and the the libs/targets that
were rebuilt unnecessarily. You don't have to be exhaustive about the list,
it's more important here that at least some information gets collected and
doesn't languish on the ML or get dropped on the floor.
I'm working on a buildbot script that will test for missing dependencies by
building every target from scratch individually, and will then test for
unnecessary rebuilds by rebuilding each target after no updates. That's
been taking a back seat to just getting the conversion completed, but I've
accelerated my work on it as we wind down to the last few targets.
--SK
On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.orgwrote:
Yeah it happened to me before as well, I just figured I'd complain now..
Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, these are missing dependencies on ui_tests.
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote:
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek
j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx
daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings
in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work
properly, so
make sure you gclient sync after you git pull, or whatever the
right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make
sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe
to gyp,
I'm going to (try to) land two changes now that you should be
aware of:
1) convert the 'app' target in the chrome.gyp file to being named
'chrome'. 2) actually convert the 'chrome_exe' project to using a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for
the new
'chrome' target instead of 'app', and Linux developers who have
been typing
'hammer app' (or 'make app' if you're using the Makefile
generator) will
need to type 'hammer chrome' ('make chrome'). The default
behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to use
the
'chrome' project, instead of the former 'chrome_exe' project.
NOTE:
because the underlying .vcproj file will be completely different,
any local
settings you've configured into the old 'chrome_exe' project will
NOT be
transferred to the new 'chrome' project. You'll have to make a
note of any
custom settings before updating and re-apply them to the new
'chrome'
project.
There's always the chance that one or both of these changes will
have to be
reverted if unintended side effects pop up. I'll send out
confirming email
with the final state of things.
--SK
--~--~-~--~~~---~--~~
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: Heads up: Clobber required for disabling TR1 in windows
On Thu, Jun 18, 2009 at 3:51 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: This upgrade should fix the compatibility issues MSVS 2008 users hav been having due to bad tr1 interactions with various bits of code. It also moves us closer to killing rtti. What else needs rtti? Do we have a bug open on killing it? --~--~-~--~~~---~--~~ 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: Heads up: Clobber required for disabling TR1 in windows
2009/6/18 Evan Martin e...@chromium.org On Thu, Jun 18, 2009 at 3:51 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: This upgrade should fix the compatibility issues MSVS 2008 users hav been having due to bad tr1 interactions with various bits of code. It also moves us closer to killing rtti. What else needs rtti? Do we have a bug open on killing it? base/hash_table.h pulls in tr1/functional which uses typeid. -Albert --~--~-~--~~~---~--~~ 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: V8 Generated Constructors
Ok, so. So far I've created a new file V8HTMLAudioElementConstructor.cpp and modeled it off V8HTMLImageElementConstructor.cpp (changing all images to audios, plus modified V8CustomBinding.h and webkit.gyp. Change is here: http://codereview.chromium.org/132036 But I'm still getting TypeError: Illegal constructor when I try to call the audio constructor. Is there another hook I'm missing? On Jun 16, 11:47 am, Dimitri Glazkov dglaz...@google.com wrote: A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor Thanks. --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
Andrew, can you give an example of something that built that shouldn't have
for test_shell? Maybe we have some overspecified dependencies as well.
-BradN
On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.orgwrote:
I'll see if I can repro this again before filing a bug, but similar to what
Daniel and John reported, when I right click on test_shell and say Build it
builds the minimal set required to fully build+link test_shell.exe
However when I set test_shell as the start-up project and launch the
debugger, Visual Studio warns that every other project in chrome.sln must be
built before running (not true!). Is there a difference in build vs. runtime
dependencies?
Andrew
On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote:
All--
When you notice missing dependencies, pleased add them to the necessary
.gyp file(s)! One of the main reasons we've been trying to land all this
stuff is so that tracking down all these pieces isn't single-threaded
through one person (or two). If you're not comfortable making the change
yourself, then please file a bug so the dependency problems get tracked and
fixed in an organized fashion.
Re: unnecessary rebuilds: please file bugs so they don't get lost.
Please include the target you were building, and the the libs/targets that
were rebuilt unnecessarily. You don't have to be exhaustive about the list,
it's more important here that at least some information gets collected and
doesn't languish on the ML or get dropped on the floor.
I'm working on a buildbot script that will test for missing dependencies
by building every target from scratch individually, and will then test for
unnecessary rebuilds by rebuilding each target after no updates. That's
been taking a back seat to just getting the conversion completed, but I've
accelerated my work on it as we wind down to the last few targets.
--SK
On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.orgwrote:
Yeah it happened to me before as well, I just figured I'd complain now..
Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin
btw just to be clear, these are missing dependencies on ui_tests.
On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.comwrote:
I actually had this problem _before_ this change. Guess I should have
brought it up, but I figured it was just something funny on my system.
On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek
j...@chromium.orgwrote:
+1 this is affecting a lot of people.
On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx
daniel.c...@gmail.comwrote:
I notice that when I load chrome.sln and do a build, not all the
dependencies are built anymore. For instance, theme_dll isn't built
(not listed in the proj deps), is this expected?
On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote:
Okay, it looks like this change is sticking, at least until someone
discovers Yet Another Unintended Side Effect. So heed the warnings
in the
previous message, quoted below.
Git users on Linux: this requires an update to gyp to work
properly, so
make sure you gclient sync after you git pull, or whatever the
right
combination of commands is. If you see Python stack traces from
gyp
accompanied by complaints about looking up a Dir as a File, make
sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
wrote:
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert
chrome.exe to gyp,
I'm going to (try to) land two changes now that you should be
aware of:
1) convert the 'app' target in the chrome.gyp file to being
named
'chrome'. 2) actually convert the 'chrome_exe' project to using
a
gyp-generated chrome.vcproj file, instead of the checked-in one.
When the first change lands, Mac developers will need to look for
the new
'chrome' target instead of 'app', and Linux developers who have
been typing
'hammer app' (or 'make app' if you're using the Makefile
generator) will
need to type 'hammer chrome' ('make chrome'). The default
behaviors of
building everything should be unaffected.
When the second change lands, Visual Studio users will need to
use the
'chrome' project, instead of the former 'chrome_exe' project.
NOTE:
because the underlying .vcproj file will be completely
different, any local
settings you've configured into the old 'chrome_exe' project will
NOT be
transferred to the new 'chrome' project. You'll have to make a
note of any
custom settings before updating and re-apply them to the new
'chrome'
project.
There's always the chance that one or both of these changes will
have to be
reverted if unintended side effects pop up. I'll send out
[chromium-dev] Re: V8 Generated Constructors
My only quick suggestion would be: did you try a clobber build? My experience with bindings is they never seem to incrementally build or link very well :( On Thu, Jun 18, 2009 at 4:05 PM, kylep ky...@chromium.org wrote: Ok, so. So far I've created a new file V8HTMLAudioElementConstructor.cpp and modeled it off V8HTMLImageElementConstructor.cpp (changing all images to audios, plus modified V8CustomBinding.h and webkit.gyp. Change is here: http://codereview.chromium.org/132036 But I'm still getting TypeError: Illegal constructor when I try to call the audio constructor. Is there another hook I'm missing? On Jun 16, 11:47 am, Dimitri Glazkov dglaz...@google.com wrote: A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor Thanks. --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. There was a thread on chromium-dev about it a few weeks ago, which is why you probably didn't hear more people complain. --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
I'll add the dependencies I was complaining about :)
John just came by with some questions, so in the interests of sharing
information more widely, here's the executive summary for adding
dependencies you notice missing:
- There's no distinction in gyp between build-time and run-time
dependencies.
- If a target needs something built by another target at build time *or*
run-time, it needs to be added to the (a) 'dependencies' section of the
relevant target's dictionary.
- You refer to another target as a dependency just by name if it's in the
same .gyp file:
'dependencies': [
'other_target',
],
Or by filename.gyp:target if it's in another .gyp file:
'dependencies': [
'../other/other.gyp:other_target',
],
- Other .gyp file names are always specified relative to the .gyp file
you're in.
- If the dependency is only applicable to a single platform (Windows) it
needs to go down in a conditions section, usually towards the bottom of the
target's dictionary:
'conditions': [
['OS==win', {
'dependencies': [
'../other/other.gyp:other_target',
],
}],
],
- Yes, navigating the nested dictionaries and lists can drive you a
little bonkers.
Don't hesitate to ask for help or ask questions.
--SK
--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp
Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.comwrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.orgwrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.orgwrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.comwrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.orgwrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the dependencies are built anymore. For instance, theme_dll isn't built (not listed in the proj deps), is this expected? On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote: Okay, it looks like this change is sticking, at least until someone discovers Yet Another Unintended Side Effect. So heed the warnings in the previous message, quoted below. Git users on Linux: this requires an update to gyp to work properly, so make sure you gclient sync after you git pull, or whatever the right combination of commands is. If you see Python stack traces from gyp accompanied by complaints about looking up a Dir as a File, make sure the tools/gyp subdirectory is at r521. --SK On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org wrote: Heads up, again, dept.: In the next in an ongoing series of attempts to convert chrome.exe to gyp, I'm going to (try to) land two changes now that you should be aware of: 1) convert the 'app' target in the chrome.gyp file to being named 'chrome'. 2) actually convert the 'chrome_exe' project to using a gyp-generated chrome.vcproj file, instead of the checked-in one. When the first change lands, Mac developers will need to look for the new 'chrome' target instead of 'app', and Linux developers who have been typing 'hammer app' (or 'make
[chromium-dev] resource_dispatcher_host warning spam
My console is filled with: WARNING:chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found I filed this bug: http://code.google.com/p/chromium/issues/detail?id=14494 But I don't know how to track down the problem, or what it even means. --~--~-~--~~~---~--~~ 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: V8 Generated Constructors
Ok, that didn't work. On Jun 18, 4:11 pm, Andrew Scherkus scher...@chromium.org wrote: My only quick suggestion would be: did you try a clobber build? My experience with bindings is they never seem to incrementally build or link very well :( On Thu, Jun 18, 2009 at 4:05 PM, kylep ky...@chromium.org wrote: Ok, so. So far I've created a new file V8HTMLAudioElementConstructor.cpp and modeled it off V8HTMLImageElementConstructor.cpp (changing all images to audios, plus modified V8CustomBinding.h and webkit.gyp. Change is here: http://codereview.chromium.org/132036 But I'm still getting TypeError: Illegal constructor when I try to call the audio constructor. Is there another hook I'm missing? On Jun 16, 11:47 am, Dimitri Glazkov dglaz...@google.com wrote: A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor Thanks. --~--~-~--~~~---~--~~ 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: V8 Generated Constructors
You're almost there. You also need to make sure to register it in v8_proxy.cpp (look for Image as a pattern to follow). BTW, with gyp, dependencies in bindings are pretty robust. No need to clobber anymore. :DG On Thu, Jun 18, 2009 at 4:05 PM, kylepky...@chromium.org wrote: Ok, so. So far I've created a new file V8HTMLAudioElementConstructor.cpp and modeled it off V8HTMLImageElementConstructor.cpp (changing all images to audios, plus modified V8CustomBinding.h and webkit.gyp. Change is here: http://codereview.chromium.org/132036 But I'm still getting TypeError: Illegal constructor when I try to call the audio constructor. Is there another hook I'm missing? On Jun 16, 11:47 am, Dimitri Glazkov dglaz...@google.com wrote: A good place to start would be to look at existing *Constructor.cpp files in WebCore/bindings/v8 and see how they are hooked in (like Image constructor). Also, you have dimich and levin in close proximity you who have added a V8 constructor or two in the past (I think). ;DG On Mon, Jun 15, 2009 at 5:47 PM, Kyle Preteky...@chromium.org wrote: Hey I'm looking into these layout tests: LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-constructor.html LayoutTests/media/constructors.html and I need to know how constructors are generated. The failures all appear to be due to the Audio constructor, specifically: TypeError: Illegal constructor Thanks. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
