[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow wrote: > I think the main points of contention regarding SecurityOrigin::toString() > are the name "toString" and what type it should return. > > In terms of the names: I think we should provide constructors and getters > for each "component" of each WebKit API type. So, for example, > WebSecurityOrigin should have a constructor that takes in a single string > and a getter called |origin|. > It seems strange for something that is an origin to have a getter named origin. It leads to code like this: origin->origin(), which seems bad to me. toString() is the name used by WebCore, and it seems reasonable to me. It is merely a method that returns a string representation of the SecurityOrigin suitable for pickling. What is your objection to toString? > (We can argue about the name later.) base::SecurityOrigin > I mentioned before that base is not the right place for SecurityOrigin. See Brett's posts about what should and shouldn't be part of base/. It is a dumping ground today, and we should resist more of that will full force. In this case, only webkit/glue and above needs this type, so it does not need to live in base/. > can then have a method to produce WebSecurityOrigins (using that > constructor that takes in the base componentswhich is just "origin" in > this classes case) and it can have a constructor that takes in a > WebSecurityOrigin (which will construct itself by using the aforementioned > getter(s)). > This seems fine to me provided we actually need WebSecurityOrigin or SecurityOrigin to expose the component parts. However, I haven't seen any use cases for that yet. Maybe I have missed them? > > In terms of what it should return: Each "component" should really be a C++ > primitive. This of course leaves the question of how to handle strings. > Personally, I think we should do one of 2 things: Either WebString should > expose its components (an array of unsigned shorts + a size_t) > WebString already has accessors for the array of unsigned shorts and a size_t for the length. > or we should just put string16 into the WebKit API. The latter is not as > insane as it sounds: it's just a special case of std::string. The former > isn't that insane either since it can be fed directly to a std::string(16) > constructor. > The WebKit API is intended to be usable by consumers who do not have a full STL implementation (e.g., Android). > > If we add the proper constructors and factories for WebKit types to > NullableString16, GURL, SecurityOrigin, and any other types we might want to > connect to WebKit types in the future, then we can actually make the > dependency 100% one way. > It is OK for the WebKit API to know about GURL since WebCore depends on googleurl (specifically the generic, implementation bits). However, since GURL uses STL, there is just an optional (#ifdef controlled) conversion helper on WebURL for it. The same does not apply for NullableString16 or SecurityOrigin. > > I guess I feel like we should either say that depending on base types is OK > (as long as we think they'll be very stable implementation wise) or we > should say they're never allowed. This middle ground just feels wrong. > Note that the difference between toString and a single getter that returns > a string is subtle, but if all WebKit types follow this same convention, > then it's much less likely that people will do stupid things with them. > > I generally prefer all or nothing approaches too, but the implicit conversions to string16 and std::string are extremely nice. I don't want to give them up. At the same time, I object to building further dependencies on base from svn.webkit.org. NullableString16 seemed like a reasonable addition since it is just a slight variant of string16 that we can probably afford to treat as frozen. -Darin > J > > > On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher wrote: > >> On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow wrote: >> >>> You mean string16, right? >> >> >> I see instances of std::string and string16. I would be happiest if we >> unified on one. string16 is probably the path of least resistance. >> >> std::string has the benefit of being more compact, which for something >> like this which is really just a bag of bytes is probably a good thing. >> >> >> >>> >>> I really don't think it buys us much if it's purely optional that people >>> put the security origin (in string representation) into a wrapper that then >>> blocks them from doing anything silly with it. >>> >> >> we could give it a ToString() method. i think the point of SecurityOrigin >> would be to guide people in the right direction. >> >> -darin >> >> >> >>> >>> More to the point, I don't think it's useful enough that I'm going to >>> bother implementing it. If someone else wants to, I'd probably use it. >>> >>> >>> On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher wrote: >>> To be clear: I only weakly advocate Ch
[chromium-dev] Who's sheriff?
Today on the waterfall, I see: Sheriffs: munjal >From past experience, one sheriff really isn't enough. Munjal should be able to take a lunch break. Also, I think that this will be his first stint as sheriff. It would probably help him out if he had a co-sheriff who had done it at least once before. (Munjal, apologies if you've done it before and I missed it - in that case, maybe we can get you a rookie co-sheriff so you can be the mentor.) Who's sheriff? What do we do in cases where a sheriff declines or goes on vacation without swapping with someone else? Mark --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
Awesome Can we link to it from the waterfall? (*) * I am in no way volunteering to do this :-P :DG< On Thu, Oct 15, 2009 at 9:11 AM, Glenn Wilson wrote: > Hi Webkit gardeners, > The Windows canary bot now generates formatted layout test results on each > build that had unexpected failing layout tests, which means you can quickly > see layout test failures, diffs, and upstream baselines without running the > tool manually. The goal of this output is to help gardeners assess what may > have changed, and how to best handle the failure. > For example, here are the failures for build 13359: > http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html > To see the formatted layout test failures for a specific canary build, just > click on the "layout test results" link in the "archive webkit test results" > step, then click on the "index-.html" file. > There's still more work to do, including getting the formatter working > properly on the Mac & Linux canaries, adding flakiness data, adding a link > directly to the waterfall display, and more. Many thanks go to Ojan, > Nicolas and all others who endured my many code reviews, and Eric Roman and > Dimitri for the original spec and design. > Please let me know what you think, and what changes you'd like to see. > Glenn > > > > > --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
This makes me very happy! 2009/10/15 Glenn Wilson : > Hi Webkit gardeners, > The Windows canary bot now generates formatted layout test results on each > build that had unexpected failing layout tests, which means you can quickly > see layout test failures, diffs, and upstream baselines without running the > tool manually. The goal of this output is to help gardeners assess what may > have changed, and how to best handle the failure. > For example, here are the failures for build 13359: > http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html > To see the formatted layout test failures for a specific canary build, just > click on the "layout test results" link in the "archive webkit test results" > step, then click on the "index-.html" file. > There's still more work to do, including getting the formatter working > properly on the Mac & Linux canaries, adding flakiness data, adding a link > directly to the waterfall display, and more. Many thanks go to Ojan, > Nicolas and all others who endured my many code reviews, and Eric Roman and > Dimitri for the original spec and design. > Please let me know what you think, and what changes you'd like to see. > Glenn > > > > > -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Running applications in chrome with javascript
hi! i want to know how to run an applicacion with the chrome, as the same as activeX in IE and xpcom interfaces in Mozilla... thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] hi!
- --~--~-~--~~~---~--~~ 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: Who owns crash...@chromium.org and why is there so many updates from it?
Disabled the auto-crash features for Mac. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Oct 12, 2009 at 9:44 AM, Mike Pinkerton wrote: > I just had crashbot add a totally unrelated stack trace to a bug. I > emailed anthony about it, we'll see. > > Something is clearly wrong. > > On Mon, Oct 12, 2009 at 12:41 PM, Scott Hess wrote: > > > > Does this relate to receiving crashbot emails adding "Crash" labels on > > closed-out bugs where the backtrace doesn't apparently have any > > relevance to the original backtraces involved with the bug? I've > > gotten a couple of these in the past week. > > > > -scott > > > > [Unfortunately, I don't remember the earlier one, the latter is > > http://crbug.com/13113 ] > > > > On Tue, Oct 6, 2009 at 9:58 PM, John Abd-El-Malek > wrote: > >> > >> > >> On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge > >> wrote: > >>> > >>> The short of it: > >>> > >>> People manually associated bugs in http:crash > >>> My tool creates its own map of signatures and for whatever reason that > bug > >>> is on all of them > >>> It goes through each aggregate signature and updates the status of the > bug > >>> (which is a flash crasher) > >>> It's made much worse because we are dealing w/ crashes that don't have > >>> symbols and cannot be aggregated... > >>> > >>> What went wrong: > >>> > >>> The limiting function (seeing if crash-VERSION) was applied does not > >>> happen for priority updates. This was actually intentional since we > start > >>> looking at crash data early on. However this should no longer be > needed > >>> since we wait for enough data that priority should no longer be > shifting. > >>> > >>> What can be done about it? > >>> > >>> I will put a limiter on setting the priority > >> > >> Thanks. > >> > >>> > >>> Kind Regards, > >>> > >>> Anthony Laforge > >>> Technical Program Manager > >>> Mountain View, CA > >>> > >>> > >>> On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson > >>> wrote: > > John's question is about why it's generating so many issue updates. > > Patrick > > > On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge > > wrote: > > It's the role account that manages crashes and crash related bugs. > > Kind Regards, > > > > Anthony Laforge > > Technical Program Manager > > Mountain View, CA > > > > > > On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson < > patr...@chromium.org> > > wrote: > >> > >> [+laforge] > >> > >> On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek < > j...@chromium.org> > >> wrote: > >> > I got 21 emails in the last day > >> > for http://code.google.com/p/chromium/issues/detail?id=20915 > >> > >> > > >> > > > > > > >>> > >> > >> > >> > > >> > > > > > > > > > > > > -- > 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-dev] How To Compile Chrome OS
Is it possible to Compile Chrome OS version of Chromium? Where I can find more news? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Canary bot, now with formatted layout test results
Hi Webkit gardeners, The Windows canary bot now generates formatted layout test results on each build that had unexpected failing layout tests, which means you can quickly see layout test failures, diffs, and upstream baselines without running the tool manually. The goal of this output is to help gardeners assess what may have changed, and how to best handle the failure. For example, here are the failures for build 13359: http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html To see the formatted layout test failures for a specific canary build, just click on the "layout test results" link in the "archive webkit test results" step, then click on the "index-.html" file. There's still more work to do, including getting the formatter working properly on the Mac & Linux canaries, adding flakiness data, adding a link directly to the waterfall display, and more. Many thanks go to Ojan, Nicolas and all others who endured my many code reviews, and Eric Roman and Dimitri for the original spec and design. Please let me know what you think, and what changes you'd like to see. Glenn --~--~-~--~~~---~--~~ 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: Is it time to create a SecurityOrigin class in Chromium?
I guess you're rightabout pretty much everything. I'll put it in chrome/common then? (Note I actually wasn't planning on putting it in base unless the API depended on it, but it seemed like including that would just make what I was saying more confusing.) On Thu, Oct 15, 2009 at 12:19 AM, Darin Fisher wrote: > On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow wrote: > >> I think the main points of contention regarding SecurityOrigin::toString() >> are the name "toString" and what type it should return. >> >> In terms of the names: I think we should provide constructors and getters >> for each "component" of each WebKit API type. So, for example, >> WebSecurityOrigin should have a constructor that takes in a single string >> and a getter called |origin|. >> > > It seems strange for something that is an origin to have a getter named > origin. It leads to code like this: origin->origin(), which seems bad to > me. > > toString() is the name used by WebCore, and it seems reasonable to me. It > is merely a method that returns a string representation of the > SecurityOrigin suitable for pickling. What is your objection to toString? > > > >> (We can argue about the name later.) base::SecurityOrigin >> > > I mentioned before that base is not the right place for SecurityOrigin. > See Brett's posts about what should and shouldn't be part of base/. It is > a dumping ground today, and we should resist more of that will full force. > In this case, only webkit/glue and above needs this type, so it does not > need to live in base/. > > > >> can then have a method to produce WebSecurityOrigins (using that >> constructor that takes in the base componentswhich is just "origin" in >> this classes case) and it can have a constructor that takes in a >> WebSecurityOrigin (which will construct itself by using the aforementioned >> getter(s)). >> > > This seems fine to me provided we actually need WebSecurityOrigin or > SecurityOrigin to expose the component parts. However, I haven't seen any > use cases for that yet. Maybe I have missed them? > > > >> >> In terms of what it should return: Each "component" should really be a >> C++ primitive. This of course leaves the question of how to handle strings. >> Personally, I think we should do one of 2 things: Either WebString should >> expose its components (an array of unsigned shorts + a size_t) >> > > WebString already has accessors for the array of unsigned shorts and a > size_t for the length. > > > >> or we should just put string16 into the WebKit API. The latter is not as >> insane as it sounds: it's just a special case of std::string. The former >> isn't that insane either since it can be fed directly to a std::string(16) >> constructor. >> > > The WebKit API is intended to be usable by consumers who do not have a full > STL implementation (e.g., Android). > > > >> >> If we add the proper constructors and factories for WebKit types to >> NullableString16, GURL, SecurityOrigin, and any other types we might want to >> connect to WebKit types in the future, then we can actually make the >> dependency 100% one way. >> > > It is OK for the WebKit API to know about GURL since WebCore depends on > googleurl (specifically the generic, implementation bits). However, since > GURL uses STL, there is just an optional (#ifdef controlled) conversion > helper on WebURL for it. > > The same does not apply for NullableString16 or SecurityOrigin. > > > >> >> I guess I feel like we should either say that depending on base types is >> OK (as long as we think they'll be very stable implementation wise) or we >> should say they're never allowed. This middle ground just feels wrong. >> Note that the difference between toString and a single getter that returns >> a string is subtle, but if all WebKit types follow this same convention, >> then it's much less likely that people will do stupid things with them. >> >> > I generally prefer all or nothing approaches too, but the implicit > conversions to string16 and std::string are extremely nice. I don't want to > give them up. At the same time, I object to building further dependencies > on base from svn.webkit.org. > > NullableString16 seemed like a reasonable addition since it is just a > slight variant of string16 that we can probably afford to treat as frozen. > > -Darin > > > > >> J >> >> >> On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher wrote: >> >>> On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow wrote: >>> You mean string16, right? >>> >>> >>> I see instances of std::string and string16. I would be happiest if we >>> unified on one. string16 is probably the path of least resistance. >>> >>> std::string has the benefit of being more compact, which for something >>> like this which is really just a bag of bytes is probably a good thing. >>> >>> >>> I really don't think it buys us much if it's purely optional that people put the security origin (in string representation) into a wrapper that then >
[chromium-dev] Re: Canary bot, now with formatted layout test results
Christmas came early for anyone working on WebKit! Thanks Glen. :-) On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry wrote: > > This makes me very happy! > > 2009/10/15 Glenn Wilson : > > Hi Webkit gardeners, > > The Windows canary bot now generates formatted layout test results on > each > > build that had unexpected failing layout tests, which means you can > quickly > > see layout test failures, diffs, and upstream baselines without running > the > > tool manually. The goal of this output is to help gardeners assess what > may > > have changed, and how to best handle the failure. > > For example, here are the failures for build 13359: > > > http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html > > To see the formatted layout test failures for a specific canary build, > just > > click on the "layout test results" link in the "archive webkit test > results" > > step, then click on the "index-.html" file. > > There's still more work to do, including getting the formatter working > > properly on the Mac & Linux canaries, adding flakiness data, adding a > link > > directly to the waterfall display, and more. Many thanks go to Ojan, > > Nicolas and all others who endured my many code reviews, and Eric Roman > and > > Dimitri for the original spec and design. > > Please let me know what you think, and what changes you'd like to see. > > Glenn > > > > > > > > > > > > > -- > Erik Corry, Software Engineer > Google Denmark ApS. CVR nr. 28 86 69 84 > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 > Copenhagen K, Denmark. > > > > --~--~-~--~~~---~--~~ 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: [chromium-extensions] HTML5 spellcheck attribute
This is not really an extensions question. I think you want chromium-...@. - a On Thu, Oct 15, 2009 at 9:10 AM, Mixe wrote: > > Chrome does not support HTML5 spellcheck attribute? Then why > spellchecking is enabled by default? > How we can disable (using JS) spellchecking into INPUT and TEXTAREA > elements? > For example, when a user put the path or another specific text into a > text box, Chrome spellcheck always put red lines under the text :( A > user may think that something is wrong. > > > > --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
Glenn, this tool is amazing! It really helped me yesterday on my 1st gardening shift. Re: "upstream baselines without running the tool manually" How do I do that? On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow wrote: > Christmas came early for anyone working on WebKit! Thanks Glen. :-) > > > On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry wrote: > >> >> This makes me very happy! >> >> 2009/10/15 Glenn Wilson : >> > Hi Webkit gardeners, >> > The Windows canary bot now generates formatted layout test results on >> each >> > build that had unexpected failing layout tests, which means you can >> quickly >> > see layout test failures, diffs, and upstream baselines without running >> the >> > tool manually. The goal of this output is to help gardeners assess what >> may >> > have changed, and how to best handle the failure. >> > For example, here are the failures for build 13359: >> > >> http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html >> > To see the formatted layout test failures for a specific canary build, >> just >> > click on the "layout test results" link in the "archive webkit test >> results" >> > step, then click on the "index-.html" file. >> > There's still more work to do, including getting the formatter working >> > properly on the Mac & Linux canaries, adding flakiness data, adding a >> link >> > directly to the waterfall display, and more. Many thanks go to Ojan, >> > Nicolas and all others who endured my many code reviews, and Eric Roman >> and >> > Dimitri for the original spec and design. >> > Please let me know what you think, and what changes you'd like to see. >> > Glenn >> > >> > >> > > >> > >> >> >> >> -- >> Erik Corry, Software Engineer >> Google Denmark ApS. CVR nr. 28 86 69 84 >> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 >> Copenhagen K, Denmark. >> >> >> > > > > --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
The tool lives in
src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
actually be run against any builder, not just the canaries. Adding better
documentation is on the TODO list :)
(Also, re: adding link to waterfall, I think we can do this -- I'm
investigating now.)
On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman wrote:
> Glenn, this tool is amazing! It really helped me yesterday on my 1st
> gardening shift.
> Re: "upstream baselines without running the tool manually"
> How do I do that?
>
> On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow wrote:
>
>> Christmas came early for anyone working on WebKit! Thanks Glen. :-)
>>
>>
>> On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry wrote:
>>
>>>
>>> This makes me very happy!
>>>
>>> 2009/10/15 Glenn Wilson :
>>> > Hi Webkit gardeners,
>>> > The Windows canary bot now generates formatted layout test results on
>>> each
>>> > build that had unexpected failing layout tests, which means you can
>>> quickly
>>> > see layout test failures, diffs, and upstream baselines without running
>>> the
>>> > tool manually. The goal of this output is to help gardeners assess what
>>> may
>>> > have changed, and how to best handle the failure.
>>> > For example, here are the failures for build 13359:
>>> >
>>> http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
>>> > To see the formatted layout test failures for a specific canary build,
>>> just
>>> > click on the "layout test results" link in the "archive webkit test
>>> results"
>>> > step, then click on the "index-.html" file.
>>> > There's still more work to do, including getting the formatter working
>>> > properly on the Mac & Linux canaries, adding flakiness data, adding a
>>> link
>>> > directly to the waterfall display, and more. Many thanks go to Ojan,
>>> > Nicolas and all others who endured my many code reviews, and Eric Roman
>>> and
>>> > Dimitri for the original spec and design.
>>> > Please let me know what you think, and what changes you'd like to see.
>>> > Glenn
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Erik Corry, Software Engineer
>>> Google Denmark ApS. CVR nr. 28 86 69 84
>>> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
>>> Copenhagen K, Denmark.
>>>
>>>
>>>
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
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: [chromium-extensions] HTML5 spellcheck attribute
On Thu, Oct 15, 2009 at 10:04 AM, Aaron Boodman wrote: > > This is not really an extensions question. I think you want chromium-...@. > > - a > > On Thu, Oct 15, 2009 at 9:10 AM, Mixe wrote: > > > > Chrome does not support HTML5 spellcheck attribute? Then why > > spellchecking is enabled by default? > > How we can disable (using JS) spellchecking into INPUT and TEXTAREA > > elements? > I think there is a bug here, the spellcheck attribute should work. works, but myTextArea.spellcheck = false seems not to. Can you file a bug for this at crbug.com? > > For example, when a user put the path or another specific text into a > > text box, Chrome spellcheck always put red lines under the text :( A > > user may think that something is wrong. > > > > > > > > > > > --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
Replying off-list as requested... Firstly, this is awesome! On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips wrote: > git-cl upload > Runs presubmit tests on upload, continues even if tests fail. > This latter part is different than the gcl version. Is that intentional? I don't have an opinion on which is the correct behavior, but it would be nice to keep the scripts consistent. > To bypass the presubmit tests in upload or dcommit, use > the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks > along with skipping the commit confirm prompt. > Ditto above. The gcl flag is --no-presubmit. --~--~-~--~~~---~--~~ 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: layout test dashboard goofup
I put some more thought into this. Given that we only store a month's worth of data, it's not worth doing backups. Keeping around all the data (maybe a year's worth?) would be awesome though. I actually think that would not be too much work and would add value to the dashboard. At that point, doing backups seems more worthwhile. I'm happy to walk someone through how to make this happen. It really would not be a lot of work if you have a workable knowledge of Python and JS. Ojan On Wed, Oct 14, 2009 at 5:15 PM, Nicolas Sylvain wrote: > On Wed, Oct 14, 2009 at 4:53 PM, Ojan Vafai wrote: > >> The data is stored in a single file per bot. For example, the webkit >> release bot's results are at >> http://build.chromium.org/buildbot/layout_test_results/webkit-rel/results.json. >> That >> file holds all the historical data for that bot and is copied over during >> the archive step of each run. We intentionally limit the number of results >> we keep in that file to 750 runs to keep filesize down. In my accidental >> checking, I changed 750 to 9. :( > > A little bit unrelated: This data, along with all the data on > build.chromium.org, is replicated on at least 4 machines. It would be easy > to recover the data if the server dies for example. We are also planning to > do daily backups, but the data is huge. For example, we archive 25GB of new > layout test results every day. > > Nicolas > > >> A trivial to implement "backup" would be to also copy the file to the >> archive location for just that run (same place as where we copy >> layout_test_results.zip), e.g. also copy it to >> http://build.chromium.org/buildbot/layout_test_results/webkit-rel/29056/. >> The downside is that this uses up disk space (e.g. the largest results.json >> file was 25mb before being clobbered). >> >> Another problem with backing up is that you'd also have to find a way to >> restore from backup that didn't lose data from runs that happened since the >> problem occurred. Merging the two files results.json should be pretty >> relatively trivial code, but it's all code that someone would need to write >> and test. >> >> While it sucks, I don't think backing up this data is worth the effort. >> It's a temporary productivity hit for the team, but we get enough new data >> to make reasonable decisions relatively quickly. Mistakes like this are very >> rare. It will become even more rare as coding work on the dashboard winds >> down. >> >> Feel free to have at it if you disagree. >> >> Creates the results.json file and it's content: >> trunk/src/webkit/tools/layout_tests/layout_package/json_results_generator.py >> Copies the results.json file to the right >> place: >> trunk/tools/buildbot/scripts/slave/chromium/archive_layout_test_results.py >> >> Ojan >> >> >> On Wed, Oct 14, 2009 at 4:24 PM, Jeremy Orlow wrote: >> >>> I haven't actually gotten anything done on LocalStorage this week because >>> I've been doing so many small side projects like this.but if it's a >>> priority, sure. >>> How about a cron job on some machine that ssh's via a cert into whatever >>> machines the data is stored on, pulls it back, and dumps it into some dir? >>> When we start filling up the hard drive, we can look at doing something >>> smarter, deleting old data, or putting it somewhere like GFS. >>> >>> What server can I use and where's the data stored? >>> >>> On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin wrote: >>> Sounds like we've got a volunteer! :D :D :D On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow wrote: > I assume we're going to start backing this data up from now on? > > On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting wrote: >> >> On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai wrote: >>> >>> I accidentally checked in some test code (one number was wrong!) and >>> clobbered all but 10 of the runs of data for each builder. There's no way to >>> recover it. >> >> Do you moonlight for the Danger team at Microsoft? >> 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
Hi Andrew, On Wed, Oct 14, 2009 at 11:31 PM, Andrew Scherkus wrote: > Hrmm... it looks your script assumes depot_tools is in your PATH -- if it > can't find it the script crashes. Thanks for pointing this out. The hooks should fail gracefully in those cases, so I'll make that happen. > Trying to figure out a workaround. If all else fails I can always give in > and add depot_tools to my PATH :) > I am under the impression depot_tools in each of our PATHs was already a hard requirement. Are tools like git-cl, git-try, trychange.py, etc in some other directory in your PATH, or do you run them with absolute paths, or ...? Giving in might be best. :) Chase > > On Wed, Oct 14, 2009 at 11:08 PM, Aaron Boodman wrote: > >> >> Hooray, this is awesome. >> >> On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips >> wrote: >> > If you don't use git-cl, you can stop reading now. >> > Attention git-cl users: git-cl now has presubmit support! New users >> that >> > set up their git checkout on or after Wednesday (2009/10/14) are already >> > configured with presubmit support. Feel free to skip >> the setup instructions >> > since you've already run them but read on to learn more about the recent >> > changes. >> > Presubmit support for Existing Users (if you set up your git checkout >> before >> > 2009/10/14): >> > Run these commands to install the required git hooks in your repository: >> > >> > cd /work/chromium/src # where "/work/chromium/src" is the path to your >> git >> > repository >> > gclient sync # to upgrade your copy of depot_tools and git-cl >> > git cl config http://src.chromium.org/svn/ # to install the git-cl >> presubmit >> > hooks >> > >> > You must rerun the git cl config command in each of your local git >> > repositories. >> > New and updated git-cl commands: >> > git-cl presubmit >> > Runs upload and commit presubmit checks on the current changelist. >> > git-cl upload >> > Runs presubmit tests on upload, continues even if tests fail. >> > git-cl dcommit >> > Run presubmit tests on commit, halts if tests fail. >> > To bypass the presubmit tests in upload or dcommit, use >> > the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks >> > along with skipping the commit confirm prompt. >> > Questions? >> > Feel free to reply to me off-list with any questions you have. >> > Thanks to Evan Martin, Marc-Antoine Ruel, and Nicolas Sylvain for their >> help >> > making git-cl presubmit support a reality. >> > Chase >> > > >> > >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Memory] Observations on memory usage in flickr
I spent some time this morning looking at Chrome's memory usage (on OS X 10.5.8) while viewing flickr.com. First I simply started at my photo- stream page and hit Reload over and over. Next I tried going through all of my photos one by one. I used the RPRVT column in 'top', and the 'heap' and 'mmap' tools to examine memory usage. Reloading: • Memory usage keeps going up. The renderer starts at about 13MB resident, and goes up a little over 1MB after each reload. I could easily get it up above 50MB. There is some GC going on during the first few reloads, but not after that. Both the malloc and v8 heaps are growing, primarily malloc. • Forcing full GCs brings usage down somewhat, but you have to do it at least five or six times. • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. Browsing multiple pages: • Similar memory growth, as above. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. Conclusions: • As already known, V8 isn't collecting enough objects that have handles to big native object trees. • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. • There may be an opportunity in WebCore to toss out image backing stores more aggressively. —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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 11:03 AM, Chase Phillips wrote: > Hi Andrew, > > On Wed, Oct 14, 2009 at 11:31 PM, Andrew Scherkus > wrote: > >> Hrmm... it looks your script assumes depot_tools is in your PATH -- if it >> can't find it the script crashes. > > > Thanks for pointing this out. The hooks should fail gracefully in those > cases, so I'll make that happen. > > >> Trying to figure out a workaround. If all else fails I can always give in >> and add depot_tools to my PATH :) >> > > I am under the impression depot_tools in each of our PATHs was already a > hard requirement. Are tools like git-cl, git-try, trychange.py, etc in some > other directory in your PATH, or do you run them with absolute paths, or > ...? > For git-cl and git-try, they're symlinked from ~/bin to my depot_tools and everything seems to work. The difference here is that the git hook is executed from .git/hooks > > Giving in might be best. :) > Already did :) > > Chase > > >> >> On Wed, Oct 14, 2009 at 11:08 PM, Aaron Boodman wrote: >> >>> >>> Hooray, this is awesome. >>> >>> On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips >>> wrote: >>> > If you don't use git-cl, you can stop reading now. >>> > Attention git-cl users: git-cl now has presubmit support! New users >>> that >>> > set up their git checkout on or after Wednesday (2009/10/14) are >>> already >>> > configured with presubmit support. Feel free to skip >>> the setup instructions >>> > since you've already run them but read on to learn more about the >>> recent >>> > changes. >>> > Presubmit support for Existing Users (if you set up your git checkout >>> before >>> > 2009/10/14): >>> > Run these commands to install the required git hooks in your >>> repository: >>> > >>> > cd /work/chromium/src # where "/work/chromium/src" is the path to your >>> git >>> > repository >>> > gclient sync # to upgrade your copy of depot_tools and git-cl >>> > git cl config http://src.chromium.org/svn/ # to install the git-cl >>> presubmit >>> > hooks >>> > >>> > You must rerun the git cl config command in each of your local git >>> > repositories. >>> > New and updated git-cl commands: >>> > git-cl presubmit >>> > Runs upload and commit presubmit checks on the current changelist. >>> > git-cl upload >>> > Runs presubmit tests on upload, continues even if tests fail. >>> > git-cl dcommit >>> > Run presubmit tests on commit, halts if tests fail. >>> > To bypass the presubmit tests in upload or dcommit, use >>> > the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks >>> > along with skipping the commit confirm prompt. >>> > Questions? >>> > Feel free to reply to me off-list with any questions you have. >>> > Thanks to Evan Martin, Marc-Antoine Ruel, and Nicolas Sylvain for their >>> help >>> > making git-cl presubmit support a reality. >>> > Chase >>> > > >>> > >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 10:38 AM, Ojan Vafai wrote: > Replying off-list as requested... > Right! ;) > Firstly, this is awesome! > Thanks. > On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips wrote: > >> git-cl upload >> Runs presubmit tests on upload, continues even if tests fail. >> > > This latter part is different than the gcl version. Is that intentional? I > don't have an opinion on which is the correct behavior, but it would be nice > to keep the scripts consistent. > I agree about keeping them as consistent as possible. However, my tests of gcl upload show they already have the same behavior here: gcl uploads the patch to codereview whether or not the presubmit step fails. I just tested this twice again to confirm it. You see gcl fail to upload if the presubmit step fails? > To bypass the presubmit tests in upload or dcommit, use >> the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks >> along with skipping the commit confirm prompt. >> > > Ditto above. The gcl flag is --no-presubmit. > I considered both gcl and git's convention. I decided I would first wait to see if anyone cared enough to raise the issue and take it from there. :) git-cl is not Chromium-specific and using gcl's convention appeared to be a Chromium-specific solution. Based on that, I decided to go git's route where not running hooks is done using --bypass-hooks. This also seemed justified because git-cl's hooks could be used for more than just presubmit tests. It might be valid to add --no-presubmit to git-cl, or --bypass-hooks to gcl, or both. Thoughts? Chase --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 11:19 AM, Chase Phillips wrote: >>> To bypass the presubmit tests in upload or dcommit, use >>> the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks >>> along with skipping the commit confirm prompt. >> >> Ditto above. The gcl flag is --no-presubmit. > > I considered both gcl and git's convention. I decided I would first wait to > see if anyone cared enough to raise the issue and take it from there. :) > git-cl is not Chromium-specific and using gcl's convention appeared to be a > Chromium-specific solution. Based on that, I decided to go git's route > where not running hooks is done using --bypass-hooks. This also seemed > justified because git-cl's hooks could be used for more than just presubmit > tests. > It might be valid to add --no-presubmit to git-cl, or --bypass-hooks to gcl, > or both. Thoughts? I agree with Chase's reasoning. Also, you shouldn't need to bypass hooks frequently enough for this to matter much, and nobody switches between these two tools (they either use one or the other). --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke wrote: > • Switching to another tab in the same window is the only way to get > heap usage down significantly (by calling V8's IdleNotification) and > even then it takes over a minute of occasional idle-time GC to have a > significant effect. > Once I get my MemoryPurger functionality checked in, I'd like you to try it and see if it can successfully purge this memory. It loops calling IdleNotification() until that returns true. • Even hiding the tab doesn't bring memory usage down as much. The > 'vmmap' tool shows that there's a lot of space allocated to > CoreGraphics backing stores, much more than in the single-page case > (like 13MB vs 1MB.) I'm not sure if this is for the images on the > pages, or snapshots of the pages themselves for the back/forward > cache. Safari 4 on Mac has similar behavior. > My tool also dumps backing stores. 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: Is it time to create a SecurityOrigin class in Chromium?
On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote: > On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote: > >> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman >> wrote: >> > As mentioned f2f, this falls apart as soon as Chrome tries to >> manufacture a >> > security origin. I'm not sure, may already have instances of that in the >> > code base for all I know. >> >> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. >> There's a lot of tricky work in the canonicalization that we don't >> want to duplicate. >> >> Adam >> > > > Agreed, and we shouldn't be in that business. I think for all our use > cases, the > factory for security origins can be WebCore. > > Chrome just needs to be able to serialize / de-serialize a security > origin, compare > them, and possibly access some component parts (though I'm not certain of > this > requirement). > I think i have use cases for creating an 'origin' based on a GURL. > > -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: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote: > > > On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote: > >> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote: >> >>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman >>> wrote: >>> > As mentioned f2f, this falls apart as soon as Chrome tries to >>> manufacture a >>> > security origin. I'm not sure, may already have instances of that in >>> the >>> > code base for all I know. >>> >>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. >>> There's a lot of tricky work in the canonicalization that we don't >>> want to duplicate. >>> >>> Adam >>> >> >> >> Agreed, and we shouldn't be in that business. I think for all our use >> cases, the >> factory for security origins can be WebCore. >> >> Chrome just needs to be able to serialize / de-serialize a security >> origin, compare >> them, and possibly access some component parts (though I'm not certain of >> this >> requirement). >> > > I think i have use cases for creating an 'origin' based on a GURL. > We've talked through these repeatedly and I think we've made good cases against them. WebCore canonicalizes security origins. At the moment, we never create "security origins" in Chrome. You've given some examples of where we _might_ (read: this is vaporware) do this in the future. For all the use cases I've seen so far, I would actually propose adding a canonicalizeSecurityOrigin() method to WebSecurityOrigin that would create a WebCore::SecurityOrigin and then immediately toString() it. What other use cases are there? With each one, please make clear whether it's something we need today or whether it's something you suspect we'll need in the future...because I think most if not all of them are in this second bucket. And I don't want us to code ourselves into a corner, but I also don't want us to write a bunch of dead code that may be used in the future. --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke wrote: > > I spent some time this morning looking at Chrome's memory usage (on OS > X 10.5.8) while viewing flickr.com. First I simply started at my photo- > stream page and hit Reload over and over. Next I tried going through > all of my photos one by one. I used the RPRVT column in 'top', and the > 'heap' and 'mmap' tools to examine memory usage. > > Reloading: > • Memory usage keeps going up. The renderer starts at about 13MB > resident, and goes up a little over 1MB after each reload. I could > easily get it up above 50MB. There is some GC going on during the > first few reloads, but not after that. Both the malloc and v8 heaps > are growing, primarily malloc. > • Forcing full GCs brings usage down somewhat, but you have to do it > at least five or six times. > • Switching to another tab in the same window is the only way to get > heap usage down significantly (by calling V8's IdleNotification) and > even then it takes over a minute of occasional idle-time GC to have a > significant effect. > The suspicion is that V8 is holding handles active that are keeping the old DOM alive after refresh, so perhaps we need a way to tell V8 to actively attempt to purge its handles to C++. This would be called after a refresh or a navigation. - James > > Browsing multiple pages: > • Similar memory growth, as above. > • Even hiding the tab doesn't bring memory usage down as much. The > 'vmmap' tool shows that there's a lot of space allocated to > CoreGraphics backing stores, much more than in the single-page case > (like 13MB vs 1MB.) I'm not sure if this is for the images on the > pages, or snapshots of the pages themselves for the back/forward > cache. Safari 4 on Mac has similar behavior. > > Conclusions: > • As already known, V8 isn't collecting enough objects that have > handles to big native object trees. > • We should call V8::IdleNotification in situations other than a > hidden tab. A long-lived tab might go for quite a while without being > hidden in this way: the user might activate another app, hide Chrome > itself, or just use multiple windows instead of tabs. > • There may be an opportunity in WebCore to toss out image backing > stores more aggressively. > > —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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke wrote: > > I spent some time this morning looking at Chrome's memory usage (on OS > X 10.5.8) while viewing flickr.com. First I simply started at my photo- > stream page and hit Reload over and over. Next I tried going through > all of my photos one by one. I used the RPRVT column in 'top', and the > 'heap' and 'mmap' tools to examine memory usage. > > Reloading: > • Memory usage keeps going up. The renderer starts at about 13MB > resident, and goes up a little over 1MB after each reload. I could > easily get it up above 50MB. There is some GC going on during the > first few reloads, but not after that. Both the malloc and v8 heaps > are growing, primarily malloc. > • Forcing full GCs brings usage down somewhat, but you have to do it > at least five or six times. > • Switching to another tab in the same window is the only way to get > heap usage down significantly (by calling V8's IdleNotification) and > even then it takes over a minute of occasional idle-time GC to have a > significant effect. > > Browsing multiple pages: > • Similar memory growth, as above. > • Even hiding the tab doesn't bring memory usage down as much. The > 'vmmap' tool shows that there's a lot of space allocated to > CoreGraphics backing stores, much more than in the single-page case > (like 13MB vs 1MB.) I'm not sure if this is for the images on the > pages, or snapshots of the pages themselves for the back/forward > cache. Safari 4 on Mac has similar behavior. > > Conclusions: > • As already known, V8 isn't collecting enough objects that have > handles to big native object trees. > I disagree with this conclusion. V8 doesn't know anything about the large object trees. I think we (webkit) need to figure out how to clean up these trees independently. Since you said you're just reloading constantly, it could be that we're not cleaning up on page transitions. Alternatively, we could rework the bindings to allow cleanup of memory, while leaving only a small stub C++ wrapper. Webkit could cleanup it's huge object trees independent of GC this way. The bindings would need to be modified to deal with this case and error out (or re-wrap) appropriately. > • We should call V8::IdleNotification in situations other than a > hidden tab. A long-lived tab might go for quite a while without being > hidden in this way: the user might activate another app, hide Chrome > itself, or just use multiple windows instead of tabs. > We should try to avoid this. The V8 team has (rightfully) resisited hooks to allows the application to call gc() directly, because once you do that, invariably, some smart programmer decides to call gc() all the time!! :-) V8IdleNotification is basically a route to get at gc(). Let's not abuse it. If we're having problems getting memory cleaned up we should figure out: - where did the memory go in the first place - how to clean up incrementally We definitely don't want to grow too dependent on gc() to keep memory low. > • There may be an opportunity in WebCore to toss out image backing > stores more aggressively. > > —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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 11:19 AM, Chase Phillips wrote: > On Thu, Oct 15, 2009 at 10:38 AM, Ojan Vafai wrote: > >> Replying off-list as requested... >> > Right! ;) > Doh. > However, my tests of gcl upload show they already have the same behavior >> here: gcl uploads the patch to codereview whether or not the presubmit step >> fails. I just tested this twice again to confirm it. You see gcl fail to >> upload if the presubmit step fails? > > Huh. I just tested this and see the opposite (it did not upload). I made a change that breaks the test_expectations.txt presubmit check. Maybe that's just a bug? > git-cl is not Chromium-specific and using gcl's convention appeared to be a > Chromium-specific solution. Based on that, I decided to go git's route > where not running hooks is done using --bypass-hooks. This also seemed > justified because git-cl's hooks could be used for more than just presubmit > tests. > > It might be valid to add --no-presubmit to git-cl, or --bypass-hooks to > gcl, or both. Thoughts? > Ah. That makes more sense. Not sure it's worth bothering to put more work into this. As you said, if it becomes a problem we can always fix it later. --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:57 AM, Mike Belshe wrote: > • We should call V8::IdleNotification in situations other than a >> hidden tab. A long-lived tab might go for quite a while without being >> hidden in this way: the user might activate another app, hide Chrome >> itself, or just use multiple windows instead of tabs. >> > > We should try to avoid this. The V8 team has (rightfully) resisited hooks > to allows the application to call gc() directly, because once you do that, > invariably, some smart programmer decides to call gc() all the time!! :-) > V8IdleNotification is basically a route to get at gc(). Let's not abuse > it. > I don't think it's unfair to call IdleNotification() on the foreground tab if e.g. the user has not done anything with it for five or ten minutes. 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: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow wrote: > On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote: > >> >> >> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote: >> >>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote: >>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman wrote: > As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a > security origin. I'm not sure, may already have instances of that in the > code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam >>> >>> >>> Agreed, and we shouldn't be in that business. I think for all our use >>> cases, the >>> factory for security origins can be WebCore. >>> >>> Chrome just needs to be able to serialize / de-serialize a security >>> origin, compare >>> them, and possibly access some component parts (though I'm not certain of >>> this >>> requirement). >>> >> >> I think i have use cases for creating an 'origin' based on a GURL. >> > > We've talked through these repeatedly and I think we've made good cases > against them. WebCore canonicalizes security origins. At the moment, we > never create "security origins" in Chrome. > I wasn't implying that webcore's origin code wasn't doing the work, just mentioning the use case of determining an origin based on a url. Something like this could work. // Returns the security origin associated with the given url. (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url); > You've given some examples of where we _might_ (read: this is vaporware) do > this in the future. For all the use cases I've seen so far, I would > actually propose adding a canonicalizeSecurityOrigin() method to > WebSecurityOrigin that would create a WebCore::SecurityOrigin and then > immediately toString() it. > > What other use cases are there? With each one, please make clear whether > it's something we need today or whether it's something you suspect we'll > need in the future...because I think most if not all of them are in this > second bucket. And I don't want us to code ourselves into a corner, but I > also don't want us to write a bunch of dead code that may be used in the > future. > The use case is tracking usage per-origin in the appcache code. This isn't a hypothetical thing. --~--~-~--~~~---~--~~ 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: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman wrote: > > > On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow wrote: > >> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote: >> >>> >>> >>> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote: >>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote: > On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman > wrote: > > As mentioned f2f, this falls apart as soon as Chrome tries to > manufacture a > > security origin. I'm not sure, may already have instances of that in > the > > code base for all I know. > > I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. > There's a lot of tricky work in the canonicalization that we don't > want to duplicate. > > Adam > Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). >>> >>> I think i have use cases for creating an 'origin' based on a GURL. >>> >> >> We've talked through these repeatedly and I think we've made good cases >> against them. WebCore canonicalizes security origins. At the moment, we >> never create "security origins" in Chrome. >> > > I wasn't implying that webcore's origin code wasn't doing the work, just > mentioning the use case of determining an origin based on a url. Something > like this could work. > > // Returns the security origin associated with the given url. > (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url); > > >> You've given some examples of where we _might_ (read: this is vaporware) >> do this in the future. For all the use cases I've seen so far, I would >> actually propose adding a canonicalizeSecurityOrigin() method to >> WebSecurityOrigin that would create a WebCore::SecurityOrigin and then >> immediately toString() it. >> > >> What other use cases are there? With each one, please make clear whether >> it's something we need today or whether it's something you suspect we'll >> need in the future...because I think most if not all of them are in this >> second bucket. And I don't want us to code ourselves into a corner, but I >> also don't want us to write a bunch of dead code that may be used in the >> future. >> > > The use case is tracking usage per-origin in the appcache code. This isn't > a hypothetical thing. > And also restricting access to resources based on origins, also not a hypothetical thing. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] bugtracker cleanup
Today I reviewed some old bugs which didn't get any attention and tried to correctly mark/assign/close them. Feel free to reassign a bug if I assigned it to you - I was generally looking for people familiar with the area so that they can decide what to do next (please not that the status of such bugs is "unconfirmed" and not "assigned"). A lot of bugs got marked with Area-Compat-* so the compatibility metric might be affected. I think I can continue the cleanup at least a little bit. However, if we could have a plan to deal with the bugs so that every bug gets proper attention and an owner, that would be great. --~--~-~--~~~---~--~~ 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: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 12:17 PM, Michael Nordman wrote: > > > On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman wrote: > >> >> >> On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow wrote: >> >>> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman >>> wrote: >>> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote: > On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote: > >> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman >> wrote: >> > As mentioned f2f, this falls apart as soon as Chrome tries to >> manufacture a >> > security origin. I'm not sure, may already have instances of that in >> the >> > code base for all I know. >> >> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. >> There's a lot of tricky work in the canonicalization that we don't >> want to duplicate. >> >> Adam >> > > > Agreed, and we shouldn't be in that business. I think for all our use > cases, the > factory for security origins can be WebCore. > > Chrome just needs to be able to serialize / de-serialize a security > origin, compare > them, and possibly access some component parts (though I'm not certain > of this > requirement). > I think i have use cases for creating an 'origin' based on a GURL. >>> >>> We've talked through these repeatedly and I think we've made good cases >>> against them. WebCore canonicalizes security origins. At the moment, we >>> never create "security origins" in Chrome. >>> >> >> I wasn't implying that webcore's origin code wasn't doing the work, just >> mentioning the use case of determining an origin based on a url. Something >> like this could work. >> >> // Returns the security origin associated with the given url. >> (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url); >> >> >>> You've given some examples of where we _might_ (read: this is vaporware) >>> do this in the future. For all the use cases I've seen so far, I would >>> actually propose adding a canonicalizeSecurityOrigin() method to >>> WebSecurityOrigin that would create a WebCore::SecurityOrigin and then >>> immediately toString() it. >>> >> >>> What other use cases are there? With each one, please make clear whether >>> it's something we need today or whether it's something you suspect we'll >>> need in the future...because I think most if not all of them are in this >>> second bucket. And I don't want us to code ourselves into a corner, but I >>> also don't want us to write a bunch of dead code that may be used in the >>> future. >>> >> >> The use case is tracking usage per-origin in the appcache code. This isn't >> a hypothetical thing. >> > > And also restricting access to resources based on origins, also not a > hypothetical thing. > I don't think I ever used the word "hypothetical". Anyway, I think the WebSecurityOrigin::fromURL(blah)->toString() will work fine in this use case. But I might create a static method that's a shortcut for that just to make it super obvious to users. --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
Actually, can you package this so it could be upstreamed to webkit.org?
On Thu, Oct 15, 2009 at 1:09 PM, Glenn Wilson wrote:
> The tool lives in
> src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
> actually be run against any builder, not just the canaries. Adding better
> documentation is on the TODO list :)
>
> (Also, re: adding link to waterfall, I think we can do this -- I'm
> investigating now.)
>
>
> On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman wrote:
>
>> Glenn, this tool is amazing! It really helped me yesterday on my 1st
>> gardening shift.
>> Re: "upstream baselines without running the tool manually"
>> How do I do that?
>>
>> On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow wrote:
>>
>>> Christmas came early for anyone working on WebKit! Thanks Glen. :-)
>>>
>>>
>>> On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry wrote:
>>>
This makes me very happy!
2009/10/15 Glenn Wilson :
> Hi Webkit gardeners,
> The Windows canary bot now generates formatted layout test results on
each
> build that had unexpected failing layout tests, which means you can
quickly
> see layout test failures, diffs, and upstream baselines without
running the
> tool manually. The goal of this output is to help gardeners assess
what may
> have changed, and how to best handle the failure.
> For example, here are the failures for build 13359:
>
http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
> To see the formatted layout test failures for a specific canary build,
just
> click on the "layout test results" link in the "archive webkit test
results"
> step, then click on the "index-.html" file.
> There's still more work to do, including getting the formatter working
> properly on the Mac & Linux canaries, adding flakiness data, adding a
link
> directly to the waterfall display, and more. Many thanks go to Ojan,
> Nicolas and all others who endured my many code reviews, and Eric
Roman and
> Dimitri for the original spec and design.
> Please let me know what you think, and what changes you'd like to see.
> Glenn
>
>
> >
>
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
>>>
>>>
>>>
>>
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] problem passing Frame pointer across glue/WebCore boundary
Hi All,
Starting some time after rev 28713 I'm having a strange problem when I pass
a WebCore::Frame pointer across the glue/WebCore library boundary with CEF (
http://code.google.com/p/chromiumembedded). Everything works as expected
with the test_shell build, which makes me think there's a configuration
setting that I'm missing. I'm hoping that a new pair of eyes can spot my
mistake :-)
Consider the following method in webview_impl.cc:
void WebViewImpl::resize(const WebSize& new_size) {
...
if (main_frame()->frameview()) {
main_frame()->frameview()->resize(size_.width, size_.height);
main_frame()->frame()->eventHandler()->sendResizeEvent();
}
...
}
The "main_frame()->frameview()->resize()" call succeeds as expected.
However, the "main_frame()->frame()->eventHandler()->sendResizeEvent()" call
shows the following characteristics:
When I step into the WebFrameImpl::frame() method the 'this' pointer and
'frame_' member has the expected contents:
-this0x01863fe8 {frame_loader_client_={...}
scope_matches_factory_={...} client_handle_={client_=0x018620b0 } ...}
const WebFrameImpl * const
+frame_0x01864300 {m_page=0x01862e18 m_treeNode={...}
m_loader={...} ...}WebCore::Frame *
However, when I step into the Frame::eventHandler() method the 'this'
pointer has value 0x:
+this0x {m_page=??? m_treeNode={...} m_loader={...}
...}const WebCore::Frame * const
I thought initially that it might be an issue with my WebCore-related
defines, but I'm including features_override.gypi and I've verified by
visual inspection that the resulting .vcproj file has the same defines as
the test_shell project. Also, I've copied/pasted the Debug directory from
chrome and am still experiencing the problem with the exact same libraries
that work for test_shell.
Attached is the GYP configuration that I'm using. I'm building it using the
following command:
..\tools\gyp\gyp.bat cef.gyp -I ..\build\common.gypi -I
..\build\features_override.gypi
Any suggestions on what I'm doing wrong or what I should try next would be
greatly appreciated.
Thanks,
Marshall
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
cef.gyp
Description: Binary data
[chromium-dev] No co-sheriff today
I am the only scheduled sheriff today and there is no co-sheriff. I was out for 5 minutes to grab lunch and ran to my desk. The tree became red in the meantime. Sorry for not being thoughful to aks someone to cover for me during those 5 minutes. It would be great if someone can help me out today and tomorrow. -Munjal --~--~-~--~~~---~--~~ 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: No co-sheriff today
I've been sheriffing for Munjal for the past hour, when I found the tree in a bad state. I'm happy to keep helping, but it'd be great if some other folks would step up too. Mark Munjal wrote: > I am the only scheduled sheriff today and there is no co-sheriff. I was out > for 5 minutes to grab lunch and ran to my desk. The tree became red in the > meantime. > Sorry for not being thoughful to aks someone to cover for me during those 5 > minutes. > It would be great if someone can help me out today and tomorrow. --~--~-~--~~~---~--~~ 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: No co-sheriff today
I'll keep an eye on things tomorrow morning (east coast hours). TVL On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai wrote: > > I've been sheriffing for Munjal for the past hour, when I found the > tree in a bad state. > > I'm happy to keep helping, but it'd be great if some other folks would > step up too. > > Mark > > Munjal wrote: > > I am the only scheduled sheriff today and there is no co-sheriff. I was > out > > for 5 minutes to grab lunch and ran to my desk. The tree became red in > the > > meantime. > > Sorry for not being thoughful to aks someone to cover for me during those > 5 > > minutes. > > It would be great if someone can help me out today and tomorrow. > > > > --~--~-~--~~~---~--~~ 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: problem passing Frame pointer across glue/WebCore boundary
On Thu, Oct 15, 2009 at 3:49 PM, Marshall Greenblatt wrote:
> Hi All,
>
> Starting some time after rev 28713 I'm having a strange problem when I pass
> a WebCore::Frame pointer across the glue/WebCore library boundary with CEF (
> http://code.google.com/p/chromiumembedded). Everything works as expected
> with the test_shell build, which makes me think there's a configuration
> setting that I'm missing. I'm hoping that a new pair of eyes can spot my
> mistake :-)
>
Forgot to mention that I'm currently at rev 29114 and the problem also
existed at rev 28999.
>
> Consider the following method in webview_impl.cc:
>
> void WebViewImpl::resize(const WebSize& new_size) {
> ...
> if (main_frame()->frameview()) {
> main_frame()->frameview()->resize(size_.width, size_.height);
> main_frame()->frame()->eventHandler()->sendResizeEvent();
> }
> ...
> }
>
> The "main_frame()->frameview()->resize()" call succeeds as expected.
> However, the "main_frame()->frame()->eventHandler()->sendResizeEvent()" call
> shows the following characteristics:
>
> When I step into the WebFrameImpl::frame() method the 'this' pointer and
> 'frame_' member has the expected contents:
>
> -this0x01863fe8 {frame_loader_client_={...}
> scope_matches_factory_={...} client_handle_={client_=0x018620b0 } ...}
> const WebFrameImpl * const
> +frame_0x01864300 {m_page=0x01862e18 m_treeNode={...}
> m_loader={...} ...}WebCore::Frame *
>
> However, when I step into the Frame::eventHandler() method the 'this'
> pointer has value 0x:
>
> +this0x {m_page=??? m_treeNode={...} m_loader={...}
> ...}const WebCore::Frame * const
>
> I thought initially that it might be an issue with my WebCore-related
> defines, but I'm including features_override.gypi and I've verified by
> visual inspection that the resulting .vcproj file has the same defines as
> the test_shell project. Also, I've copied/pasted the Debug directory from
> chrome and am still experiencing the problem with the exact same libraries
> that work for test_shell.
>
> Attached is the GYP configuration that I'm using. I'm building it using
> the following command:
>
> ..\tools\gyp\gyp.bat cef.gyp -I ..\build\common.gypi -I
> ..\build\features_override.gypi
>
> Any suggestions on what I'm doing wrong or what I should try next would be
> greatly appreciated.
>
> Thanks,
> Marshall
>
--~--~-~--~~~---~--~~
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: No co-sheriff today
whats this sheriff thing can anyone explain :) ?I thought the first email was a spam hehe . On Fri, Oct 16, 2009 at 1:10 AM, Thomas Van Lenten wrote: > I'll keep an eye on things tomorrow morning (east coast hours). > TVL > > > On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai wrote: > >> >> I've been sheriffing for Munjal for the past hour, when I found the >> tree in a bad state. >> >> I'm happy to keep helping, but it'd be great if some other folks would >> step up too. >> >> Mark >> >> Munjal wrote: >> > I am the only scheduled sheriff today and there is no co-sheriff. I was >> out >> > for 5 minutes to grab lunch and ran to my desk. The tree became red in >> the >> > meantime. >> > Sorry for not being thoughful to aks someone to cover for me during >> those 5 >> > minutes. >> > It would be great if someone can help me out today and tomorrow. >> >> >> > > > > --~--~-~--~~~---~--~~ 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: No co-sheriff today
http://dev.chromium.org/developers/tree-sheriffs On Thu, Oct 15, 2009 at 4:12 PM, Abubakar wrote: > whats this sheriff thing can anyone explain :) ?I thought the first email > was a spam hehe . > > > On Fri, Oct 16, 2009 at 1:10 AM, Thomas Van Lenten > wrote: > >> I'll keep an eye on things tomorrow morning (east coast hours). >> TVL >> >> >> On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai wrote: >> >>> >>> I've been sheriffing for Munjal for the past hour, when I found the >>> tree in a bad state. >>> >>> I'm happy to keep helping, but it'd be great if some other folks would >>> step up too. >>> >>> Mark >>> >>> Munjal wrote: >>> > I am the only scheduled sheriff today and there is no co-sheriff. I was >>> out >>> > for 5 minutes to grab lunch and ran to my desk. The tree became red in >>> the >>> > meantime. >>> > Sorry for not being thoughful to aks someone to cover for me during >>> those 5 >>> > minutes. >>> > It would be great if someone can help me out today and tomorrow. >>> >>> >>> >> >> >> >> > --~--~-~--~~~---~--~~ 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: No co-sheriff today
On Thu, Oct 15, 2009 at 1:13 PM, Thomas Van Lenten wrote: > http://dev.chromium.org/developers/tree-sheriffs ...which is the top answer when you search for "sheriff" on dev.chromium.org. (Plug for automated tools) 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: bugtracker cleanup
On Thu, Oct 15, 2009 at 12:41 PM, Paweł Hajdan Jr. wrote: > Today I reviewed some old bugs which didn't get any attention and tried to > correctly mark/assign/close them. Feel free to reassign a bug if I assigned > it to you - I was generally looking for people familiar with the area so > that they can decide what to do next (please not that the status of such > bugs is "unconfirmed" and not "assigned"). > A lot of bugs got marked with Area-Compat-* so the compatibility metric > might be affected. > I think I can continue the cleanup at least a little bit. However, if we > could have a plan to deal with the bugs so that every bug gets proper > attention and an owner, that would be great. Thank you for doing this! I (and I think estade too) periodically skim through [os:linux status:unconfirmed] and try to at least comment on all the bugs that haven't seen any action in a while, so the number of bugs there tend to stay under 100 or so... --~--~-~--~~~---~--~~ 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: No co-sheriff today
oh. Thanks :) On Fri, Oct 16, 2009 at 1:13 AM, Thomas Van Lenten wrote: > http://dev.chromium.org/developers/tree-sheriffs > > > On Thu, Oct 15, 2009 at 4:12 PM, Abubakar wrote: > >> whats this sheriff thing can anyone explain :) ?I thought the first email >> was a spam hehe . >> >> >> On Fri, Oct 16, 2009 at 1:10 AM, Thomas Van Lenten > > wrote: >> >>> I'll keep an eye on things tomorrow morning (east coast hours). >>> TVL >>> >>> >>> On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai wrote: >>> I've been sheriffing for Munjal for the past hour, when I found the tree in a bad state. I'm happy to keep helping, but it'd be great if some other folks would step up too. Mark Munjal wrote: > I am the only scheduled sheriff today and there is no co-sheriff. I was out > for 5 minutes to grab lunch and ran to my desk. The tree became red in the > meantime. > Sorry for not being thoughful to aks someone to cover for me during those 5 > minutes. > It would be great if someone can help me out today and tomorrow. >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebKit Layouts bot pulling code from the canary?
The layout try bots are just too slow for the purposes of webkit gardening, which needs to keep up with the fast stream of layout test breakage coming from webkit.org. Gclient and compilation consume most of the time, but the gardener is usually only interested in the layout tests themselves. How hard would it be to ask the bots to use chrome built by the canaries rather than waste time rebuilding it from scratch? --~--~-~--~~~---~--~~ 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: [LTTF] Flaky tests and setTimeout
Another class of layout tests with bad setTimeouts in them -
Tests of the form:
...
function runTest() {
// Wait for img to load
setTimeout(step2, 200);
}
These tests are not flaky, but the setTimeouts are completely
unnecessary (body onload always fires AFTER the img loads) and are just
leading to longer cycle times. If you encounter these, feel free to
eliminate the setTimeout and waitUntilDone calls.
Julie
On Tue, Oct 13, 2009 at 11:48 PM, Andrew Scherkus wrote:
> On Tue, Oct 13, 2009 at 3:55 PM, Ojan Vafai wrote:
>
>> On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus
>> wrote:
>>
>>> What's happening is loadstart fires and the video reloads which should
>>> cause an abort event. For some reason load will occasionally fire after
>>> loadstart, ending the test.
>>>
>>> I know we can patch the test, but I've been digging through the event
>>> dispatching code to verify that the flakiness isn't limited to Chromium.
>>>
>>
>> Even if it is just limited to Chromium, it is still a bug, right? Unless
>> I'm not understanding, there's no case under which we should be patching the
>> test in the above case. I don't know anything about video events, so I don't
>> really know what event order guarantees there should be.
>>
>> Ojan
>>
>
> Yeah it's has to be a bug somewhere, just tricky to track down due to the
> thread interaction between the video subsystem and the renderer thread.
>
> Andrew
>
--~--~-~--~~~---~--~~
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: WebKit Layouts bot pulling code from the canary?
Would another solution be to have canary bots for both release and debug? On Thu, Oct 15, 2009 at 1:58 PM, Yaar Schnitman wrote: > The layout try bots are just too slow for the purposes of webkit gardening, > which needs to keep up with the fast stream of layout test breakage coming > from webkit.org. Gclient and compilation consume most of the time, but the > gardener is usually only interested in the layout tests themselves. > > How hard would it be to ask the bots to use chrome built by the canaries > rather than waste time rebuilding it from scratch? > > > > --~--~-~--~~~---~--~~ 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: WebKit Layouts bot pulling code from the canary?
That will help too. I've been missing On Thu, Oct 15, 2009 at 2:03 PM, Julie Parent wrote: > Would another solution be to have canary bots for both release and debug? > That will certainly help. I've rolled in test failures into our tree because the canaries didn't detect the debug ones. Still, it would be great if a gardener (or anybody) who's just changing some layout tests or expectations could test them against a specified build that already exists on one of the bots (e.g. the canaries), rather than wait 30-60 minutes for that build to complete. > On Thu, Oct 15, 2009 at 1:58 PM, Yaar Schnitman wrote: > >> The layout try bots are just too slow for the purposes of webkit >> gardening, which needs to keep up with the fast stream of layout test >> breakage coming from webkit.org. Gclient and compilation consume most of >> the time, but the gardener is usually only interested in the layout tests >> themselves. >> >> How hard would it be to ask the bots to use chrome built by the canaries >> rather than waste time rebuilding it from scratch? >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Mac] Chromium terminates when running from Terminal
Hi all, Starting from today, I can't run Chromium from Terminal, unless I'm running it under gdb. I'm getting the following bunch of error messages (on a Release build): 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in -[BrowserWindowController initWithWindowNibPath:owner:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not satisfying: windowNibPath 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: windowNibPath' 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( 2417545195, 2485780027, 2417544651, 2463723204, 2433132475, 36896176, 36889665, 36840062, 36542144, 36543780, 36611717, 36618850, 36622599, 36646971, 35731773 ) Trace/BPT trap If I launch Chromium from Finder, XCode, or under gdb in Terminal, it works fine. I've done a clean rebuild of Chromium, and I'm seeing this behavior on two machines. Does anyone have a similar problem, or maybe have a clue what goes wrong? --~--~-~--~~~---~--~~ 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: [Mac] Chromium terminates when running from Terminal
How exactly are you launching it? ie-what are you typing into the terminal. it might be the executable path change last night. TVL On Thu, Oct 15, 2009 at 6:07 PM, Mikhail Naganov wrote: > > Hi all, > > Starting from today, I can't run Chromium from Terminal, unless I'm > running it under gdb. I'm getting the following bunch of error > messages (on a Release build): > > 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in > -[BrowserWindowController initWithWindowNibPath:owner:], > /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 > 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was > raised > 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not > satisfying: windowNibPath > 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to > uncaught exception 'NSInternalInconsistencyException', reason: > 'Invalid parameter not satisfying: windowNibPath' > 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( > 2417545195, > 2485780027, > 2417544651, > 2463723204, > 2433132475, > 36896176, > 36889665, > 36840062, > 36542144, > 36543780, > 36611717, > 36618850, > 36622599, > 36646971, > 35731773 > ) > Trace/BPT trap > > If I launch Chromium from Finder, XCode, or under gdb in Terminal, it > works fine. I've done a clean rebuild of Chromium, and I'm seeing this > behavior on two machines. Does anyone have a similar problem, or maybe > have a clue what goes wrong? > > > > --~--~-~--~~~---~--~~ 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: [Mac] Chromium terminates when running from Terminal
How are you launching it from the Terminal? Can you tell me the exact invocation? $PATH and working directory too? Can you log the value of path after PathService::Get(base::FILE_EXE, &path) in chrome::GetVersionedDirectory(), chrome/common/chrome_paths_mac.mm:72? Mark Mikhail Naganov wrote: > Hi all, > > Starting from today, I can't run Chromium from Terminal, unless I'm > running it under gdb. I'm getting the following bunch of error > messages (on a Release build): > > 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in > -[BrowserWindowController initWithWindowNibPath:owner:], > /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 > 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised > 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not > satisfying: windowNibPath > 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to > uncaught exception 'NSInternalInconsistencyException', reason: > 'Invalid parameter not satisfying: windowNibPath' > 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( > 2417545195, > 2485780027, > 2417544651, > 2463723204, > 2433132475, > 36896176, > 36889665, > 36840062, > 36542144, > 36543780, > 36611717, > 36618850, > 36622599, > 36646971, > 35731773 > ) > Trace/BPT trap > > If I launch Chromium from Finder, XCode, or under gdb in Terminal, it > works fine. I've done a clean rebuild of Chromium, and I'm seeing this > behavior on two machines. Does anyone have a similar problem, or maybe > have a clue what goes wrong? --~--~-~--~~~---~--~~ 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: [Mac] Chromium terminates when running from Terminal
Also answering on Mark's question. $ pwd /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS $ ls -l total 40 -rwxr-xr-x 1 mnaganov eng 16472 Oct 16 01:25 Chromium $ echo $PATH /opt/local/bin:/opt/local/sbin:/Users/mnaganov/depot_tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin/g4bin $ ./Chromium <<< this way, it fails >>> $ gdb ./Chromium (gdb) pwd Working directory /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS. (gdb) show paths Executable and object file path: /opt/local/bin:/opt/local/sbin:/Users/mnaganov/depot_tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin/g4bin:/sbin:/bin:/usr/sbin:/usr/bin (gdb) r Starting program: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/Chromium <<< this way, it runs just fine >>> Here is the value of 'path' when running from Terminal: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/./Chromium When I run it under gdb, the path is printed two times: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/Chromium /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/Versions/4.0.223.1/Chromium Helper.app/Contents/MacOS/Chromium Helper On Fri, Oct 16, 2009 at 02:10, Thomas Van Lenten wrote: > How exactly are you launching it? ie-what are you typing into the terminal. > it might be the executable path change last night. > TVL > > On Thu, Oct 15, 2009 at 6:07 PM, Mikhail Naganov > wrote: >> >> Hi all, >> >> Starting from today, I can't run Chromium from Terminal, unless I'm >> running it under gdb. I'm getting the following bunch of error >> messages (on a Release build): >> >> 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in >> -[BrowserWindowController initWithWindowNibPath:owner:], >> /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 >> 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was >> raised >> 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not >> satisfying: windowNibPath >> 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to >> uncaught exception 'NSInternalInconsistencyException', reason: >> 'Invalid parameter not satisfying: windowNibPath' >> 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( >> 2417545195, >> 2485780027, >> 2417544651, >> 2463723204, >> 2433132475, >> 36896176, >> 36889665, >> 36840062, >> 36542144, >> 36543780, >> 36611717, >> 36618850, >> 36622599, >> 36646971, >> 35731773 >> ) >> Trace/BPT trap >> >> If I launch Chromium from Finder, XCode, or under gdb in Terminal, it >> works fine. I've done a clean rebuild of Chromium, and I'm seeing this >> behavior on two machines. Does anyone have a similar problem, or maybe >> have a clue what goes wrong? >> >> >> > > --~--~-~--~~~---~--~~ 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: Please confirm the bug (some bitmaps aren/t displayed)
Area-Misc bugs had a bit of a hiccup in triage, but we're looking at them regularly again. This bug was Unconfirmed, not Untriaged. We don't do a good job of looking at those bugs. It's an issue on my list, but not something I have anyone actively working on. On Mon, Oct 12, 2009 at 11:53, Jeremy Orlow wrote: > I think the bigger issue is how/when Area-Misc bugs get triaged. Do they > ever? If not, we should probably change that. > > > On Mon, Oct 12, 2009 at 11:50 AM, Guria wrote: > >> >> Please confirm the bug >> http://code.google.com/p/chromium/issues/detail?id=12900 >> It really annoys me. >> I expect that someone will fix it soon. I can provide more examples if >> needed. >> >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Change to default build architecture
http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES="target_arch=ia32" in the environment. Michael --~--~-~--~~~---~--~~ 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: layout test dashboard goofup
I actually have a copy of the data from Tuesday at 2:30pm. If you need any information out of the results page, just let me know. Julie On Thu, Oct 15, 2009 at 10:58 AM, Ojan Vafai wrote: > I put some more thought into this. Given that we only store a month's worth > of data, it's not worth doing backups. > > Keeping around all the data (maybe a year's worth?) would be awesome > though. I actually think that would not be too much work and would add value > to the dashboard. At that point, doing backups seems more worthwhile. > > I'm happy to walk someone through how to make this happen. It really would > not be a lot of work if you have a workable knowledge of Python and JS. > > Ojan > > > On Wed, Oct 14, 2009 at 5:15 PM, Nicolas Sylvain wrote: > >> On Wed, Oct 14, 2009 at 4:53 PM, Ojan Vafai wrote: >> >>> The data is stored in a single file per bot. For example, the webkit >>> release bot's results are at >>> http://build.chromium.org/buildbot/layout_test_results/webkit-rel/results.json. >>> That >>> file holds all the historical data for that bot and is copied over during >>> the archive step of each run. We intentionally limit the number of results >>> we keep in that file to 750 runs to keep filesize down. In my accidental >>> checking, I changed 750 to 9. :( >> >> A little bit unrelated: This data, along with all the data on >> build.chromium.org, is replicated on at least 4 machines. It would be >> easy to recover the data if the server dies for example. We are also >> planning to do daily backups, but the data is huge. For example, we archive >> 25GB of new layout test results every day. >> >> Nicolas >> >> >>> A trivial to implement "backup" would be to also copy the file to the >>> archive location for just that run (same place as where we copy >>> layout_test_results.zip), e.g. also copy it to >>> http://build.chromium.org/buildbot/layout_test_results/webkit-rel/29056/. >>> The downside is that this uses up disk space (e.g. the largest results.json >>> file was 25mb before being clobbered). >>> >>> Another problem with backing up is that you'd also have to find a way to >>> restore from backup that didn't lose data from runs that happened since the >>> problem occurred. Merging the two files results.json should be pretty >>> relatively trivial code, but it's all code that someone would need to write >>> and test. >>> >>> While it sucks, I don't think backing up this data is worth the effort. >>> It's a temporary productivity hit for the team, but we get enough new data >>> to make reasonable decisions relatively quickly. Mistakes like this are very >>> rare. It will become even more rare as coding work on the dashboard winds >>> down. >>> >>> Feel free to have at it if you disagree. >>> >>> Creates the results.json file and it's content: >>> trunk/src/webkit/tools/layout_tests/layout_package/json_results_generator.py >>> Copies the results.json file to the right >>> place: >>> trunk/tools/buildbot/scripts/slave/chromium/archive_layout_test_results.py >>> >>> Ojan >>> >>> >>> On Wed, Oct 14, 2009 at 4:24 PM, Jeremy Orlow wrote: >>> I haven't actually gotten anything done on LocalStorage this week because I've been doing so many small side projects like this.but if it's a priority, sure. How about a cron job on some machine that ssh's via a cert into whatever machines the data is stored on, pulls it back, and dumps it into some dir? When we start filling up the hard drive, we can look at doing something smarter, deleting old data, or putting it somewhere like GFS. What server can I use and where's the data stored? On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin wrote: > Sounds like we've got a volunteer! :D :D :D > > On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow > wrote: > > I assume we're going to start backing this data up from now on? > > > > On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting > wrote: > >> > >> On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai > wrote: > >>> > >>> I accidentally checked in some test code (one number was wrong!) > and > >>> clobbered all but 10 of the runs of data for each builder. There's > no way to > >>> recover it. > >> > >> Do you moonlight for the Danger team at Microsoft? > >> 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: Canary bot, now with formatted layout test results
Yes, possibly. The tool is written explicitly for the Chromium builders'
output, so it would be plausible but non-trivial to generalize it.
It may not be as useful since I don't think they have a concept of an
'upstream' baseline. Those of you who do a lot of work upstream, would it
be worth upstreaming this?
Glenn
On Thu, Oct 15, 2009 at 12:44 PM, Marc-Antoine Ruel wrote:
> Actually, can you package this so it could be upstreamed to webkit.org?
>
>
> On Thu, Oct 15, 2009 at 1:09 PM, Glenn Wilson wrote:
>
>> The tool lives in
>> src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
>> actually be run against any builder, not just the canaries. Adding better
>> documentation is on the TODO list :)
>>
>> (Also, re: adding link to waterfall, I think we can do this -- I'm
>> investigating now.)
>>
>>
>> On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman wrote:
>>
>>> Glenn, this tool is amazing! It really helped me yesterday on my 1st
>>> gardening shift.
>>> Re: "upstream baselines without running the tool manually"
>>> How do I do that?
>>>
>>> On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow wrote:
>>>
Christmas came early for anyone working on WebKit! Thanks Glen. :-)
On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry wrote:
>
> This makes me very happy!
>
> 2009/10/15 Glenn Wilson :
> > Hi Webkit gardeners,
> > The Windows canary bot now generates formatted layout test results on
> each
> > build that had unexpected failing layout tests, which means you can
> quickly
> > see layout test failures, diffs, and upstream baselines without
> running the
> > tool manually. The goal of this output is to help gardeners assess
> what may
> > have changed, and how to best handle the failure.
> > For example, here are the failures for build 13359:
> >
> http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
> > To see the formatted layout test failures for a specific canary
> build, just
> > click on the "layout test results" link in the "archive webkit test
> results"
> > step, then click on the "index-.html" file.
> > There's still more work to do, including getting the formatter
> working
> > properly on the Mac & Linux canaries, adding flakiness data, adding a
> link
> > directly to the waterfall display, and more. Many thanks go to Ojan,
> > Nicolas and all others who endured my many code reviews, and Eric
> Roman and
> > Dimitri for the original spec and design.
> > Please let me know what you think, and what changes you'd like to
> see.
> > Glenn
> >
> >
> > >
> >
>
>
>
> --
> Erik Corry, Software Engineer
> Google Denmark ApS. CVR nr. 28 86 69 84
> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
> Copenhagen K, Denmark.
>
>
>
>>>
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] LTTF helping the GTTF make cycle times *minutes* faster
There are a lot of tests that consistently (i.e. not flaky) timeout. They eat up significant percentage (~10%!) of the cycle time for the test bots (e.g., >1 minute on Windows release). If LTTF folk focus some effort on fixing these first, it would help all of us move forward faster as the bot cycle times would be improved as would the times to run the tests locally. To make this easier, I compiled the list of all the tests that consistently timeout. I excluded the flaky timeouts since the LTTF is currently focused on non-flaky failures. Any takers? Ojan ALL PLATFORMS: LayoutTests/fast/dom/Window/window-property-shadowing-name.html LayoutTests/fast/dom/cssTarget-crash.html LayoutTests/fast/events/add-event-without-document.html LayoutTests/http/tests/history/back-to-post.php LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html LayoutTests/http/tests/navigation/onload-navigation-iframe.html LayoutTests/http/tests/security/cross-frame-access-document-direct.html LayoutTests/http/tests/security/xss-DENIED-defineProperty.html LayoutTests/http/tests/xmlhttprequest/methods-async.html LayoutTests/loader/go-back-to-different-window-size.html LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-play-event.html LayoutTests/media/controls-drag-timebar.html LayoutTests/media/event-attributes.html LayoutTests/media/video-no-audio.html LayoutTests/media/video-source-add-src.html LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html LayoutTests/storage/domstorage/localstorage/iframe-events.html LayoutTests/storage/domstorage/sessionstorage/iframe-events.html WIN RELEASE+DEBUG: LayoutTests/http/tests/cache/subresource-expiration.html WIN DEBUG: LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html LINUX RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LINUX DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html MAC RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LayoutTests/http/tests/plugins/get-url.html LayoutTests/http/tests/plugins/interrupted-get-url.html LayoutTests/http/tests/plugins/npapi-response-headers.html LayoutTests/http/tests/plugins/post-url-file.html LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html LayoutTests/plugins/destroy-stream-twice.html LayoutTests/plugins/embed-inside-object.html LayoutTests/plugins/geturl-replace-query.html LayoutTests/plugins/npruntime.html LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html MAC RELEASE: LayoutTests/http/tests/cache/subresource-expiration.html MAC DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
One could show baselines of all the other platforms instead of just an
"upstream" baseline.
I'm not really sure from the output what this tool does. So it's
difficult for me to tell how useful it would be to upstream.
-eric
On Thu, Oct 15, 2009 at 8:38 PM, Glenn Wilson wrote:
> Yes, possibly. The tool is written explicitly for the Chromium builders'
> output, so it would be plausible but non-trivial to generalize it.
> It may not be as useful since I don't think they have a concept of an
> 'upstream' baseline. Those of you who do a lot of work upstream, would it
> be worth upstreaming this?
> Glenn
>
> On Thu, Oct 15, 2009 at 12:44 PM, Marc-Antoine Ruel
> wrote:
>>
>> Actually, can you package this so it could be upstreamed to webkit.org?
>>
>> On Thu, Oct 15, 2009 at 1:09 PM, Glenn Wilson
>> wrote:
>>>
>>> The tool lives in
>>> src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
>>> actually be run against any builder, not just the canaries. Adding better
>>> documentation is on the TODO list :)
>>> (Also, re: adding link to waterfall, I think we can do this -- I'm
>>> investigating now.)
>>>
>>> On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman
>>> wrote:
Glenn, this tool is amazing! It really helped me yesterday on my 1st
gardening shift.
Re: "upstream baselines without running the tool manually"
How do I do that?
On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow
wrote:
>
> Christmas came early for anyone working on WebKit! Thanks Glen. :-)
>
> On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry
> wrote:
>>
>> This makes me very happy!
>>
>> 2009/10/15 Glenn Wilson :
>> > Hi Webkit gardeners,
>> > The Windows canary bot now generates formatted layout test results
>> > on each
>> > build that had unexpected failing layout tests, which means you can
>> > quickly
>> > see layout test failures, diffs, and upstream baselines without
>> > running the
>> > tool manually. The goal of this output is to help gardeners assess
>> > what may
>> > have changed, and how to best handle the failure.
>> > For example, here are the failures for build 13359:
>> >
>> > http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
>> > To see the formatted layout test failures for a specific canary
>> > build, just
>> > click on the "layout test results" link in the "archive webkit test
>> > results"
>> > step, then click on the "index-.html" file.
>> > There's still more work to do, including getting the formatter
>> > working
>> > properly on the Mac & Linux canaries, adding flakiness data, adding
>> > a link
>> > directly to the waterfall display, and more. Many thanks go to
>> > Ojan,
>> > Nicolas and all others who endured my many code reviews, and Eric
>> > Roman and
>> > Dimitri for the original spec and design.
>> > Please let me know what you think, and what changes you'd like to
>> > see.
>> > Glenn
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Erik Corry, Software Engineer
>> Google Denmark ApS. CVR nr. 28 86 69 84
>> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
>> Copenhagen K, Denmark.
>>
>>
>
>
>
>>>
>>>
>>>
>>
>
>
> >
>
--~--~-~--~~~---~--~~
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: LTTF helping the GTTF make cycle times *minutes* faster
I'll take on the media ones. On Thu, Oct 15, 2009 at 6:38 PM, Ojan Vafai wrote: > There are a lot of tests that consistently (i.e. not flaky) timeout. They > eat up significant percentage (~10%!) of the cycle time for the test bots > (e.g., >1 minute on Windows release). If LTTF folk focus some effort on > fixing these first, it would help all of us move forward faster as the bot > cycle times would be improved as would the times to run the tests locally. > > To make this easier, I compiled the list of all the tests that consistently > timeout. I excluded the flaky timeouts since the LTTF is currently focused > on non-flaky failures. Any takers? > > Ojan > > > ALL PLATFORMS: > LayoutTests/fast/dom/Window/window-property-shadowing-name.html > LayoutTests/fast/dom/cssTarget-crash.html > LayoutTests/fast/events/add-event-without-document.html > LayoutTests/http/tests/history/back-to-post.php > > LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html > LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html > LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html > LayoutTests/http/tests/navigation/onload-navigation-iframe.html > LayoutTests/http/tests/security/cross-frame-access-document-direct.html > LayoutTests/http/tests/security/xss-DENIED-defineProperty.html > LayoutTests/http/tests/xmlhttprequest/methods-async.html > LayoutTests/loader/go-back-to-different-window-size.html > LayoutTests/media/audio-constructor-src.html > LayoutTests/media/audio-play-event.html > LayoutTests/media/controls-drag-timebar.html > LayoutTests/media/event-attributes.html > LayoutTests/media/video-no-audio.html > LayoutTests/media/video-source-add-src.html > > LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html > LayoutTests/storage/domstorage/localstorage/iframe-events.html > LayoutTests/storage/domstorage/sessionstorage/iframe-events.html > > WIN RELEASE+DEBUG: > LayoutTests/http/tests/cache/subresource-expiration.html > > WIN DEBUG: > LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html > > LINUX RELEASE+DEBUG: > LayoutTests/fast/loader/local-JavaScript-from-local.html > LayoutTests/http/tests/misc/timer-vs-loading.html > > LINUX DEBUG: > LayoutTests/fast/css/large-list-of-rules-crash.html > LayoutTests/fast/frames/frame-limit.html > > MAC RELEASE+DEBUG: > LayoutTests/fast/loader/local-JavaScript-from-local.html > LayoutTests/http/tests/misc/timer-vs-loading.html > LayoutTests/http/tests/plugins/get-url.html > LayoutTests/http/tests/plugins/interrupted-get-url.html > LayoutTests/http/tests/plugins/npapi-response-headers.html > LayoutTests/http/tests/plugins/post-url-file.html > > LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html > LayoutTests/plugins/destroy-stream-twice.html > LayoutTests/plugins/embed-inside-object.html > LayoutTests/plugins/geturl-replace-query.html > LayoutTests/plugins/npruntime.html > > LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html > > MAC RELEASE: > LayoutTests/http/tests/cache/subresource-expiration.html > > MAC DEBUG: > LayoutTests/fast/css/large-list-of-rules-crash.html > LayoutTests/fast/frames/frame-limit.html > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: [webkit-dev] Visual Studio 2005 ATL Security Update
In case any of you who hack on WebKit aren't on webkit-dev. (If that's you, you should definitely join webkit-dev now. It's very very low traffic and very high signal to noise ratio.) -eric -- Forwarded message -- From: Brian Weinstein Date: Thu, Oct 15, 2009 at 11:37 PM Subject: [webkit-dev] Visual Studio 2005 ATL Security Update To: webkit-dev Development At least a few people on IRC have noticed errors that look something like the following: 1) If you try to open FindSafari in Windows Explorer you will get the message "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." or 2) In the Control Panel->Administrative Tools->Events Viewer under the System events, you will see a SideBySide error with the message "Dependent Assembly Microsoft.VC890.CRT could not be found and Last Error was The referenced assembly is not installed on your system." You need to install the Visual Studio 2005 ATL Security update, which is linked to from http://webkit.org/building/tools.html. The link to download the update is: Visual Studio 2005 Service Pack 1 ATL Security Update. This should fix the problem. Brian Weinstein ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-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: Change to default build architecture
On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES="target_arch=ia32", of course. -- ukai On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss wrote: > > http://codereview.chromium.org/271113 may require a clobber for Linux > builds. The default build used to be 32-bit, but it will now be > whatever your build host architecture is. If you are on a 64-bit > machine, and haven't explicitly been setting 'target_arch' in gyp, > your build will switch from 32-bit to 64-bit. If this breaks anything, > clobbering or moving your existing build directory should fix it. > > If you want to continue building 32-bit on 64-bit hosts, you can force > it by setting GYP_DEFINES="target_arch=ia32" in the environment. > > Michael > > > > --~--~-~--~~~---~--~~ 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: Change to default build architecture
On Thu, Oct 15, 2009 at 8:59 PM, Fumitoshi Ukai (鵜飼文敏) wrote: > On x86_64 machine, I couldn't build even if I clobber.. > > /usr/bin/ld: skipping incompatible > /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a > when searching for -lnpGoogleNaClPluginChrome > /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome > collect2: ld returned 1 exit status > > Is this known issue? > It is fine with GYP_DEFINES="target_arch=ia32", of course. I haven't looked into it yet, but NaCl apparently has it's own notion of target_arch. For now, the best bet is probably explicitly setting GYP_DEFINES as you're doing. Michael > On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss wrote: >> >> http://codereview.chromium.org/271113 may require a clobber for Linux >> builds. The default build used to be 32-bit, but it will now be >> whatever your build host architecture is. If you are on a 64-bit >> machine, and haven't explicitly been setting 'target_arch' in gyp, >> your build will switch from 32-bit to 64-bit. If this breaks anything, >> clobbering or moving your existing build directory should fix it. >> >> If you want to continue building 32-bit on 64-bit hosts, you can force >> it by setting GYP_DEFINES="target_arch=ia32" in the environment. >> >> Michael >> >> >> >> > --~--~-~--~~~---~--~~ 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: LTTF helping the GTTF make cycle times *minutes* faster
I'm currently working on tests under LayoutTests/http/tests/navigation/. Thanks, Yuta 2009/10/16 Ojan Vafai > There are a lot of tests that consistently (i.e. not flaky) timeout. They > eat up significant percentage (~10%!) of the cycle time for the test bots > (e.g., >1 minute on Windows release). If LTTF folk focus some effort on > fixing these first, it would help all of us move forward faster as the bot > cycle times would be improved as would the times to run the tests locally. > > To make this easier, I compiled the list of all the tests that consistently > timeout. I excluded the flaky timeouts since the LTTF is currently focused > on non-flaky failures. Any takers? > > Ojan > > > ALL PLATFORMS: > LayoutTests/fast/dom/Window/window-property-shadowing-name.html > LayoutTests/fast/dom/cssTarget-crash.html > LayoutTests/fast/events/add-event-without-document.html > LayoutTests/http/tests/history/back-to-post.php > > LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html > LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html > LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html > LayoutTests/http/tests/navigation/onload-navigation-iframe.html > LayoutTests/http/tests/security/cross-frame-access-document-direct.html > LayoutTests/http/tests/security/xss-DENIED-defineProperty.html > LayoutTests/http/tests/xmlhttprequest/methods-async.html > LayoutTests/loader/go-back-to-different-window-size.html > LayoutTests/media/audio-constructor-src.html > LayoutTests/media/audio-play-event.html > LayoutTests/media/controls-drag-timebar.html > LayoutTests/media/event-attributes.html > LayoutTests/media/video-no-audio.html > LayoutTests/media/video-source-add-src.html > > LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html > LayoutTests/storage/domstorage/localstorage/iframe-events.html > LayoutTests/storage/domstorage/sessionstorage/iframe-events.html > > WIN RELEASE+DEBUG: > LayoutTests/http/tests/cache/subresource-expiration.html > > WIN DEBUG: > LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html > > LINUX RELEASE+DEBUG: > LayoutTests/fast/loader/local-JavaScript-from-local.html > LayoutTests/http/tests/misc/timer-vs-loading.html > > LINUX DEBUG: > LayoutTests/fast/css/large-list-of-rules-crash.html > LayoutTests/fast/frames/frame-limit.html > > MAC RELEASE+DEBUG: > LayoutTests/fast/loader/local-JavaScript-from-local.html > LayoutTests/http/tests/misc/timer-vs-loading.html > LayoutTests/http/tests/plugins/get-url.html > LayoutTests/http/tests/plugins/interrupted-get-url.html > LayoutTests/http/tests/plugins/npapi-response-headers.html > LayoutTests/http/tests/plugins/post-url-file.html > > LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html > LayoutTests/plugins/destroy-stream-twice.html > LayoutTests/plugins/embed-inside-object.html > LayoutTests/plugins/geturl-replace-query.html > LayoutTests/plugins/npruntime.html > > LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html > > MAC RELEASE: > LayoutTests/http/tests/cache/subresource-expiration.html > > MAC DEBUG: > LayoutTests/fast/css/large-list-of-rules-crash.html > LayoutTests/fast/frames/frame-limit.html > > > > --~--~-~--~~~---~--~~ 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: Change to default build architecture
On Thu, Oct 15, 2009 at 9:04 PM, Michael Moss wrote: > > On Thu, Oct 15, 2009 at 8:59 PM, Fumitoshi Ukai (鵜飼文敏) > wrote: > > On x86_64 machine, I couldn't build even if I clobber.. > > > > /usr/bin/ld: skipping incompatible > > > /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a > > when searching for -lnpGoogleNaClPluginChrome > > /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome > > collect2: ld returned 1 exit status > > > > Is this known issue? > > It is fine with GYP_DEFINES="target_arch=ia32", of course. > > I haven't looked into it yet, but NaCl apparently has it's own notion > of target_arch. For now, the best bet is probably explicitly setting > GYP_DEFINES as you're doing. > > Michael > You can also disable NaCl with disable_nacl=1 in GYP_DEFINES. Antoine > > > > On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss > wrote: > >> > >> http://codereview.chromium.org/271113 may require a clobber for Linux > >> builds. The default build used to be 32-bit, but it will now be > >> whatever your build host architecture is. If you are on a 64-bit > >> machine, and haven't explicitly been setting 'target_arch' in gyp, > >> your build will switch from 32-bit to 64-bit. If this breaks anything, > >> clobbering or moving your existing build directory should fix it. > >> > >> If you want to continue building 32-bit on 64-bit hosts, you can force > >> it by setting GYP_DEFINES="target_arch=ia32" in the environment. > >> > >> Michael > >> > >> >> > >> > > > > > > --~--~-~--~~~---~--~~ 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: LTTF helping the GTTF make cycle times *minutes* faster
I'll have a look at LayoutTests/fast/dom/Window/window-property-shadowing-name.html yours, anton. On Fri, Oct 16, 2009 at 8:13 AM, Yuta Kitamura wrote: > I'm currently working on tests under LayoutTests/http/tests/navigation/. > Thanks, > Yuta > 2009/10/16 Ojan Vafai >> >> There are a lot of tests that consistently (i.e. not flaky) timeout. They >> eat up significant percentage (~10%!) of the cycle time for the test bots >> (e.g., >1 minute on Windows release). If LTTF folk focus some effort on >> fixing these first, it would help all of us move forward faster as the bot >> cycle times would be improved as would the times to run the tests locally. >> To make this easier, I compiled the list of all the tests that >> consistently timeout. I excluded the flaky timeouts since the LTTF is >> currently focused on non-flaky failures. Any takers? >> Ojan >> >> ALL PLATFORMS: >> LayoutTests/fast/dom/Window/window-property-shadowing-name.html >> LayoutTests/fast/dom/cssTarget-crash.html >> LayoutTests/fast/events/add-event-without-document.html >> LayoutTests/http/tests/history/back-to-post.php >> >> LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html >> LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html >> LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html >> LayoutTests/http/tests/navigation/onload-navigation-iframe.html >> LayoutTests/http/tests/security/cross-frame-access-document-direct.html >> LayoutTests/http/tests/security/xss-DENIED-defineProperty.html >> LayoutTests/http/tests/xmlhttprequest/methods-async.html >> LayoutTests/loader/go-back-to-different-window-size.html >> LayoutTests/media/audio-constructor-src.html >> LayoutTests/media/audio-play-event.html >> LayoutTests/media/controls-drag-timebar.html >> LayoutTests/media/event-attributes.html >> LayoutTests/media/video-no-audio.html >> LayoutTests/media/video-source-add-src.html >> >> LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html >> LayoutTests/storage/domstorage/localstorage/iframe-events.html >> LayoutTests/storage/domstorage/sessionstorage/iframe-events.html >> WIN RELEASE+DEBUG: >> LayoutTests/http/tests/cache/subresource-expiration.html >> WIN DEBUG: >> LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html >> LINUX RELEASE+DEBUG: >> LayoutTests/fast/loader/local-JavaScript-from-local.html >> LayoutTests/http/tests/misc/timer-vs-loading.html >> LINUX DEBUG: >> LayoutTests/fast/css/large-list-of-rules-crash.html >> LayoutTests/fast/frames/frame-limit.html >> MAC RELEASE+DEBUG: >> LayoutTests/fast/loader/local-JavaScript-from-local.html >> LayoutTests/http/tests/misc/timer-vs-loading.html >> LayoutTests/http/tests/plugins/get-url.html >> LayoutTests/http/tests/plugins/interrupted-get-url.html >> LayoutTests/http/tests/plugins/npapi-response-headers.html >> LayoutTests/http/tests/plugins/post-url-file.html >> >> LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html >> LayoutTests/plugins/destroy-stream-twice.html >> LayoutTests/plugins/embed-inside-object.html >> LayoutTests/plugins/geturl-replace-query.html >> LayoutTests/plugins/npruntime.html >> >> LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html >> MAC RELEASE: >> LayoutTests/http/tests/cache/subresource-expiration.html >> MAC DEBUG: >> LayoutTests/fast/css/large-list-of-rules-crash.html >> LayoutTests/fast/frames/frame-limit.html >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
