Initial gtk3 support

content/browser/browser_main_loop.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/browser_main_loop.h"
 
 #include "base/bind.h"
 #include "base/command_line.h"
 #include "base/location.h"
 #include "base/logging.h"
@@ skipping 222 matching lines @@
     LOG(ERROR) << "DConf settings backend could not connect to session bus: "
                << "http://crbug.com/179797";
   } else if (strstr(message, "Attempting to store changes into") ||
              strstr(message, "Attempting to set the permissions of")) {
     LOG(ERROR) << message << " (http://bugs.chromium.org/161366)";
   } else if (strstr(message, "drawable is not a native X11 window")) {
     LOG(ERROR) << message << " (http://bugs.chromium.org/329991)";
   } else if (strstr(message, "Cannot do system-bus activation with no user")) {
     LOG(ERROR) << message << " (http://crbug.com/431005)";
   } else {
-    LOG(DFATAL) << log_domain << ": " << message;

[Elliot Glaysher, 2015/09/01 22:43:58]

You'll want to revert back to DFATAL and whitelist the specific error messages
here.

[knthzh, 2015/09/02 05:48:29]

Why are glib logs being filtered this way? Can I convert log_level to a Chrome
log level instead and remove this whole whitelist?

[Elliot Glaysher, 2015/09/03 19:28:01]

Because of GTK's permissiveness.

GTK has the annoying property that a lot of things that should be fatal errors,
such as array out of bounds errors (!), are treated as non-fatal. If you open
pretty much any other program written with GTK on the console, you will usually
see a complete spew of state invariant errors.

(The correct action is almost always to crash as soon as you know that something
is wrong. Most attempts to recover from a state invariant failure just cause the
failure to migrate somewhere else.)

[knthzh, 2015/09/04 00:15:18]

Well then.

I'm still skeptical about this, though. I have a bad premonition of a future
gtk3 upgrade doing something that slips through this whitelist and forces
everyone to scramble to get an emergency patch out.

I also personally want to reduce the differences between all the various Linux
configurations (including ChromeOS). I don't think it's fair for the Chrome team
to have to integrate with every single toolkit like this when the Linux
ecosystem as a whole is already such a minority in the first place.

For developers working on the gtk port, there's --g-fatal-warnings. Is that good
enough? https://developer.gnome.org/gtk3/stable/gtk-running.html

[Elliot Glaysher, 2015/09/09 17:58:10]

Yes. That is the story of this list.
I agree with you that it isn't fair. That the entire situation on the Linux
desktop is ridiculous. I too wanted to minimize the differences between the
various chrome ports. Seeing that porting the full gtk2 chrome to gtk3 was
entirely infeasible was the main catalyst for why I jumped on replacing as much
of the linux UI with the cross-platform views UI, leaving only small stubs here
and there to deal with the things that have to stay gtk.

After spending several days looking at the linking issues, it'll be a long time
before we can really separate out this module and dlopen() different versions of
it (if ever). gtk2 vs gtk3 will probably have to stay a compile time flag.
Realistically, the various distros will probably ship gtk3 compiled chromium
first before Google ships a Chrome build with it switched on.

It would be nice to get rid of gtk entirely, but that's not realistic. There's
native dialogs, IMEs and printing support. And there's the integration with
theming which was our big goodwill gesture to the Linux community, which was why
we went to such trouble to get this working when we stopped using gtk2 natively
for all the UI.
There are two problems with g-fatal-warnings. We want to ignore some of these.
(GTK icon errors failures are actually surprisingly common. So are Ubuntu Menu
Proxy errors.) And then there's the issue that it isn't on by default and I
don't think the average chrome engineer will remember to pass --g-fatal-warnings
on top of all the other things they have to remember to do.

+    LOG(ERROR) << log_domain << ": " << message;
   }
 }
 
 static void SetUpGLibLogHandler() {
   // Register GLib-handled assertions to go through our logging system.
   const char* kLogDomains[] = { NULL, "Gtk", "Gdk", "GLib", "GLib-GObject" };
   for (size_t i = 0; i < arraysize(kLogDomains); i++) {
     g_log_set_handler(kLogDomains[i],
                       static_cast<GLogLevelFlags>(G_LOG_FLAG_RECURSION |
                                                   G_LOG_FLAG_FATAL |
@@ skipping 1107 matching lines @@
   DCHECK(is_tracing_startup_);
 
   is_tracing_startup_ = false;
   TracingController::GetInstance()->DisableRecording(
       TracingController::CreateFileSink(
           startup_trace_file_,
           base::Bind(OnStoppedStartupTracing, startup_trace_file_)));
 }
 
 }  // namespace content