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 da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman a...@google.com wrote:
On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting pkast...@google.com
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 SingletonT. 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
[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] 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 dglaz...@google.comwrote: 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 senorbla...@chromium.org 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 micha...@chromium.org 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
Re: [chromium-dev] WebKit roll status
Ah... thank you for the ptr. On Tue, Dec 8, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Tue, Dec 8, 2009 at 12:55 PM, Michael Nordman micha...@chromium.org 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
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 a...@google.com wrote: On Tue, Dec 8, 2009 at 1:27 PM, Dimitri Glazkov dglaz...@chromium.org 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] 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 atwil...@chromium.org 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 sh...@chromium.org 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 jor...@chromium.org 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 Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. We've talked through these repeatedly and I think we've made good cases against them. WebCore canonicalizes security origins. At the moment, we never create security origins in Chrome. I wasn't implying that webcore's origin code wasn't doing the work, just mentioning the use case of determining an origin based on a url. Something like this could work. // Returns the security origin associated with the given url. (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL url); You've given some examples of where we _might_ (read: this is vaporware) do this in the future. For all the use cases I've seen so far, I would actually propose adding a canonicalizeSecurityOrigin() method to WebSecurityOrigin that would create a WebCore::SecurityOrigin and then immediately toString() it. What other use cases are there? With each one, please make clear whether it's something we need today or whether it's something you suspect we'll need in the future...because I think most if not all of them are in this second bucket. And I don't want us to code ourselves into a corner, but I also don't want us to write a bunch of dead code that may be used in the future. The use case is tracking usage per-origin in the appcache code. This isn't a hypothetical thing. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman micha...@google.comwrote: On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com 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?
+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 jor...@chromium.org 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?
On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.comwrote: +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 jor...@chromium.org 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?
On Wed, Oct 14, 2009 at 4:03 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc d...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.com 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: 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 jhawk...@chromium.org 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 Martine...@chromium.org 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 hap...@gmail.com wrote: On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.orgwrote: On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com 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
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 foo plugin works better on this and bar plugin works better on that in some odd corner case. On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlowjor...@chromium.org 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
+ 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 foo plugin works better on this and bar plugin works better on that in some odd corner case. On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlowjor...@chromium.org 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 jor...@google.com 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. phajdan...@chromium.org 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: 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 ama...@chromium.org 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 Walkerama...@chromium.org wrote: On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org 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: ** micha...@chromium.org 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: ** micha...@chromium.org 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* micha...@google.com 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 (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
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 RefCountedWebSocketHandle 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 (鵜飼文敏) u...@chromium.org
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 (鵜飼文敏) u...@chromium.orgwrote:
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 ( verb noun, 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 Janssenpraseo...@gmail.com 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 Nordmanmicha...@google.com 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: 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 w...@google.com wrote: On Mon, Jun 8, 2009 at 2:02 PM, Daniel Cowxdaniel.c...@gmail.com 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 11:40 AM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman a...@chromium.org wrote: On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman micha...@chromium.org 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 le...@google.com 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 micha...@chromium.org 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 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: localStorage design document - please offer feedback!
+ chromium-dev chromium-dev@googlegroups.com On Tue, Apr 14, 2009 at 9:36 AM, Darin Fisher da...@chromium.org 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 for storage events. the costs to having a separate implementation
[chromium-dev] Re: Need advice on where localStorage should live
+chromium-dev On Mon, Mar 23, 2009 at 12:03 PM, Darin Fisher da...@chromium.org wrote: On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow jor...@chromium.org 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 created string to the browsing process and having it send the data on to the renderer and some backend like sqlite? Do we trust sqlite enough to use it
[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 j...@chromium.org wrote: On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow jor...@chromium.org 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 interpreted, we shouldn't be overly concerned with this. This does not share the same security concerns as the Database or as Workers
