[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 -~--~~~~--~~--~--~---
[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 Laurie 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] 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. 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 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 Martin 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. 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. 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 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. >> 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 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 Martin 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. 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: 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 Martin wrote: > > On Wed, Aug 5, 2009 at 3:51 PM, John Gregg 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: 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 Kasting wrote: > On Tue, Sep 1, 2009 at 8:04 PM, Tim Steele 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: Enabling --disable-hang-monitor for new windows when Chrome is already running
Perhaps rather than disabling the hang monitor altogether what that could do is add an additional option to the warning the first time: "don't notify me again." If you click that, then it will disable the hang monitor until the plugin is once again responsive and then becomes unresponsive again. (Or maybe even until the plugin terminates.) That avoids the need to have a plugin be trusted in any way, but keeps the UI simple unless the plugin knows it wants to display it and get debugged. You'd still have to deal with the dialog once but after that it would get out of your way. --Mike On Fri, Sep 11, 2009 at 3:41 PM, Scott Hess wrote: > > Another alternative would be a "ping" type call to say "I'm > unresponsive, and I mean it." Like a watchdog timer. The plug-in > could still effectively be hung, but at least it has to have things > together enough to call the watchdog. > > -scott > > > On Fri, Sep 11, 2009 at 3:37 PM, John Abd-El-Malek wrote: >> For reference, something similar is done for popups: >> void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); >> void NPN_PopPopupsEnabledState(NPP instance); >> Perhaps we can do the same thing here: >> void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); >> void NPN_Pop PluginHangDetectorState(NPP instance); >> On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin wrote: >>> >>> On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. >>> >>> I was thinking something like this for my case (substitute appropriate >>> method names): >>> NPN_SetPluginWarning(false); >>> processSocketMessages(); >>> NPN_SetPluginWarning(true); >>> and trying to call NPN_SetPluginWarning where you didn't request that >>> permission in the manifest would fail. >>> >>> -- >>> John A. Tamplin >>> Software Engineer (GWT), Google >>> >>> >> >> >> > >> > > > > --~--~-~--~~~---~--~~ 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 wrote: > > On Wed, Sep 16, 2009 at 12:44 PM, spotrh 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 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: "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 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 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 >> 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 wrote: >> >> >> >> On Thu, Sep 17, 2009 at 3:54 PM, Brett Wilson >> >> wrote: >> >> > On Thu, Sep 17, 2009 at 3:50 PM, Evan Martin >> >> > wrote: >> >> >> >> >> >> On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley >> >> >> wrote: >> >> >>> >> >> >>> On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) >> >> >>> 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 -~--~~~~--~~--~--~---
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 > 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
