[chromium-dev] Re: Sandbox Interception Design
I'd like to better understand how the interception mechanism works. Is it using IAT rewriting? On Mar 27, 2:18 pm, Ricardo Vargas wrote: > I guess we'll have to update the documentation with a few things that were > left behind. > In the mean time, do you have something specific in mind? > > On Fri, Mar 27, 2009 at 1:59 PM, Brett Wilson wrote: > > > On Fri, Mar 27, 2009 at 1:50 PM, Book'em Dano > > wrote: > > > > At the top of sandbox\src\interception.h, it refers the reader to: > > >http://wiki/Main/ChromeSandboxInterceptionDesign. Does anyone know > > > where this document can be found? > > > > The sandbox info on > >http://dev.chromium.org/developers/design-documents/sandbox > > > is too high level...I want to find out more details about the > > > interception framework and design. > > > The internal doc is the same as the external one you found, so there > > probably isn't one more detailed (but I don't know for sure). > > > Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: external DNS queries in tests
Great, thanks for doing this!
(By the way, I had once upon a time filed
http://code.google.com/p/chromium/issues/detail?id=2635 to track this
issue.)
-Darin
On Fri, Mar 27, 2009 at 12:08 PM, Paweł Hajdan Jr.
wrote:
> I recently checked in a change after which making external DNS lookup
> (directly or indirectly) will make the test fail (so it's really hard to
> ignore). By external I mean everything except 127.0.0.1 and localhost.
>
> I added that check to chrome_test_suite.h, so unit_tests are affected, as
> well as ui_tests, interactive_ui_tests etc. When a test executable launches
> a chrome executable, only the test executable is covered by the check.
>
> When you encounter a problem with that, you have three choices:
>
> a) don't make that lookup (sometimes easy, sometimes not)
> b) simulate a failed lookup
> c) allow that lookup (it will be passed to the dns resolver, and the test
> will pass)
>
> For options b) and c), the general pattern is like this (real example):
>
> #include "net/base/host_resolver_unittest.h"
>
> // InProcessBrowserTest is not necessary; can be testing::Test just as well
> class BrowserFocusTest : public InProcessBrowserTest {
> public:
> BrowserFocusTest() {
> host_mapper_ = new net::RuleBasedHostMapper();
> // TODO(phajdan.jr): Don't make a real dns lookup here.
> // page_with_focus.html has a reference to google.com.
> host_mapper_->AllowDirectLookup("*.google.com"); // To simulate a
> failure use AddSimulatedFailure instead
> scoped_host_mapper_.Init(host_mapper_.get());
> ... snip ...
> }
>
> private:
> scoped_refptr host_mapper_;
> net::ScopedHostMapper scoped_host_mapper_;
> };
>
> >
>
--~--~-~--~~~---~--~~
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: Sandbox Interception Design
Who wants to rubber-stamp http://codereview.chromium.org/55043 for me? :) On Fri, Mar 27, 2009 at 2:18 PM, Ricardo Vargas wrote: > I guess we'll have to update the documentation with a few things that were > left behind. > In the mean time, do you have something specific in mind? > > On Fri, Mar 27, 2009 at 1:59 PM, Brett Wilson wrote: >> >> On Fri, Mar 27, 2009 at 1:50 PM, Book'em Dano >> wrote: >> > >> > At the top of sandbox\src\interception.h, it refers the reader to: >> > http://wiki/Main/ChromeSandboxInterceptionDesign. Does anyone know >> > where this document can be found? >> > >> > The sandbox info on >> > http://dev.chromium.org/developers/design-documents/sandbox >> > is too high level...I want to find out more details about the >> > interception framework and design. >> >> The internal doc is the same as the external one you found, so there >> probably isn't one more detailed (but I don't know for sure). >> >> Brett >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging
I would take this a step further actually. We just generally won't be able to compute useful statistics from the test runner. We'll only be able to give the total, raw numbers of fail/skip/pass/timeout/crash and we can subtract out the WONTFIX tests that we never intend to fix. But we won't have any numbers of tests we intend to fix for a given release. So, in order to get useful numbers of tests we need to fix, we would need to look at the bug tracker. Seems to me that all bugs filed for layout tests should have a LayoutTest label in the bug tracker so we can track them easily. Ojan On Thu, Mar 26, 2009 at 6:27 PM, Pam Greene wrote: > I take it back: there's one additional disadvantage. With no DEFER, we > won't be able to use the layout-test report directly to say what percentage > of "tests that we want to pass for the next release" we pass. Instead, we'll > have to take one number from that report and one number (searching on > priority/milestone) from the code tracker. > > If the people who do that regularly (Jon?) are happy with that, then I have > no problem with it. > > - Pam > > > On Thu, Mar 26, 2009 at 3:45 PM, Ojan Vafai wrote: > >> This matches my understanding. As a transition plan, I'm thinking to >> replace DEFER with UNTRIAGED. That way there is a way we can keep from >> adding 400 "this test has no bug id" warnings until we add bugs for all the >> currently deferred tests. >> Ojan >> >> >> On Thu, Mar 26, 2009 at 3:28 PM, Pam Greene wrote: >> >>> Just to make sure I understand correctly, the model here is that each >>> test has a BUG12345 note, possibly shared with other tests. But it doesn't >>> have a name or priority, not even the (ambiguous) priority implied by DEFER, >>> directly in the list. Instead, we use the bug tracker to track all that, >>> that being what it as designed for, after all. >>> >>> Sounds good to me. I can think of several advantages to this plan not >>> listed in your original email, and no additional disadvantages. (And as for >>> the overhead of filing and closing bugs for a rebaseline, if it's clear a >>> priori that that's all that's needed, you can always choose to do the >>> rebaseline instead.) >>> >>> The merger, or whoever is adding a test to the list, should still be >>> responsible for a preliminary investigation. Bug reports should be more than >>> "test a/b/c.html is failing". At a minimum, "started failing in r34567"; >>> better, a sentence or two such as "started failing in r34567, which looks >>> like David's change to the zorkmid system", or "new test in r34567, will >>> fail until we implement FrobozzClient". (So any script that does this >>> should ask for a description, not just file a bare bug.) >>> >>> - Pam >>> >>> >>> On Wed, Mar 25, 2009 at 4:00 PM, Ojan Vafai wrote: >>> Just want to make sure everyone sees this. Please voice yourself now if you care about layout test fixing process and about managing test list process. I'll give another day. Unless I hear objections, I'll make run_webkit_tests do option 3. I'm not quite sure how we transition from the current world with no bug ids to a future world with a bug id for each test, but I'll figure that out. Ojan On Wed, Mar 25, 2009 at 3:51 PM, David Levin wrote: > We could go with option 3 until someone is annoyed enough by the > overhead to write a script. :) > > > > On Tue, Mar 24, 2009 at 4:19 PM, Ojan Vafai wrote: > >> OK. So, what I'm hearing is that every test should have a bug assigned >> to it, no matter the priority. In that case, there's a couple other >> options. >> >> *Option 3* >> Get rid of DEFER and don't add priorities to the test list. Instead >> require that every test have an associated bug (multiple tests can share >> a >> bug) and rely on the bug priority/owner to figure out when the test needs >> fixing and who is responsible for fixing it. >> Pros: >> -Works with our current bug triage process (kind of) >> -Makes for one easy place that people need to look for their todo list >> (the google code issue tracker) >> Cons: >> -Overhead of filing and closing bugs when the common case is just a >> rebaseline anyways >> -Hard to triage layout tests without understanding what's wrong with >> them >> >> *Option 4* >> Same as option 3, except we have a script that monitors the test list >> and automatically files a bug whenever a new test appears. The subject of >> the test is just the path listed in the test list, so the test can be >> found >> by searching the issue tracker. Similarly, when a test is removed from >> the >> test list, the bug is automatically closed. >> >> This has the same pros and cons as option 3 except that it totally >> removes the overhead associated with having a bug for each test path. >> Also, >> this would requ
[chromium-dev] Re: Sandbox Interception Design
I guess we'll have to update the documentation with a few things that were left behind. In the mean time, do you have something specific in mind? On Fri, Mar 27, 2009 at 1:59 PM, Brett Wilson wrote: > > On Fri, Mar 27, 2009 at 1:50 PM, Book'em Dano > wrote: > > > > At the top of sandbox\src\interception.h, it refers the reader to: > > http://wiki/Main/ChromeSandboxInterceptionDesign. Does anyone know > > where this document can be found? > > > > The sandbox info on > http://dev.chromium.org/developers/design-documents/sandbox > > is too high level...I want to find out more details about the > > interception framework and design. > > The internal doc is the same as the external one you found, so there > probably isn't one more detailed (but I don't know for sure). > > Brett > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Views and Linux
After further discussion, the Linux team feels strongly that the best approach for building Google Chrome on Linux is to stay the course with a solution using gtk for layout, so that's what they'll do. As a refinement to this, there will not be any attempts to refactor views code to share with the gtk front end unless the Mac engineers would also find such a refactoring to be useful. -Ben On Sat, Mar 21, 2009 at 5:57 PM, Ben Goodger (Google) wrote: > Summary: > > The Google Chrome team should build the Linux front end for Google > Chrome using Views and Gtk rather than using Gtk alone. > > Operational Details > > This week, Elliot will continue to stub out some of the basic widget > and top level window framework. I will continue vacuuming some of the > other constructs we have (NativeControl and a few things in browser/). > I've put together a basic work list that will bring almost everything > up under the label "views-linux": > http://code.google.com/p/chromium/issues/list?q=label:views-linux > Feel free to sign up for aspects that you're interested in working on. > > Rationale > > From a product perspective, the Google Chrome leadership has a strong > desire to have the browser that Google delivers as "Google Chrome" > share the clearly identifiable aesthetic of Chrome on other platforms. > > On MacOS it is possible to do this while blending in fairly well with > the surrounding environment. The prototypes that Cole has been > building and that have been making their way into the Mac ToT bear > this out. On Linux, the variety of window managers in use mean that to > achieve our unique skyline, in all likelihood the window manager frame > would have to be disabled and we would provide our own. Because there > isn't a consistent window manager appearance, there's no stable target > for what the browser frame and hence UI (which derives its appearance > from the frame) should look like. Because of this, the Linux team has > been copying the Windows UI appearance using Gtk and friends for the > widgets, layout and rendering. > > It's my opinion that the engineering work in doing this is not worth > it considering the tradeoffs: > > - It requires maintaining a front end that looks identical to Windows > but which has entirely different code, which includes writing a new > custom layout and event propagation system for things like the > TabStrip, where one already exists on Windows. > - Regardless of whether the underlying browser UI were implemented > entirely in Gtk using its own layout system or with a combination of > Gtk+views, it's likely that there'll be a number of Linux users who > don't like what we produce because to get the "Chrome look" we will > have to disable the frame and use non-standard button appearances. > > For these reasons I think the best investment of time is to bring up > Views so that we can share code with Windows. We will retain Gtk > widgets everywhere where the Windows front end uses Windows Common > Controls - for native buttons, checkboxes, text fields, some menus, > etc - so that we don't need to roll our own IME or accessibility. > Views is used to provide the containing layout engine and custom > rendering system. > > Over the past week Elliot and I have been investigating bringing up > the the base elements of the Views system on Linux. I had some reason > to believe that it may be easier to do so now since over the past > month or so I've made some improvements to the views::Window class > hierarchy that simplifies the arrangement considerably. From the work > Elliot's been able to do, I believe it should be possible to bring up > Views widgets relatively easily. I am investing time in helping clear > the path in the Views code to do so (See my earlier emails about > native controls). > > What this means for Gtk-only and Qt: > > I am actually very supportive of Gtk- and Qt-only front ends. I am > supportive of them not looking like Chrome if it means they fit in > better with the GNOME and KDE environments. I would love to see the > Chromium project deliver (and host the source of) something that each > of those environments feel is worthy of being a first class browser > for their system. This work should not be encumbered by having to have > Chrome's exact aesthetic. My comments above are related to where I > think the efforts of the Google development team's effort should be > directed at this time. > > -Ben > --~--~-~--~~~---~--~~ 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: Sandbox Interception Design
On Fri, Mar 27, 2009 at 1:50 PM, Book'em Dano wrote: > > At the top of sandbox\src\interception.h, it refers the reader to: > http://wiki/Main/ChromeSandboxInterceptionDesign. Does anyone know > where this document can be found? > > The sandbox info on > http://dev.chromium.org/developers/design-documents/sandbox > is too high level...I want to find out more details about the > interception framework and design. The internal doc is the same as the external one you found, so there probably isn't one more detailed (but I don't know for sure). Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Sandbox Interception Design
At the top of sandbox\src\interception.h, it refers the reader to: http://wiki/Main/ChromeSandboxInterceptionDesign. Does anyone know where this document can be found? The sandbox info on http://dev.chromium.org/developers/design-documents/sandbox is too high level...I want to find out more details about the interception framework and design. Thanks, D --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] external DNS queries in tests
I recently checked in a change after which making external DNS lookup
(directly or indirectly) will make the test fail (so it's really hard to
ignore). By external I mean everything except 127.0.0.1 and localhost.
I added that check to chrome_test_suite.h, so unit_tests are affected, as
well as ui_tests, interactive_ui_tests etc. When a test executable launches
a chrome executable, only the test executable is covered by the check.
When you encounter a problem with that, you have three choices:
a) don't make that lookup (sometimes easy, sometimes not)
b) simulate a failed lookup
c) allow that lookup (it will be passed to the dns resolver, and the test
will pass)
For options b) and c), the general pattern is like this (real example):
#include "net/base/host_resolver_unittest.h"
// InProcessBrowserTest is not necessary; can be testing::Test just as well
class BrowserFocusTest : public InProcessBrowserTest {
public:
BrowserFocusTest() {
host_mapper_ = new net::RuleBasedHostMapper();
// TODO(phajdan.jr): Don't make a real dns lookup here.
// page_with_focus.html has a reference to google.com.
host_mapper_->AllowDirectLookup("*.google.com"); // To simulate a
failure use AddSimulatedFailure instead
scoped_host_mapper_.Init(host_mapper_.get());
... snip ...
}
private:
scoped_refptr host_mapper_;
net::ScopedHostMapper scoped_host_mapper_;
};
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Need to attach to chrome super early?
I was about to add a --browser-startup-dialog, because I wanted a chance to stop chrome as early as possible. This would have required changing chrome.exe, adding a flag, etc. Instead I peaked a bit at what currently happens, and I came up with this trick (Windows only). bash$ CHROME_CRASHED=1 CHROME_RESTART="yoz|start chrome?|RIGHT_TO_LEFT" ./chrome/Debug/chrome.exe This gives you a startup dialog really early in chrome.exe, and gives you a chance, for example, to inject a DLL into chrome. My example makes the English popup RIGHT_TO_LEFT, just to make sure that your coworkers know you're up to something gnarly. -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot to Linux: no gyp for you!
Linux gyp conversion isn't happening tonight--stymied by an execution problem preventing building libwebcore.a on the buildbot slaves (but not on desktop systems). I've reverted the initial buildbot changes and will re-open the tree shortly once things have cycled green. As you were, --SK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-reviews] A quick fix for Issue 2215....
Hi Elliot, Thank you for your response and analysis. My UI test just calls the SimulateOSKeyPress() function to send a keyboard event to a test page which contains a onkeydown event handler, and GetActiveTabTitle() to retrieve the tab name. Anyway, I'm going to divide this change into a code change and a test. When I confirm the test works on a try bot, I will send another review request. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/3/27 Elliot Glaysher : > I am not sure you can write a normal UI test that uses SimulateOS*. (I > know you can't do mouse clicks). This is because the windows screen > needs to be unlocked for those commands to work so it will appear to > pass locally but not on the buildbot. > > Perhaps this test should be in interactive_ui_tests, which is set up > for tests that simulate OS events? > > -- Elliot > > On Thursday, March 26, 2009, Hironori Bono (坊野 博典) wrote: >> >> Chromium-developers, >> >> Sorry for my stupid question. >> I'm writing a fix for Issue 2215 and its UI test to verify a DOM event >> sent when we press a VK_MENU key, which is uploaded into Rietveld >> (*1). Even though this UI test works fine on my PCs, it always fails >> on a try bot. >> >> (*1) http://codereview.chromium.org/42500/show >> >> To analyze the failure log listed below, it seems a DOM event is not >> sent to my onkeydown handler even when I send a keyboard event with a >> WindowProxy::SimulateOSKeyPress() call. >> Would it be possible to give me any hints why my UI test fails on a try bot? >> >> [--] 1 test from InputTest >> [ RUN ] InputTest.ModifierKeys >> ..\..\browser\input_uitest.cc(46): error: Value of: GetActiveTabTitle() >> Actual: L"KeyCode Test" >> Expected: L"SUCCEEDED" >> ..\..\browser\input_uitest.cc(46): error: Value of: GetActiveTabTitle() >> Actual: L"KeyCode Test" >> Expected: L"SUCCEEDED" >> ..\..\browser\input_uitest.cc(46): error: Value of: GetActiveTabTitle() >> Actual: L"KeyCode Test" >> Expected: L"SUCCEEDED" >> [ FAILED ] InputTest.ModifierKeys (61250 ms) >> [--] 1 test from InputTest (61250 ms total) >> >> Regards, >> >> Hironori Bono >> E-mail: hb...@chromium.org >> >> -- Forwarded message -- >> From: >> Date: Wed, Mar 25, 2009 at 10:31 PM >> Subject: Re: A quick fix for Issue 2215 >> To: hb...@chromium.org >> Cc: chromium-revi...@googlegroups.com >> >> >> With changes, lgtm. >> >> I don't know UI tests well, and don't know why this might fail. You >> might want to ask the list for their thoughts. >> >> >> http://codereview.chromium.org/42500/diff/28/2017 >> File chrome/browser/input_unittest.cc (right): >> >> http://codereview.chromium.org/42500/diff/28/2017#newcode1 >> Line 1: // Copyright (c) 2006-2008 The Chromium Authors. All rights >> reserved. >> Fix the copyright date; 2009. >> >> http://codereview.chromium.org/42500/diff/28/2017#newcode1 >> Line 1: // Copyright (c) 2006-2008 The Chromium Authors. All rights >> reserved. >> This file has a bad name. UI tests are named xxx_uitest.cc; see the >> vcproj to see examples. >> >> http://codereview.chromium.org/42500 >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
