[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some browser helper process
On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting pkast...@chromium.orgwrote: On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow jor...@chromium.org wrote: Darin was there on that lunch and was actually the one who first suggested running parts of WebCore in the browser to me during a 1:1. :-) Indeed, we're already planning to do it in other ways -- using a text field as a directly-instantiable class in the UI, for example. I don't really have much of an opinion on this discussion except that I'm not so negative about the original plan of writing our own backend as Jeremy is. Here are his objections: From a technical standpoint, it's unclear how testing would work since our test_shell would be testing a different backend from what's in Chromium. It also means we have more code to maintain, and that code is completely off of WebKit's radar. It also makes Apple mad and Dimitri sad. So really, this doesn't seem like a good solution. I'm not sure how test_shell matters w.r.t. testing this backend, since the primary test of the backend (and the frontend?) would presumably be through unittests (w/mocks where necessary), which test the code directly and don't care what backend it's in. test_shell already doesn't have the same code as the main browser for 100 other things. Having code to maintain off WebKit's radar is again not a new situation. I'm not talking about forked stuff, just anything that isn't in WebKit. Having the code in WebKit is a two-edged sword, since when it's there it's gatekeepered on WebKit code review (not a big problem anymore since we have a couple reviewers now) and the WebKit community doesn't seem to try to keep their tree green. So IMO having code in WebKit is still just as much of a maintenance burden on us except with the additional hurdle that it's not in our direct tree. As far as making people mad, feh. Let's decide the right implementation first. making people mad is a simplification of a complex set of things. Ideally, there would be one implementation in webkit for html features which would allow multiple things: 1. Better compatibility across webkit impls. This makes it easier for web devs. 2. Bugs fixes in one implementation help for both. 3. It helps move the web forward better because we may implement a feature and our webkit impls will get it. 4. The above means that we can make better use of layout tests both in knowing that the ones there should probably pass and contributing new ones too. 5. Giving back to the webkit community is a good thing. etc. But even if the original plan is IMO not so bad, I'm not opposed to the new plans either. People like Darin are much more qualified to comment on what would be *best* and I will be OK with whatever gets decided. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some browser helper process
On Wed, Apr 29, 2009 at 7:43 AM, David Levin le...@google.com wrote: On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting pkast...@chromium.orgwrote: On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow jor...@chromium.orgwrote: Darin was there on that lunch and was actually the one who first suggested running parts of WebCore in the browser to me during a 1:1. :-) Indeed, we're already planning to do it in other ways -- using a text field as a directly-instantiable class in the UI, for example. I don't really have much of an opinion on this discussion except that I'm not so negative about the original plan of writing our own backend as Jeremy is. Here are his objections: From a technical standpoint, it's unclear how testing would work since our test_shell would be testing a different backend from what's in Chromium. It also means we have more code to maintain, and that code is completely off of WebKit's radar. It also makes Apple mad and Dimitri sad. So really, this doesn't seem like a good solution. I'm not sure how test_shell matters w.r.t. testing this backend, since the primary test of the backend (and the frontend?) would presumably be through unittests (w/mocks where necessary), which test the code directly and don't care what backend it's in. test_shell already doesn't have the same code as the main browser for 100 other things. Having code to maintain off WebKit's radar is again not a new situation. I'm not talking about forked stuff, just anything that isn't in WebKit. Having the code in WebKit is a two-edged sword, since when it's there it's gatekeepered on WebKit code review (not a big problem anymore since we have a couple reviewers now) and the WebKit community doesn't seem to try to keep their tree green. So IMO having code in WebKit is still just as much of a maintenance burden on us except with the additional hurdle that it's not in our direct tree. As far as making people mad, feh. Let's decide the right implementation first. making people mad is a simplification of a complex set of things. Ideally, there would be one implementation in webkit for html features which would allow multiple things: 1. Better compatibility across webkit impls. This makes it easier for web devs. 2. Bugs fixes in one implementation help for both. 3. It helps move the web forward better because we may implement a feature and our webkit impls will get it. 4. The above means that we can make better use of layout tests both in knowing that the ones there should probably pass and contributing new ones too. 5. Giving back to the webkit community is a good thing. etc. David hit on most of the points I planned to make. making people mad was obviously a gross oversimplification of the situation. :-) One thing that I forgot to mention was that the WebKit guys are now starting to think about making WebKit more attractive to others that want to use a multi-process model. To me, this is a very noble goal, and fits in with the original goals of Chromium, so it's something we should try to support--even if it means a bit more work for us. But even if the original plan is IMO not so bad, I'm not opposed to the new plans either. People like Darin are much more qualified to comment on what would be *best* and I will be OK with whatever gets decided. I hate speaking for Darin because it's possible that there's some details here he did not agree with, but I'm pretty sure that most of this is exactly what we talked about, and that he was supportive of it. I agree that having our own backend still _could_ be the way to go, but I guess I'd like to give this a shot first. Note also that localStorage is actually a pretty simple example. It'll be interesting to see what things look like for other features, like AppCache. There, having our own backend probably has more impact, though I'm not sure if it's a positive or negative impact. 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: Need to run parts of WebCore in either the browser process or some browser helper process
I think it's a great idea and the only drawback I can see is the WTF dependency and the security implications, which shouldn't be anything we couldn't overcome. The biggest challenges IMHO would be: 1) clearly identifying what backend and frontend mean and where the separation occurs. I worry (perhaps without substance) that the definition may vary from port to port. 2) general logistics of actually lopping off huge parts of existing WebKit code and refactoring them in-flight. But I totally think we (you) are up to the challenge :) :DG On Tue, Apr 28, 2009 at 5:05 PM, Jeremy Orlow jor...@chromium.org wrote: Yes, yes, I know this is a horrible idea, but please hear me out :-) Last week, a couple of us (Darin F, Michael N, Jeremy M, and I) had lunch at Apple to talk to talk about sharing more code. HTML 5 brings with it a lot of APIs that reach outside of the top level browsing context boundary (i.e. the render process boundary in Chromium). We talked specifically about localStorage and appCache. Although I believe the following generalizes well for any such API, I recognize that there are some unique constraints for stuff like databases...so I'm not even going to talk about them right now. Anyhow... For a while now, I've looked at a bunch of ways to make localStorage multi-process aware, but really none of them have any hope except one: splitting localStorage into a frontend and backend. The frontend would be the portion in each renderer process that connects into the JS bindings. A single backend would store all the data and be shared by the frontends. Originally, my plan was to do this split and then write my own back end in the browser process, but there are several problems with this. From a technical standpoint, it's unclear how testing would work since our test_shell would be testing a different backend from what's in Chromium. It also means we have more code to maintain, and that code is completely off of WebKit's radar. It also makes Apple mad and Dimitri sad. So really, this doesn't seem like a good solution. Assuming the only viable solution is having several frontends talking to one backend (I'm confident this is true) and assuming having our own backend is not viable (this also seems true), then the only choice is for us to use the WebCore backend. We can't run this in any renderer process since the response times for browser-renderer communication are unbounded. So that leaves either the browser process or some browser helper process. Creating a helper process for the browser seems like a pretty interesting idea to me since there's already a lot of somewhat dangerous stuff running in the browser process. (The only thing I can remember right now is v8 for parsing .pac files, but I know there's more.) Basically, the helper process would be a sandboxed process where anything dangerous but not bound to a single renderer process would run. Ideally it would store little to no state so that the browser could easily restart it and resend any pending messages if it crashed. For localStorage, the backend (which is part of WebCore) would run there and all localStorage messages would be proxied through the browser process. The VFS could be used to retrieve file handles. The other option is to simply run part of WebCore's localStorage within the browser process. LocalStorage only depends on WTF, so this really isn't _that_ terrible of an idea. Thoughts? Anyhow, the WebKit guys we talked to like the idea of a split frontend/backend, especially if it means we'll continue sharing code. I believe Michael is going to be doing something similar for AppCache. 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: 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: Changes to FilePath?
Greg Spencer wrote: So there's currently no right way to do the conversion, but I still think that the FilePath constructor is probably in the best position to inspect LC_ALL, etc. and do as close to the right thing as possible. I doubt most Linux developers even think about this, and so the chances that they will implement anything other than assuming that it's ASCII are slim -- this would allow us to at least implement a baseline for them. Not doing the conversion is kinda the point. Well, it's exactly the point. (Hi, I'm the author of FilePath.) If you've got an arbitrary path, it might be encoded in some scheme, and it might not, and it might contain a mix of encodings. The point of FilePath is we know it's a path and we don't necessarily know anything else. Chromium didn't used to have FilePath. Everything was a wstring which implied UTF-16/32, and the conversions implied UTF-8 because we couldn't do anything smarter, and there was all sorts of potential for messing things up. Not a pretty story. When FilePath was born, the *Hack methods showed up to give us a way to transition the old-style wstring APIs to new-style FilePath APIs at reasonable cut points, instead of having to do everything all at once. I understand your problem. You're saying I have user-supplied data that I want to build a filename from, and I have this pathname that I want to display back to the user. I agree that it would be good to have a way to handle these cases in base. I don't know if FilePath proper is the right place to do it. If we do it in FilePath, it still won't really be right. If we had something, it should probably be made to operate only on single pathname components, and it should be the caller's responsibility to only deal with user-created names with this interface. 2) I'd like to make it possible to instantiate a POSIX FilePath object on Windows and a Windows FilePath on POSIX platforms. This is because some libraries (e.g. the zip library, or tar files), use POSIX semantics for their paths even on Windows (I haven't seen a use case for Windows paths on POSIX yet, actually). This would make it possible to use the nice API that FilePath has to manipulate paths appropriately for these other libraries. This could be easily accomplished by having POSIX and Windows versions of FilePath, and then typedef'ing FilePath differently on different platforms to one of these versions. Sounds pretty Pythonic. FilePath already sort of has some support for this - it does a bunch of things based on feature macros, mostly so that as I was writing it, I could test the Windows semantics without having to (shudder) resort to running on Windows. These could probably be adapted to do what you're asking. 3) It would be helpful to have real path normalization for each of the platforms (although I know what a testing nightmare that can be). I might try and tackle this if people think it would be beneficial. It's also a specification and implementation nightmare. Everyone has a different idea of what normalization means. What's your idea? 4) Make sure we handle case sensitivity vs case preservation correctly. It's unclear to me that FilePath does this correctly on the Mac -- Mac file names are case preserving, but case insensitive, Unix filenames are both (and windows filenames are neither :-). Again with the normalization. What do you want this stuff for? What's your idea of how this should work? Remember: FilePath is specified to be light and to never touch the disk. If you've got a disk-touching operation, it probably doesn't belong in FilePath proper. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] API sprucing
I'll raise this again:
your js object that methods hang off should be called chrome not
chromium... we use chrome in all of our other API points
(chrome-ui:// and chrome-extensions:// protocol schemes, the user
agent string etc).
FYI - Chromium is the name of the project, not the product, and should
never appear in code. I should probably add this to the style guide on
dev.chromium.org!
-Ben
On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman a...@chromium.org wrote:
A few of us extension guys were talking offline Monday about how now
that we've all had a chance to implement some APIs, we are probably
better positioned to come to consensus on the remaining style points.
I went through the existing three browser APIs (windows, tabs, and
bookmarks -- http://dev.chromium.org/developers/design-documents/extensions)
and tried to identify all the places where they differ. I've also put
my vote for whether and how they should be aligned.
Let me know what you think...
Naming:
- We have chromium.windows.getWindows(),
chromium.windows.createWindow(), etc and chromium.bookmarks.get(),
chromium.bookmarks.create().
- My vote: I like chromium.bookmarks.create(). The downside to this is
that we can never put more than one primary object in a namespace, but
I'm OK with that. We should also change the event names to be like
onMove instead of onTabMoved.
Querying:
- We have getWindows(WindowQuery), getTabs(TabQuery), and
bookmarks.get(ids)+bookmarks.search(text).
- My vote: It doesn't look to me like there is a general solution
here. Searching for windows and tabs using multiple criterion
(WindowQuery, TabQuery) feels pretty hard to use to me. Doing so in
history feels more natural. Doing so for bookmarks is kinda in
between. I feel like for these we might want to do things that are
more optimized for the module in question. For example
windows.getTop(), windows.getCurrent(), bookmarks.getTree(), etc. I'll
start separate conversations for these, though.
Updating:
- We have bookmarks.setTitle(id, title) and windows.updateWindow({id,
top, left, width, height, ...})
- My vote. I like the single update method for objects that naturally
have lots of fields you can update. For bookmarks, for example, you
will eventually be able to update both url and title. It seems natural
to me to be able to do both at the same time. It also lends itself
well to batch operations, should we ever want to do that. I also
really like Rafael's idea to separate out the id parameter, so it
would look like windows.updateWindow(id, {top, left, width, height,
...}). This elegantly solves the problem of accidentally using an old
object and clobbering more recent state. If we do this, probably we
should also split out id in the move apis, to be consistent.
Update Event:
- Sometimes we pass old and new objects according to the docs, but I
think it will be difficult to actually do that.
- My vote: onUpdate(int id, {properties and values that changed}). The
second param would be an object containing the names of the properties
that changed and their new values.
Move Event:
- We have onBookmarkOrderChanged(int folderid, int[] newchildids) and
onTabMoved(int tabid, int windowid, int fromindex, int toindex)
- My vote: I think we should go with onTabMoved(int tabid, int
newindex). In other places we have assumed that the client is keeping
state, so this should be the same. We'd still send only one move event
and assume the client either understands the implied shuffling, or
will refetch the entire list. Question: Do we need to send fromIndex?
- 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: [extensions] API sprucing
That's fine. As I said before, As it appears that nobody else does
either, I'll make this a TODO to sweep through and fix.
- a
On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google) b...@chromium.org wrote:
I'll raise this again:
your js object that methods hang off should be called chrome not
chromium... we use chrome in all of our other API points
(chrome-ui:// and chrome-extensions:// protocol schemes, the user
agent string etc).
FYI - Chromium is the name of the project, not the product, and should
never appear in code. I should probably add this to the style guide on
dev.chromium.org!
-Ben
On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman a...@chromium.org wrote:
A few of us extension guys were talking offline Monday about how now
that we've all had a chance to implement some APIs, we are probably
better positioned to come to consensus on the remaining style points.
I went through the existing three browser APIs (windows, tabs, and
bookmarks -- http://dev.chromium.org/developers/design-documents/extensions)
and tried to identify all the places where they differ. I've also put
my vote for whether and how they should be aligned.
Let me know what you think...
Naming:
- We have chromium.windows.getWindows(),
chromium.windows.createWindow(), etc and chromium.bookmarks.get(),
chromium.bookmarks.create().
- My vote: I like chromium.bookmarks.create(). The downside to this is
that we can never put more than one primary object in a namespace, but
I'm OK with that. We should also change the event names to be like
onMove instead of onTabMoved.
Querying:
- We have getWindows(WindowQuery), getTabs(TabQuery), and
bookmarks.get(ids)+bookmarks.search(text).
- My vote: It doesn't look to me like there is a general solution
here. Searching for windows and tabs using multiple criterion
(WindowQuery, TabQuery) feels pretty hard to use to me. Doing so in
history feels more natural. Doing so for bookmarks is kinda in
between. I feel like for these we might want to do things that are
more optimized for the module in question. For example
windows.getTop(), windows.getCurrent(), bookmarks.getTree(), etc. I'll
start separate conversations for these, though.
Updating:
- We have bookmarks.setTitle(id, title) and windows.updateWindow({id,
top, left, width, height, ...})
- My vote. I like the single update method for objects that naturally
have lots of fields you can update. For bookmarks, for example, you
will eventually be able to update both url and title. It seems natural
to me to be able to do both at the same time. It also lends itself
well to batch operations, should we ever want to do that. I also
really like Rafael's idea to separate out the id parameter, so it
would look like windows.updateWindow(id, {top, left, width, height,
...}). This elegantly solves the problem of accidentally using an old
object and clobbering more recent state. If we do this, probably we
should also split out id in the move apis, to be consistent.
Update Event:
- Sometimes we pass old and new objects according to the docs, but I
think it will be difficult to actually do that.
- My vote: onUpdate(int id, {properties and values that changed}). The
second param would be an object containing the names of the properties
that changed and their new values.
Move Event:
- We have onBookmarkOrderChanged(int folderid, int[] newchildids) and
onTabMoved(int tabid, int windowid, int fromindex, int toindex)
- My vote: I think we should go with onTabMoved(int tabid, int
newindex). In other places we have assumed that the client is keeping
state, so this should be the same. We'd still send only one move event
and assume the client either understands the implied shuffling, or
will refetch the entire list. Question: Do we need to send fromIndex?
- 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: [extensions] API sprucing
On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google) b...@chromium.org wrote: I'll raise this again: your js object that methods hang off should be called chrome not chromium... we use chrome in all of our other API points (chrome-ui:// and chrome-extensions:// protocol schemes, the user agent string etc). FYI - Chromium is the name of the project, not the product, and should never appear in code. I should probably add this to the style guide on dev.chromium.org! It might be worth bringing this up as a top-level thread, as it's news to me. Not that I disagree, but grepping for chromium in the code indicates it might be a surprise to others. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Today we run zero LayoutTests in chrome
We're still using the test-shell to run the LayoutTests.I just fixed a bug, wrote a layout test, and then realized how dumb I was because the code I was testing was only in Chrome, and not in the test_shell. I think we're accumulating a lot of code that is chrome specific, but which could effect rendering and layout. In my case, I'm working on v8 extensions that have been put into the browser, but there is tons of code which differs between chrome and test shell. Not having layout tests for chrome itself is making me a bit nervous. 2 Questions: 1) Any plans already underway to run chrome rather than test_shell through the Layout Tests? 2) Should we create those plans :-) Cheers, Mike --~--~-~--~~~---~--~~ 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: Today we run zero LayoutTests in chrome
On Wed, Apr 29, 2009 at 14:05, Mike Belshe mbel...@google.com wrote: We're still using the test-shell to run the LayoutTests.I just fixed a bug, wrote a layout test, and then realized how dumb I was because the code I was testing was only in Chrome, and not in the test_shell. I think we're accumulating a lot of code that is chrome specific, but which could effect rendering and layout. In my case, I'm working on v8 extensions that have been put into the browser, but there is tons of code which differs between chrome and test shell. Not having layout tests for chrome itself is making me a bit nervous. 2 Questions: 1) Any plans already underway to run chrome rather than test_shell through the Layout Tests? No. 2) Should we create those plans :-) Based on the response to this thread, sounds like yes. I filed a bug. I don't know what's involved to support running layout tests effectively in the browser itself. If you have an idea of what needs to be done, please update http://bugs.chromium.org/11186. Cheers, Mike --~--~-~--~~~---~--~~ 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: [extensions] API sprucing
I said this back when we set up the Chromium project before launching the public beta. We deliberately decided not to change any of the code (see all our include lines that start with CHROME_ or chrome/ etc.) There should be no difficulty or careful judgment to be made here. It's very simple. In code, it's chrome. The emphasis is always on consistency in google coding style. It seems any time a legal department is involved in something the failplane takes off -_-. -Ben On Wed, Apr 29, 2009 at 2:04 PM, Evan Martin e...@chromium.org wrote: On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google) b...@chromium.org wrote: I'll raise this again: your js object that methods hang off should be called chrome not chromium... we use chrome in all of our other API points (chrome-ui:// and chrome-extensions:// protocol schemes, the user agent string etc). FYI - Chromium is the name of the project, not the product, and should never appear in code. I should probably add this to the style guide on dev.chromium.org! It might be worth bringing this up as a top-level thread, as it's news to me. Not that I disagree, but grepping for chromium in the code indicates it might be a surprise to others. --~--~-~--~~~---~--~~ 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: Today we run zero LayoutTests in chrome
The more I think about this, the more trouble we might be in :-) Page cyclers are also misleading as they test Test Shell, not Chrome. To illustrate I ran a few tests with the moz page cycler: Test-shell: 29.41 Chrome default: 37.43 Chrome w/ Extensions and Web Workers 39.41// these are not enabled yet. Chrome w/o chrome-specific v8 extensions: 36.35 Conclusions: * Chrome is 27% slower than test shell. We knew this. * When we turn on extensions and web workers, Chrome will regress by 5.3%. This would not be detected by our automated tests. * We already have a 3% hit due to using v8 extensions (Interval, CSI, etc) which we hadn't detected via automation. Mike On Wed, Apr 29, 2009 at 2:18 PM, Mark Larson (Google) m...@chromium.orgwrote: On Wed, Apr 29, 2009 at 14:05, Mike Belshe mbel...@google.com wrote: We're still using the test-shell to run the LayoutTests.I just fixed a bug, wrote a layout test, and then realized how dumb I was because the code I was testing was only in Chrome, and not in the test_shell. I think we're accumulating a lot of code that is chrome specific, but which could effect rendering and layout. In my case, I'm working on v8 extensions that have been put into the browser, but there is tons of code which differs between chrome and test shell. Not having layout tests for chrome itself is making me a bit nervous. 2 Questions: 1) Any plans already underway to run chrome rather than test_shell through the Layout Tests? No. 2) Should we create those plans :-) Based on the response to this thread, sounds like yes. I filed a bug. I don't know what's involved to support running layout tests effectively in the browser itself. If you have an idea of what needs to be done, please update http://bugs.chromium.org/11186. Cheers, Mike --~--~-~--~~~---~--~~ 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: Today we run zero LayoutTests in chrome
Whoops - I was wrong on this. page cycler tests on the bbots do run chrome now. Bug on making v8::extensions less costly is http://crbug.com/11189 Mike On Wed, Apr 29, 2009 at 3:02 PM, Mike Belshe mbel...@google.com wrote: The more I think about this, the more trouble we might be in :-) Page cyclers are also misleading as they test Test Shell, not Chrome. To illustrate I ran a few tests with the moz page cycler: Test-shell: 29.41 Chrome default: 37.43 Chrome w/ Extensions and Web Workers 39.41// these are not enabled yet. Chrome w/o chrome-specific v8 extensions: 36.35 Conclusions: * Chrome is 27% slower than test shell. We knew this. * When we turn on extensions and web workers, Chrome will regress by 5.3%. This would not be detected by our automated tests. * We already have a 3% hit due to using v8 extensions (Interval, CSI, etc) which we hadn't detected via automation. Mike On Wed, Apr 29, 2009 at 2:18 PM, Mark Larson (Google) m...@chromium.orgwrote: On Wed, Apr 29, 2009 at 14:05, Mike Belshe mbel...@google.com wrote: We're still using the test-shell to run the LayoutTests.I just fixed a bug, wrote a layout test, and then realized how dumb I was because the code I was testing was only in Chrome, and not in the test_shell. I think we're accumulating a lot of code that is chrome specific, but which could effect rendering and layout. In my case, I'm working on v8 extensions that have been put into the browser, but there is tons of code which differs between chrome and test shell. Not having layout tests for chrome itself is making me a bit nervous. 2 Questions: 1) Any plans already underway to run chrome rather than test_shell through the Layout Tests? No. 2) Should we create those plans :-) Based on the response to this thread, sounds like yes. I filed a bug. I don't know what's involved to support running layout tests effectively in the browser itself. If you have an idea of what needs to be done, please update http://bugs.chromium.org/11186. Cheers, Mike --~--~-~--~~~---~--~~ 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: Changes to FilePath?
On Wed, Apr 29, 2009 at 12:22 PM, Mark Mentovai m...@chromium.org wrote: I understand your problem. You're saying I have user-supplied data that I want to build a filename from, and I have this pathname that I want to display back to the user. I agree that it would be good to have a way to handle these cases in base. I don't know if FilePath proper is the right place to do it. If we do it in FilePath, it still won't really be right. OK, so it sounds like you're telling me not to use FilePath to represent file paths from a disk for my purposes because they can't ever be converted reliably to a particular encoding on Linux (which is a requirement for me, because of the third party libraries that require a particular encoding). That's fine, but what do I do instead? Roll my own FilePath clone that has some encoding assumptions? I can do that, but it has the same issues as the ones you're worried about with FilePath, so it seems better to solve the issue in one place rather than have two versions that are both insufficient. Man, it would be better if FilePath could reliably know its encoding! (I realize that Linux makes this impossible, it just seems like it would be better that way. :-) Since Linux is the only platform where the encoding is unclear, what if we did the best we could on Linux: When constructing a FilePath from a char* string on Linux: - Test the input string for values 127 to determine if it's really just ASCII (and if so, we're out of the woods). - Then check LANG, LC_CTYPE, LC_ALL (through appropriate Linux APIs) for an encoding that we can support, and note the encoding for later if we are requested to do a conversion. - If we run into an invalid sequence during a conversion, or an encoding we can't convert from, then use a CHECK to crash. This should work on most filenames, in almost all situations -- I'll bet most filenames are ASCII, even on foreign systems, and the ones that aren't ASCII have set LANG to something in /etc/profile, so all filenames created by any app running on that machine should match that encoding. Where they don't do that correctly, they're already getting garbage (and should expect garbage) from any application they use, not just Chrome, since there is no way *any *app can decode a path with multiple encodings in it, or where the encoding is different than LANG (or LC_*) says it is. Chrome already crashes like this when it encounters situations where it's just impossible to know what's right, so it's consistent with Chrome's behavior in other areas. it should be the caller's responsibility to only deal with user-created names with this interface. What do you mean here? Isn't that the case now with FilePath? (It's the file_util routines that actually read the filesystem and make FilePaths out of them, afterall). As for your suggestion to only deal with path components, how would you propose to parse user-supplied paths into one of these? 2) I'd like to make it possible to instantiate a POSIX FilePath object on Windows and a Windows FilePath on POSIX platforms. This is because some libraries (e.g. the zip library, or tar files), use POSIX semantics for their paths even on Windows (I haven't seen a use case for Windows paths on POSIX yet, actually). This would make it possible to use the nice API that FilePath has to manipulate paths appropriately for these other libraries. This could be easily accomplished by having POSIX and Windows versions of FilePath, and then typedef'ing FilePath differently on different platforms to one of these versions. Sounds pretty Pythonic. FilePath already sort of has some support for this - it does a bunch of things based on feature macros, mostly so that as I was writing it, I could test the Windows semantics without having to (shudder) resort to running on Windows. These could probably be adapted to do what you're asking. Cool. 3) It would be helpful to have real path normalization for each of the platforms (although I know what a testing nightmare that can be). I might try and tackle this if people think it would be beneficial. It's also a specification and implementation nightmare. Everyone has a different idea of what normalization means. What's your idea? Yes, I know it's a nightmare all around, but I think it would be useful to have something that addresses this. My idea would be the same as Python's os.path.normpath, mainly because it's a well-tested, seasoned example with test cases. Windows also has a routine for this (PathCanonicalize) that could be used (but I know it doesn't work for UNC paths). 4) Make sure we handle case sensitivity vs case preservation correctly. It's unclear to me that FilePath does this correctly on the Mac -- Mac file names are case preserving, but case insensitive, Unix filenames are both (and windows filenames are neither :-). Again with the normalization. What do you want this stuff for? What's your
[chromium-dev] Some help with Layout Test regressions
Hi, Today's WebKit merge (42932:42994 - http://trac.webkit.org/changeset?new=42...@trunkold=42...@trunk) has brought in some new regressions. If anyone has any spare cycles I'd really appreciate it if you might be able to look at these - http://crbug.com/11178: xss stuff: LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-addEventListener.html LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-shortcut.html LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-addEventListener.html LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-shortcut.html LayoutTests/http/tests/security/listener/xss-window-onclick-addEventListener.html LayoutTests/http/tests/security/listener/xss-window-onclick-shortcut.html chrome/http/tests/security/listener/xss-inactive-closure.html LayoutTests/http/tests/security/xss-eval.html and: DEBUG WIN : LayoutTests/transitions/repeated-firing-background-color.html = FAIL MAC : LayoutTests/fast/dom/Document/open-with-pending-load.html = CRASH Thanks, Jeremy --~--~-~--~~~---~--~~ 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: Some help with Layout Test regressions
There's a change to DOMWindow.idl, which pretty much always warrants a clobber on Win builds. I just clobbered WebKit builder, let's see what happens. :DG On Wed, Apr 29, 2009 at 4:11 PM, Jeremy Moskovich jer...@chromium.org wrote: Hi, Today's WebKit merge (42932:42994 - http://trac.webkit.org/changeset?new=42...@trunkold=42...@trunk) has brought in some new regressions. If anyone has any spare cycles I'd really appreciate it if you might be able to look at these - http://crbug.com/11178: xss stuff: LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-addEventListener.html LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-shortcut.html LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-addEventListener.html LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-shortcut.html LayoutTests/http/tests/security/listener/xss-window-onclick-addEventListener.html LayoutTests/http/tests/security/listener/xss-window-onclick-shortcut.html chrome/http/tests/security/listener/xss-inactive-closure.html LayoutTests/http/tests/security/xss-eval.html and: DEBUG WIN : LayoutTests/transitions/repeated-firing-background-color.html = FAIL MAC : LayoutTests/fast/dom/Document/open-with-pending-load.html = CRASH Thanks, Jeremy --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Improving build time on Linux
I was greatly disheartened when I set up a build environment on my Linux box and realized it takes 36 seconds for scons to figure out nothing has changed. After talking with Stephen he suggested the following command line: hammer --implicit-conversion app LOAD=app,browser This dropped the time it takes scons to figure out nothing has changed from 36 seconds to 6 seconds. Much more livable. Caveats: this won't pick up changes you make to files outside of browser, you'll need to modify the arguments to LOAD appropriately. I've updated the Wiki with this information. -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Tech talk videos
Just wanted to let everyone know that we posted videos of 5 tech talks related to Chromium. There's a blog post on the Chromium Blog ( http://blog.chromium.org/2009/04/chromium-tech-talks.html), but here are some direct links: Darin Fisher http://www.youtube.com/watch?v=A0Z0ybTCHKs talking about Chromium's multi-process architecture Brett Wilson http://www.youtube.com/watch?v=IiN9fxwjcL0 talking about the various layers of Chromium Dimitri Glazkov http://www.youtube.com/watch?v=QND2lFCrIGw talking about hacking on WebKit Ben Goodger http://www.youtube.com/watch?v=WsvNebq1dRg talking about Views (and how to write good tests for them) Wan-Teh Chang and Eric Roman http://www.youtube.com/watch?v=ZhDb42M6ZLk talking about Chromium's network stack (and its history) A big thanks to all the presenters who did the hard work. :-) 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: depricating CppBindingClass
Hi All, I'm excited about using v8::Extension instead of CppBoundClass but the JavaScript side of v8::Extension (via the |source| argument) seems a bit magical to me. Is there a document that explains the usage and capabilities of v8::Extension in greater detail? I have the following questions so far: 1. Can native functions be called directly by a renderer-loaded script, or must calls to them always be wrapped within |source|-defined JS objects/functions? 2. Are there any limits in scope or size to what can be done within a |source|-defined script? 3. Is there a way to specify native getter/setter functions for a property defined on the JS side? For instance, myobject.foo = bar would somehow call a natively defined setFoo function with the bar argument. If this isn't possible, are there any plans to support native properties directly? Thanks, Marshall On Tue, Apr 28, 2009 at 9:39 PM, Mike Belshe mbel...@google.com wrote: Yup. I am not saying we need to get rid of all of it immediately; just put some comments in the header so that we don't use it *more*. Mike On Tue, Apr 28, 2009 at 6:38 PM, Feng Qian fq...@google.com wrote: CppBindingClass was started for test_shell if I remember correctly, and I think the functionality can be replaced by using NPAPI instead. I had an implementation of replacing CppBindingClass by NPAPI in test_shell (to avoid two implementations for JSC and V8), I don't remember where the code went. On Tue, Apr 28, 2009 at 6:15 PM, Mike Belshe mbel...@google.com wrote: I've felt this way for a while, and I figured I'd throw it out to see if we all agree. I'm hoping we can deprecate CppBindingClass. At this point, most extensions are better served (I think!) via the v8::extension facility than the CppBindingObject. If there are cases where this isn't true, I'd happily work on v8::extension to make it so it could be. If nobody objects, I hope we can agree to stop adding any new CppBindingClass based bindings, and then over time get rid of CppBindingObject altogether. Anyone feel strongly in opposition? Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
