[chromium-dev] Re: Stack traces on layout test crashes
On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: Some things to consider: 1. On windows, breakpad used to be wired in test_shell. And I'm pretty sure we used to archive crash dumps for the layout tests too. It should not be hard to do that again. Huan also write a nice script to dump to stdio the crashing stacks of all crashes that happened in a buildbot run. It only runs on chromium xp for now, but there is no reason why we could not make it work for the layout tests. See http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/6491/steps/Process%20Dumps/logs/stdio for example. I like the idea of leveraging breakpad for crash dumps if possible. It seems like that's the best plan and the debug_util code and/or Viet-Trung's code would be a backup plan if that proved too complicated/hacky. 2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
When people change themes regularly, I believe their intension is to try out themes. When theme preview is going to come in, that would be simpler. A person isn't going to change themes every day, if they want to change themes, they could just goto the UI and change to any theme they please. I believe a drop down for a list of themes is a waste of space for the options panel, people wont use that frequently. I have been told that once you installed a new theme, the old theme will not be archived (stored on the system), so switching themes would be harder when the CL comes in. I thought you guys are picky when it comes to options, and introducing a themes drop down is actually a useless control which will be rarely used. There are many other areas where I would like to have options which actually makes more sense compared to this. Aaron, I believe the themes page could use a currently installed theme that way the user would know what theme he/she installed. It was possible by visiting chrome://extensions/, but now its removed from that page. -- Mohamed Mansour On Mon, Aug 10, 2009 at 1:46 AM, PhistucK phist...@gmail.com wrote: But people like to change themes periodically and also, to choose from themes they have already installed and new themes, you (currently) cannot incorporate both of them in the theme gallery. I saw that happening with regular, non techy users - all of the time (not in Chrome, obviously, since they did not have an option up until now, but with tons of other programs). They choose one, they choose another, they select from their collection again and also look for new ones. So these should either be combined (existing and total in one page), or an option to select a theme should be present, in my opinion. ☆PhistucK On Mon, Aug 10, 2009 at 08:19, Aaron Boodman a...@chromium.org wrote: On Sun, Aug 9, 2009 at 5:51 PM, Peter Kastingpkast...@google.com wrote: FWIW, I'd prefer if all the ports have this. There are three reasons for this, one of them silly: (1) Shows themes you've gotten from sources other than the gallery (I don't know if this is possible at this moment, but it will be someday, right?) No, why is it useful to see themes you've previously installed? I mean, why is it anymore than seeing any other webpage you've previously visited. We already have mechanisms to find things you visited previously. Why does themes need it's own? (2) Limited to the set of themes you've actually shown interest in by using. Think about if the gallery had several thousand themes (the way Firefox has several thousand Personas). I don't even buy that this would work. You can't tell which themes you like by looking at the picture. I suspect it is more typical to actually try it on for size before deciding it is hideous/awesome. (3) Usable while offline/unable to access gallery (silly reason). You're right, silly. The first two are sufficient reasons to me that I've been surprised to not see this kind of a switch in the WIndows UI. Funny, you recently argued in a different thread (about a different feature request) that the cost for following a link is basically nil, so there shouldn't be any separate UI other than that ;-). Agree right now that installing a theme is slightly higher cost than following a link. But it shouldn't be. On Sun, Aug 9, 2009 at 9:02 PM, PhistucKphist...@gmail.com wrote: Seeing as there is currently no UI for it other than actually installing a theme again, I would say the theme selection dropdown is kind of a needed element. We should change the word install to pick. Why should there be a different UI for re-picking a theme than there is for the initial pick? On Sun, Aug 9, 2009 at 10:04 PM, Caleb Eggenspergercaleb...@gmail.com wrote: It would be nice for the UI for installing a theme to be the same as for choosing it again. Maybe the themes directory could have an already installed section, although I think the fact that I've installed a theme and moved on to another means I'm less interested in using it again. A dropdown would become kinda unmanageable with a large number of themes, unless there's a way to remove them, and not nearly as usable as the themes directory is now. What if I can't remember what legal pad looks like? Good points! On Sun, Aug 9, 2009 at 10:13 PM, PhistucKphist...@gmail.com wrote: I meant it would be nice as a temporary solution, until a chrome://themes page or something comes up. And per your wondering - when you mouse over\select a theme with the keyboard arrows (but no mouse click, nor Enter key press is made), a preview can be shown, or the whole theme can change. That would have to make the theme transitioning faster and more fluid, of course, but that is the intention anyway, so this could be step one. If you do not select a theme at last (clicking otherwise), the theme will revert to the one it has been. I think
[chromium-dev] Re: Urgent, a very evil site i think which does evil things (no joke)
On Mon, Aug 10, 2009 at 12:32 AM, PhistucK phist...@chromium.org wrote: Obviously, but since there is a website (what started this thread) and people do run into issues (Help forums) with such a thing, is a specific solution for Flash, at least, coming up soon? People getting infected while using Chrome is... really, really, not optimal. Oh, agreed. But a sandbox for plugins that removes Adobe's ability to let Flash update itself with security fixes doesn't really solve this problem either (which is what some of the discussion earlier in the thread was about). Right now, as I understand it, this vulnerability affects all browsers, not just Chrome--saying that a plugin vendor is in a better position to fix problems within a plugin isn't meant as a cop-out, it's just a description of where the problem lies. Any sandbox is just one line of defense. The underlying problem is that the current spec for browser plugins (NPAPI) effectively gives a plugin all of the capabilities of an application. Flash, since it's a programming environment in its own right, uses those capabilities to deliver value to users. For example, Gmail uses a small Flash application that improves the user experience for attaching files to email messages--but also depends on Flash's ability to access the file system. A video chat widget written in Flash needs access to the I/O subsystem in order to access the webcam. Acrobat (at least in recent versions) allows embedded Javascript, which expands the capabilities of Acrobat but also provides new places for potentially malicious code to live. The fact that these capabilities are used for genuinely useful stuff as well as security exploits is what makes sandboxing plugins difficult. We could turn off file system access, but then all sorts of file upload widgets would break, as well as Flash's own update facility. We could turn off access to other I/O devices, but then webcam and video chat would break. The real solution is to improve the plugin runtime environment so that plugins don't need to talk to the OS directly for these sorts of things. There is active work going on in places like the HTML5 working group, Mozilla's plugin wiki and mailing lists, etc. to make this happen, and we're contributing to that work. All of us, browser and plugin writers alike, are painfully aware of the problems here. And while we don't have a spot fix for this particular malicious website, it does serve as a good example of why that work is necessary. --Amanda --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
I think that maybe a viable interim workaround to flash's vulnerability problems would be to implement something like flashblock by default. There would have to be some always show flash on *.google.com whitelisting option (maybe automatically whitelist bookmarked sites?), and it would have to be an infobar style notification, since not all instances of flash are large enough/visible. But this would basically solve the problem of malicious flash on untrusted websites while not significantly hindering legitimate uses of flash. Is something like this in progress or would it be considered? On Mon, Aug 10, 2009 at 05:50, Amanda Walkerama...@chromium.org wrote: On Mon, Aug 10, 2009 at 12:32 AM, PhistucK phist...@chromium.org wrote: Obviously, but since there is a website (what started this thread) and people do run into issues (Help forums) with such a thing, is a specific solution for Flash, at least, coming up soon? People getting infected while using Chrome is... really, really, not optimal. Oh, agreed. But a sandbox for plugins that removes Adobe's ability to let Flash update itself with security fixes doesn't really solve this problem either (which is what some of the discussion earlier in the thread was about). Right now, as I understand it, this vulnerability affects all browsers, not just Chrome--saying that a plugin vendor is in a better position to fix problems within a plugin isn't meant as a cop-out, it's just a description of where the problem lies. Any sandbox is just one line of defense. The underlying problem is that the current spec for browser plugins (NPAPI) effectively gives a plugin all of the capabilities of an application. Flash, since it's a programming environment in its own right, uses those capabilities to deliver value to users. For example, Gmail uses a small Flash application that improves the user experience for attaching files to email messages--but also depends on Flash's ability to access the file system. A video chat widget written in Flash needs access to the I/O subsystem in order to access the webcam. Acrobat (at least in recent versions) allows embedded Javascript, which expands the capabilities of Acrobat but also provides new places for potentially malicious code to live. The fact that these capabilities are used for genuinely useful stuff as well as security exploits is what makes sandboxing plugins difficult. We could turn off file system access, but then all sorts of file upload widgets would break, as well as Flash's own update facility. We could turn off access to other I/O devices, but then webcam and video chat would break. The real solution is to improve the plugin runtime environment so that plugins don't need to talk to the OS directly for these sorts of things. There is active work going on in places like the HTML5 working group, Mozilla's plugin wiki and mailing lists, etc. to make this happen, and we're contributing to that work. All of us, browser and plugin writers alike, are painfully aware of the problems here. And while we don't have a spot fix for this particular malicious website, it does serve as a good example of why that work is necessary. --Amanda -- Caleb Eggensperger http://calebegg.com/ --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? We should probably implement a suppression mechanism here as well, so that the crashes due to current work in progress (Mac plugins, workers, etc.) don't take any time. This should minimize the impact. :DG --~--~-~--~~~---~--~~ 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: Hyperlink-like UI element
On Sun, Aug 9, 2009 at 2:41 PM, Peter Kastingpkast...@google.com wrote: On Sun, Aug 9, 2009 at 4:43 AM, Caleb Eggensperger caleb...@gmail.com wrote: I associate a button with doing something and a link with navigating somewhere. But a link is used to remove a bookmark (from the menu you get when you press the star button), and a button is used for the Get Themes in the options box. Is there a rule here that I'm not seeing, or were these just overlooked? The link in the bookmark bubble has been raised as an issue before. One problem with a button is that (a) it's technically hard to put there and That was true at one point, but no more. If you bring up the bookmark bubble you'll see it already has a couple of buttons. -Scott --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 7:46 AM, Mohamed Mansour m...@chromium.org wrote: I have been told that once you installed a new theme, the old theme will not be archived (stored on the system), so switching themes would be harder when the CL comes in. That isn't the case today; that may be the case in the future. I thought you guys are picky when it comes to options This one's mine, so I'll take the blame/praise as it goes. Right now there's no real control over themes. Once they're installed, they're permanently installed; there's no easy way to remove them (chrome://extensions used to list them so they could be removed, but now you can't even do that). So why not let the user switch? Assuming that the themes gallery will be the only source of themes and that the users would just have to go there is silly. The Get Themes button is only a suggestion, and while we have themes that we think are nice, there will be third-party providers. If you don't think the popup does an adequate job of showing previews/management, you are absolutely correct. I'd love a chrome://themes page that - showed installed themes -- with previews -- with deinstall buttons - allowed switching themes - allowed tinting for themes (which I've heard only Cole talk about but no one else mention) Until then I figured that throwing a picker into prefs would be something useful. Avi --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 8:50 AM, Avi Drissmana...@google.com wrote: Right now there's no real control over themes. Once they're installed, they're permanently installed; there's no easy way to remove them We should completely drop the concept of theme installation. We can do this by changing the language around themes in the UI. For example, instead of get themes, the button could read pick new theme. There can only be one theme active at a time, so whether the themes are still on your computer when you switch away from them is sorta irrelevant. From a cleanliness perspective, I would like to remove them, but the fact that you currently can't remove a theme after you switch away from it should not be an issue for most people. (chrome://extensions used to list them so they could be removed, but now you can't even do that). So why not let the user switch? I'm not saying the user shouldn't be able to switch. I'm saying why have two ways to switch, one that is inferior to the other. Assuming that the themes gallery will be the only source of themes and that the users would just have to go there is silly. The Get Themes button is only a suggestion, and while we have themes that we think are nice, there will be third-party providers. Of course, but if you want to reinstall one of those themes, you can just go back to the page you originally got it from. Why is it useful to have a list of every theme you have ever picked in the options menu? Like others have said, I expect this list to get long and there is no way to manage it. If you don't think the popup does an adequate job of showing previews/management, you are absolutely correct. I'd love a chrome://themes page that - showed installed themes - allowed switching themes It sounds like you want something almost like favorite themes - a list that can be managed. I can see some minor utility in this above just going back to the web page that has the theme you want and picking it again, but it seems pretty thin. I don't believe it is worth the implementation, maintenance, and simplicity costs to implement it. -- with previews Why do we need a separate concept of preview when you can just install a theme, and if you don't like it switch back to the one you had before. If the infobar said (and did) undo instead of back to default, doesn't this meet the need? -- with deinstall buttons Why does it matter to uninstall a theme that you aren't using? Particularly if we automatically delete theme resources when they are switched away from? - allowed tinting for themes (which I've heard only Cole talk about but no one else mention) Once we have this, you're right that we'll need some UI around it. I'd prefer to wait until we know what the needs. - a --~--~-~--~~~---~--~~ 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: How not to spend the day getting depot_tools, cygwin svn to play nicely...
My experience with this is that it's either all-or-nothing when it comes to using cygwin tools. My main git-svn checkout was created using cygwin svn+python, so I now need to comment out the lines in gclient that tries to run the .bat file :\ Overall I think I'm happier with my all-cygwin client.. it keeps the carriage returns away, which also makes git much happier. On Fri, Aug 7, 2009 at 5:25 PM, Peter Kasting pkast...@google.com wrote: On Fri, Aug 7, 2009 at 5:13 PM, Rafael Weinstein rafa...@chromium.orgwrote: Cygwin svn was doing something horrible (probably permissions-related) to my third_party/python_24 that caused the python binary not to run. The visible symptom was that my build generated a ton of cryptic Error 24s from Cmd.exe. The solution was to use the windows svn binaries. Yep. You MUST have the depot_tools svn ahead of the cygwin svn and use only that to check out Chromium. I thought we noted this somewhere... 1) Download depot_tools 2) Run gclient for the first time from command.exe (so you get the windows binaries) 3) Put /cygdrive/path/to/depot_tools as the FIRST component of you cygwin path (from .profile or .bashrc) Easier steps than these (maybe): Copy over a depot_tools folder from your previous machine (if applicable), ensure it's ahead of /usr/bin via .bash_profile or whatever. 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: Stack traces on layout test crashes
On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: 2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? A minute is a really long amount of time to add for the bots to cycle. Our goal historically has been 5 minutes for a full cycle. The tree is generally so much greener and easier to keep that way when we have fast cycle times. If there is a way to do it that doesn't require hitting the critical path, I think we should seriously consider it. Ojan --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 9:24 AM, Steve Vandebogartvand...@google.com wrote: Undoubtedly, there will be hundreds of themes, finding the same one you were using last week before you decided to try a different one will be a daunting task. From a usability perspective, it seems to me that keeping around a small set of recently used themes makes sense. That seems better. I'm a lot more interested in a recently used themes or previously used themes (in the style of the history page) chrome://themes/ page than having the dropdown in the options menu. On the same page, we could combine the theme customization controls (tinting, etc). - a --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
Seems like all of this can be done on the page. The nice property of the page is that there's room to show a preview of the theme, which in many cases is more memorable than the name. -Ben On Mon, Aug 10, 2009 at 10:02 AM, Aaron Boodmana...@chromium.org wrote: On Mon, Aug 10, 2009 at 9:24 AM, Steve Vandebogartvand...@google.com wrote: Undoubtedly, there will be hundreds of themes, finding the same one you were using last week before you decided to try a different one will be a daunting task. From a usability perspective, it seems to me that keeping around a small set of recently used themes makes sense. That seems better. I'm a lot more interested in a recently used themes or previously used themes (in the style of the history page) chrome://themes/ page than having the dropdown in the options menu. On the same page, we could combine the theme customization controls (tinting, etc). - a --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
[Edit: right as I was going to send this, I see you seem to be thinking along similar lines.] You're right that a dropdown with the names of every theme the user has ever used is both unwieldy and unhelpful. How about this: We replace the Options buttons with a page with the 5 MRU themes (perhaps that have been used for more than 1 minute) and the default theme, each with a name, a thumbnail, and perhaps a link to the container page; and a link to the main theme gallery called pick another theme or get more themes or something. Click on a theme and it changes the current theme instantly, but doesn't reorder the list until you close the page. Or, instead of building this list in locally, we could build it in to the themes gallery. When you go there these MRU themes (and the default) are right on the first page. This can also help when you're trying to set up another machine with the theme you like and need to remember what it is. I hope you can understand why having the MRU themes at your fingertips can be convenient even if there is some way (the history page?) to try and find past themes. Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. Perhaps have both? * Don't leave crud (.crx files, anything in downloads directory, files in the user profile) on disk for previously installed themes. Clean them up. (Low priority.) 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 10:05 AM, Peter Kastingpkast...@google.com wrote: [Edit: right as I was going to send this, I see you seem to be thinking along similar lines.] You're right that a dropdown with the names of every theme the user has ever used is both unwieldy and unhelpful. How about this: We replace the Options buttons with a page with the 5 MRU themes (perhaps that have been used for more than 1 minute) and the default theme, each with a name, a thumbnail, and perhaps a link to the container page; and a link to the main theme gallery called pick another theme or get more themes or something. Click on a theme and it changes the current theme instantly, but doesn't reorder the list until you close the page. Or, instead of building this list in locally, we could build it in to the themes gallery. When you go there these MRU themes (and the default) are right on the first page. This can also help when you're trying to set up another machine with the theme you like and need to remember what it is. I hope you can understand why having the MRU themes at your fingertips can be convenient even if there is some way (the history page?) to try and find past themes. I think that building this into the gallery makes a lot of sense. And I realized that by preview you all might mean a picture of what this looks like, before you click anything. Similar to what is on the current gallery pages. Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. We have a bug open on this. It requires some changes to the themes service. I think that Avi is working on this. Perhaps have both? I'd rather it be just undo alone. We have an emergency exit back to default theme hidden in the prefs. Maybe it could also be in the gallery. * Don't leave crud (.crx files, anything in downloads directory, files in the user profile) on disk for previously installed themes. Clean them up. (Low priority.) It actually deletes them as of right now. You're remembering the way it used to behave. However, they still show up on the downloads page. There is a bug open on that. - a --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai o...@chromium.org wrote: On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: 2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? A minute is a really long amount of time to add for the bots to cycle. Our goal historically has been 5 minutes for a full cycle. The tree is generally so much greener and easier to keep that way when we have fast cycle times. If there is a way to do it that doesn't require hitting the critical path, I think we should seriously consider it. K. I'll assume that's not an option when I look into this, then. --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
On Mon, Aug 10, 2009 at 10:35 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai o...@chromium.org wrote: On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow jor...@chromium.orgwrote: On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: 2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? A minute is a really long amount of time to add for the bots to cycle. Our goal historically has been 5 minutes for a full cycle. The tree is generally so much greener and easier to keep that way when we have fast cycle times. If there is a way to do it that doesn't require hitting the critical path, I think we should seriously consider it. K. I'll assume that's not an option when I look into this, then. We might be able to speed it up. We can try it and see how much slower it gets. see test_shell_switches.cc There is already a : const wchar_t kCrashDumps[] = Lcrash-dumps; // Enable crash dumps It is using breakpad. I think it should work. Nicolas --~--~-~--~~~---~--~~ 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: Hyperlink-like UI element
The use of blue-underlined links for actions, as opposed to navigation, is unfortunately common in a number of Google's web UIs (like Sites and Docs.) I'm not sure what the official position is on it at Google, or among the web UI design community at large, but I personally think it's a very bad idea. —Jens --~--~-~--~~~---~--~~ 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: How not to spend the day getting depot_tools, cygwin svn to play nicely...
On Aug 7, 2009, at 5:25 PM, Peter Kasting wrote: Yep. You MUST have the depot_tools svn ahead of the cygwin svn and use only that to check out Chromium. I thought we noted this somewhere... Thanks for the tip. I'm just going through this setup right now, though it sounds like I'll be OK since I installed depot_tools and checked out Chromium before I installed Cygrin. I'll update the wiki page. —Jens --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
[Still didn't make it to chromium-dev -- trying yet again. Sorry for any dupes.] Here's a slightly improved (well, much improved, in that it doesn't crash[*]) version, again if anyone wants to mess with it: http://codereview.chromium.org/165224 (pardon the ugly code). Unfortunately, it fails miserably at resolving many symbols (my implementation falls back to dladdr(), which provides really crappy symbols), since proper symbols aren't actually generated for most Objective-C methods (at least in the system libraries). For those, you have to search in the __OBJC segment ... which I'm not quite keen enough to do right now. [*] The image isn't mapped into memory contiguously starting from the base address; the symtab and string table should usually end up in the __LINKEDIT segment, so you have to figure out appropriate addresses. You also have the joy of figuring out whether you're dealing with relocated or unrelocated addresses (hmmm -- maybe my abbreviation rel == relative == unrelocated isn't so great), for some reason. Ugh. - Trung On Aug 8, 2:42 pm, Albert J. Wong (王重傑) ajw...@chromium.org wrote: FYI, the code in debug_util.h will generate a stack trace, but symbol resolution doesn't work on mac. Last I messed with it (~4 months ago), mac didn't work because most of the symbols are private. Mark Mentovai suggested trying to reimplement dladdr, but I could never get it working. Here's the uploaded code if anyone to mess with it: http://codereview.chromium.org/164228 On windows and linux, assuming you actually have symbols generated (which I don't think you do for windows on the build bots), getting a trace should be as simple as creating one of those StackTrace objects in debug_util.h, and calling PrintBacktrace or OutputToStream on it. The hard part is knowing when to create the object, and making sure you're on the right thread. Also, these functions do some heap allocations so using them in a crash handler might be a bit unsafe...but if it's crashing, and there's already no way to get a core or something, making it crash harder isn't going to matter. -Albert --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
Here's a slightly improved (well, much improved, in that it doesn't crash[*]) version, again if anyone wants to mess with it: http://codereview.chromium.org/165224 (pardon the ugly code). Unfortunately, it fails miserably at resolving many symbols (my implementation falls back to dladdr(), which provides really crappy symbols), since proper symbols aren't actually generated for most Objective-C methods (at least in the system libraries). For those, you have to search in the __OBJC segment ... which I'm not quite keen enough to do right now. [*] The image isn't mapped into memory contiguously starting from the base address; the symtab and string table should usually end up in the __LINKEDIT segment, so you have to figure out appropriate addresses. You also have the joy of figuring out whether you're dealing with relocated or unrelocated addresses (hmmm -- maybe my abbreviation rel == relative == unrelocated isn't so great), for some reason. Ugh. - Trung Albert J. Wong (王重傑) wrote: FYI, the code in debug_util.h will generate a stack trace, but symbol resolution doesn't work on mac. Last I messed with it (~4 months ago), mac didn't work because most of the symbols are private. Mark Mentovai suggested trying to reimplement dladdr, but I could never get it working. Here's the uploaded code if anyone to mess with it: http://codereview.chromium.org/164228 On windows and linux, assuming you actually have symbols generated (which I don't think you do for windows on the build bots), getting a trace should be as simple as creating one of those StackTrace objects in debug_util.h, and calling PrintBacktrace or OutputToStream on it. The hard part is knowing when to create the object, and making sure you're on the right thread. Also, these functions do some heap allocations so using them in a crash handler might be a bit unsafe...but if it's crashing, and there's already no way to get a core or something, making it crash harder isn't going to matter. -Albert On Sat, Aug 8, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org mailto:jor...@chromium.org wrote: I'll take a look. If anyone has ideas on how to implement this (beyond looking at base/debug_util.h) please let me know! The last time I messed around with programatic stack traces was 5+ years ago. :-) On Sat, Aug 8, 2009 at 7:53 AM, Dimitri Glazkov dglaz...@chromium.org mailto:dglaz...@chromium.org wrote: Somebody please run with this! :) :DG On Fri, Aug 7, 2009 at 8:45 PM, Darin Fisherda...@chromium.org mailto:da...@chromium.org wrote: On Fri, Aug 7, 2009 at 8:39 PM, Ojan Vafai o...@chromium.org mailto:o...@chromium.org wrote: On Fri, Aug 7, 2009 at 8:45 PM, Jeremy Orlow jor...@chromium.org mailto:jor...@chromium.org wrote: Has anyone ever looked into printing out stack traces when layout tests crash? Of the couple layout test crashes I've investigated, I think most could have been solved just by having a stack trace. I'm not really sure what's involved or if anyone's looked into this, which is why I'm asking. This could be especially helpful for flaky tests that crash. I don't remember anyone having looked into this. I agree that this would make tracking down and fixing these issues immensely easier, especially for tests that only sometimes crash. Ojan I've wanted this for a very long time. I think there might be a bug on it. At any rate, we now have a nice utility in base/debug_util.h that can provide a stack trace. I would love to see crash stacks on the buildbot. It would probably help us eliminate a lot of flakiness! -Darin --~--~-~--~~~---~--~~ 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: Hyperlink-like UI element
I agree that Get Themes ought to be a link. There are other links in the options menu (Learn More, Manage Certificates), so I think this was just an oversight. -- Evan Stade On Mon, Aug 10, 2009 at 11:14 AM, Jens Alfkes...@google.com wrote: The use of blue-underlined links for actions, as opposed to navigation, is unfortunately common in a number of Google's web UIs (like Sites and Docs.) I'm not sure what the official position is on it at Google, or among the web UI design community at large, but I personally think it's a very bad idea. —Jens --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
Yes, I wholeheartedly agree that these are gallery features. We should remove them from options/prefs panels. On Mon, Aug 10, 2009 at 11:09 AM, Avi Drissman a...@google.com wrote: On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman a...@chromium.org wrote: Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. We have a bug open on this. It requires some changes to the themes service. I think that Avi is working on this. I am? Please assign the bug, then, because I was unaware of it. Avi --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
As a user I don't mind going back to the gallery each time I want to change theme (and my mood will make me change themes regularly), but what is frustrating is that everytime I go back to one that I've tried in the past it redownloads the file again rather than using the .crx that is already present. Maybe the themes/extensions shouldn't be downloaded into the main download folder and checked to see if already present. Can themes auto-update? --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
[I can't seem to get this reply to chromium-dev. Maybe it didn't like the Chinese characters in Albert's name? I hope N duplicates don't eventually show up on the list.] Here's a slightly improved (well, much improved, in that it doesn't crash[*]) version, again if anyone wants to mess with it: http://codereview.chromium.org/165224 (pardon the ugly code). Unfortunately, it fails miserably at resolving many symbols (my implementation falls back to dladdr(), which provides really crappy symbols), since proper symbols aren't actually generated for most Objective-C methods (at least in the system libraries). For those, you have to search in the __OBJC segment ... which I'm not quite keen enough to do right now. [*] The image isn't mapped into memory contiguously starting from the base address; the symtab and string table should usually end up in the __LINKEDIT segment, so you have to figure out appropriate addresses. You also have the joy of figuring out whether you're dealing with relocated or unrelocated addresses (hmmm -- maybe my abbreviation rel == relative == unrelocated isn't so great), for some reason. Ugh. - Trung Albert J. Wong wrote: FYI, the code in debug_util.h will generate a stack trace, but symbol resolution doesn't work on mac. Last I messed with it (~4 months ago), mac didn't work because most of the symbols are private. Mark Mentovai suggested trying to reimplement dladdr, but I could never get it working. Here's the uploaded code if anyone to mess with it: http://codereview.chromium.org/164228 On windows and linux, assuming you actually have symbols generated (which I don't think you do for windows on the build bots), getting a trace should be as simple as creating one of those StackTrace objects in debug_util.h, and calling PrintBacktrace or OutputToStream on it. The hard part is knowing when to create the object, and making sure you're on the right thread. Also, these functions do some heap allocations so using them in a crash handler might be a bit unsafe...but if it's crashing, and there's already no way to get a core or something, making it crash harder isn't going to matter. -Albert --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
I hereby hang my head in shame. :-( (Should have noticed the new members moderated bit) --~--~-~--~~~---~--~~ 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: How not to spend the day getting depot_tools, cygwin svn to play nicely...
This thread couldn't have been more appropriately timed. I ran into the Error 34 issue again checking out a fresh client :\ Never again... http://codereview.chromium.org/164281 On Mon, Aug 10, 2009 at 11:17 AM, Jens Alfke s...@google.com wrote: On Aug 7, 2009, at 5:25 PM, Peter Kasting wrote: Yep. You MUST have the depot_tools svn ahead of the cygwin svn and use only that to check out Chromium. I thought we noted this somewhere... Thanks for the tip. I'm just going through this setup right now, though it sounds like I'll be OK since I installed depot_tools and checked out Chromium before I installed Cygrin. I'll update the wiki pagehttp://dev.chromium.org/developers/how-tos/get-the-code . —Jens --~--~-~--~~~---~--~~ 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: Do we have any existing code for reading/writing INI files?
On Mon, Aug 10, 2009 at 3:28 PM, Daniel Cowxdaniel.c...@gmail.com wrote: Just wondering if there's any code kicking around somewhere in the codebase for reading/writing INI files? No, we don't deal with ini files at all to my knowledge. We use JSON for that type of thing. What do you need it for? Brett --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
On Mon, Aug 10, 2009 at 1:39 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Mon, Aug 10, 2009 at 10:35 AM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai o...@chromium.org wrote: On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow jor...@chromium.orgwrote: On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain nsylv...@chromium.org wrote: 2. The show stopper for any implementation of this feature is that the machines running the layout tests don't have the pdbs for test_shell. Since the binary is built on another machine, it was too slow to copy the pdbs from one machine to another. If you guys think it's important, and can take the ~30-60 more seconds to cycle the bots, then we can copy them too, and the feature would work. I'm not really sure what the right answer is. It sure would be nice if we didn't need to use a tool to decode the call stacks of crashed layout tests. I kind of feel like an additional 30-60 seconds isn't going to be a big deal on these bots, but maybe it is. What do people think? A minute is a really long amount of time to add for the bots to cycle. Our goal historically has been 5 minutes for a full cycle. The tree is generally so much greener and easier to keep that way when we have fast cycle times. If there is a way to do it that doesn't require hitting the critical path, I think we should seriously consider it. K. I'll assume that's not an option when I look into this, then. We might be able to speed it up. We can try it and see how much slower it gets. I'm all for trying the easy thing and seeing what the cost is. If it turns out to be expensive, we can try other things. Also, if getting a 1 minute hit on build cycle times is the only (reasonable) way to accomplish this, then I *do* think it's worth it. This is really valuable. Would be great if we could get stacktraces and keep the same(ish) cycle times though. :) Ojan --~--~-~--~~~---~--~~ 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 11:09 AM, Avi Drissmana...@google.com wrote: On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman a...@chromium.org wrote: Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. We have a bug open on this. It requires some changes to the themes service. I think that Avi is working on this. I am? Please assign the bug, then, because I was unaware of it. FYI, just so interested parties know the resolution, the work I was thinking of Avi was working on, but it i done now. We can now implement the undo UI, I will create a bug on myself. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] build error, libavcodec.so.52
Just got this error: scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52' not found, needed by target `/chromium/src/sconsbuild/Debug/libavcodec.so.52'. I'll try to workaround it, but it looks like a bug. I did gclient sync recently (which ran gyp). --~--~-~--~~~---~--~~ 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: build error, libavcodec.so.52
Looks like gclient sync --force fixed that. I think something confused git while switching old branches. On Mon, Aug 10, 2009 at 17:04, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Just got this error: scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52' not found, needed by target `/chromium/src/sconsbuild/Debug/libavcodec.so.52'. I'll try to workaround it, but it looks like a bug. I did gclient sync recently (which ran gyp). --~--~-~--~~~---~--~~ 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: build error, libavcodec.so.52
On the bright side, now you only download the binaries that make sense for your platform. :) -Albert On Mon, Aug 10, 2009 at 5:18 PM, Andrew Scherkus scher...@chromium.orgwrote: We shuffled these around on Friday such that these binaries now live in /deps/third_party/ffmpeg and are pulling in via DEPS. Try: rm -rf src/third_party/ffmpeg/binaries rm .gclient_entries gclient sync --force On Mon, Aug 10, 2009 at 5:04 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just got this error: scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52' not found, needed by target `/chromium/src/sconsbuild/Debug/libavcodec.so.52'. I'll try to workaround it, but it looks like a bug. I did gclient sync recently (which ran gyp). --~--~-~--~~~---~--~~ 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: gyp failing while triggering gclient sync in linux with git
Not that I know of. Too bad really...-BradN On Thu, Aug 6, 2009 at 10:56 PM, Mohamed Mansour m...@chromium.org wrote: What is stopping us doing Massive line endings commit for all the files in our repository in src/chrome. +1 on the presubmit check! Is there a way to force Visual Studio Solutions or Projects to always save line endings in LF generated via gyp. -- Mohamed Mansour On Fri, Aug 7, 2009 at 1:48 AM, Bradley Nelson bradnel...@google.comwrote: Yeah we should certainly handle this better.This was a known thing, but I've called it out in this gyp issue: http://code.google.com/p/gyp/issues/detail?id=38 I do like have consistent line endings, but the error message leaves something to be desired (not to mention being different on each platform :-). Shouldn't be a big deal to fix. -BradN On Thu, Aug 6, 2009 at 10:39 PM, Evan Martin e...@chromium.org wrote: I am a little surprised that Python's eval isn't line-ending agnostic. This thread http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html suggests it doesn't like \r even on Windows and offers a simple workaround when reading the file: '\n'.join(s.splitlines()) On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelsonbradnel...@google.com wrote: Yes Mohamed, please do. Which files had the dos line endings? We should really add a presubmit check... -BradN On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Ah thank you Dan! It worked! I guess I should commit the line ending then? -- Mohamed Mansour On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel d...@kegel.com wrote: Please check to make sure the python scripts have UNIX line endings, not DOS ones. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Clobbering
We really need a better way to submit patches that we know require a clobber. Today alone, there were 2 WebKit deps rolls that we _knew_ would need a clobber. Both ended up closing the tree for a bit. What if we added an optional flag to the CL descriptions that tells the bots that a clobber is necessary? Maybe just CLOBBER=blah where blah is the platforms that require it split by commas and/or spaces? So, for example, my CL might look like: This is a really nice CL, but it touches files that confuse the dependency tracking system on Windows and linux. TEST=none BUG=none CLOBBER=win, linux Would this be terribly hard? Any major downsides? J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
