Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
On Thu, Jan 7, 2010 at 4:02 PM, Darin Fisher wrote:
> On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman wrote:
>
>> On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting
>> wrote:
>> > If you have ever used any of the EmptyXXX() functions, or ever will,
>> please
>> > read on.
>> > These functions (in string_util.h and gurl.h) are meant for a single,
>> > specific use case:
>> > const std::string& MyClass::foo() const {
>> > return (everything == OK) ? member_string : EmptyString();
>> > }
>> > Here you cannot return "string()", because it's destroyed before the
>> > function returns, and the caller receives garbage; and you don't want to
>> > have the function return by value, because you can access the member
>> > variable directly and save a copy. The utility functions give you a
>> global
>> > empty string that you can safely return a const reference to.
>> > DON'T USE THESE OUTSIDE THIS CASE. You should never use these as
>> > initializers, arguments to functions, or return values in functions that
>> > return by value. Just use the default constructor; that's what it's
>> there
>> > for.
>>
>> Out of curiosity, what is wrong with using EmptyString() in those
>> cases? Is there a correctness problem? Unnecessary inclusion of
>> string_util.h?
>>
>>
> probably just a tad more costly since it involves Singleton. but, i
> think peter's main reason was simply to stick to the simpler and more
> familiar std::string.
>
> -darin
>
Where as It looks like GURL::EmptyGURL() may be a tad less costly than
GURL().
>
>
>
>
>> - a
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
Yes, It sounds like in all cases, there's going to be a big rebaseline-them-all-on-linux step at some point, the sooner the better. Given the nature of the problem (scrollbar drawing differences), lets roll and deal with the rebaselining seperately. But that should be done soonish, in the interim we'll the expected scrollbar drawing diffs could be masking real bugs. Gee.. lots of fun to put hundreds of expected failures in test_expecations for linux :) On Tue, Dec 8, 2009 at 1:30 PM, Adam Langley wrote: > On Tue, Dec 8, 2009 at 1:27 PM, Dimitri Glazkov > wrote: > > Let's go with this. You'll have a chance all about the great > > rebaselining tool in the process. :) > > > > Michael will roll and add all the failures to expectations, creating a > > bug for you to rebaseline. > > Ok. Markus is going to do a quick WK patch, before we roll, to set the > defaults to something like the current values. > > > AGL > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
Ah... thank you for the ptr. On Tue, Dec 8, 2009 at 1:00 PM, Adam Langley wrote: > On Tue, Dec 8, 2009 at 12:55 PM, Michael Nordman > wrote: > > yikes 481 failures on linux... k... holding off rolling until we get a > > handle on the nature of the linux borkage > > This is probably the result of Markus's first WebKit patch. It was > LGTMed and he asked that it be landed and didn't think that it would > break anything. > > However, it appears that he didn't know about the pixel tests! > > http://trac.webkit.org/changeset/51827 > > You might want to revert it for now, although it should be ok to > rebaseline any pixel tests that changed. It's just a very minor change > in the scrollbar colours. > > > AGL > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit roll status
yikes 481 failures on linux... k... holding off rolling until we get a handle on the nature of the linux borkage On Tue, Dec 8, 2009 at 12:45 PM, Dimitri Glazkov wrote: > I wonder if we should investigate and determine the cause of Linux > failures before rolling. > > :DG< > > On Tue, Dec 8, 2009 at 12:43 PM, Stephen White > wrote: > > For the curious, as of WebKit 51800, SVG Filters are enabled by default. > In > > theory (since this code is cross-platform), this should just require us > > turning them on in Chrome, and rebaselining the affected tests (about 24 > on > > Windows). In practice, however, some of the code behind #if > > ENABLE(SVG_FILTERS) on the V8 bindings side may have rotted, and need > some > > attention. Also, there are also a huge number of additional tests are > > failing on Linux (481) for reasons unknown as yet. > > This issue is being tracked > > at http://code.google.com/p/chromium/issues/detail?id=29737 > > Stephen > > > > On Tue, Dec 8, 2009 at 3:23 PM, Michael Nordman > > wrote: > >> > >> Hi all, > >> Just a note to let you know what's up with webkit rolls (or lack > thereof) > >> right now. > >> We're at r51794 and have been for a while. Tip-of-tree webkit is at > >> r51868. > >> * All manner of svg tests are borked from some reason around r 51800, > >> senorblanco is on that. > >> * A couple of build breaks obscured things for a while, ajwong has > >> resolved those already. > >> I'm putting together a CL to roll deps to r51868 and update test > >> expectations to expect the svg failures (as recommended by senorblanco). > >> This may be a little bit of a bumpy ride. > >> > >> PS. Oh, and my car broke down this morning. Just my lucky day i guess :) > >> > >> -- > >> Chromium Developers mailing list: chromium-dev@googlegroups.com > >> View archives, change email options, or unsubscribe: > >> http://groups.google.com/group/chromium-dev > > > > > > -- > > All truth passes through three stages. First, it is ridiculed. Second, it > is > > violently opposed. Third, it is accepted as being self-evident. -- > > Schopenhauer > > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] WebKit roll status
Hi all, Just a note to let you know what's up with webkit rolls (or lack thereof) right now. We're at r51794 and have been for a while. Tip-of-tree webkit is at r51868. * All manner of svg tests are borked from some reason around r 51800, senorblanco is on that. * A couple of build breaks obscured things for a while, ajwong has resolved those already. I'm putting together a CL to roll deps to r51868 and update test expectations to expect the svg failures (as recommended by senorblanco). This may be a little bit of a bumpy ride. PS. Oh, and my car broke down this morning. Just my lucky day i guess :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Profiles + SharedWorkers
I was wondering if worker processes have a profile affinity too. Eric's bringing up Databases in workers right now and databases are definitely per-profile. I'd vote to assert that a worker process only runs workers on behalf one profile, just like renderers. >ResourceMessageFilter has a reference to a Profile object - are these Profile objects global > (for example, in the typical situation of a single profile + incognito, are there only two Profile > objects in the Browser process)? Yes. The fact that a worker process can host at most one worker certainly does simplify things for the time being ;) On Mon, Dec 7, 2009 at 11:37 AM, Drew Wilson wrote: > Hi all, > > I'm trying to understand the current (and future) state of Profile support. > > Currently, SharedWorkers are shared by all windows in the system - any two > windows under the same domain can do "new SharedWorker(url)" and get a > reference to the same SharedWorker, and can use that worker to share data. > > I currently am special-casing incognito windows, so incognito windows don't > share workers with non-incognito workers, but I don't do anything to deal > with profiles in general (so if you were running with separate profiles, > those profiles would see one another's workers). > > I'm trying to figure out the best way to address this (and whether this is > something that needs to be addressed in the near term, given that we don't > officially support profiles - it sounds like chromeos may make some use of > them?). ResourceMessageFilter has a reference to a Profile object - are > these Profile objects global (for example, in the typical situation of a > single profile + incognito, are there only two Profile objects in the > Browser process)? > > -atw > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess wrote: > > Just to be clear for those of us who are wobbly on C++, this is > because during the constructor or destructor, your object is of the > class in question, NOT of the class it will finally be, because in the > constructor the subclass has not been constructed, yet, and in the > destructor the subclass was already destructed. So calling to the > subclass virtual implementation would be bad. > > Scott Meyers says: http://www.artima.com/cppsource/nevercall.html > > Is there any way we could modify an object to assert that it can't > happen in development? Like scoped_vtable_killer declared in the > constructor and destructor which makes calling a virtual method on > that object fatal? > That's an intriguing idea. It seems like you could swap the real vtable ptr out on ctor/dtor entry, and replace it with a ptr to a poisoned vtable. This sounds like debug build stuff only. > > -scott > > > On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow wrote: > > I've spent a good deal of this week trying to track down what turned out > to > > be a simple but fairly common problem: I forgot virtual dispatch only > > partially works in destructors. There have been several email threads > about > > this, but it still bites us form time to time, so I thought it was worth > > another reminder. > > > > Details: > > I subclassed ChromeThread which subclasses base::Thread. base::Thread > calls > > CleanUp on the thread right before termination. CleanUp is virtual. > Both > > ChromeThread and my class override CleanUp(). base::Thread calls Stop() > in > > its destructor to stop the thread (if it hasn't already been stopped). > But > > by the time you hit destruction, the vtable is no longer available and > thus > > the destructor of base::Thread (and anything it calls) does NOT have > access > > to the vtable of ChromeThread (or my class). So, if you don't explicitly > > call Stop(), your subclass's CleanUp method will NOT be called. Thus the > > thread was going away without my CleanUp method ever being called. > > Obviously this affects more than just base::Thread. And this is also how > > you can hit errors with pure virtual methods being called. > > J > > > > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 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] 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 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 Wed, Oct 14, 2009 at 4:03 PM, Jeremy Orlow wrote: > On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc wrote: > >> >> >> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote: >> >>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote: >>> >>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote: >>>> >>>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote: >>>>> >>>>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman >>>>> > wrote: >>>>>> >>>>>>> +1 SecurityOrigin class >>>>>>> Sounds like a reasonable plan. >>>>>>> I suspect there may already be cases where we're actually comparing a >>>>>>> chrome generated security origin, as produced by GURL.GetOrigin(), with >>>>>>> a >>>>>>> webkit generated security origin, as produced by >>>>>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of >>>>>>> the >>>>>>> plan to do more than opaquely pass around and test webkit generated >>>>>>> representations. >>>>>>> >>>>>>> Also, I think dumi has a use case to crack it open in order to form >>>>>>> file path elements of the form 'scheme_host_port' >>>>>>> >>>>>> >>>>>> Actually, Dumi's case is slightly different. He wants to get >>>>>> SecurityOrigin::databaseIdentifier, right? Maybe WebSecurityOrigin >>>>>> should >>>>>> have a databaseIdentifier() method that outputs a FilePath object? >>>>>> >>>>> >>>>> Dumi has such a method in a CL that he is working on at the moment. >>>>> Also, note: we don't have a way to use FilePath from the WebKit API, and >>>>> I'm not sure that we should. We use WebString for file paths in the >>>>> WebKit >>>>> API. >>>>> >>>> >>>> So then he's adding such a method to WebSecurityOrigin that returns a >>>> string? If so, sounds good. What's the CL, btw? >>>> >>> >>> Yes: >>> http://codereview.chromium.org/256073/diff/11001/11029 >>> >>> >> we decided to use GURLs instead of string16s to represent SecurityOrigins >> on the chromium side, so we don't need a >> (Web)SecurityOrigin::toFilePath()-like method anymore; we can just do >> GURL(SecurityOrigin::toString()), and then create a file path from >> GURL::scheme(), GURL::host() and GURL::port(). >> > > The point of this thread is that we should not be converting > SecurityOrigins of GURLs. I believe michaeln was the primary proponent of > this and I believe we convinced him that we shouldn't be doing it. And I > believe most if not all the reasons why were in my original email. > (Michael, correct me if I'm wrong.) > I think i have two primary concerns. 1) What is the format of the data written to disk that we need to support going forward since it is on disk. We need a decision that we can stick with. 2) What measures are in place to ensure that we're actually persisting data in that prescribed format today. Having 'strings' float around makes me uneasy on that second point. If chrome can't validate these string values are in the prescribed format (its not smart enough to reason about them), how can we assert we've got it right (inspection doesn't work well... working backwards from a callsite in chrome browser code storing an 'origin' string to the source of that string being produced is just not practical). Given the current state of affairs, i still think GURL is a better option. Given a GURL, we can reason about it (produce path elements, produce a canonical string representation, test if another GURL falls in that origin or not (we do that in appcache code sans webkit)). The "null" security origin is an odd corner case that gives the GURL representation grief. > >> also, i'd argue that no class representing an origin should have a >> toFilePath()-like method: origins and file paths have nothing in common; >> using the origin URL as part of the DB file name is a database-specific >> decision and the code for that conversion should be kept in some >> database-specific class, or a separate origin_to_file_path_util.h file at >> best. (It was very tempting to use SecurityOrigin::databaseIdentifier() only >> because that method was already there.) >> > > Well, SecurityOrigin has a method that creates a database file name. I > don't see why we can't have a "::databasePath" method of our own. And if we > do, then it does make sense for it to return a FilePath. > > That said, I think what Darin suggested in the code review is actually the > cleanest way to do it. And I think returning a String is not a big deal. > --~--~-~--~~~---~--~~ 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 2:08 PM, Jeremy Orlow wrote: > On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote: > >> +1 SecurityOrigin class >> Sounds like a reasonable plan. >> I suspect there may already be cases where we're actually comparing a >> chrome generated security origin, as produced by GURL.GetOrigin(), with a >> webkit generated security origin, as produced by >> WebSecurityOrigin.toString(). So we may want to accelerate the part of the >> plan to do more than opaquely pass around and test webkit generated >> representations. >> >> Also, I think dumi has a use case to crack it open in order to form file >> path elements of the form 'scheme_host_port' >> > > Actually, Dumi's case is slightly different. He wants to get > SecurityOrigin::databaseIdentifier, right? Maybe WebSecurityOrigin should > have a databaseIdentifier() method that outputs a FilePath object? > Dumi needs to form file path elements, yes. Dumi also needs to store a canonical string representation of an 'origin' in the tracker database which will equate to the canonical string represetation 6 months from now (either that or upgrade the column values whenever that representation changes). Q: What is the canonical string representation used in the localstorage.db which has the similar requirement to track things per origin? Probably WebCore::SecurityOrigin::toString(), is that right? Those two things probably shouldn't be confounded. At some point in the not too distant future, we'll need to interrogate from a ChromeUI database, localstorage, appcache, and (filesystem) for what 'origins' are making how heavy a use of those systems. An important point is that code today is writing string values, and code 6 months from now has to interpret those values and match against them. > ... and why not use strings? >> * does the string contain a trailing slash, or not? >> * in the default port case, does the string contain the default port >> number or not? >> > > WebCore::SecurityOrigin handles these for us. I'll make it difficult for a > base::SecurityOrigin to be constructed any way besides it coming from > WebKit::WebSecurityOrigin (which only comes from > WebCore::WebSecurityOrigin). We can then deal with these details only > if/when we need to. > 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. > > > On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote: >> >>> Right now, we don't have a good story for what to do with >>> WebCore::SecurityOrigins in Chromium. We now have a WebSecurityOrigin in >>> WebKit, but if you want to move the data between processes, you need to >>> convert it to a string and then send that. In some cases we then convert >>> the string to a GURL, but this seems like the wrong thing to do (more on >>> this in a sec). >>> To me, the right answer is to create a type in base called SecurityOrigin >>> that wraps a string and does equality checks. The equality checks can be >>> done as string comparisons since the WebCore::SecurityOrigin::toString() >>> method canonicalizes it. If, in the future, we need to do anything more >>> with SecurityOrigins (besides transporting them, testing equality, and using >>> them in sets/maps) then we can make the class more complex. >>> >>> Why not use GURL? For one, the SecurityOrigin has a "null" state which >>> is significant and which isn't represented in GURL. In addition, there's a >>> lot of operations you can do with a GURL which don't really make sense in >>> the context of a SecurityOrigin. Passing around a SecurityOrigin object is >>> also much more self-documenting. But, the fact that GURL looks like a >>> tempting way to store a SecurityOrigin is actually one of the biggest >>> reasons why I think we should make a dedicated type. >>> >>> If people agree with this, my plan is to create such a type in base and >>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin. >>> I'll then convert everything over (or ask people to do the conversion if it >>> looks scary). Finally, I'll remove WebSecurityOrigin::toString(). >>> >>> Does this sound like a good plan? >>> >>> J >>> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
+1 SecurityOrigin class Sounds like a reasonable plan. I suspect there may already be cases where we're actually comparing a chrome generated security origin, as produced by GURL.GetOrigin(), with a webkit generated security origin, as produced by WebSecurityOrigin.toString(). So we may want to accelerate the part of the plan to do more than opaquely pass around and test webkit generated representations. Also, I think dumi has a use case to crack it open in order to form file path elements of the form 'scheme_host_port' ... and why not use strings? * does the string contain a trailing slash, or not? * in the default port case, does the string contain the default port number or not? On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote: > Right now, we don't have a good story for what to do with > WebCore::SecurityOrigins in Chromium. We now have a WebSecurityOrigin in > WebKit, but if you want to move the data between processes, you need to > convert it to a string and then send that. In some cases we then convert > the string to a GURL, but this seems like the wrong thing to do (more on > this in a sec). > To me, the right answer is to create a type in base called SecurityOrigin > that wraps a string and does equality checks. The equality checks can be > done as string comparisons since the WebCore::SecurityOrigin::toString() > method canonicalizes it. If, in the future, we need to do anything more > with SecurityOrigins (besides transporting them, testing equality, and using > them in sets/maps) then we can make the class more complex. > > Why not use GURL? For one, the SecurityOrigin has a "null" state which is > significant and which isn't represented in GURL. In addition, there's a lot > of operations you can do with a GURL which don't really make sense in the > context of a SecurityOrigin. Passing around a SecurityOrigin object is also > much more self-documenting. But, the fact that GURL looks like a tempting > way to store a SecurityOrigin is actually one of the biggest reasons why I > think we should make a dedicated type. > > If people agree with this, my plan is to create such a type in base and > modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin. > I'll then convert everything over (or ask people to do the conversion if it > looks scary). Finally, I'll remove WebSecurityOrigin::toString(). > > Does this sound like a good plan? > > J > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Debugging CachedResource memory leak in test_shell
I think there may be more than one code path to CachedResource removal. 1. See DocLoader. It has a DocumentResourceMap that contains cached resources that have been loaded for its Document. The collection gets poked at in the ~DocLoader to clean things up. 2. During CacheResource validation. See CachedResource.clearResourceToRevalidate and deleteIfPossible. On Thu, Sep 24, 2009 at 1:35 PM, Marshall Greenblatt wrote: > Hi All, > > I'm trying to debug the leak of CachedResource objects in test_shell. > Every time I browse to a page that contains an image or CSS file a new > CachedResource object is created in Cache.cpp createResource(). However, > none of these objects are ever freed. Does anyone happen to know where/how > the CachedResource objects should be freed so that I can figure out why > they're getting lost? > > 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: linux startup regression
There's is nothing platform specific about r25099, since other platforms don't show a hit... probably not it. r25112 - use x11_util::GetXWindowStack Does that load additional libraries? On Wed, Sep 2, 2009 at 6:41 PM, James Hawkins wrote: > > Maybe r25099? I don't know how long it takes between commit time and > when the results show up in the graph, so this is a rough guess. > > r25099 -- > Plumb request interception into the appcache library for both chrome > and test_shell. > ... > Chrome: > * Each UserProfile instantiates a ChromeAppCacheService, which is > derived from an appcache library class. > > > On Wed, Sep 2, 2009 at 6:21 PM, Evan Martin wrote: > > > > > http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150 > > > > We seem to have lost about 50% around r25132, but the commits around > > there aren't at all suspicious. :( > > Any guesses? Maybe Brett's change? > > > > > > > > > > > --~--~-~--~~~---~--~~ 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: Question about resource_dispatcher_host.h
On Thu, Aug 27, 2009 at 11:57 AM, hap 497 wrote: > > > On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek wrote: > >> >> >> On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson wrote: >> >>> >>> On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote: >>> > Thanks. But the picture in the document shows there is only 1 >>> > ResourceDispatcherHost and there are 2 Renderer Processes: >>> > >>> > >>> http://dev.chromium.org/developers/design-documents/multi-process-architecture >>> > And the ResourceDispatcherHost has access to both Channels for each >>> Renderer >>> > Process. >>> >>> Information about each request including the originating renderer is >>> tacked onto each URLRequest in the form of "ExtraRequestInfo." See one >>> of the functions in there such as >>> ResourceDispatcherHost::OnResponseCompleted for how this is retrieved. >>> >> >> Right, information such as renderer process id is available, but there are >> no pointers to the ResourceMessageFilter in there. Using the process id, >> you could get to the RenderProcessHost (but only on the UI thread) and from >> there to the RMF. >> >> > > Thanks for all the answers. > > If ResourceMessageFilter has all the information for dispatching the > message, why it needs to talk to ResourceDispatcherHost ( a singleton class) > for dispatching? Looking at resource_dispatcher_host.h, I am not sure what > centralized information it is holding so that each ResourceMessageFilter > needs ResourceDispatcherHost for dispatching. > > Thank you for your help. > Resource loading involves interactions with a number of objects that span all child processes (renderers, workers, plugins, etc). So while ResourceMessageFilter does contain all of the info needed to communicate a response back to its child process, it does not contain all of the information to handle the request. That is where ResourceDispatcherHost comes in. It does contain all of the info needed to fully handle the request. Things like... SafeBrowsingService, UserScriptListener, a centralized timer for stats collection, the list of 'observers' to spam with info about what requests are happening system wide, a centralized place to all things down... etc... Not sure we're doing this yet, but it also provides a centralized place to prioritize requests on behalf of processA vs processB. --~--~-~--~~~---~--~~ 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: Copying of profiles across systems
+ chromium-dev (this time, sorry for the resend) Is the OS in the user-agent string? "Mozilla/5.0 (*Windows*; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.6 Safari/532.0" There's a chance that http resource caches will contain data tweeked per OS. Maybe for cosmetic purposes... to make it look more OSX'y or ChromeOS'y or Windows'y... or perhaps for functional purposes like plugin works better on this and plugin works better on that in some odd corner case. On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel wrote: > >> >> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow >> wrote: >> >> I really like the idea of being able to move people between >> >> operating systems and just bringing the profile along >> >> without having to export and import... >> >> >> >> (seems to me there are online services that offer that >> >> convenience, but being able to do it with the raw file >> >> is cool.) >> > >> > In what scenarios would this be useful? If it's easy to do, it'd be >> cool, >> > but it seems like this would have a very small minority of users. >> >> When migrating users between operating systems. Say, >> a company decides to migrate all its office workers from >> Windows to Linux. Or if somebody installs Ubuntu on >> a Windows machine on its own; I believe they try >> to migrate settings when you do that. >> >> One goal of Chrome was to make operating systems not matter; >> one way to do that is to make the profile file (mostly) portable. >> - Dan >> >> >> >> > --~--~-~--~~~---~--~~ 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: Copying of profiles across systems
Is the OS in the user-agent string? "Mozilla/5.0 (*Windows*; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.6 Safari/532.0" There's a chance that http resource caches will contain data tweeked per OS. Maybe for cosmetic purposes... to make it look more OSX'y or ChromeOS'y or Windows'y... or perhaps for functional purposes like plugin works better on this and plugin works better on that in some odd corner case. On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel wrote: > > On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote: > >> I really like the idea of being able to move people between > >> operating systems and just bringing the profile along > >> without having to export and import... > >> > >> (seems to me there are online services that offer that > >> convenience, but being able to do it with the raw file > >> is cool.) > > > > In what scenarios would this be useful? If it's easy to do, it'd be > cool, > > but it seems like this would have a very small minority of users. > > When migrating users between operating systems. Say, > a company decides to migrate all its office workers from > Windows to Linux. Or if somebody installs Ubuntu on > a Windows machine on its own; I believe they try > to migrate settings when you do that. > > One goal of Chrome was to make operating systems not matter; > one way to do that is to make the profile file (mostly) portable. > - Dan > > > > --~--~-~--~~~---~--~~ 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: tryserver flakiness
I just submitted the change that ENABLE's that flag a moment ago... we're clobbering things now On Wed, Aug 12, 2009 at 1:55 PM, Jeremy Orlow wrote: > Clobber needed? > I know Michael just enabled this within the last 24 hours. > > > On Wed, Aug 12, 2009 at 1:49 PM, Paweł Hajdan Jr. > wrote: > >> Just got this on the Windows tryserver: >> C:\b\slave\win\build\src\chrome\renderer\renderer_webkitclient_impl.cc : >> error C2220: warning treated as error - no 'object' file generated >> C:\b\slave\win\build\src\chrome\renderer\renderer_webkitclient_impl.cc : >> warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for >> precompiled header but not for current compile >> render_thread.cc >> C:\b\slave\win\build\src\chrome\renderer\render_thread.cc : error C2220: >> warning treated as error - no 'object' file generated >> C:\b\slave\win\build\src\chrome\renderer\render_thread.cc : warning C4651: >> '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but >> not for current compile >> renderer_glue.cc >> C:\b\slave\win\build\src\chrome\renderer\renderer_glue.cc : error C2220: >> warning treated as error - no 'object' file generated >> C:\b\slave\win\build\src\chrome\renderer\renderer_glue.cc : warning C4651: >> '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but >> not for current compile >> >> It's a bit annoying... Is it easily fixable? >> >> > > > > --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
> These instructions turn src/third_party/WebKit into a full-fledged WebKit checkout Hallelujah... thank you for writing this up! --~--~-~--~~~---~--~~ 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: Buildbot performance issue.
Turning off auto refresh by default sounds reasonable idea right now... with an option to enable it if really desired... &autorefresh[=] where n is a number of minutes maybe (defaults to 1) type thing. A fair amount of the load may just evaporate with that change. On Tue, Jul 14, 2009 at 3:32 PM, Jeremy Orlow wrote: > On Tue, Jul 14, 2009 at 2:42 PM, Adam Langley wrote: > >> >> On Tue, Jul 14, 2009 at 2:40 PM, Albert J. Wong >> (王重傑) wrote: >> > That is pretty nuts. Is it calling fsync or something crazy? Since you >> > said strace, I'm assmuming linux. In that case, the buffer cache should >> be >> > saving you from disk accesses for most everything. >> >> Of course, vmstat 1 will tell you what disk IO is happening. If you >> don't have noatime, that would probably be good. > > > atop is a really nice program for getting a birds eye view of what's going > on with the system. It's not installed by default, but if you're running > ubuntu, it's easy to install. > > > More generally: I think there are a couple uses of the build bots: > 1) Most people just want to know "can I commit" and then are watching one > specific CL's status. In this case, not auto-refreshing is fine and not > much history is fine. > 2) Sheriffing is the one case where I think you actually do need > auto-refreshing, but normally you don't need a lot of history. That said, > sometimes things fail and then > 3) You're trying to fix things: In this case you want to see a lot of > history (or at least need the option to see more) and you do NOT want it to > auto refresh. I've definitely had times when I wish there was a "show me > more" button. And I've definitely have been reading something far down the > page only to have it refresh on me. > > It seems to me that these requirements are diverse enough that one single > configuration isn't going to make everyone happy. I know you can do a bunch > of customization so you can see exactly what you want, but I assume that > will only chew up more resources. Maybe the right way to go is a couple > customized pages for each roll? There's definitely much more information > there than people need most of the time, though. > > > > --~--~-~--~~~---~--~~ 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: LayoutTest unexpected success
I'd leave decisions about the worker related message port tests for drew and dimich... the feature isn't fully functional yet in chrome (even if they don't crash and happen to pass and such). I've been unable to dup the LayoutTests/fast/events/mouseover-mouseout2.html failure locally and have no clue why it started failing yesterday afternoon... ditto with the embed-display-none.html test. On Tue, Jul 14, 2009 at 1:06 PM, Amanda Walker wrote: > > And as soon as I took them out, they started failing again. We're > reverting. > > --Amanda > > > On Tue, Jul 14, 2009 at 12:08 PM, Amanda Walker > wrote: > > On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlow > wrote: > >> I think we should re-enable them ASAP unless there's some good reason > why > >> you want to wait. > > > > They've been stable and passing all morning, so that works for me. > > > > --Amanda > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: 1) Roll WebKit DEPS to 45685...
Fyi: In case your wondering why the webkit canary is red and DEPs have not been rolled... Forwarded conversation Subject: 1) Roll WebKit DEPS to 45685... From: ** Date: Thu, Jul 9, 2009 at 10:14 PM To: j...@chromium.org Cc: chromium-revi...@googlegroups.com, da...@chromium.org, j...@chromium.org Reviewers: John Abd-El-Malek, Message: Crossing my fingers I don't see a sea of red in the webkit canary after this. The try-bots are happy so far, comipiles on all and passes tests on linux and mac, win is still chewing on the ui tests. If the try succeeds I'm going to submit TBR, then look to see wha'happens next... what could possible go wrong :) John, please take a closer look at correctness here. I'm getting things to build but thats about it. Doh... the try just failed on windows! test_shell_tests: PluginVisibility is RED PluginTest.PluginVisibilty: c:\b\slave\win\build\src\webkit\tools\test_shell\plugin_tests.cc(48): error: Value of: file_util::CopyDirectory(plugin_src_, plugin_file_path_, true) Actual: false Expected: true Guessing we failed to make a new copy because a previous copy is pinned open. Description: 1) Roll WebKit DEPS to 45685 This roll picks up changes to WebCore::Widget which make that a RefCounted class. 2) Mods to plugin handling in our "glue" needed to recover from the above Please review this at http://codereview.chromium.org/149443 SVN Base: svn://chrome-svn/chrome/trunk/src/ Affected files: M DEPS M webkit/glue/webframeloaderclient_impl.h M webkit/glue/webframeloaderclient_impl.cc M webkit/glue/webplugin_impl.h M webkit/glue/webplugin_impl.cc -- From: ** Date: Thu, Jul 9, 2009 at 10:35 PM To: j...@chromium.org Cc: chromium-revi...@googlegroups.com, da...@chromium.org, j...@chromium.org Huh... surpsised that it shows up as a green try despite the RED plugin test? Not sure how to proceed honestly. Its not like I can revert the change in webkit. So we can't pick any new webkit changes w/o coming to terms with this change first. Ouch... just ran a local build and got a crashing YouTube page when navigating away... For now I'm NOT rolling DEPs :( -- From: *Michael Nordman* Date: Thu, Jul 9, 2009 at 10:46 PM To: j...@chromium.org Cc: chromium-revi...@googlegroups.com, da...@chromium.org John, could use your help with this tomorrow please. --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
2009/6/25 Fumitoshi Ukai (鵜飼文敏)
> Thanks for review.
>
> 2009/6/25 Michael Nordman
>
>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>
> Sure. I've added a diagram in webkit part.
>
>
>> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
>> is a refcounted object and this design looks modeled off of that (which may
>> be why you've spec'd it this way). Unless your design actually needs
>> refcounting on this class, you may be able to simplify things without it.
>> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>>
>
> Yes. I missed to add public RefCounted as base class of
> WebSocketHandle.
> Thanks.
>
I was suggesting that perhaps the WebSocketHandle does not need to be
refcounted.
>
>
> > should we reuse WebCore/loader instead of adding new component?
>>
>> The loader is somewhat notorious for its complexity. I think you've made a
>> good decision to keep this out of there and to design the websocket system
>> in a good clean modular fashion.
>>
>> > which component is responsible of web socket protocol framing? This
>> design assumes WebSocketChannel serializes/deserializes message in web
>> socket frame.
>>
>> Since WebSocketHandle is inevitably going to be platform specific, any
>> code you want to be shared code shouldn't be slated for that class. To the
>> extent the 'web socket protocol framing' can be done indepedent of the
>> 'platform' socket handle (which it looks like it can be), it would be a good
>> thing to put it in WebSocketChannel so its shared core common code goodness.
>>
>
> I see.
> I've one question: Web socket handshaking is also platform independent.
> Should we do the handshaking in WebSocketChannel and WebSocketHandle just
> provides almost raw TCP socket?
> Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
> platform code?
>
I haven't read the web sockets spec, so I don't know what the 'handshaking'
entails?
OS level socket creation/destruction and tcp connection opening/closing
needs to be per-platform. Once you have a full-duplex connection and are
sending application 'protocol' data back and forth (message framing), that
probably wants to be common code. Which camp does the 'handshaking' fall
into?
>
>
> > Regarding the "WebKit API", note that no WebCore data types can be used
>> there. So you'll need to create wrapper classes.
>>
>> I see you have speced WebKit:: wrapper classes with the same name as the
>> corresponding WebCore:: classes.
>>
>> I wonder if that same naming could be confusingt? The naming convention
>> darin has been employing would be WebKit::WebWebSocketHandle, which
>> certainly looks odd.
>>
>
> Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
>
>
>> * virtual void didReceiveData(const String& msg) {}
>>
>> Maybe rename this to channel client api to didReceiveMessage() to help
>> distinguish between raw 'data' being surface by the 'handle', and complete
>> 'messages' being surfaced by the 'channel'.
>>
>
> Sure. Fixed.
>
> Thanks!
> ukai
>
>
>>
>>
>> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > > wrote:
>>
>>> Hi,
>>>
>>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and
>>> write design docs
>>>
>>> WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>> Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>>
>>> We'll send WebKit part to webkit-dev, if it looks ok.
>>> We'd welcome if you could give us feedback on our design docs.
>>>
>>> Thanks,
>>> ukai
>>>
>>> >>>
>>>
>>
>
--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc
Only skimmed thusfar as well... but from what i've seen, looks reasonable to
me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
>From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
> should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
> which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any code
you want to be shared code shouldn't be slated for that class. To the extent
the 'web socket protocol framing' can be done indepedent of the 'platform'
socket handle (which it looks like it can be), it would be a good thing to
put it in WebSocketChannel so its shared core common code goodness.
> Regarding the "WebKit API", note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
* virtual void didReceiveData(const String& msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
> Hi,
>
> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
> design docs
>
> WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
> Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>
> We'll send WebKit part to webkit-dev, if it looks ok.
> We'd welcome if you could give us feedback on our design docs.
>
> Thanks,
> ukai
>
> >
>
--~--~-~--~~~---~--~~
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: does chromium care about appcache manifests?
Chromium has no behavior whatsoever yet... the feature is utterly unimplemented thus far... but it will have identical behavior to safari, iphone, andriod by virtue of the same code base performing those behaviors... thats the plan at least, and I'm working on the code now. Gears (i'm partly guilty of that) users have similar issues with the gears system. Developing for 'offline' butts heads ( , not buttheads :O) with standard operating procedures for web development (put new stuff on server, hit reload, repeat as needed). I can think of at least some things that may help? * if the user-agent had a debugging level feature (in some debug/tools menu) to blow away the current appcache. would that help? Or perhaps a UI to show appcaches and a option to 'remove' one? The former could be provided without any spec changes and agreement amoungst browser vendors. We're not far enough along with this feature in chrome to be too concerned with UI yet... but I'll write this down in my design doc. On Wed, Jun 17, 2009 at 5:14 AM, Mark Janssen wrote: > Hi Michael, > > It's been some time (I rarely read this address), but why I was asking > is because I'm testing a web application for iPhone/Android. Safari > does care about appcache manifest, but does so a bit too well: it's > nearly impossible get it to reload a new version from the server (thus > ignoring the appcache manifest). As you can imagine this is quite > cumbersome during development, so I was wondering of Chromium has the > same behaviour. > > Regards, > Mark > > On Mon, Jun 1, 2009 at 11:54 PM, Michael Nordman wrote: >> Hi, I'm assuming you and praseodym in #chromium IRC are one and the >> same... if not, sorry for the spam. >> >> Yes, we do. >> >> At this point, there is no support for the feature in chromium, but >> we're working towards that. The implementation in webcore has to be >> refactored so that chromium can use it too... or chromium has to >> implement this feature outside of webcore... we're pursuing the first >> option at this time. >> >> https://bugs.webkit.org/show_bug.cgi?id=25436 >> >> Why do you ask? >> > --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
Sounds like the underlying issue is not the number of requests (or type of request), but the number of SharedMemory instances in use on behalf of request handling at any one time. Maybe put some limits on directly on that. When a request gets to the point where it needs a SharedMemory block it may have to wait if we're at the limit and continue when the water level comes back down under the limit. And really, it sounds like the limit would want to be applied not just for request handling, but for any uses of SharedMemory blocks in the system. Also, 256 is a pretty low limit. What all do we use SharedMemory blocks for, and is 256 a limit we can live with? --~--~-~--~~~---~--~~ 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: Difference between TestShell and Chromium
On Tue, Jun 9, 2009 at 12:34 PM, Daniel Dreiberg < daniel.dreiber...@gmail.com> wrote: > Hi > I understand TestShell is > > a test harness for running layout tests and a Chromium is a multi-process > web browser. > > And I understand Chromium's browser thread does the I/O for each renderer > process (using Webkit +V8). > > My question is much code in TestShell are 'common' with Chromium. > > I think these are common: > > * Webkit rendering engine > > * V8 JS engine > * image decoding code > * graphics library (i.e. Skia) > > what about ? > * Http stack? > * cookie support > * cache support > Yes, these are 'common' as well. Another way to say it is that chromium's 'net' library is used in both the TestShell and Chromium. The primary interface to the net library, used by both TestShell and Chromium, is the URLRequest class. > > > > --~--~-~--~~~---~--~~ 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: HTTP POST via net package?
If you're interested in seeing the multipart form data encoder, that's in WebCore. WebCore/platform/network/FormData.cpp h WebCore/platform/network/FormDataBuilder.cpp h In Chrome, the webcore FormData data type is translated to a chrome net::UploadData structure in WebRequestImpl::GetUploadData. The net package doesn't know about multipart form encoding... just UploadData structures. On Mon, Jun 8, 2009 at 3:11 PM, Wan-Teh Chang wrote: > > On Mon, Jun 8, 2009 at 2:02 PM, Daniel Cowx wrote: > > > > How can I upload multipart form data (including a file) via HTTP POST? > > Is there something already written in the net package (or elsewhere) > > for this task? If so, can someone please point me to what class to > > use. > > You can use the URLRequest class in the net package to do HTTP POST. > The URLFetcher class in chrome/browser/net is good example code. You > can also use url_request_unittest.cc as example code. > > Wan-Teh > > > > --~--~-~--~~~---~--~~ 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: Need to run parts of WebCore in either the browser process or some "browser helper" process
On Thu, Apr 30, 2009 at 12:26 PM, Michael Nordman wrote: > On Thu, Apr 30, 2009 at 11:40 AM, Darin Fisher wrote: >> On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote: >>> >>> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman >>> wrote: >>> > >>> > + chromium-dev >>> > >>> >> Can you please explain what you think has changed since such decisions >>> >> were made (or why it's time to revisit such decisions)? >>> > >>> > I don't think there was code in webcore suitable for this purpose >>> > before... html parsing, javascript,sql interpretting... all dangerous >>> > from a security point of view (acting in very complex ways on >>> > untrusted web content). The backend logic for these new features >>> > aren't like that. Its not so much that its webcore code is untrusted, >>> > as much as the data it operates on is untrusted. >>> >>> I think this gets at the core of my question: is it OK to run webcore >>> code in the browser process if it is similar in nature to chromium >>> code we would run in the browser process? Or is there some deeper >>> structural reason we don't want to do that? >>> >>> I fear that this is really a question for Darin, who is on vacation. >> >> can talk more when i get back, but in a nut shell: >> 1- we already use webcore indirectly (albeit in a very limited way) from the >> browser process >> 2- the challenge with doing so is threading: what is the webcore main >> thread? what things depend on this and what don't is not well defined. >> -darin > > I've been thinking thru how to share the backend appcache code and > have some thoughts on the threading issue. > > When built into a single process (so not the chrome situation) > > * the 'backend' appache code is NOT used on the 'main' webkit thread > * for the sake of discussion, lets call the thread it is used on the > 'backend' webkit thread > * the single process 'frontend' classes post tasks to the backend thread > * sync apis are handled by waiting on a WaitableEvent in the frontend > classes, which the will get signaled by the backend thread when done > * async api completion is handled by posting tasks to the 'main' > thread (probably easier to setup than having the main thead wait for > multple waitable event handles in the main message loop) > * generally, backend classes running on the 'backend' thread don't > block that thread for file io. Any blocking file io work gets pushed > off to a seperate file io handling thread(s). (This is similar to what > we require of code that executes on chrome's IPC thread in the main > browser process) > > When built into chrome > > * the 'backend' code is NOT used in the renderer at all > * it is used on the IPC thread in the main browser process (and it > doesn't block that thread) > * the multiprocess 'frontend' classes send IPC message instead of > posting thread tasks (sync and async) > * the 'frontend' code is NOT used in the browser process all all In this view... * The 'main' webkit thread is free to be the UI thead in the browser process. I don't think we have a need for this for the appcache or localstorage systems yet... but perhaps when it comes time to prompt users for things or alert them to quota excesses and such this could become relevant for those system. * the 'backend' webkit thread == the IPC thread in the browser process --~--~-~--~~~---~--~~ 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: Need to run parts of WebCore in either the browser process or some "browser helper" process
On Thu, Apr 30, 2009 at 11:40 AM, Darin Fisher wrote: > On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote: >> >> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman >> wrote: >> > >> > + chromium-dev >> > >> >> Can you please explain what you think has changed since such decisions >> >> were made (or why it's time to revisit such decisions)? >> > >> > I don't think there was code in webcore suitable for this purpose >> > before... html parsing, javascript,sql interpretting... all dangerous >> > from a security point of view (acting in very complex ways on >> > untrusted web content). The backend logic for these new features >> > aren't like that. Its not so much that its webcore code is untrusted, >> > as much as the data it operates on is untrusted. >> >> I think this gets at the core of my question: is it OK to run webcore >> code in the browser process if it is similar in nature to chromium >> code we would run in the browser process? Or is there some deeper >> structural reason we don't want to do that? >> >> I fear that this is really a question for Darin, who is on vacation. > > can talk more when i get back, but in a nut shell: > 1- we already use webcore indirectly (albeit in a very limited way) from the > browser process > 2- the challenge with doing so is threading: what is the webcore main > thread? what things depend on this and what don't is not well defined. > -darin I've been thinking thru how to share the backend appcache code and have some thoughts on the threading issue. When built into a single process (so not the chrome situation) * the 'backend' appache code is NOT used on the 'main' webkit thread * for the sake of discussion, lets call the thread it is used on the 'backend' webkit thread * the single process 'frontend' classes post tasks to the backend thread * sync apis are handled by waiting on a WaitableEvent in the frontend classes, which the will get signaled by the backend thread when done * async api completion is handled by posting tasks to the 'main' thread (probably easier to setup than having the main thead wait for multple waitable event handles in the main message loop) * generally, backend classes running on the 'backend' thread don't block that thread for file io. Any blocking file io work gets pushed off to a seperate file io handling thread(s). (This is similar to what we require of code that executes on chrome's IPC thread in the main browser process) When built into chrome * the 'backend' code is NOT used in the renderer at all * it is used on the IPC thread in the main browser process (and it doesn't block that thread) * the multiprocess 'frontend' classes send IPC message instead of posting thread tasks (sync and async) * the 'frontend' code is NOT used in the browser process all all > > >> >> >> I have always felt like running the WebCore "backend" in the browser >> >> was elegant >> > >> > Yea, but we need a webcore backend to run :) >> >> Well last time I looked at this there was already a Database backend :) >> >> - a >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process
Yup, I'm looking to work thru things in a similar fashion with anders (original appcache author). On Wed, Apr 29, 2009 at 11:53 AM, David Levin wrote: > I think how to split/refactor depends on the feature, understanding the > current code, and working with the appropriate webkit dev. > For workers, we thought about how/where it made sense to split the impl for > chrome and talked with a...@webkit about it. There was some iteration as we > figured out things better and as he made suggestions and it has worked out > fine so far. > > On Wed, Apr 29, 2009 at 11:49 AM, Michael Nordman > wrote: >> >> +chromium-dev >> >> Designing things in this front/back fashion and re-using the code >> entirely in chrome removes at least one high-coefficient of friction >> surface rubbing between the chromium and webkit teams. We will likely >> pay a higher price up front, but it should pay dividends down the >> road. Add an interesting feature and iphone, andriod, chrome, and >> safari all pick it up. >> >> I'm worried about the logistics of pulling this off for the appcache >> given the existing impl is live and in use in iphone and safari and >> soon andriod. We're talking about 'refactoring' or 'replacing' >> existing impls with new ones that support a remote backend. How can we >> reduce the upfront cost? >> >> * maybe build these new impls out in webcore w/o disrupting the existing >> impl >> * use the new impl for chrome (and any other webkit consumer that >> wishes to compile the new impls in would be free to do so) >> * somewhere down the road, deprecate the existing impl in favor of the >> new impl in webcore >> >> We haven't talked to the webkit guys about logistics like this, no >> data on where their head is? >> >> > > > > > --~--~-~--~~~---~--~~ 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: Need to run parts of WebCore in either the browser process or some "browser helper" process
+chromium-dev Designing things in this front/back fashion and re-using the code entirely in chrome removes at least one high-coefficient of friction surface rubbing between the chromium and webkit teams. We will likely pay a higher price up front, but it should pay dividends down the road. Add an interesting feature and iphone, andriod, chrome, and safari all pick it up. I'm worried about the logistics of pulling this off for the appcache given the existing impl is live and in use in iphone and safari and soon andriod. We're talking about 'refactoring' or 'replacing' existing impls with new ones that support a remote backend. How can we reduce the upfront cost? * maybe build these new impls out in webcore w/o disrupting the existing impl * use the new impl for chrome (and any other webkit consumer that wishes to compile the new impls in would be free to do so) * somewhere down the road, deprecate the existing impl in favor of the new impl in webcore We haven't talked to the webkit guys about logistics like this, no data on where their head is? --~--~-~--~~~---~--~~ 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: Need to run parts of WebCore in either the browser process or some "browser helper" process
On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote: > On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman > wrote: >> >> + chromium-dev >> >>> Can you please explain what you think has changed since such decisions were >>> made (or why it's time to revisit such decisions)? >> >> I don't think there was code in webcore suitable for this purpose >> before... html parsing, javascript,sql interpretting... all dangerous >> from a security point of view (acting in very complex ways on >> untrusted web content). The backend logic for these new features >> aren't like that. Its not so much that its webcore code is untrusted, >> as much as the data it operates on is untrusted. > > I think this gets at the core of my question: is it OK to run webcore > code in the browser process if it is similar in nature to chromium > code we would run in the browser process? Or is there some deeper > structural reason we don't want to do that? > > I fear that this is really a question for Darin, who is on vacation. Me too, when i asked him he said "thats not a problem". > >>> I have always felt like running the WebCore "backend" in the browser was >>> elegant >> >> Yea, but we need a webcore backend to run :) > > Well last time I looked at this there was already a Database backend :) Right... interpretting random SQL from the web :) > > - a > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process
+ chromium-dev > Can you please explain what you think has changed since such decisions were > made (or why it's time to revisit such decisions)? I don't think there was code in webcore suitable for this purpose before... html parsing, javascript,sql interpretting... all dangerous from a security point of view (acting in very complex ways on untrusted web content). The backend logic for these new features aren't like that. Its not so much that its webcore code is untrusted, as much as the data it operates on is untrusted. > I have always felt like running the WebCore "backend" in the browser was > elegant Yea, but we need a webcore backend to run :) --~--~-~--~~~---~--~~ 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: Need to run parts of WebCore in either the browser process or some "browser helper" process
On Tue, Apr 28, 2009 at 5:38 PM, Jeremy Orlow wrote: > On Tue, Apr 28, 2009 at 5:27 PM, Michael Nordman > wrote: >> >> > In some sense we do have separate process in which to run sandboxed >> > 'backend' code relevant to multiple renders if the need arises... the >> > worker process. > > The way you stated this is a bit odd, but on the surface I guess this could > be solved via special "shared workers" that ran WebKit code instead of > javascript. That said, this means a lot of extra processes (for now, shared > workers are each in their own process), this blocks localStorage on that, > and actually makes the design more complicated. This might be worth > exploring at some point, but not now. Let me re-iterate my main point... i dont think we need to sandbox the localstorage or appcache backend code, so we should be able to run that directly in the browser process. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Fwd: [chromium-dev] Re: localStorage design document - please offer feedback!
+ chromium-dev On Tue, Apr 14, 2009 at 1:16 PM, Jeremy Orlow wrote: >> "When you fire an event, will other windows see it? If not, no need for >> the rest of this... When the event is dispatched, a synchronous message >> will be sent to the browser process which will be redistributed to all >> render processes currently subscribed. A nested message loop will be run >> during the synchronous action. (Also synchronous for serialization >> purposes.)" <-- I don't understand this. Since storage events originate in >> the browser, why would the renderer need to send them back to the browser to >> be re-distributed? > > This was talking about DocumentEvent.createEvent which happens in v8 in a > render process. The only question (and this is something I can answer by > myself--I just haven't yet) is whether events created in one window are > supposed to be transmitted to all other windows in that origin. I'd assume > yes. I would not expect storage events synthesized in this way to actually be sent outside of the current window. Strictly speaking, it probably would be nice if script could not create mock storage events at all. >> "Cleanup of WebKit's *Storage code" <-- It would be good to start the >> conversation early with folks from WebKit about how significantly different >> our implementation of localStorage is. You should expect push-back unless >> you can adequately justify why a separate implementation is required. I >> think your design is the right approach, so this should be an "easy" >> argument to make ;-) > > Yup. My next step is starting this conversation with the WebKit people. > >> >> "Rejected alternative approaches" <-- i'm surprised that you don't explain >> why you are not using the current webkit implementation perhaps with the >> same VFS approach that we are using for HTML5 database. the only thing >> missing there is a solution for storage events. > > The information was there, but poorly organized. I've fleshed things out > further and re-labeled things a bit. It's not exactly easy to read because > there's many possible ways you could re-use WebKit code and there's > basically a linear relationship between how bad the solution is and how much > it reuses code. > Let me know if I missed anything in my analysis. > >> >> the costs to having a separate implementation from apple is non-trivial. >> ideally you're solution here would be a refactoring of their code to enable >> you to share some of their code. for example, i would expect that you could >> share the code that interacts with sqlite. > > Because we're handling database operations in the browser process and we > don't use WebKit there, this is not possible. > I promise I did put a good deal of thought into how we could share more > code. My email to WebKit.org will be soliciting ideas, but I think we've > come up with pretty sound problems for each implementation. Their > implementation is _very_ rooted in the idea of having one process. Ultimately we do want to share the same implementation. We should look at that as a design goal/constraint. Jeremy's design for this feature is just fine. Unfortunately we can't use webkit code to realize that design Oh well, too bad, end of story NO. If "their" implementation wasn't so rooted in the idea of having on process... we could reuse it. So, we have to make "their" implemetation not so rooted in that. We have to start looking at webkit as collectively ours too, and contributing to it to make it meet our needs. We don't want to hold the Good hostage to the Perfect, so I don't think this level of reuse should be required in our initial implemenation of these things, but if we could pull it off... that would be really nice. We face the similar issues with the appcache system. --~--~-~--~~~---~--~~ 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: localStorage design document - please offer feedback!
+ chromium-dev On Tue, Apr 14, 2009 at 9:36 AM, Darin Fisher wrote: > DOM Storage Overview > LGTM > > LocalStorage > "The exception is when a synchronous operation (synch XHR or alert() are > examples) or when navigator.unlockStorage() is executed" <-- I think you > should also say that the lock is released when calling into a plugin. I > believe that issue was also discussed on the whatwg thread. > "For localStorage, the BrowserProcess::db_thread will be unless a new thread > is absolutely necessary." <-- I agree that we should not need a new thread. > "This thread will receive and process all localStorage IPC messages." <-- I > assume you will intercept the IPC messages on the IO thread, and delegate to > the DB thread. This means that the IO thread is also involved in receiving > and processing localStorage IPC messages. > "Luckily, each origin is completely isolated from the next, so we > essentially must implement a per-origin lock for localStorage." <-- In > discussing this with Ian Hickson, he was convinced that we would still need > a global lock to avoid dead-locks. I didn't fully understand the dead-lock > scenario he was concerned about, so it might be good to ask him about it. > He said you could imagine a frame from origin A containing a frame from > origin B. There may also be a frame from origin B containing a frame from > origin A in another process. If there was a way for script in the outer > frame to synchronously block on execution of script in the inner frame, then > I guess you could get a dead-lock. I'm not sure how to construct that > scenario though. I'm probably overlooking something... > "How do we know when a process dies?" <-- See > BrowserRenderProcessHost::OnChannelError. > "Because responses may be deferred for some time, the message handler will > probably be IPC_MESSAGE_HANDLER_DELAY_REPLY. " <-- this is also necessary in > order to delegate IPC message processing to the DB thread. in other words, > you don't want to block the IO thread waiting for the DB thread. > "When a render process asks to subscribe to storage events, that process > will be added to the set for a particular origin." <-- it seems like this > registration will happen asynchronously in chrome. there could be some > interesting race conditions that cause you to either send a notification > when one was not expected or miss a notification that would be sent by > safari. what are your plans for this? maybe the races don't matter since > it is hard to predict (even in a single threaded browser like safari) when > another window will modify localStorage. > It seems unfortunate to me that the spec requires a storage event to carry a > copy of the old and new values. Oh well :( > "The render process will then need to run a nested message loop to process > messages. TODO: How will this work? We can probably do whatever set/get > cookie does." <-- Yes, just use the existing synchronous IPC messaging code > that we use for cookies and many other things. This should be easy. > "Other blocking operations like synchronous XHR operations and calling > alert() should release the lock as well." <-- you should probably try to > recognize these cases in chrome/renderer/ so that you can have a single IPC > for unlocking. > StorageEvent: "These messages are synchronous and thus require a nested > message loop." <-- why do they need to be synchronous? OK, I see that you > are addressing the race issue I mentioned before. I think we can probably > stick with asynchronous messages but keep a corresponding data structure in > the renderer that allows us to drop notifications that we should not > dispatch. i don't think we benefit from using synchronous IPC here. > "When you fire an event, will other windows see it? If not, no need for the > rest of this... When the event is dispatched, a synchronous message will be > sent to the browser process which will be redistributed to all render > processes currently subscribed. A nested message loop will be run during > the synchronous action. (Also synchronous for serialization purposes.)" <-- > I don't understand this. Since storage events originate in the browser, why > would the renderer need to send them back to the browser to be > re-distributed? > "Cleanup of WebKit's *Storage code" <-- It would be good to start the > conversation early with folks from WebKit about how significantly different > our implementation of localStorage is. You should expect push-back unless > you can adequately justify why a separate implementation is required. I > think your design is the right approach, so this should be an "easy" > argument to make ;-) > Please ask Brett Wilson to review your DB schema and operations. > "Rejected alternative approaches" <-- i'm surprised that you don't explain > why you are not using the current webkit implementation perhaps with the > same VFS approach that we are using for HTML5 database. the only thing > missing there is a solution
Fwd: [chromium-dev] Re: Visual Studio Conversion to 2008 not converting couple of projects 4 errors?
+ chromium-dev Something like this is happening to me right now. The first time i ran gclient sync, it complained about webkit.sln. Subsequent runs have it repeatedly complaining about test_shell_tests.vcproj... what's the trick to resolving this... delete the files its griping about? Gripes in order seen so far... * One: webkit.sln * Repeaded: test_shell_tests.vcproj C:\chrome\src>svn status ! . ? media\media_bench.vcproj ! webkit M webkit\port\bindings\v8\v8_proxy.cpp M webkit\port\bindings\v8\v8_index.h M webkit\glue\chromium_bridge_impl.cc ! webkit\tools ! webkit\tools\test_shell ? net\data\url_request_unittest\dump M net\url_request\url_request_job_manager.cc M net\url_request\url_request_job.cc M net\url_request\url_request.h M net\url_request\url_request_job_manager.h M net\url_request\url_request_job.h M net\url_request\url_request_unittest.cc M net\url_request\url_request.cc M net\url_request\url_request_context.h ? sandbox\sbox_unit_tests.vcproj ? build\temp_gyp\v8.log ? chrome\test\data\temp_test_icon.ico ? chrome\test\data\dump M chrome\browser\browser.vcproj ? chrome\common\app_cache\app_cache.notes.h ? chrome\common\app_cache\net ? chrome\common\app_cache\app_cache_service.h A chrome\common\app_cache\app_cache_interceptor.cc A chrome\common\app_cache\app_cache_interceptor.h M chrome\common\common.vcproj On Mon, Apr 6, 2009 at 12:01 AM, Bradley Nelson wrote: > Very odd. > Was build/temp_gyp affected at all? > Next time this happens can you run svn status in src and send me the result. > Thanks! > -BradN > > On Fri, Apr 3, 2009 at 2:46 PM, Mohamed Mansour > wrote: >> >> Hey Bradley, >> Just to let you know, it happened again, just right now. I gclient synced, >> my project, and getting these errors now: >> Failed to upgrade project file Please make sure the file exists and >> is not write-protected. >> Where is: >> ..\googleurl\build\googleurl.vcproj >> ..\v8\tools\visual_studio\v8.vcproj >> ..\v8\tools\visual_studio\v8_base.vcproj >> ..\v8\tools\visual_studio\v8_mksnapshot.vcproj >> ..\v8\tools\visual_studio\v8_shell_sample.vcproj >> ..\v8\tools\visual_studio\v8_snapshot.vcproj >> ..\v8\tools\visual_studio\v8_snapshot_cc.vcproj >> I deleted all my vcproj files, and resynced, and ran the hooks, but still >> these errors happened. >> I had to delete (once again) the folders googleurl and v8 to make my >> build work. >> What could it be? Must be my end or gyp? >> On Tue, Mar 24, 2009 at 10:51 AM, Marc-Antoine Ruel >> wrote: >>> >>> Just to close the issue, VS2008 is working fine here at the moment. >>> >>> On Thu, Mar 19, 2009 at 9:18 PM, Bradley Nelson >>> wrote: >>> >> >>> >> We are not using 2.6? >>> > >>> > Not at the moment. >>> > Thanks, at a loss to explain it. >>> > Let me know if this happens again. >>> > Has anyone else seen this sort of thing? >>> > -BradN >>> > >>> > >>> > >>> > >>> >> >>> >> >>> >> On Thu, Mar 19, 2009 at 1:42 PM, Bradley Nelson >>> >> >>> >> wrote: >>> >> > Very mysterious. >>> >> > These are gyp related: >>> >> > ..\base\base.vcproj >>> >> > ..\base\base_gfx.vcproj >>> >> > ..\base\base_unittests.vcproj >>> >> > ..\third_party\bzip2\bzip2.vcproj >>> >> > ..\net\crash_cache.vcproj >>> >> > ..\base\debug_message.vcproj >>> >> > But these are not: >>> >> > ..\googleurl\build\googleurl.vcproj >>> >> > ..\v8\tools\visual_studio\v8.vcproj >>> >> > ..\v8\tools\visual_studio\v8_base.vcproj >>> >> > ..\v8\tools\visual_studio\v8_mksnapshot.vcproj >>> >> > ..\v8\tools\visual_studio\v8_shell_sample.vcproj >>> >> > ..\v8\tools\visual_studio\v8_snapshot.vcproj >>> >> > ..\v8\tools\visual_studio\v8_snapshot_cc.vcproj >>> >> > >>> >> > Do you recall roughly when this was time wise? >>> >> > Did you have a local python installed, if so, what version? >>> >> > Let me know if this crops up again. >>> >> > -BradN >>> >> > >>> >> > On Wed, Mar 18, 2009 at 11:11 PM, Mohamed Mansour >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Hi, I did what you said, and now getting other files which failed: >>> >> >> >>> >> >> ..\googleurl\build\googleurl.vcproj >>> >> >> ..\v8\tools\visual_studio\v8.vcproj >>> >> >> ..\v8\tools\visual_studio\v8_base.vcproj >>> >> >> ..\v8\tools\visual_studio\v8_mksnapshot.vcproj >>> >> >> ..\v8\tools\visual_studio\v8_shell_sample.vcproj >>> >> >> ..\v8\tools\visual_studio\v8_snapshot.vcproj >>> >> >> ..\v8\tools\visual_studio\v8_snapshot_cc.vcproj >>> >> >> >>> >> >> I did a gclient sync, and then got these previous errors (again): >>> >> >> ..\base\base.vcproj >>> >> >> ..\base\base_gfx.vcproj >>> >> >> ..\base\base_unittests.vcproj >>> >> >> ..\third_party\bzip2\bzip2.vcproj >>> >> >> ..\net\crash_cache.vcproj >>> >> >> ..\base\debug_message.vcproj >>> >> >> >>> >> >> So I deleted the complete folder associated with these projects >>> >> >> which >>> >> >> were: >>> >> >> - googleurl >>> >> >> - v8
[chromium-dev] Re: Need advice on where localStorage should live
On Mon, Mar 23, 2009 at 1:02 PM, Darin Fisher wrote: > On Mon, Mar 23, 2009 at 12:44 PM, Michael Nordman wrote: > >> >> >> On Mon, Mar 23, 2009 at 12:03 PM, Darin Fisher wrote: >> >>> On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow wrote: >>> >>>> *If you don't care where various bits of the localStorage >>>> implementation live and you aren't scared about letting stuff out of the >>>> sandbox, you can stop reading now.* >>>> >>>> * >>>> * >>>> Background: >>>> >>>> For those who don't know the spec by heart: SessionStorage can be >>>> thought of as 'tab local' storage space for each origin. >>>> >>> >>> SessionStorage can probably be implemented entirely within WebKit. We >>> should be able to share this implementation with Safari (except for the >>> differences in JS bindings of course). >>> >> >> The other difference will be around how the existing sessionStorage is >> cloned when spawning a new top-level browsing context from an existing >> one. Right-click open in new tab/window, should result in a new tab/window >> whose sessionStorage is pre-populated with the contents of the original's. >> > > Interesting. I wonder why this is so different than session cookies. > /shrug > The use of the term session is a little misleading in this API. This repository is really a tab specific collection of transient name/value pairs. I would love to see a "session" specific (in the more conventional use of the word session) non-persistent collection in addition to the per tab bag of bits currently provided. > -Darin > > > > >> >> >>> >>> >>> >>>> LocalStorage is shared across all browser windows of the same origin >>>> and is persistent. All data is stored in key/value pairs where both the >>>> key >>>> and value are strings. It's possible to subscribe to DOM storage events. >>>> Events and ease of use are why a developer might use localStorage even >>>> though the database interface exists. The exact spec is here: >>>> http://dev.w3.org/html5/webstorage/ >>>> >>>> >>>> *Where should the localStorage implementation live? >>>> * >>>> >>>> I'm planning on implementing localStorage very soon within Chromium. >>>> Unfortunately, how to do this is not very clearcut. Here are all the >>>> possibilities I know of so far: (Note that I'm intentionally ignoring the >>>> backing file format for now...as that debate will partially depend on how >>>> it's implemented.) >>>> >>>> 1) The most obvious solution is to have have the browser process keep >>>> track of the key/values for each origin and write it to disk. The problem >>>> with this approach is that we're allowing user supplied data to exist in >>>> memory (possibly the stack at times, though we could probably avoid this if >>>> we tried) outside of a sandbox. Ian Fette (and I'm sure others) have >>>> pretty >>>> big reservations for this reason. That said, this is definitely the >>>> simplest and cleanest solution, so if we can figure out something that >>>> we're >>>> confident with security wise, this is how I'd like to do it. >>>> >>> >>> We do this for cookies, so doing it for localStorage is no big deal. >>> >>> >>> >>>> >>>> >>>> 2) What follows from #1 is simply pulling all the localStorage code >>>> into its own (sandboxed) process. The problem is that, unless a lot of the >>>> internet starts using localStorage, it seems disproportionately heavy >>>> weight. Starting it on demand and killing it off if localStorage hasn't >>>> been used for a while would mitigate. >>>> >>> >>> Why would we need a separate process? It seems like we could just have >>> some IPCs to get/set localStorage values. We could mimic what we do for >>> cookies. I don't see much value in sandboxing the storage component of >>> localStorage. >>> >>> >>> >>>> >>>> >>>> 3) A completely different solution is to use shared memory + the code >>>> recently written to pass file handles between processes. The shared memory >>>> would be used to coor
[chromium-dev] Re: Need advice on where localStorage should live
+chromium-dev On Mon, Mar 23, 2009 at 12:03 PM, Darin Fisher wrote: > On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow wrote: > >> *If you don't care where various bits of the localStorage implementation >> live and you aren't scared about letting stuff out of the sandbox, you can >> stop reading now.* >> >> * >> * >> Background: >> >> For those who don't know the spec by heart: SessionStorage can be thought >> of as 'tab local' storage space for each origin. >> > > SessionStorage can probably be implemented entirely within WebKit. We > should be able to share this implementation with Safari (except for the > differences in JS bindings of course). > The other difference will be around how the existing sessionStorage is cloned when spawning a new top-level browsing context from an existing one. Right-click open in new tab/window, should result in a new tab/window whose sessionStorage is pre-populated with the contents of the original's. > > > >> LocalStorage is shared across all browser windows of the same origin and >> is persistent. All data is stored in key/value pairs where both the key and >> value are strings. It's possible to subscribe to DOM storage events. >> Events and ease of use are why a developer might use localStorage even >> though the database interface exists. The exact spec is here: >> http://dev.w3.org/html5/webstorage/ >> >> >> *Where should the localStorage implementation live? >> * >> >> I'm planning on implementing localStorage very soon within Chromium. >> Unfortunately, how to do this is not very clearcut. Here are all the >> possibilities I know of so far: (Note that I'm intentionally ignoring the >> backing file format for now...as that debate will partially depend on how >> it's implemented.) >> >> 1) The most obvious solution is to have have the browser process keep >> track of the key/values for each origin and write it to disk. The problem >> with this approach is that we're allowing user supplied data to exist in >> memory (possibly the stack at times, though we could probably avoid this if >> we tried) outside of a sandbox. Ian Fette (and I'm sure others) have pretty >> big reservations for this reason. That said, this is definitely the >> simplest and cleanest solution, so if we can figure out something that we're >> confident with security wise, this is how I'd like to do it. >> > > We do this for cookies, so doing it for localStorage is no big deal. > > > >> >> >> 2) What follows from #1 is simply pulling all the localStorage code into >> its own (sandboxed) process. The problem is that, unless a lot of the >> internet starts using localStorage, it seems disproportionately heavy >> weight. Starting it on demand and killing it off if localStorage hasn't >> been used for a while would mitigate. >> > > Why would we need a separate process? It seems like we could just have > some IPCs to get/set localStorage values. We could mimic what we do for > cookies. I don't see much value in sandboxing the storage component of > localStorage. > > > >> >> >> 3) A completely different solution is to use shared memory + the code >> recently written to pass file handles between processes. The shared memory >> would be used to coordinate between processes and to store key/val data. >> One render process for each origin will take responsibility for syncing data >> to disk. Event notifications can occur either via IPC (though sharing >> key/val data can NOT for latency/responsiveness reasons) or shared >> memory--whichever is easier. Obviously the chief problem with this is >> memory usage. I'm sure it'll also be more complex and have a greater >> bug/exploit cross section. >> > > I think this is too complex for something that is not used much on the web. > We don't do this for cookies, so we shouldn't need to do it for > localStorage. > > > >> >> >> 4) A variation of #3 would be to keep all key/val data in the file and >> only use shared memory for locking (if necessary). I'm not going to discuss >> the implementation details because I don't want us to get hung up on them, >> but the general idea would be for each process to have an open file handle >> for their origin(s) and somehow (shared memory, flock, etc) coordinate with >> the other processes. This will almost certainly be slower than memory (if >> nothing else, due to system calls) but it'll use less memory and possibly be >> easier to make secure. >> >> 5) One last option is to layer the whole thing on top of the HTML 5 >> database layer. Unfortunately, there's no efficient way for this layer to >> support events. Even hooking directly into sqlite won't work since its >> triggers layer apparently only notifies you (i.e. works) if the >> insert/delete/update happens in your own process. Of course sqlite can be >> the backing for any other option, but please, let's hold off on that >> discussion for now. >> >> >> *So here are my questions:* >> >> How paranoid should we be about passing a user crea
[chromium-dev] Re: Need advice on where localStorage should live
+chromium-dev. On Sat, Mar 21, 2009 at 9:30 AM, John Abd-El-Malek wrote: > > > On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow wrote: > >> *If you don't care where various bits of the localStorage implementation >> live and you aren't scared about letting stuff out of the sandbox, you can >> stop reading now.* >> >> * >> * >> Background: >> >> For those who don't know the spec by heart: SessionStorage can be thought >> of as 'tab local' storage space for each origin. LocalStorage is shared >> across all browser windows of the same origin and is persistent. All data >> is stored in key/value pairs where both the key and value are strings. It's >> possible to subscribe to DOM storage events. Events and ease of use are why >> a developer might use localStorage even though the database interface >> exists. The exact spec is here: http://dev.w3.org/html5/webstorage/ >> >> >> *Where should the localStorage implementation live? >> * >> >> I'm planning on implementing localStorage very soon within Chromium. >> Unfortunately, how to do this is not very clearcut. Here are all the >> possibilities I know of so far: (Note that I'm intentionally ignoring the >> backing file format for now...as that debate will partially depend on how >> it's implemented.) >> >> 1) The most obvious solution is to have have the browser process keep >> track of the key/values for each origin and write it to disk. The problem >> with this approach is that we're allowing user supplied data to exist in >> memory (possibly the stack at times, though we could probably avoid this if >> we tried) outside of a sandbox. Ian Fette (and I'm sure others) have pretty >> big reservations for this reason. That said, this is definitely the >> simplest and cleanest solution, so if we can figure out something that we're >> confident with security wise, this is how I'd like to do it. >> > > I really don't see the big issue here. We already do this with renderer > supplied data such as FORMs, POST, even really long URLs. The main point is > to ensure that we don't trust that data. > > >> >> 2) What follows from #1 is simply pulling all the localStorage code into >> its own (sandboxed) process. The problem is that, unless a lot of the >> internet starts using localStorage, it seems disproportionately heavy >> weight. Starting it on demand and killing it off if localStorage hasn't >> been used for a while would mitigate. >> >> 3) A completely different solution is to use shared memory + the code >> recently written to pass file handles between processes. The shared memory >> would be used to coordinate between processes and to store key/val data. >> One render process for each origin will take responsibility for syncing data >> to disk. Event notifications can occur either via IPC (though sharing >> key/val data can NOT for latency/responsiveness reasons) or shared >> memory--whichever is easier. Obviously the chief problem with this is >> memory usage. I'm sure it'll also be more complex and have a greater >> bug/exploit cross section. >> >> 4) A variation of #3 would be to keep all key/val data in the file and >> only use shared memory for locking (if necessary). I'm not going to discuss >> the implementation details because I don't want us to get hung up on them, >> but the general idea would be for each process to have an open file handle >> for their origin(s) and somehow (shared memory, flock, etc) coordinate with >> the other processes. This will almost certainly be slower than memory (if >> nothing else, due to system calls) but it'll use less memory and possibly be >> easier to make secure. >> >> 5) One last option is to layer the whole thing on top of the HTML 5 >> database layer. Unfortunately, there's no efficient way for this layer to >> support events. Even hooking directly into sqlite won't work since its >> triggers layer apparently only notifies you (i.e. works) if the >> insert/delete/update happens in your own process. Of course sqlite can be >> the backing for any other option, but please, let's hold off on that >> discussion for now. >> > > It seems that either way you have to build your own custom notification > system in order to alert all renderer processes if a url they have loaded > has updated storage values. Why not use sqlite in each renderer process > then, with this system build on top of it? > > >> >> >> *So here are my questions:* >> >> How paranoid should we be about passing a user created string to the >> browsing process and having it send the data on to the renderer and some >> backend like sqlite? >> > Good question. 100% of the untrusted web content that ends up in sandboxed processes ends up flowing thru the browser process, and much of it gets cached on disk. Every page and embedded resource, script generated values of in form posts, cookie strings etc, all of it is resides in the process browser for a time and on disk. This content is no different... so how paranoid... since its not i
