Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline -open-in-new-window switch
At least on Linux, this is currently a feature that we visibly lack compared to Firefox (and pretty much every other browser). In GNOME browsers tell the desktop environment how to open links in new windows as well as new tabs, or that they can't do that (like us), and the UI for selecting which browser to use lets the user specify which behavior to use when clicking links in other applications. This works by providing command line options to use when the links are clicked. Since we can't do that, those options are grayed out in that UI when you select Chrome. I think it would be nice to support this feature. On Dec 12, 2009, at 1:01 AM, Peter Kasting wrote: On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth clem...@endorphin.org wrote: http://codereview.chromium.org/464060 adds the small one-line feature to open an URL in a new window from commandline Can any review these changes? Please read http://dev.chromium.org/developers/contributing-code . In particular, because the original bug here has never been triaged, you need to get approval from the UI team that the idea is one we want implemented. Then, if that goes well, you need to pick a particular reviewer to review your patch. chromium-reviews is a CC list that tracks code reviews, not a direct mailing list to ask for reviewers on. In this particular case, the patch doesn't solve what I perceive to be the original bug as stated (provide an option to open all links in new windows) because it provides a command-line option that external programs can use to open new windows, but nothing to deal with links opened within the browser. Also, I'm not sure this is behavior that we want to add command-line switches for; we try and avoid these unless they're truly necessary. 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: Clear Strict-Transport-Security state checkbox added
There's a published paper about it too: http://www.adambarth.com/papers/2008/jackson-barth.pdf On Thu, Sep 17, 2009 at 4:34 PM, Robert Sesek rse...@chromium.org wrote: It clears the list of hosts in StrictTransportSecurityState: // StrictTransportSecurityState // // Tracks which hosts have enabled StrictTransportSecurityState. After a host // enables StrictTransportSecurityState, then we refuse to talk to the host // over HTTP, treat all certificate errors as fatal, and refuse to load any // mixed content. // rsesek / @chromium.org On Thu, Sep 17, 2009 at 7:28 PM, Erik Kay erik...@chromium.org wrote: For those of us who are curious, could someone explain what this does? Erik On Thu, Sep 17, 2009 at 4:20 PM, Finnur Thorarinsson fin...@chromium.org wrote: +1 to what Peter is saying. Like Brett, I have no clue what this checkbox means and think it shouldn't have been added. However, the question I have... is it appropriate to tuck this in with something like deleting the history (like we do with last session, recently closed tabs, autogenerated keywords, etc)? It is hard for me to evaluate that, not knowing what this does... :) -F On Thu, Sep 17, 2009 at 16:09, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:54 PM, Brett Wilson bre...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:50 PM, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley a...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: Whoever added this UI, please remove it before I have to when I get back next week. Very well, reverting. Why not #ifdef around it? I fear if you revert you'll never check it in again. If that happens, it's the best possible argument that this is a silly thing to add. No, it's just the argument that it's not the sort of thing people are willing to expend the energy to argue about. With this sort of response I'd be tempted to just give up on the patch. --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On Wed, Sep 16, 2009 at 12:59 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 12:44 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 02:23 PM, Evan Martin wrote: What is the error message? I wonder if there is something Linux-specific where we're getting an error code that is harmless. (We've had a lot of that in code that checks errno where the value differs between Linux and OS X.) User says it reports: [5070:5093:8302515214:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090910svn25958/src/chrome/common/sqlite_utils.cc(52)] Check failed: false. sqlite fatal error 11 Hm, that doesn't sound good! #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... --~--~-~--~~~---~--~~ 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: Crashes due to 25633
One of the things I've done is to *find* all of our changes and try to separate them out from one another, so that should help. (I've created a set of patch files which contain all the changes compared to vanilla 3.6.18.) Some of our changes had been sent upstream already, and of those, some have now been merged. I don't know much about exactly why we have all the changes we do though, so I'm not really the best one to make a case for them in sending them upstream. Hopefully we can track down the authors of these patches though, and ask them to push them upstream. --Mike On Wed, Sep 16, 2009 at 1:21 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 04:07 PM, Mike Mammarella wrote: FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... This is good news, but FWIW, this is also a big reason why forking from established upstreams can lead to headaches. Is there any chance of reworking the chromium specific sqlite changes into something that upstream might merge? ~spot --~--~-~--~~~---~--~~ 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: Platform parity
Actually the Linux version already had the dialog, and the OS X version doesn't need it (at the moment) since there is no built-in password manager. So I think the bug is closed. --Mike On Tue, Sep 1, 2009 at 10:44 PM, Peter Kastingpkast...@google.com wrote: On Tue, Sep 1, 2009 at 8:04 PM, Tim Steele t...@chromium.org wrote: I don't think all[platforms]-or-nothing would have really fair to insist on :\ I don't think any person who wants to contribute to chromium should be required to have either a machine and/or skills required for each platform to test things out on, or be dedicated enough to have to solve everything instead of little chunks that they are immediately passionate about fixing; every little bit helps in my book. Could we just keep the bug (labelled OS-All) open? I agree with this. 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: desktop notifications, preliminary code for review
On Linux you could probably get this effect by using the notify-send utility: http://manpages.ubuntu.com/manpages/gutsy/man1/notify-send.1.html http://www.galago-project.org/specs/notification/0.9/index.html --Mike On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? --~--~-~--~~~---~--~~ 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] creating desktop shortcuts
There should also already be a desktop file for Chrome/Chromium on the system; you might consider using it as a template in order to create the desktop shortcut. You can find it by searching a set of directories given by the environment variables $XDG_DATA_HOME and $XDG_DATA_DIRS, the former defaulting to $HOME/.local/share and the latter being a colon-separated search path defaulting to /usr/local/share:/usr/share. Within each directory you'd look for a subdirectory named applications that contains desktop files. (This info comes from the XDG site.) As for the correct name for the desktop file, check out chrome/browser/shell_integration_linux.cc which has to do this to figure out whether we are the default browser or not. There is a bit of an issue when you're running an unpackaged version you just compiled; in that case, unless you run it with chrome-wrapper instead of just chrome there might not be a desktop file at all. (See chrome/tools/build/linux/chrome-wrapper which is copied alongside the binary when you compile.) But that's probably OK. --Mike On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Yes, but even then we need to know how the launcher is named. Hardcoding google-chrome is not good for chromium builds (and we are going to have Chromium packaged for Gentoo). Having it chromium for Chromium is also not good, because of the conflict with Chromium (the game). On Tue, Aug 4, 2009 at 13:18, Evan Martin e...@chromium.org wrote: E.g. this successfully starts xeyes when you click on it. [Desktop Entry] Version=1.0 Encoding=UTF-8 Name=test.txt Type=Application Exec=xeyes Name[en_US]=test.txt On Tue, Aug 4, 2009 at 1:17 PM, Evan Martine...@chromium.org wrote: Do we need a full path? I think desktop files know to search $PATH for executables. On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: There is one problem with creating desktop shortcuts on Linux: getting correct path to the launcher script. Gears find Firefox launcher using which: http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc Currently Chromium needs the launcher for correct library path to load custom ffmpeg libraries. The launcher may be at different locations on different distros. Do you have ideas what to do? I was thinking about patching some file for each distro with the correct path... but it's not the most elegant solution. --~--~-~--~~~---~--~~ 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] creating desktop shortcuts
Yeah, there's not much you can do in that case. For the default browser setting, when there's no desktop file it just claims that it's the default browser to avoid bothering you about it every time. Fortunately that case should only occur with people running unpackaged versions and not using that wrapper script. (Or for people with really broken packages...) Perhaps the error message could suggest running it with the wrapper for the feature to work though? --Mike On Tue, Aug 4, 2009 at 1:37 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Thanks. Looks like a good solution. How about a case when there is no desktop file? I don't have better idea than displaying an error message. On Tue, Aug 4, 2009 at 13:28, Mike Mammarella m...@chromium.org wrote: There should also already be a desktop file for Chrome/Chromium on the system; you might consider using it as a template in order to create the desktop shortcut. You can find it by searching a set of directories given by the environment variables $XDG_DATA_HOME and $XDG_DATA_DIRS, the former defaulting to $HOME/.local/share and the latter being a colon-separated search path defaulting to /usr/local/share:/usr/share. Within each directory you'd look for a subdirectory named applications that contains desktop files. (This info comes from the XDG site.) As for the correct name for the desktop file, check out chrome/browser/shell_integration_linux.cc which has to do this to figure out whether we are the default browser or not. There is a bit of an issue when you're running an unpackaged version you just compiled; in that case, unless you run it with chrome-wrapper instead of just chrome there might not be a desktop file at all. (See chrome/tools/build/linux/chrome-wrapper which is copied alongside the binary when you compile.) But that's probably OK. --Mike On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Yes, but even then we need to know how the launcher is named. Hardcoding google-chrome is not good for chromium builds (and we are going to have Chromium packaged for Gentoo). Having it chromium for Chromium is also not good, because of the conflict with Chromium (the game). On Tue, Aug 4, 2009 at 13:18, Evan Martin e...@chromium.org wrote: E.g. this successfully starts xeyes when you click on it. [Desktop Entry] Version=1.0 Encoding=UTF-8 Name=test.txt Type=Application Exec=xeyes Name[en_US]=test.txt On Tue, Aug 4, 2009 at 1:17 PM, Evan Martine...@chromium.org wrote: Do we need a full path? I think desktop files know to search $PATH for executables. On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: There is one problem with creating desktop shortcuts on Linux: getting correct path to the launcher script. Gears find Firefox launcher using which: http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc Currently Chromium needs the launcher for correct library path to load custom ffmpeg libraries. The launcher may be at different locations on different distros. Do you have ideas what to do? I was thinking about patching some file for each distro with the correct path... but it's not the most elegant solution. --~--~-~--~~~---~--~~ 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: Compiler warnings?
gcc/g++ have __attribute__((warn_unused_result)) that you can specify on a per-function basis: http://www.ohse.de/uwe/articles/gcc-attributes.html#func-warn_unused_result Or do you mean warnings when a function is supposed to return a value but does not have a return statement at the end? --Mike On Thu, Jul 23, 2009 at 4:09 PM, Ben Laurieb...@google.com wrote: I just fixed a bug that wouldn't have happened at all if missing return values were flagged ... is there a way to turn on compiler warnings (building on Linux using make)? Is there some reason they're not on by default? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] help with gyp?
Hi all, I'm trying to add a file which needs to be processed autoconf-style at compile time. It's a script with things like @@FOO@@ that are values known at the time gyp runs, but which should actually be substituted during the compile when the .in version of the script is processed and written to the output directory. (This is only for the Linux port.) It looks like the !() feature will only run a command when gyp runs, not when the build system later runs, so using that would mean that changes to the .in file would not be taken up unless gyp is rerun. For files that don't need this processing, I could use the copies facility in gyp, but I can't figure out how to tell it to process the file (e.g. with sed -e 's/@@FOO@@/(FOO)/g' or something) when the build system runs. Anyone know how to do this? Thanks, --Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
