The ultimate goal is to eliminate TOOLKIT_USES_GTK. Once that migration is completed, TOOLKIT_VIEWS + OS_LINUX should be enough.
Until this happens, we need a binary that:
1) has both gtk and pure-views
2) can enable pure views components with --use-pure-views when possible (this is default in touchui=1).
If we could switch everything with --use-pure-views, that'd be nice, but the world is not perfect and there are things that cannot co-exist (such as message pump). For such component, we'll use GYP_DEFINES to switch.
1) TOOLKIT_USES_PURE_VIEWS is defined with toolkit_pure_views=1.
2) all (or most of) chrome features must be functional with toolkit_pure_views=1
3) both TOOLKIT_USES_GTK and TOOLKIT_USES_PURE_VIEWS are defined. The latter has higher priority (that is, if implementation can't co-exists, TOOLKIT_USE_PURE_VIEWS will take precedence).
4) As the migration proceeds, there will be less TOOLKIT_USES_GTK and more TOOLKIT_USES_PURE_VIEWS.
5) Once the migration is complete (that is, there is no TOOKIT_USES_GTK), we can remove TOOLKIT_USES_PURE_VIEWS or replace it with OS_LINUX when necessary.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7273079
git-svn-id: http://src.chromium.org/svn/trunk/src/build@91164 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add runtime flag to control smooth scrolling. Add compile time flag handling for a GYP_DEFINE (enable_smooth_scrolling=1).
BUG=575,61140
TEST=compile still works without the flag. Compiling with the flag works once the WebKit change is landed, and then the flag appears in the about:flags page, and actually turns on that WebKit implementation.
Review URL: http://codereview.chromium.org/7034052
git-svn-id: http://src.chromium.org/svn/trunk/src/build@90136 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In addition to these rules, to build
the USE_SKIA_ON_MAC_CHROME variation,
define: gyp_defines='use_skia=1'
As is, this does not change any existing
platform, and has no new tests.
BUG=79463
TEST=none
Review URL: http://codereview.chromium.org/7219009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@89877 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Notable changes in the range:
* r132735 (hopefully) fixes a bug introduced in r131951 that made
gold 1.10 crash with
/usr/bin/ld: internal error in set_offset, at output.cc:4030
* r132535 fixes the crash at -O3 on mac
* r132565 adds a warning for "x + y ? a : b" to -Wparentheses
BUG=85289,84424
TEST=none
TBR=evan
Review URL: http://codereview.chromium.org/7046048
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88344 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
clang recently added a warning that warns when invoking 'delete' on a polymorphic non-final class without a virtual destructor. This finds real bugs – see the bug referenced below for a few examples.
However, one common pattern where it fires is this case:
class SomeInterface {
public:
virtual void interfaceMethod() {} // or = 0;
protected:
~SomeInterface() {}
}
class WorkerClass : public SomeInterface {
public:
// many non-virtual functions, but also:
virtual void interfaceMethod() override { /* do actual work */ }
};
void f() {
scoped_ptr<WorkerClass> c(new WorkerClass); // simplified example
}
(See the 2nd half of http://www.gotw.ca/publications/mill18.htm for an explanation of this pattern.)
It is arguably correct to fire the warning here, since someone might make a subclass of WorkerClass and replace |new WorkerClass| with |new WorkerClassSubclass|. This would be broken since WorkerClass doesn't have a virtual destructor.
The solution that the clang folks recommend is to mark WorkerClass as |final| (a c++0x keyword that clang supports as an extension in normal c++ mode – like override). But chrome's base/OWNERS deemed that as too complicated and we decided to make virtual the destructors of leaf classes that implement these interfaces and that are deleted dynamically. All of the changes in this CL are to shut up the warning, not because of real problems (I fixed these in separate CLs).
(For the gtk files, this is necessary because the CHROMEGTK_CALLBACK_ macros add virtual functions.)
BUG=84424
TEST=none
Review URL: http://codereview.chromium.org/7087028
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88270 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The OS-level registration isn't implemented on Linux, and so every time the
browser starts it will act as though another program has been registered to
handle the protocols it knows about and deregister them all internally.
Review URL: http://codereview.chromium.org/7024043
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88246 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In chrome/browser/task_manager I moved notifications related code to their own files and allow exclusion and stubbing via GYP. Similarly I have added stubs for other parts including a chrome/browser/notifications/notification_stubs.cc which takes care of classes within that directory.
I also created some static methods in DesktopNotificationService to wrap commonly used notification related code so that we reduce the amount of stubs required.
BUG=none
TEST=existing notification tests succeed
Review URL: http://codereview.chromium.org/7053041
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88040 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This change implements a settings page that allows users to manage protocol
handlers registered via navigator.registerProtocolHandler.
tony: could you review the ProtocolHandlerRegistry stuff?
estade: could you review the webui stuff?
Thanks!
TEST=Unit tests provided.
Review URL: http://codereview.chromium.org/7033018
git-svn-id: http://src.chromium.org/svn/trunk/src/build@86762 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
is just a prototype for us to play with. There are plenty of issues to
resolve before its made real, but I wanted to check something in for
others to play with rather than keeping it all local. To get it to
compile you need to set the GYP_DEFINE to views_compositor.
BUG=none
TEST=none
R=ben@chromium.org,apatrick@chromium.org
Review URL: http://codereview.chromium.org/7067029
git-svn-id: http://src.chromium.org/svn/trunk/src/build@86516 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Chromium has also been built on other BSDs, so rather than adding each Unix to every gyp file individually every time another port is added, these broad defines can be used instead and modified with specific logic only where necessary.
I included a few modified gyp files so the usage can be seen. I also added sunos5 to some grd/html files and set the default host_arch on i86pc solaris to ia32.
BUG=0
TEST={}
Patch by ruben <chromium@hybridsource.org>.
Review URL: http://codereview.chromium.org/6965007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@85154 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With ICF the linker merges identical functions into one block of assembly,
which leads to
a) wrong symbols for some functions - which is debugger/Valgrind-unfriendly
b) all ThreadSanitizer annotations end up being one function which makes TSan crazy.
Since we run release code (with -O1 -g) on Valgrind bots,
we have to disable ICF if release_valgrind_build!=0.
BUG=82114
TEST=linux_tsan trybot goes green
TEST=`gclient runhooks` with and w/o GYP_DEFINES="release_valgrind_build=1"
and `grep "\-\-icf" base/base.target.mk`
Review URL: http://codereview.chromium.org/7004005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84833 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With ICF the linker merges identical functions into one block of assembly,
which leads to
a) wrong symbols for some functions - which is debugger/Valgrind-unfriendly
b) all ThreadSanitizer annotations end up being one function which makes TSan crazy.
Since we run release code (with -O1 -g) on Valgrind bots,
we have to disable ICF if release_valgrind_build!=0.
BUG=82114
TEST=linux_tsan trybot goes green
Review URL: http://codereview.chromium.org/6991009TBR=timurrrr@chromium.org
Review URL: http://codereview.chromium.org/6995026
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84804 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With ICF the linker merges identical functions into one block of assembly,
which leads to
a) wrong symbols for some functions - which is debugger/Valgrind-unfriendly
b) all ThreadSanitizer annotations end up being one function which makes TSan crazy.
Since we run release code (with -O1 -g) on Valgrind bots,
we have to disable ICF if release_valgrind_build!=0.
BUG=82114
TEST=linux_tsan trybot goes green
Review URL: http://codereview.chromium.org/6991009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84802 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Mark says: "When GCC_STRICT_ALIASING is YES, Xcode adds -fstrict-aliasing to the compiler command line. When it’s NO, it doesn’t add anything (not even -fno-strict-aliasing). Xcode doesn’t know that -fstrict-aliasing is on at our selected optimization level."
So add this directly to OTHER_CLFAGS.
BUG=32204
TEST=none
Review URL: http://codereview.chromium.org/6909037
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84064 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This requires disabling most /W4 warnings so the patch doesn't get too large.
I still fixed a few bugs so I didn't have to disable some more serious warnings. Most of these warnings are already enabled on gcc so it's mostly windows-specific code that is affected.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/6902069
git-svn-id: http://src.chromium.org/svn/trunk/src/build@83840 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
saintlou@chromium.org
fta@sofaraway.org
cevans@chromium.org
scottbyer@chromium.org
caryclark@chromium.org
wjmaclean@chromium.org
jamesr@chromium.org
thakis@chromium.org
jam@chromium.org
koz@chromium.org
satish@chromium.org
piman@chromium.org
jknotten@chromium.org
tony@chromium.org
nirnimesh@chromium.org
nirnimesh@google.com
sky@chromium.org
hashimoto@chromium.org
evan@chromium.org
mdm@chromium.org
mark@chromium.org
rkc@chromium.org
timurrrr@chromium.org
bradnelson@google.com
maruel@chromium.org
raymes@chromium.org
rvargas@google.com
penghuang@chromium.org
zelidrag@chromium.org