Re: [chromium-dev] revised output for run_webkit_tests
On Thu, Dec 10, 2009 at 11:28 PM, David Levin le...@chromium.org wrote: On Thu, Dec 10, 2009 at 10:57 PM, Dirk Pranke dpra...@chromium.org wrote: We could do this, but we'd have to add logic to track when directories were done, and arbitrarily delay printing results about other directories (hence delaying and serializing results). This might end up causing weirdly irregular bursts of output. The irregular bursts of output isn't that bad. (I had a version of run-webkit-test that did this. Unfortunately, perl is not a fun language for me at least, and I have to admit that the perl code I had would have been hard to maintain/fragile.) Worst case, since we intentionally run the http tests first, and they're the long pole in the run, this might delay printing all the other directories until near the end. Not a big deal either. My version did this as well. (I started this behavior in my webkit version and talked to Ojan about doing it.) Well, I can certainly try to hack up a version of the script that generates the output you're looking for to see how it works. I'm not sure what the real benefit of this would be. The benefit is working in a community and understanding how they do things and adapting to that as opposed to trying to push something very different on them. Sure. Of course, there's not necessarily a reason to leave things the same just because that's the way it's always been done, especially when trying to keep things the same imposes costs. Sometimes different is better. (A) Have you looked at the new output yet? (B) Is getting output by directory really that useful? I understood your description. Having run the webkit version, I much prefer it due to knowing when certain directories are done and knowing what test(s) failed in those directories as the test goes along (even in the parallel version where the failures may be slightly delayed). The output by directory also adapts better to the buildbot output instead of the huge test-by-test list that chromium buildbots have (which takes a while to download when you click the link for stdio). There's no arguing that the --verbose output is in fact extremely verbose. But, that is because there is a lot of information there. Personally, I find the webkit output a bad compromise between terseness and verbosity - it's too much text for interactive use where you expect things to pass, and too little if you actually want to debug what happened. In particular I think this would be very true in a multithreaded scenarios, since you would lose any grasp of what was actually happening in parallel. The current implementation tells you that tests have failed as it goes, but not which tests (of course, the webkit script doesn't tell you either, apart from which directory the failure might be in). That would be easy to add if there is demand. dave -- Dirk On Thu, Dec 10, 2009 at 10:10 PM, David Levin le...@chromium.org wrote: Actually, you can have a similar output even with the multi-threading. You can display the results for one only directory (even though multiple directories are being processed at the same time) and when that directory is done, display the results for the next directory until it is done, etc. The ordering of the directories may be different but the output is very similar to what they have now. The effect is quite satisfying and clear. dave On Thu, Dec 10, 2009 at 10:04 PM, Dirk Pranke dpra...@chromium.org wrote: Yes, I did consider that. The fatal flaw in that plan is that the webkit test script is single-threaded and runs through the tests in order. Ours doesn't, and so we can't easily guarantee the same sort of output they have. Eric and I will probably work through this as we upstream the code. I'm actually hoping to get them to adopt my output, but we'll see. -- Dirk On Thu, Dec 10, 2009 at 7:45 PM, David Levin le...@chromium.org wrote: Have you considered making the output closer to that of WebKit's run-webkit-tests? It seems that would ease the hopeful transition to this version upstream. dave On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, If you never run the webkit layout tests, you can stop reading. Otherwise, earlier today I checked in a patch that should make the output much less verbose in the normal case. From the CL: First, a number of log messages have had their levels changed (mostly to make them quieter). Second, the script outputs a meter that shows progress through the test run, which is a one line summary of where it's at current (e.g. parsing expectations, gathering files. During the actual test execution, the meter displays %d tests completed as expected, %d didn't, %d remain. The meter uses carriage returns but no linefeeds, so the output is overwritten as it progresses. The meter is disabled if
Re: [chromium-dev] Re: Building chromium for arm--erroring out
2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I get an Illegal Instruction. I restart and I can now see chrome as shown in the attachment but I cannot browse. When I reload the page, it again kills chrome saying Illegal instruction. Has anyone seen this before? I have my proxy settings set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. Any help is highly appreciated. Thanks, Sofia On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley j...@chromium.org wrote: On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen sofia.tahs...@gmail.com wrote: /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so when searching for -lrt The errors are indicative of trying to link against libraries from a different platform. To confirm: check the output of $ 'file /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so I suspect it will tell you it's a symbolic link to /lib/librt.so.1, which itself is a symbolic link to /lib/librt-2.10.2.so - note these paths are relative to /, not to your sysroot directory. You have two slightly solutions - adjust the symlinks in sys-root/usr/lib so they point to the files in sys-root//lib - replace the smymlinks with the actual libraries, ie copy files from sys-root/lib to sys-root/usr/lib I would be happy to hear a neater solution for this, but the above worked for me. Cheers, Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: [WebGL] Recommending --no-sandbox
(Resending from chromium.org) On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote: After reading the WebGL blog post today, and following the link to the wiki, it struck me as fairly *bad* that we are telling people to disable the sandbox. A good number of folks are going to disable the sandbox and forget that they had ever done so. I don't follow. The --no-sandbox command line argument only takes effect for the current invocation of the browser. Most people launch Chrome or Chromium from its icon, which will not have that argument associated with it. Once we can support WebGL in the sandbox, what will we do? It would be nice if we could somehow restore the sandbox automatically. But renaming --no-sandbox doesn't seem like a great choice, and it isn't a scalable solution for other things like this that come up in the future. We will just remove the --no-sandbox option from that wiki page, and people testing WebGL will eventually stop specifying it. Perhaps --enable-webgl should instead implicitly disable the sandbox today so that tomorrow, when WebGL just works, folks won't have to change any command line options to restore sandbox functionality. I can see a counter argument that people should have to explicitly opt-in to disabling the sandbox, but I'm not sure that out-weighs the cost of having a good number of dev channel users running *permanently* without the sandbox. Was this idea considered? Any other ideas? I considered this but rejected it because it might lull people into a false sense of security -- thinking that they had just enabled WebGL but were actually browsing without the sandbox. The best solution is to get the GPU process in place on all platforms, at which point WebGL can be run inside the sandbox; this is a high priority for me and others. -Ken -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Webkit Mac Builder, revision 34337
Automatically closing tree for compile on Webkit Mac Builder http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac%20Builder/builds/6 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Mac%20Builder --= Automatically closing tree for compile on Webkit Mac Builder =-- Revision: 34337 Blame list: yu...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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] [WebGL] Recommending --no-sandbox
This is exactly what I was thinking. An infobar is the right choice in my opinion. Having a modal dialog on startup for those who use this switch regularly due to issues, should not be suddenly have a *really annoying* modal dialog every time they start their browser. An infobar, on the other hand, is informative enough to make people be aware that their are using it and a learn more link to how to turn it off (in case they were once instructed to do so for support purposes and did not turn it off since then) would be the best solution here. ☆PhistucK On Fri, Dec 11, 2009 at 07:49, Finnur Thorarinsson fin...@chromium.orgwrote: I wonder... should we show an infobar on startup when the sandbox is disabled? On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote: After reading the WebGL blog post today, and following the link to the wiki, it struck me as fairly *bad* that we are telling people to disable the sandbox. A good number of folks are going to disable the sandbox and forget that they had ever done so. Once we can support WebGL in the sandbox, what will we do? It would be nice if we could somehow restore the sandbox automatically. But renaming --no-sandbox doesn't seem like a great choice, and it isn't a scalable solution for other things like this that come up in the future. Perhaps --enable-webgl should instead implicitly disable the sandbox today so that tomorrow, when WebGL just works, folks won't have to change any command line options to restore sandbox functionality. I can see a counter argument that people should have to explicitly opt-in to disabling the sandbox, but I'm not sure that out-weighs the cost of having a good number of dev channel users running *permanently* without the sandbox. Was this idea considered? Any other ideas? -Darin -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell k...@chromium.org wrote: (Resending from chromium.org) On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote: After reading the WebGL blog post today, and following the link to the wiki, it struck me as fairly *bad* that we are telling people to disable the sandbox. A good number of folks are going to disable the sandbox and forget that they had ever done so. I don't follow. The --no-sandbox command line argument only takes effect for the current invocation of the browser. Most people launch Chrome or Chromium from its icon, which will not have that argument associated with it. On Windows, the most common way for people to launch with arguments is to add them to a short cut. The risk is that they'd do this to their main shortcut and then forget about it. Once we can support WebGL in the sandbox, what will we do? It would be nice if we could somehow restore the sandbox automatically. But renaming --no-sandbox doesn't seem like a great choice, and it isn't a scalable solution for other things like this that come up in the future. We will just remove the --no-sandbox option from that wiki page, and people testing WebGL will eventually stop specifying it. _New_ users will stop specifying it, but I doubt people will be regularly checking the wiki page. Perhaps --enable-webgl should instead implicitly disable the sandbox today so that tomorrow, when WebGL just works, folks won't have to change any command line options to restore sandbox functionality. I can see a counter argument that people should have to explicitly opt-in to disabling the sandbox, but I'm not sure that out-weighs the cost of having a good number of dev channel users running *permanently* without the sandbox. Was this idea considered? Any other ideas? I considered this but rejected it because it might lull people into a false sense of security -- thinking that they had just enabled WebGL but were actually browsing without the sandbox. The best solution is to get the GPU process in place on all platforms, at which point WebGL can be run inside the sandbox; this is a high priority for me and others. We definitely know this is true, and I think it's even safe to assume this will be true for other features in the future that only work with the sandbox off initially. The problem is the time before this is true. As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. The solution to this is either the annoying/scary UI can't be disabled/clicked-through/etc (like a red and white striped theme that can't be overridden) or to pop up a modal dialog or info bar periodically (it could even be once an hour or even day) in addition to popping it up initially. In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur said Also, when thinking about options 1 and 2 above (changing the appearance of Chrome) I can't help but think of someone pitching WebGL (which currently doesn't work in the sandbox) to their development team and the audience asking 'why is your browser all red?'. Answer: 'Oh, I have to turn off all the security in Chrome to get the demo to work'... :) I respectfully disagree. I think it's an opportunity to make it clear that the browser is normally running at a higher level of security than any other and that we're _temporarily_ making Chromium on par with any other browser. At the end of the day, Chromium will have these features within a sandboxed environment. Other browsers won't. This point could be very powerful if presented well. J -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Linux build bots
Greetings chromium-developers, sheriffs, and troopers, As you can see in our buildbot waterfall page, three build bots has been stopping for a long time, Chromium Linux, Chromium Linux x64, Modules Linux since I noticed they seemed to be sick and stopped building them. Unfortunately, I wasn't able to fix them even though I tried re-building them. I'm deeply sorry for all chromium developers, especially sheriffs who keep the Chromium builds green. (*1) http://build.chromium.org/buildbot/waterfall/waterfall Regards, Hironori Bono E-mail: hb...@chromium.org -- 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: [WebGL] Recommending --no-sandbox
Yes, a periodic inforbar would be swell and fairly effective. in my opinion. ☆PhistucK On Fri, Dec 11, 2009 at 11:57, Jeremy Orlow jor...@chromium.org wrote: On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell k...@chromium.org wrote: (Resending from chromium.org) On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote: After reading the WebGL blog post today, and following the link to the wiki, it struck me as fairly *bad* that we are telling people to disable the sandbox. A good number of folks are going to disable the sandbox and forget that they had ever done so. I don't follow. The --no-sandbox command line argument only takes effect for the current invocation of the browser. Most people launch Chrome or Chromium from its icon, which will not have that argument associated with it. On Windows, the most common way for people to launch with arguments is to add them to a short cut. The risk is that they'd do this to their main shortcut and then forget about it. Once we can support WebGL in the sandbox, what will we do? It would be nice if we could somehow restore the sandbox automatically. But renaming --no-sandbox doesn't seem like a great choice, and it isn't a scalable solution for other things like this that come up in the future. We will just remove the --no-sandbox option from that wiki page, and people testing WebGL will eventually stop specifying it. _New_ users will stop specifying it, but I doubt people will be regularly checking the wiki page. Perhaps --enable-webgl should instead implicitly disable the sandbox today so that tomorrow, when WebGL just works, folks won't have to change any command line options to restore sandbox functionality. I can see a counter argument that people should have to explicitly opt-in to disabling the sandbox, but I'm not sure that out-weighs the cost of having a good number of dev channel users running *permanently* without the sandbox. Was this idea considered? Any other ideas? I considered this but rejected it because it might lull people into a false sense of security -- thinking that they had just enabled WebGL but were actually browsing without the sandbox. The best solution is to get the GPU process in place on all platforms, at which point WebGL can be run inside the sandbox; this is a high priority for me and others. We definitely know this is true, and I think it's even safe to assume this will be true for other features in the future that only work with the sandbox off initially. The problem is the time before this is true. As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. The solution to this is either the annoying/scary UI can't be disabled/clicked-through/etc (like a red and white striped theme that can't be overridden) or to pop up a modal dialog or info bar periodically (it could even be once an hour or even day) in addition to popping it up initially. In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur said Also, when thinking about options 1 and 2 above (changing the appearance of Chrome) I can't help but think of someone pitching WebGL (which currently doesn't work in the sandbox) to their development team and the audience asking 'why is your browser all red?'. Answer: 'Oh, I have to turn off all the security in Chrome to get the demo to work'... :) I respectfully disagree. I think it's an opportunity to make it clear that the browser is normally running at a higher level of security than any other and that we're _temporarily_ making Chromium on par with any other browser. At the end of the day, Chromium will have these features within a sandboxed environment. Other browsers won't. This point could be very powerful if presented well. J -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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] Extensions and the Mac
I believe the most elegant and quick (seemingly) solution is to provide the extension developers a field (in the extension gallery, not in the extension itself) that will include the platform and the version. Going farther, you can add a check if the platform and the version (or even let the developer enter the search string) exist in the user agent or anywhere else you can think of and show a warning next to the install button. And an automatic quick solution can be to go over the manifest (which you already do to search for NPAPI to add it to the approval queue) and see if there is a DLL, SO or whatever Macintosh is using in them. If there is a DLL, add a Compatible with the Windows platform and so on, or the opposite, if it does not contain, then you surely know - Not compatible with the Macintosh or Linux platforms. ☆PhistucK On Fri, Dec 11, 2009 at 03:54, Aaron Boodman a...@google.com wrote: Yes, extensions that include NPAPI are a very small minority. Last time I checked there were something like 5. It is a way out for people who already have binary code that they would like to reuse, or who need to talk to the platform. I don't see what the big deal is about a few extensions only supporting a particular platform. As long as it is clear to users (you're right, we need to do this), I think this is ok. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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] Extensions and the Mac
One viewpoint I haven't seen mentioned on this thread is from that of the extension developer. Suppose they write, from their perspective, a perfectly good extension that uses binary components. After being around for a few weeks, they notice they have a 2-star rating and a lot of angry comments saying this extension doesn't work at all wh That doesn't really seem fair to the extension writer. People are complaining because they haven't been informed and we've not put a mechanism in place to inform them, and they take it out on the extension in terms of a really bad rating. On Fri, Dec 11, 2009 at 6:29 AM, PhistucK phist...@chromium.org wrote: I believe the most elegant and quick (seemingly) solution is to provide the extension developers a field (in the extension gallery, not in the extension itself) that will include the platform and the version. Going farther, you can add a check if the platform and the version (or even let the developer enter the search string) exist in the user agent or anywhere else you can think of and show a warning next to the install button. And an automatic quick solution can be to go over the manifest (which you already do to search for NPAPI to add it to the approval queue) and see if there is a DLL, SO or whatever Macintosh is using in them. If there is a DLL, add a Compatible with the Windows platform and so on, or the opposite, if it does not contain, then you surely know - Not compatible with the Macintosh or Linux platforms. ☆PhistucK On Fri, Dec 11, 2009 at 03:54, Aaron Boodman a...@google.com wrote: Yes, extensions that include NPAPI are a very small minority. Last time I checked there were something like 5. It is a way out for people who already have binary code that they would like to reuse, or who need to talk to the platform. I don't see what the big deal is about a few extensions only supporting a particular platform. As long as it is clear to users (you're right, we need to do this), I think this is ok. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Mike Pinkerton Mac Weenie pinker...@google.com -- 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: [WebGL] Recommending --no-sandbox
The goal is to annoy you so you will try to stop passing these arguments. Don't we already have other infobars possibly showing at startup (e.g., restore tabs)? -darin On Fri, Dec 11, 2009 at 9:46 AM, Evan Martin e...@chromium.org wrote: I also like the infobar on start, especially if there's no way to say stop bugging me on it, so every time you start it will annoy you. I would like to bring back --single-process as well in that case. On Linux users are much more comfortable sending in stack traces etc. but trying to walk someone through getting a renderer subprocess crash into gdb is a pain; if I could say run 'gdb --args chrome --single-process it would save me a lot of time. On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher da...@chromium.org wrote: I don't understand the argument for a periodic indicator. We don't have a periodic indicator telling the user when to restart their browser to pick up auto-updates. The only time it makes sense for the user to re-consider the command line options is when restarting because they might have been upgraded to a version that makes the --no-sandbox option unnecessary for their usage. -Darin On Fri, Dec 11, 2009 at 3:02 AM, PhistucK phist...@chromium.org wrote: Yes, a periodic inforbar would be swell and fairly effective. in my opinion. ☆PhistucK On Fri, Dec 11, 2009 at 11:57, Jeremy Orlow jor...@chromium.org wrote: On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell k...@chromium.org wrote: (Resending from chromium.org) On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote: After reading the WebGL blog post today, and following the link to the wiki, it struck me as fairly *bad* that we are telling people to disable the sandbox. A good number of folks are going to disable the sandbox and forget that they had ever done so. I don't follow. The --no-sandbox command line argument only takes effect for the current invocation of the browser. Most people launch Chrome or Chromium from its icon, which will not have that argument associated with it. On Windows, the most common way for people to launch with arguments is to add them to a short cut. The risk is that they'd do this to their main shortcut and then forget about it. Once we can support WebGL in the sandbox, what will we do? It would be nice if we could somehow restore the sandbox automatically. But renaming --no-sandbox doesn't seem like a great choice, and it isn't a scalable solution for other things like this that come up in the future. We will just remove the --no-sandbox option from that wiki page, and people testing WebGL will eventually stop specifying it. _New_ users will stop specifying it, but I doubt people will be regularly checking the wiki page. Perhaps --enable-webgl should instead implicitly disable the sandbox today so that tomorrow, when WebGL just works, folks won't have to change any command line options to restore sandbox functionality. I can see a counter argument that people should have to explicitly opt-in to disabling the sandbox, but I'm not sure that out-weighs the cost of having a good number of dev channel users running *permanently* without the sandbox. Was this idea considered? Any other ideas? I considered this but rejected it because it might lull people into a false sense of security -- thinking that they had just enabled WebGL but were actually browsing without the sandbox. The best solution is to get the GPU process in place on all platforms, at which point WebGL can be run inside the sandbox; this is a high priority for me and others. We definitely know this is true, and I think it's even safe to assume this will be true for other features in the future that only work with the sandbox off initially. The problem is the time before this is true. As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. The solution to this is either the annoying/scary UI can't be disabled/clicked-through/etc (like a red and white striped theme that can't be overridden) or to pop up a modal dialog or info bar periodically (it could even be once an hour or even day) in addition to popping it up initially. In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur said Also, when thinking about options 1 and 2 above (changing the appearance of Chrome) I can't help but think of someone pitching WebGL
Re: [chromium-dev] Extensions and the Mac
If I'm running on Windows, I know to ignore the latter. That's a pretty big difference. -- Dirk On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman a...@chromium.org wrote: What the difference between: ★ this extension doesn't work at all wh and ★ As mentioned, this extension is incompatible with my Linux box. Bad show. Bad show. Avi On Fri, Dec 11, 2009 at 10:29 AM, Mike Pinkerton pinker...@google.com wrote: One viewpoint I haven't seen mentioned on this thread is from that of the extension developer. Suppose they write, from their perspective, a perfectly good extension that uses binary components. After being around for a few weeks, they notice they have a 2-star rating and a lot of angry comments saying this extension doesn't work at all wh That doesn't really seem fair to the extension writer. People are complaining because they haven't been informed and we've not put a mechanism in place to inform them, and they take it out on the extension in terms of a really bad rating. On Fri, Dec 11, 2009 at 6:29 AM, PhistucK phist...@chromium.org wrote: I believe the most elegant and quick (seemingly) solution is to provide the extension developers a field (in the extension gallery, not in the extension itself) that will include the platform and the version. Going farther, you can add a check if the platform and the version (or even let the developer enter the search string) exist in the user agent or anywhere else you can think of and show a warning next to the install button. And an automatic quick solution can be to go over the manifest (which you already do to search for NPAPI to add it to the approval queue) and see if there is a DLL, SO or whatever Macintosh is using in them. If there is a DLL, add a Compatible with the Windows platform and so on, or the opposite, if it does not contain, then you surely know - Not compatible with the Macintosh or Linux platforms. ☆PhistucK On Fri, Dec 11, 2009 at 03:54, Aaron Boodman a...@google.com wrote: Yes, extensions that include NPAPI are a very small minority. Last time I checked there were something like 5. It is a way out for people who already have binary code that they would like to reuse, or who need to talk to the platform. I don't see what the big deal is about a few extensions only supporting a particular platform. As long as it is clear to users (you're right, we need to do this), I think this is ok. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Builder, revision 34355
Automatically closing tree for compile on Chromium Builder http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/20276 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder --= Automatically closing tree for compile on Chromium Builder =-- Revision: 34354, 34355 Blame list: bradnel...@google.com,davemo...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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] Extensions and the Mac
Right, but the rating average doesn't take that into account. Avi On Fri, Dec 11, 2009 at 12:59 PM, Dirk Pranke dpra...@google.com wrote: If I'm running on Windows, I know to ignore the latter. That's a pretty big difference. -- Dirk On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman a...@chromium.org wrote: What the difference between: ★ this extension doesn't work at all wh and ★ As mentioned, this extension is incompatible with my Linux box. Bad show. Bad show. Avi On Fri, Dec 11, 2009 at 10:29 AM, Mike Pinkerton pinker...@google.com wrote: One viewpoint I haven't seen mentioned on this thread is from that of the extension developer. Suppose they write, from their perspective, a perfectly good extension that uses binary components. After being around for a few weeks, they notice they have a 2-star rating and a lot of angry comments saying this extension doesn't work at all wh That doesn't really seem fair to the extension writer. People are complaining because they haven't been informed and we've not put a mechanism in place to inform them, and they take it out on the extension in terms of a really bad rating. On Fri, Dec 11, 2009 at 6:29 AM, PhistucK phist...@chromium.org wrote: I believe the most elegant and quick (seemingly) solution is to provide the extension developers a field (in the extension gallery, not in the extension itself) that will include the platform and the version. Going farther, you can add a check if the platform and the version (or even let the developer enter the search string) exist in the user agent or anywhere else you can think of and show a warning next to the install button. And an automatic quick solution can be to go over the manifest (which you already do to search for NPAPI to add it to the approval queue) and see if there is a DLL, SO or whatever Macintosh is using in them. If there is a DLL, add a Compatible with the Windows platform and so on, or the opposite, if it does not contain, then you surely know - Not compatible with the Macintosh or Linux platforms. ☆PhistucK On Fri, Dec 11, 2009 at 03:54, Aaron Boodman a...@google.com wrote: Yes, extensions that include NPAPI are a very small minority. Last time I checked there were something like 5. It is a way out for people who already have binary code that they would like to reuse, or who need to talk to the platform. I don't see what the big deal is about a few extensions only supporting a particular platform. As long as it is clear to users (you're right, we need to do this), I think this is ok. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Ending the AsyncSlowStartExperiment
* I am going to turn off the AsyncSlowStart experiment, but wanted to send the results for the curious minded. What is the feature:* Some time ago, I observed that windows asynchronous IO may delay handing an IO completion to the application when only part of the requested IO can complete. Specifically, I could see from wire traces that we had received data which should complete a socket read (say 1400 bytes). But the application didn't wake until 40-50ms later! This was pure latency as it delayed chrome from doing work which it could do. I further observed that the delay did not occur when the entire buffer was filled. So, if you issue a 1KB read, there was no delay, but if you issue a 4KB or 32KB read, the OS seems to delay completing the IO. One speculative theory is that windows async-io completion logic has a Nagle-esque behavior - trying to batch additional data into a single Async IO Read Completion before handing up to the application. Without the AsyncSlowStart, chrome issues its normal reads 4KB or 32KB. With the AsyncSlowStart feature, Chrome starts the read size at 1KB. With each successful Read completion, it doubles the read size, so 1KB, 2KB, 4KB, 8KB, etc. This allows large transfers to not be impeded by using ridiculously small buffers, but allows us to avoid the delay at the beginning of a connection. *How I measured:* - Using the Net.Transaction_Connected_New_AsyncSlowStart_off compared to Net.Transaction_Connected_New_AsyncSlowStart. - This measures the time-to-first-byte for new connections when the feature is off or on. - Excluding data after the 99%-tile, because the data has a skew at 50s which is not related to this feature (and shows on all of our histograms). *Results:* Based on the time-to-first-byte measurement, the Async Slow Start feature is a clear win. The histograms vary in benefit - sometimes as low as 0.8% and sometimes as high as 6.32%. But overall, it averages a 2-3% win. This is a savings of 3-20ms per request on a fresh connection. It is probably not detectable to most users, although a single page load may hit this problem between 1-10 times on various connections. ***Next Steps:* I'm going to finally turn off the experiment and make this final. Mike - Net.Transaction_Connection_New_AsyncSlowStart --- 08/30-9/05 WIN - 4.90% to 3.73% Net.Transaction_Connected_New_AsyncSlowStart_off (All) Net.Transaction_Connected_New_AsyncSlowStart (All) Delta Savings Cutoff Value Min Avg ~AvgMax Avg Value Min Avg ~AvgMax Avg Value % ~Avg% 50.00% 260.5 109.0 115.7 122.5 249.0 103.9 110.3 116.7 11.42 4.59% 5.404.90% 70.00% 514.0 177.1 188.3 199.6 494.3 169.7 180.5 191.3 19.72 3.99% 7.824.33% 90.00% 1640317.1 337.7 358.2 1589305.6 325.3 345.0 50.80 3.20% 12.36 3.80% 95.00% 3667424.3 451.9 479.5 3595410.4 437.1 463.8 72.28 2.01% 14.82 3.39% 98.00% 26015 633.9 675.3 716.8 24523 611.1 651.0 691.0 1492 6.08% 24.28 3.73% 99.00% 53322 10861157122953271 105811281198 50.34 0.09% 29.31 2.60% 99.50% 55490 13331421150955449 130613921478 41.26 0.07% 29.22 2.10% 09/06-09/12 WIN - 1.35% to 5.07% Net.Transaction_Connected_New_AsyncSlowStart_off (All) Net.Transaction_Connected_New_AsyncSlowStart (All) Delta Savings Cutoff Value Min Avg ~AvgMax Avg Value Min Avg ~AvgMax Avg Value % ~Avg% 50.00% 299.8 125.2 133.0 140.8 289.3 123.5 131.2 138.9 10.41 3.60% 1.771.35% 70.00% 596.8 204.3 217.4 230.5 577.8 198.6 211.3 224.0 18.97 3.28% 6.122.90% 90.00% 2393385.6 410.6 435.6 2240371.6 395.7 419.8 152.7 6.82% 14.88 3.76% 95.00% 5692542.2 577.5 612.9 4928516.0 549.7 583.3 763.8 15.50% 27.88 5.07% 98.00% 50783 10561125119450883 950.4 10131075 -99.43 -0.20% 112.1 11.07% 99.00% 54328 15481650175254353 144415391634 -25.04 -0.05% 110.9 7.20% 99.50% 56101 17951913203156088 169118021914 12.16 0.02% 110.2 6.12% 09/13-09/19 WIN - 0.84% to 6.32% Net.Transaction_Connected_New_AsyncSlowStart_off (All) Net.Transaction_Connected_New_AsyncSlowStart (All) Delta Savings Cutoff Value Min Avg ~AvgMax Avg Value Min Avg ~AvgMax Avg Value % ~Avg% 50.00% 336.8 142.1 151.1 160.0 321.8 140.9 149.8 158.7 15.02 4.67% 1.260.84% 70.00% 668.6 230.6 245.4 260.2 628.5 221.9 236.2 250.4 40.06 6.37% 9.253.91% 90.00% 2679433.3 461.5 489.7 2461408.9 435.5 462.1 217.3 8.83% 26.00 5.97% 95.00% 5633594.9 633.8 672.7 5069559.6 596.1 632.7 563.9 11.12% 37.69
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 9:56 AM, Darin Fisher da...@chromium.org wrote: The goal is to annoy you so you will try to stop passing these arguments. Don't we already have other infobars possibly showing at startup (e.g., restore tabs)? Yes. It looks a little silly -- you get two of them stacked -- but part of the point of this is that most users don't encounter it, it's only the ones doing things that we're trying to discourage. Since code speaks louder than words: http://codereview.chromium.org/490019 Screenshot: http://i.imgur.com/1mPST.png -- 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: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 1:57 AM, Jeremy Orlow jor...@chromium.org wrote: As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. PK -- 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: [WebGL] Recommending --no-sandbox
As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. I'd be happier if the dialog provided a single-button way to automatically remove the flag from the shortcut (otherwise it's just easier to hit 'OK' and put off manually editing it). -- 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: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher da...@chromium.org wrote: I don't understand the argument for a periodic indicator. We don't have a periodic indicator telling the user when to restart their browser to pick up auto-updates. I don't think this is a fair comparison. One is a normal usage of Chrome and the other is something we're actively trying to discourage. On the other hand, maybe some sort of periodic indicator for when you auto-update is a good idea The only time it makes sense for the user to re-consider the command line options is when restarting because they might have been upgraded to a version that makes the --no-sandbox option unnecessary for their usage. Even when they're using the flag because they want to use an experimental feature we should still remind them that the flag is dangerous and that they shouldn't be doing normal browsing with that window. Major +1 to glens idea in theory. But in practice, how would you pull that off? -- 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: [WebGL] Recommending --no-sandbox
But, as I understand, some people do use it due to issues with the sandbox, real issues, system incompatibilities. That would be really unfair towards them. ☆PhistucK On Fri, Dec 11, 2009 at 20:43, Glen Murphy g...@chromium.org wrote: As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. I'd be happier if the dialog provided a single-button way to automatically remove the flag from the shortcut (otherwise it's just easier to hit 'OK' and put off manually editing it). -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 11:01 AM, PhistucK phist...@gmail.com wrote: But, as I understand, some people do use it due to issues with the sandbox, real issues, system incompatibilities. That would be really unfair towards them. Most issues should be fixable. We need to hear about problems the sandbox causes, and fix them. If people just disable the sandbox, we won't hear about them. If there is some issue that is not fixable, I would prefer those users not use Chrome than that they exist in the steady state of using it with the sandbox off. PK -- 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: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 10:43 AM, Glen Murphy g...@chromium.org wrote: As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. How annoying? Since we already know that people habitually mash the default button, the dialog could say Running with --no-sandbox is dangerous. Can I keep the sandbox enabled?, then OK is the good thing, and Cancel/No is the bad thing. [BTW, I hope it's obvious that we might not want to be as annoying if we disable the sandbox as part of an experimental feature. A little annoying, but since experimental features correlate with browsers crashing, we should be careful not to alienate developers who are testing the experimental feature...] [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] -scott -- 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.org wrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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: [WebGL] Recommending --no-sandbox
[from right address] On Fri, Dec 11, 2009 at 11:37 AM, Steve VanDeBogart vand...@google.comwrote: On Fri, Dec 11, 2009 at 11:23 AM, Scott Hess sh...@chromium.org wrote: [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] Instead of telling people to use --no-sandbox on the blog, we could tell them to use a new flag, --disable-sandbox-until MM/DD/. It could limit the maximum amount of time the sandbox was disabled, to say two weeks. After that, the sandbox would automatically be reenabled. There should still be some kind of notification that the user is running with the sandbox disabled, but people that ignore it or forget about it will get converted back to a secure configuration in a reasonable amount of time. -- Steve -- 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] revised output for run_webkit_tests
Sigh. Now from the right email address. On Fri, Dec 11, 2009 at 11:36 AM, Ojan Vafai o...@google.com wrote: I thought we had agreed on printing out any unexpected failures in real-time, no? Also, I do think it would be worthwhile to print each directory as it finishes. We're getting to the point where we shard all the big directories, so the largest shard takes 90 seconds (this is true on the mac release bot now!). So printing directories as they finish would actually give you decent insight into what tests have been run. Ojan On Fri, Dec 11, 2009 at 9:55 AM, Dirk Pranke dpra...@chromium.org wrote: On Fri, Dec 11, 2009 at 12:04 AM, Dirk Pranke dpra...@chromium.org wrote: The current implementation tells you that tests have failed as it goes, but not which tests (of course, the webkit script doesn't tell you either, apart from which directory the failure might be in). That would be easy to add if there is demand. It has been pointed out to me that this paragraph is incorrect. The webkit scripts do give you the test filename of the failure in real time. For some reason I was thinking it just printed an E instead of a . . Thinking about it now, I think I got its output confused with the Python and Perl unit testing frameworks ... My apologies for any confusion this might've caused, and for saying something without being sure it was right ... -- Dirk -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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] [WebGL] Recommending --no-sandbox
(adding Alice) Alice: do you have a rough estimate for how often we ask users to turn off the sandbox when debugging problems? Thanks On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.org wrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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] Modifying .gyp files
You mean they were manually pre-created, right?
I used a custom action with success and I believe that sounds better for
module updates purposes.
Perhaps we should consider adding a new target type, say, 'config', which
would invoke configure automatically.
On Fri, Dec 11, 2009 at 12:07 PM, Mikhail Naganov mnaga...@chromium.orgwrote:
You may look at e.g. third_party/libxml. 'config.h' files are
pre-created for each platform ({linux|mac|win32}/config.h), then an
appropriate include dir is chosen for the particular platform (see
libxml.gyp).
On Fri, Dec 11, 2009 at 16:39, Igor Gatis igorga...@gmail.com wrote:
This is great. Thanks a lot.
Final question: I've included a third_party module which uses autotools.
I
wrote a .gyp for this module. When I try to build it using make, it
complains because config.h is missing - how should I fix that? Is there a
way standard way to make it run configure or I should add a custom action
for that?
Thanks,
-Igor
On Thu, Dec 10, 2009 at 1:55 PM, Mikhail Naganov mnaga...@chromium.org
wrote:
http://code.google.com/p/gyp/w/list
On Thu, Dec 10, 2009 at 18:49, Igor Gatis igorga...@gmail.com wrote:
Thanks Mark.
BTW, do you guys know of lists or wiki I could get more information
regarding GYP tool?
On Wed, Dec 9, 2009 at 5:40 PM, Mark Mentovai m...@chromium.org
wrote:
There's better info in gclient.py, as a comment. Maybe we can just
rip this off and stick it in a web page somewhere on the developer
site.
Hooks
.gclient and DEPS files may optionally contain a list named hooks
to
allow custom actions to be performed based on files that have
changed
in
the
working copy as a result of a sync/update or revert operation.
This
could be prevented by using --nohooks (hooks run by default). Hooks
can
also
be forced to run with the runhooks operation. If sync is run
with
--force, all known hooks will run regardless of the state of the
working
copy.
Each item in a hooks list is a dict, containing these two keys:
pattern The associated value is a string containing a regular
expression. When a file whose pathname matches the
expression
is checked out, updated, or reverted, the hook's
action
will
run.
action A list describing a command to run along with its
arguments,
if
any. An action command will run at most one time per
gclient
invocation, regardless of how many files matched the
pattern.
The action is executed in the same directory as the
.gclient
file. If the first item in the list is the string
python,
the current Python interpreter (sys.executable) will be
used
to run the command. If the list contains string
$matching_files
it will be removed from the list and the list will be
extended
by the list of matching files.
Example:
hooks = [
{ pattern: \\.(gif|jpe?g|pr0n|png)$,
action: [python, image_indexer.py, --all]},
]
Marc-Antoine Ruel wrote:
Humm, that's a good question. Right now the only doc is gclient
help
runhooks which is .. uh .. not really useful.
M-A
On Wed, Dec 9, 2009 at 3:28 PM, Igor Gatis igorga...@gmail.com
wrote:
Is there documentation somewhere regarding gclient? I'd like to
know
more
about how hooks and other gclient features work.
On Tue, Dec 8, 2009 at 6:27 PM, Mark Mentovai
mmento...@google.com
wrote:
Igor Gatis wrote:
When I change a .gyp, do I need to call gyp or the build
process
does
that
for me?
When you change it yourself, in your own working copy, you run
gclient runhooks to get new files generated.
When a .gyp change is checked in, you don't need to do this:
gclient
will automatically run GYP as needed when you run gclient sync.
Mark
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
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] revised output for run_webkit_tests
On Fri, Dec 11, 2009 at 11:36 AM, Ojan Vafai o...@google.com wrote: I thought we had agreed on printing out any unexpected failures in real-time, no? Also, I do think it would be worthwhile to print each directory as it finishes. We're getting to the point where we shard all the big directories, so the largest shard takes 90 seconds (this is true on the mac release bot now!). So printing directories as they finish would actually give you decent insight into what tests have been run. No, I don't think we had necessarily agreed to this, although we did talk about it. At any rate, I'm working on a webkit-style-output patch that should get both of these things, and we can see which we like better. -- Dirk -- 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: [WebGL] Recommending --no-sandbox
And then an infobar would show up (only in the first time) and tell them they can be relieved since they are secure again? ;) Sounds like an appropriate Google joke. ☆PhistucK On Fri, Dec 11, 2009 at 21:40, Steve VanDeBogart vand...@chromium.orgwrote: [from right address] On Fri, Dec 11, 2009 at 11:37 AM, Steve VanDeBogart vand...@google.comwrote: On Fri, Dec 11, 2009 at 11:23 AM, Scott Hess sh...@chromium.org wrote: [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] Instead of telling people to use --no-sandbox on the blog, we could tell them to use a new flag, --disable-sandbox-until MM/DD/. It could limit the maximum amount of time the sandbox was disabled, to say two weeks. After that, the sandbox would automatically be reenabled. There should still be some kind of notification that the user is running with the sandbox disabled, but people that ignore it or forget about it will get converted back to a secure configuration in a reasonable amount of time. -- Steve -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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] Modifying .gyp files
Igor Gatis wrote: You mean they were manually pre-created, right? Yes I used a custom action with success and I believe that sounds better for module updates purposes. We used to do things like that in the pre-GYP days. When we moved our builds over to GYP, we decided that it wasn't anywhere near worthwhile. It inflated build times (autoconf's configure is SLOW) and was difficult to capture dependency data properly and get the output in the right place. I don't recommend adding configure steps when you can configure once for the platforms you need and check the results in. Mark -- 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] [WebGL] Recommending --no-sandbox
Alice's reply is below. I'm still convinced that Google Chrome shouldn't run without the sandbox, and if someone needs that, then they can use Chromium builds. We actually rarely ask users to turn off the sandbox and after we confirm that they can run it with the flag, we tell them do remove it immediately due to security vulnerabilities. The only problem is that after this point, it's hard for users to figure out what's preventing Google Chrome to run properly. We need to find an easier way or some sort of utility to do this. I agree that we need to make it obvious to the user that they shouldn't be running without sandbox but we need to give them a better way to figure out what's wrong so that they can continue to use it. -- Alice Lin | Google, Inc. | Senior Strategist, Consumer Operations | 650.253.6827 | a...@google.com On Fri, Dec 11, 2009 at 11:48 AM, John Abd-El-Malek j...@chromium.orgwrote: (adding Alice) Alice: do you have a rough estimate for how often we ask users to turn off the sandbox when debugging problems? Thanks On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.orgwrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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] [WebGL] Recommending --no-sandbox
We actually rarely ask users to turn off the sandbox and after we confirm that they can run it with the flag, we tell them do remove it immediately due to security vulnerabilities. The only problem is that after this point, it's hard for users to figure out what's preventing Google Chrome to run properly. We need to find an easier way or some sort of utility to do this. I agree that we need to make it obvious to the user that they shouldn't be running without sandbox but we need to give them a better way to figure out what's wrong so that they can continue to use it. On Fri, Dec 11, 2009 at 11:48 AM, John Abd-El-Malek j...@chromium.orgwrote: (adding Alice) Alice: do you have a rough estimate for how often we ask users to turn off the sandbox when debugging problems? Thanks On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.orgwrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- Alice Lin | Google, Inc. | Senior Strategist, Consumer Operations | 650.253.6827 | a...@google.com This email and the information it contains are confidential and may be privileged. If you have received this email in error please notify me immediately. You should not copy it for any purpose, or disclose its contents to any other person. Internet communications are not secure and, therefore, Google does not accept legal responsibility for the contents of this message as it has been transmitted over a public network. If you suspect the message may have been intercepted or amended please contact me. -- 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: Building chromium for arm--erroring out
Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry erik.co...@gmail.com wrote: 2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I get an Illegal Instruction. I restart and I can now see chrome as shown in the attachment but I cannot browse. When I reload the page, it again kills chrome saying Illegal instruction. Has anyone seen this before? I have my proxy settings set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. Any help is highly appreciated. Thanks, Sofia On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley j...@chromium.org wrote: On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen sofia.tahs...@gmail.com wrote: /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so when searching for -lrt The errors are indicative of trying to link against libraries from a different platform. To confirm: check the output of $ 'file /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so I suspect it will tell you it's a symbolic link to /lib/librt.so.1, which itself is a symbolic link to /lib/librt-2.10.2.so - note these paths are relative to /, not to your sysroot directory. You have two slightly solutions - adjust the symlinks in sys-root/usr/lib so they point to the files in sys-root//lib - replace the smymlinks with the actual libraries, ie copy files from sys-root/lib to sys-root/usr/lib I would be happy to hear a neater solution for this, but the above worked for me. Cheers, Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: Building chromium for arm--erroring out
On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. Note, if you don't set armv7=1 when you build chromium, it shouldn't use the NEON paths, so you shouldn't run into that problem. But it's better to enable it in the kernel if your hardware supports it. Antoine Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry erik.co...@gmail.com wrote: 2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I get an Illegal Instruction. I restart and I can now see chrome as shown in the attachment but I cannot browse. When I reload the page, it again kills chrome saying Illegal instruction. Has anyone seen this before? I have my proxy settings set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. Any help is highly appreciated. Thanks, Sofia On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley j...@chromium.org wrote: On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen sofia.tahs...@gmail.com wrote: /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so when searching for -lrt The errors are indicative of trying to link against libraries from a different platform. To confirm: check the output of $ 'file /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so I suspect it will tell you it's a symbolic link to /lib/librt.so.1, which itself is a symbolic link to /lib/librt-2.10.2.so - note these paths are relative to /, not to your sysroot directory. You have two slightly solutions - adjust the symlinks in sys-root/usr/lib so they point to the files in sys-root//lib - replace the smymlinks with the actual libraries, ie copy files from sys-root/lib to sys-root/usr/lib I would be happy to hear a neater solution for this, but the above worked for me. Cheers, Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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-extensions] Re: Desktop Notifications
Hi all, Bringing this topic back again. I've been able to show notifications from our extension, with a friendly name in the from label. What I'm not able to do is communicate with the background page. Is this implemented or not yet? Thanks On Tue, Nov 10, 2009 at 11:51 PM, Aaron Boodman a...@chromium.org wrote: On Tue, Nov 10, 2009 at 8:19 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hey Aaron, thanks for your answer. Does this mean that extension and communication will be able to communicate between them without using Shared workers? Yes, also, all the extension APIs, like chrome.tabs, chrome.bookmarks, etc should be available in the notification HTML page. Being able to do getBackgroundPage() from extension-created notifications would be awesome. We'll star those issues. Ok! -a -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
