Initial gtk3 support

content/browser/browser_main_loop.cc

Index: content/browser/browser_main_loop.cc
diff --git a/content/browser/browser_main_loop.cc b/content/browser/browser_main_loop.cc
index b5159df02a3e91b640f71dc37d0e5e82f77e634a..9754b8485f53e0cabb4f3055d7ff789a698af6c7 100644
--- a/content/browser/browser_main_loop.cc
+++ b/content/browser/browser_main_loop.cc
@@ -240,7 +240,7 @@ static void GLibLogHandler(const gchar* log_domain,
   } 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;
   }
 }