[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

2009/6/26 Michael Nordman 

>
>
> 2009/6/25 Fumitoshi Ukai (鵜飼文敏) 
>
>> Thanks for review.
>>
>> 2009/6/25 Michael Nordman 
>>
>>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>>> to me.
>>> * A version of the diagram you have in the chrome doc would be nice in
>>> the webkit doc too.
>>>
>>
>> Sure.  I've added a diagram in webkit part.
>>
>>
>>> * Does WebSocketHandle really need to be refcounted. I know
>>> ResourceHandle is a refcounted object and this design looks modeled off of
>>> that (which may be why you've spec'd it this way). Unless your design
>>> actually needs refcounting on this class, you may be able to simplify things
>>> without it. From the looks of it, WebSocketChannel 'owns' the
>>> WebSocketHandle.
>>>
>>
>> Yes.  I missed to add public RefCounted as base class of
>> WebSocketHandle.
>>  Thanks.
>>
>
> I was suggesting that perhaps the WebSocketHandle does not need to be
> refcounted.
>

Oh, sorry.   I changed it to OwnPtr.


>
>>
>>
>>  > 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?
>

It looks something similar like HTTP request/response.
see  http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol more
details.

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?
>

Hmm, maybe we need to move construction of request in web socket handshake,
and verification of response  in web socket handshake.  Updated.

Thanks!
ukai


>
>
>
>>
>>
>> > 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] New waterfall mode for sheriffs

[Nicolas Sylvain]

Hello,
The console view is not the best for sheriffs since it does not show in
details the current state of the tree. The waterfall has always been better
for that.

But since our waterfall is really big, it can be hard to scroll all the time
and keep track of all the failures.

For that, I modified the current waterfall to have a mode to hide all the
green slaves. Only the slaves with failures are shown.

Link: http://build.chromium.org/buildbot/waterfall/waterfall?failures=1

This should help sheriffs to quickly see what builders they need to be
monitoring, and remind them that some of them are red, even though
they are usually completely
hidden on the far right of the waterfall.

A slave is present on this waterfall if :
- The last finished build was red.
- A step of the build in progress is red (This will eventually turn the
build red)
- The slave is offline.

Let me know if you have any comments/suggestions about this.

Thanks

Nicolas

--~--~-~--~~~---~--~~
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: how to judge layouttests' running result?

[Nico Weber]

I usually try to execute the regressing tests manually (most of the
time by just open the html file in test shell, sometimes you have to
start some local web server). If they pass, I tell myself that the
test is just flaky. If they still fail, I start debugging.

2009/6/25 David Jones :
> I have ran layouttests on Windows XP, and got a result as:
> Expected to fail, but passed (5):
>   LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html
>   LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html
>   LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html
>   LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html
>   LayoutTests/fast/encoding/invalid-UTF-8.html
> Expected to timeout, but passed (1):
>   LayoutTests/http/tests/security/credentials-in-referer.html
> Regressions: Unexpected failures (8):
>   LayoutTests/fast/css/css2-system-fonts.html = FAIL
>   LayoutTests/fast/dom/anchor-toString.html = FAIL
>   LayoutTests/fast/dom/java-applet-calls.html = FAIL
>   LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL
>
> LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht
> ml = FAIL
>   LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL
>   LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL
>   LayoutTests/plugins/embed-attributes-setting.html = FAIL
> Regressions: Unexpected timeouts (1):
>   LayoutTests/http/tests/security/originHeader/origin-header-for-https.html
> = TI
> MEOUT
> --
> => Tests to be fixed for the current release (786):
> 86 test cases (10.9%) Passed
> 364 test cases (46.3%) Skipped
> 289 test cases (36.8%) Text diff mismatch
> 191 test cases (24.3%) Simplified text diff mismatch
> 160 test cases (20.4%) Image mismatch
> 11 test cases (1.4%) Test timed out
> 6 test cases (0.8%) Test shell crashed
> 2 test cases (0.3%) No expected image found
> => Tests we want to pass for the current release (8984):
> 8271 test cases (92.1%) Passed
> 364 test cases (4.1%) Skipped
> 301 test cases (3.4%) Text diff mismatch
> 201 test cases (2.2%) Simplified text diff mismatch
> 164 test cases (1.8%) Image mismatch
> 12 test cases (0.1%) Test timed out
> 6 test cases (0.1%) Test shell crashed
> 2 test cases (0.0%) No expected image found
> => Tests to be fixed for a future release (0):
> => All tests (10884):
> 8753 test cases (80.4%) Passed
> 2130 test cases (19.6%) Skipped
> 411 test cases (3.8%) Text diff mismatch
> 302 test cases (2.8%) Simplified text diff mismatch
> 183 test cases (1.7%) Image mismatch
> 13 test cases (0.1%) Test timed out
> 6 test cases (0.1%) Test shell crashed
> 2 test cases (0.0%) No expected image found
> I don't know what it tells, am I passed the layouttests?
>
> There's also a layouttests in webkit, what's the relation between chrome's
> layouttest and webkit's layouttest? I think webkit's layouttest only run on
> Leopard.
>
>
> 
> 200万种商品,最低价格,疯狂诱惑你 >
>

--~--~-~--~~~---~--~~
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: how to judge layouttests' running result?

[Lei Zhang]

http://dev.chromium.org/developers/testing/webkit-layout-tests says:

./run_webkit_tests.sh LayoutTests/path/to/your/test.html
--full-results-html will produce a page including links to the
expected result, actual result, and diff.

Does that help?

2009/6/25 David Jones :
> I have ran layouttests on Windows XP, and got a result as:
> Expected to fail, but passed (5):
>   LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html
>   LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html
>   LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html
>   LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html
>   LayoutTests/fast/encoding/invalid-UTF-8.html
> Expected to timeout, but passed (1):
>   LayoutTests/http/tests/security/credentials-in-referer.html
> Regressions: Unexpected failures (8):
>   LayoutTests/fast/css/css2-system-fonts.html = FAIL
>   LayoutTests/fast/dom/anchor-toString.html = FAIL
>   LayoutTests/fast/dom/java-applet-calls.html = FAIL
>   LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL
>
> LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht
> ml = FAIL
>   LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL
>   LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL
>   LayoutTests/plugins/embed-attributes-setting.html = FAIL
> Regressions: Unexpected timeouts (1):
>   LayoutTests/http/tests/security/originHeader/origin-header-for-https.html
> = TI
> MEOUT
> --
> => Tests to be fixed for the current release (786):
> 86 test cases (10.9%) Passed
> 364 test cases (46.3%) Skipped
> 289 test cases (36.8%) Text diff mismatch
> 191 test cases (24.3%) Simplified text diff mismatch
> 160 test cases (20.4%) Image mismatch
> 11 test cases (1.4%) Test timed out
> 6 test cases (0.8%) Test shell crashed
> 2 test cases (0.3%) No expected image found
> => Tests we want to pass for the current release (8984):
> 8271 test cases (92.1%) Passed
> 364 test cases (4.1%) Skipped
> 301 test cases (3.4%) Text diff mismatch
> 201 test cases (2.2%) Simplified text diff mismatch
> 164 test cases (1.8%) Image mismatch
> 12 test cases (0.1%) Test timed out
> 6 test cases (0.1%) Test shell crashed
> 2 test cases (0.0%) No expected image found
> => Tests to be fixed for a future release (0):
> => All tests (10884):
> 8753 test cases (80.4%) Passed
> 2130 test cases (19.6%) Skipped
> 411 test cases (3.8%) Text diff mismatch
> 302 test cases (2.8%) Simplified text diff mismatch
> 183 test cases (1.7%) Image mismatch
> 13 test cases (0.1%) Test timed out
> 6 test cases (0.1%) Test shell crashed
> 2 test cases (0.0%) No expected image found
> I don't know what it tells, am I passed the layouttests?
>
> There's also a layouttests in webkit, what's the relation between chrome's
> layouttest and webkit's layouttest? I think webkit's layouttest only run on
> Leopard.
>
>
> 
> 200万种商品,最低价格,疯狂诱惑你 >
>

--~--~-~--~~~---~--~~
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/26 John Abd-El-Malek 

>
>
> 2009/6/25 Fumitoshi Ukai (鵜飼文敏) 
>
>> Thanks for review.
>>
>> 2009/6/25 Michael Nordman 
>>
>>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>>> to me.
>>> * A version of the diagram you have in the chrome doc would be nice in
>>> the webkit doc too.
>>>
>>
>> Sure.  I've added a diagram in webkit part.
>>
>>
>>> * Does WebSocketHandle really need to be refcounted. I know
>>> ResourceHandle is a refcounted object and this design looks modeled off of
>>> that (which may be why you've spec'd it this way). Unless your design
>>> actually needs refcounting on this class, you may be able to simplify things
>>> without it. From the looks of it, WebSocketChannel 'owns' the
>>> WebSocketHandle.
>>>
>>
>> Yes.  I missed to add public RefCounted as base class of
>> WebSocketHandle.
>>  Thanks.
>>
>>  > 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?
>>
>> > Regarding the "WebKit API", note that no WebCore data types can be used
>>> there. So you'll need to create wrapper classes.
>>>
>>
> The WebKit API classes still derive from WebCore, which isn't possible.
>  The WebKit API is an abstraction around WebCore classes, so it can't use
> any WebCore types in it.
>

Ah, Ok.  I updated WebKit API part not to use WebCore 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.
>>
>
> hmm, I actually find WebWeb very unwieldy.  I vote for
> WebKit::WebSocketHandle.
>

Ok.  will use WebKit:;WebSocketHandle.


Thanks!
ukai


>
>>
>>
>>>  * 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: Landing two sided patches

[Dimitri Glazkov]

Yes, we're working feverishly (is that a good word for this? :) to
make this situation a bit less hard.

However, in the meantime, the process could go like this:

1) Make sure the canary had a green run. This would really help the
WebKit gardener to know which revision to roll up to.

2) Land your patch upstream. There's no need to close the tree -- the
only thing you'll break is the canary bot.

3) Let the gardener to roll up to last green revision

4) In parallel, prepare a patch that rolls deps to your revision,
including your fix. Since the gardener's roll is green, you shouldn't
have any breakage. If you do, it's your fault :) <--- this is
basically the key to sanity. Don't land your one-revision roll if it
breaks your local compile.

5) Let the gardener land their patch

6) Sync and land your patch right after the gardener lands.

If you have more than one of these, rinse and repeat. I don't think it
is a good idea to land multiple breakages and then sort them out
downstream.

The situation is much muddier when you are already dealing with
multiple breakages upstream. That was the case early this week. In
this case, the gardener:

1) finds the breaking rev by studying the canary and trac.webkit.org,
2) checks that the rev before indeed builds, and sort out whatever
test regressions it may have locally
3) Lands the roll
4) Depending on the nature of the breakage, calls the expert. I am
working on a list that will include various parts of our port, but for
now you could just ping levin, darin, or me (in that order ;)
5) The expert will do a one-rev roll, fixing the breakage.

Basically, the idea is to let the gardener roll while green, and make
one-rev rolls/fixes for bustage.

For gardeners: I can not emphasize enough that it is *much* easier to
roll deps many times a day in small, green increments. Use the canary,
it'll tell you the revs that are safe to roll. Otherwise, you'll be
landing large swaths full of red and wonder at the fireworks in
amazement. Don't wait for the end of the day.

Another note: today, most of the layout test failures you'll see after
a merge are either new tests or changes in expectations that just need
rebaselining. The regressions should be rare and cause for alarm.
Please look at the tests, failing on the canary. Rebaseline or file
bugs if we're not passing for a good reason. Don't sweep them under
the test_expectations rug. It is *much* harder to dig through the
hundreds of lines of failures, trying to figure this out after the
fact.

Hope this helps. Sorry this is a bit too long, I am trying to get to
actually putting this in a more stable format, and this time is as
good as any.

:DG<

On Thu, Jun 25, 2009 at 4:46 PM, Darin Fisher wrote:
> I suspect there are things we can do that will avoid much of the need to do
> a Chromium side change in unison with a WebKit side change.  #1 is probably
> upstreaming some .gypi files so that the set of files to build can be stored
> in svn.webkit.org.  The WebKit API will also help, and completing the
> upstreaming of V8 is another biggie.
> -Darin
>
> On Thu, Jun 25, 2009 at 3:53 PM, Adam Langley  wrote:
>>
>> Dear Lords of the WebKit, I come to you seeking guidance about how
>> best to avoid the mess that the tree got into this afternoon.
>>
>> Japhet and I both had two sided patches to land (where one needs to
>> land both the WebKit and Chromium sides together). We emailed the
>> merger for the day (jianli) and asked him to email us when the merge
>> landed.
>>
>> He did so and I closed the tree. japhet and I both started landing
>> upstream. I landed r45191 and the Chromium side (including a large
>> DEPS roll) in r19287. japhet landed upstream in r45193 and r19291.
>>
>> The tree went red because V8IsolatedWorld had landed upstream in the
>> mean time and needed an include file changed because of japhet's
>> upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295).
>> However, that pulled in several other upstream patches, one of which
>> broke the build in another way! So I TBRed upstream to fix that
>> (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness
>> of keyboard, no other patches landed upstream in the mean time.
>>
>> In the past, for small patches, I've emailed the WebKit merger with
>> the patch to land. However, for larger patches, esp those which might
>> have conflicts, this seems unfortunate. It also breaks the SVN
>> log/blame for the future.
>>
>> How best to deal with this now that we pull directly from upstream?
>> Should I just have reverted Chromium at the first sign of trouble?
>>
>>
>> AGL
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Where is the CGContextDrawImage() for MacOSx defined

[Eric Roman]

CGContextDrawImage() is not defined in Chromium -- it part of Mac OS
X's quartz 2D library:

http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextDrawImage

I imagine the reason you can't step into it with XCode, is that it has
no source code to display.
You should be able to step through the disassembly instead.

On Thu, Jun 25, 2009 at 7:52 PM, n179911 wrote:
>
> Hi,
>
> Can you please tell me Where is the CGContextDrawImage() for MacOSx defined?
> I have tried setting up a Breakpoints in ImageCG.cpp:197. It breaks
> there but when I click 'step into', it never goes to the
> implementation of CGContextDrawImage. XCode just jumps to the next
> line.
>
> And I also tried building a cscope myself (include .mm file), but when
> I  look for CGContextDrawImage(), it only gives me callers for that
> function:
>
> *** src/skia/ext/skia_utils_mac.mm:
> [107]                  CGContextDrawImage(context, rect, image);
>
> *** src/third_party/WebKit/WebCore/platform/graphics/cg/ImageCG.cpp:
> [118]                  CGContextDrawImage(bmap, dst, image);
> [197]                  CGContextDrawImage(context,
> adjustedDestRect, image);
> [211]                  CGContextDrawImage(context,
> GraphicsContext(context).roundToDevicePixels(FloatRect(0, 0,
> CGImageGetWidth(image), CGImageGetHeight(image))), image);
>
> *** src/third_party/WebKit/WebCore/platform/graphics/cg/PatternCG.cpp:
> [45]                   CGContextDrawImage(context, rect, 
> platformImage);
>
> *** 
> src/third_party/WebKit/WebCore/platform/graphics/win/GraphicsContextCGWin.cpp:
> [101]                  CGContextDrawImage(m_data->m_cgContext,
> dstRect, image);
> [124]                  CGContextDrawImage(m_data->m_cgContext,
> CGRectMake(point.x(), point.y(), image->size().width(),
> image->size().height()), cgImage.get());
>
> *** src/third_party/WebKit/WebCore/platform/win/DragImageCGWin.cpp:
> [111]                  CGContextDrawImage(targetContext, rect,
> srcImage);
> [156]                  CGContextDrawImage(drawContext, rect, 
> srcImage);
>
> *** src/third_party/skia/src/ports/SkImageDecoder_CG.cpp:
> [83]                   CGContextDrawImage(cg, CGRectMake(0, 0,
> width, height), image);
>
> *** src/webkit/glue/webcursor_mac.mm:
> [172]                  CGContextDrawImage(context.get(), rect,
> image_ptr);
>
> *** src/skia/ext/bitmap_platform_device_mac.cc:
> DrawToContext[299]             CGContextDrawImage(context, bounds, sub_image);
> DrawToContext[306]             CGContextDrawImage(context, bounds, image);
>
> *** 
> src/third_party/WebKit/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm:
> print[372]                     CGContextDrawImage(context,
> CGRectMake(0, 0, width, height), image.get());
>
> *** src/third_party/skia/experimental/CiCarbonSampleMain.c:
> TestDraw[208]                  CGContextDrawImage(cg, r, ref);
>
> *** src/third_party/skia/src/utils/mac/SkBitmap_Mac.cpp:
> drawToPort[133]                CGContextDrawImage(cg, rect, image);
>
> *** src/third_party/skia/src/utils/mac/SkOSWindow_Mac.cpp:
> doPaint[168]                   CGContextDrawImage(cg, r, img);
>
> *** src/third_party/skia/xcode/hostapp/test.cpp:
> SkiaDraw[60]                   CGContextDrawImage(cg, r, gImage);
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] how to judge layouttests' running result?

[David Jones]

I have ran layouttests on Windows XP, and got a result as:
Expected to fail, but passed (5):
  LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html
  LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html
  LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html
  LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html
  LayoutTests/fast/encoding/invalid-UTF-8.html
Expected to timeout, but passed (1):
  LayoutTests/http/tests/security/credentials-in-referer.html
Regressions: Unexpected failures (8):
  LayoutTests/fast/css/css2-system-fonts.html = FAIL
  LayoutTests/fast/dom/anchor-toString.html = FAIL
  LayoutTests/fast/dom/java-applet-calls.html = FAIL
  LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL
  LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht
ml = FAIL
  LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL
  LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL
  LayoutTests/plugins/embed-attributes-setting.html = FAIL
Regressions: Unexpected timeouts (1):
  LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = TI
MEOUT
--
=> Tests to be fixed for the current release (786):
86 test cases (10.9%) Passed
364 test cases (46.3%) Skipped
289 test cases (36.8%) Text diff mismatch
191 test cases (24.3%) Simplified text diff mismatch
160 test cases (20.4%) Image mismatch
11 test cases (1.4%) Test timed out
6 test cases (0.8%) Test shell crashed
2 test cases (0.3%) No expected image found
=> Tests we want to pass for the current release (8984):
8271 test cases (92.1%) Passed
364 test cases (4.1%) Skipped
301 test cases (3.4%) Text diff mismatch
201 test cases (2.2%) Simplified text diff mismatch
164 test cases (1.8%) Image mismatch
12 test cases (0.1%) Test timed out
6 test cases (0.1%) Test shell crashed
2 test cases (0.0%) No expected image found
=> Tests to be fixed for a future release (0):
=> All tests (10884):
8753 test cases (80.4%) Passed
2130 test cases (19.6%) Skipped
411 test cases (3.8%) Text diff mismatch
302 test cases (2.8%) Simplified text diff mismatch
183 test cases (1.7%) Image mismatch
13 test cases (0.1%) Test timed out
6 test cases (0.1%) Test shell crashed
2 test cases (0.0%) No expected image found
I don't know what it tells, am I passed the layouttests?
 
There's also a layouttests in webkit, what's the relation between chrome's 
layouttest and webkit's layouttest? I think webkit's layouttest only run on 
Leopard.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Where is the CGContextDrawImage() for MacOSx defined

[n179911]

Hi,

Can you please tell me Where is the CGContextDrawImage() for MacOSx defined?
I have tried setting up a Breakpoints in ImageCG.cpp:197. It breaks
there but when I click 'step into', it never goes to the
implementation of CGContextDrawImage. XCode just jumps to the next
line.

And I also tried building a cscope myself (include .mm file), but when
I  look for CGContextDrawImage(), it only gives me callers for that
function:

*** src/skia/ext/skia_utils_mac.mm:
[107]  CGContextDrawImage(context, rect, image);

*** src/third_party/WebKit/WebCore/platform/graphics/cg/ImageCG.cpp:
[118]  CGContextDrawImage(bmap, dst, image);
[197]  CGContextDrawImage(context,
adjustedDestRect, image);
[211]  CGContextDrawImage(context,
GraphicsContext(context).roundToDevicePixels(FloatRect(0, 0,
CGImageGetWidth(image), CGImageGetHeight(image))), image);

*** src/third_party/WebKit/WebCore/platform/graphics/cg/PatternCG.cpp:
[45]   CGContextDrawImage(context, rect, platformImage);

*** 
src/third_party/WebKit/WebCore/platform/graphics/win/GraphicsContextCGWin.cpp:
[101]  CGContextDrawImage(m_data->m_cgContext,
dstRect, image);
[124]  CGContextDrawImage(m_data->m_cgContext,
CGRectMake(point.x(), point.y(), image->size().width(),
image->size().height()), cgImage.get());

*** src/third_party/WebKit/WebCore/platform/win/DragImageCGWin.cpp:
[111]  CGContextDrawImage(targetContext, rect,
srcImage);
[156]  CGContextDrawImage(drawContext, rect, srcImage);

*** src/third_party/skia/src/ports/SkImageDecoder_CG.cpp:
[83]   CGContextDrawImage(cg, CGRectMake(0, 0,
width, height), image);

*** src/webkit/glue/webcursor_mac.mm:
[172]  CGContextDrawImage(context.get(), rect,
image_ptr);

*** src/skia/ext/bitmap_platform_device_mac.cc:
DrawToContext[299] CGContextDrawImage(context, bounds, sub_image);
DrawToContext[306] CGContextDrawImage(context, bounds, image);

*** 
src/third_party/WebKit/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm:
print[372] CGContextDrawImage(context,
CGRectMake(0, 0, width, height), image.get());

*** src/third_party/skia/experimental/CiCarbonSampleMain.c:
TestDraw[208]  CGContextDrawImage(cg, r, ref);

*** src/third_party/skia/src/utils/mac/SkBitmap_Mac.cpp:
drawToPort[133]CGContextDrawImage(cg, rect, image);

*** src/third_party/skia/src/utils/mac/SkOSWindow_Mac.cpp:
doPaint[168]   CGContextDrawImage(cg, r, img);

*** src/third_party/skia/xcode/hostapp/test.cpp:
SkiaDraw[60]   CGContextDrawImage(cg, r, gImage);

--~--~-~--~~~---~--~~
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: apologies for build breakage

[Mark Larson (Google)]

We're working on adding more trybot capacity (>3x for Mac). Additional Macs
should come online in the next week or so, which will reduce the try
latency. Right now, we're really underpowered.
Yoda would be happy that there is no try. Developers, not so much.

--Mark

On Thu, Jun 25, 2009 at 18:39, Evan Martin  wrote:

>
> I did run it through try bots, but overlooked mac because it finished
> running my job 50 minutes after I submitted it.  :~(
> The especial irony was that the patch is for windowed plugins, which
> only exist on Windows and Linux; it was "just" getting typedefs wrong.
>
> I will try again later.
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: "gclient runhooks --force" not forceful enough?

[Antoine Labour]

On Thu, Jun 25, 2009 at 6:20 PM, Dan Kegel wrote:
> On Thu, Jun 25, 2009 at 6:13 PM, Antoine Labour wrote:
>> Are you seeing the same thing I am seeing ? For me, through gclient,
>> Makefile is generated one directory up and is messed up.
>
> By gum, yes:
>
> $ diff Makefile ../Makefile
> 22c22
> < builddir ?= /home/dkegel/chrome-build/src/out/$(BUILDTYPE)
> ---
>> builddir ?= /home/dkegel/chrome-build/out/$(BUILDTYPE)
>
> That explains a few things.
>

Oh, goody, that means I'm not crazy !

Antoine

--~--~-~--~~~---~--~~
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: about gtest's main in chromium

[Jickae Davis]

y, that's what I want.

I know nothing about .gyp files, that's the way I can understand, 3x~!

2009/6/26 Marc-Antoine Ruel 

> It's set through .sln dependencies;
>
> src\chrome>python tools\build\win\sln_deps.py chrome.sln printing_unittests
> printing_unittests
>  base
>  gtest
>  gtestmain
>  icui18n
>  icuuc
>  printing
>
>
> M-A
>
> 2009/6/25 Jickae Davis :
>  > ah, in fact, I don't really understand what the .gyp files do.
> > Could the gtestmain be found in printing_unittests' project properties
> under
> > VS2005?
> > I have check that, and didn't find a gtestmain.lib in "Configuration
> > Properties"-->"Linker"-->"Input".
> > 2009/6/25 William Chan (陈智昌) 
> >>
> >> printing_unittests depends on gtestmain.lib.  See
> >> src/printing/printing.gyp.
> >>
> >> On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davis
> wrote:
> >> > yep, for base_unittests, that's true.
> >> > But what I want to know is how chromium uses GTest. An important
> problem
> >> > is
> >> > how it runs all the GTest projects.
> >> > Take the simplest GTest project printing_unittests as an example, I
> know
> >> > it's run via GTest's main in run_all_unittests.cc. But I don't know
> how
> >> > it
> >> > invokes the main. I checked the project properties of
> >> > printing_unittests,
> >> > and didn't find a link to gtestmain.lib as I always do while writing
> >> > GTest
> >> > tests.
> >> >
> >> >
> >> > 2009/6/23 Adam Langley 
> >> >>
> >> >> On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davis
> wrote:
> >> >> > But I find something weird in the chromiun's GTest projects, they
> >> >> > neither
> >> >> > write a main nor link a gtest_main.lib.
> >> >> >
> >> >> > How do they start GTest?
> >> >>
> >> >> Well, you can always set a breakpoint at main and see where you end
> >> >> up. For base_unittests, it's base/run_all_unittests.cc for example.
> >> >>
> >> >>
> >> >> AGL
> >> >
> >> >
> >> > >
> >> >
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] apologies for build breakage

[Evan Martin]

I did run it through try bots, but overlooked mac because it finished
running my job 50 minutes after I submitted it.  :~(
The especial irony was that the patch is for windowed plugins, which
only exist on Windows and Linux; it was "just" getting typedefs wrong.

I will try again later.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: "gclient runhooks --force" not forceful enough?

[Dan Kegel]

On Thu, Jun 25, 2009 at 6:13 PM, Antoine Labour wrote:
> Are you seeing the same thing I am seeing ? For me, through gclient,
> Makefile is generated one directory up and is messed up.

By gum, yes:

$ diff Makefile ../Makefile
22c22
< builddir ?= /home/dkegel/chrome-build/src/out/$(BUILDTYPE)
---
> builddir ?= /home/dkegel/chrome-build/out/$(BUILDTYPE)

That explains a few things.

--~--~-~--~~~---~--~~
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: "gclient runhooks --force" not forceful enough?

[Antoine Labour]

On Thu, Jun 25, 2009 at 5:57 PM, Dan Kegel wrote:
>
> I did
>  rm Makefile
>  gclient runhooks --force
> and it didn't regenerate Makefile.
>
> tools/gyp/gyp -f make build/all.gyp
> does rebuild it.
>
> Seems like gclient runhooks --force ought to, no?

Are you seeing the same thing I am seeing ? For me, through gclient,
Makefile is generated one directory up and is messed up.

Antoine

--~--~-~--~~~---~--~~
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: "gclient runhooks --force" not forceful enough?

[Dan Kegel]

On Thu, Jun 25, 2009 at 6:03 PM, Albert J. Wong
(王重傑) wrote:
> Doesn't gclient runhooks --force setup the scons build on linux?  Or did the
> make build become default at some point?

Forgot to mention, I have
GYP_GENERATORS=make
in my environment.

The scons build is so slow I can't bear to go back.

--~--~-~--~~~---~--~~
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: "gclient runhooks --force" not forceful enough?

[王重傑]

Doesn't gclient runhooks --force setup the scons build on linux?  Or did the
make build become default at some point?

On Thu, Jun 25, 2009 at 5:57 PM, Dan Kegel  wrote:

>
> I did
>  rm Makefile
>  gclient runhooks --force
> and it didn't regenerate Makefile.
>
> tools/gyp/gyp -f make build/all.gyp
> does rebuild it.
>
> Seems like gclient runhooks --force ought to, no?
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] "gclient runhooks --force" not forceful enough?

[Dan Kegel]

I did
 rm Makefile
 gclient runhooks --force
and it didn't regenerate Makefile.

tools/gyp/gyp -f make build/all.gyp
does rebuild it.

Seems like gclient runhooks --force ought to, no?

--~--~-~--~~~---~--~~
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: Landing two sided patches

[Darin Fisher]

I suspect there are things we can do that will avoid much of the need to do
a Chromium side change in unison with a WebKit side change.  #1 is probably
upstreaming some .gypi files so that the set of files to build can be stored
in svn.webkit.org.  The WebKit API will also help, and completing the
upstreaming of V8 is another biggie.
-Darin


On Thu, Jun 25, 2009 at 3:53 PM, Adam Langley  wrote:

>
> Dear Lords of the WebKit, I come to you seeking guidance about how
> best to avoid the mess that the tree got into this afternoon.
>
> Japhet and I both had two sided patches to land (where one needs to
> land both the WebKit and Chromium sides together). We emailed the
> merger for the day (jianli) and asked him to email us when the merge
> landed.
>
> He did so and I closed the tree. japhet and I both started landing
> upstream. I landed r45191 and the Chromium side (including a large
> DEPS roll) in r19287. japhet landed upstream in r45193 and r19291.
>
> The tree went red because V8IsolatedWorld had landed upstream in the
> mean time and needed an include file changed because of japhet's
> upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295).
> However, that pulled in several other upstream patches, one of which
> broke the build in another way! So I TBRed upstream to fix that
> (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness
> of keyboard, no other patches landed upstream in the mean time.
>
> In the past, for small patches, I've emailed the WebKit merger with
> the patch to land. However, for larger patches, esp those which might
> have conflicts, this seems unfortunate. It also breaks the SVN
> log/blame for the future.
>
> How best to deal with this now that we pull directly from upstream?
> Should I just have reverted Chromium at the first sign of trouble?
>
>
> AGL
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Memory usage in chrome

[Mike Beltzner]

On 25-Jun-09, at 7:02 PM, Mike Belshe wrote:

> This screen actually confuses me a little, as the Summary statistics  
> don't match the summation of the process based statistics. Do you  
> mean to say your summary statistics take into account the memory  
> that's being shared across the various processes?
>
> Correct.
>
> The "shared" across all processes is a bit of a hack, because you  
> can't know exactly which pages are shared across every single  
> process.  We do a heuristic.

Cool! Good to know. I'll take a peek into that code you mentioned to  
see what the heuristic is that you're using.

> Interestingly, as I watched this value change while webpages were  
> loading, it tracked the same pattern of growth/decline as "Memory  
> (Private Working Set)" in the Task Manager, though the values were  
> usually about 2x or so more. I suppose this is due to the heap  
> sharing you were speaking of earlier?
>
> I'm not quite sure what you mean.

I'm basically being lazy. I'd like to not have to make my own counter  
for Private Working Set, so I watched the values of "Memory (Private  
Working Set)" and "Commit Size" in the Task Manager as the test ran,  
and noticed that they increased/decreased at the same time, and the  
delta between them was a near constant 2x. Since my interest here is  
developing a metric that can help us understand when we're regressing/ 
improving memory usage, the exact value isn't as important to me as  
the delta. If the deltas are simply off by a constant factor, I could  
live with that.

As I said: lazy!

>
> The "Working Set - Private" counter doesn't seem to have a structure  
> according to the MSDN document; that's what maps to the "Memory  
> (Private Working Set)" column in the TaskManager.
>
> Right, I think you have to use QueryWorkingSet, walk the pages and  
> categorize them yourself.
>
> OK, I can look into trying that. Though I'm wondering if it's worth  
> the bother, as the meta-pattern, to me, is more interesting than the  
> precise megabyte count.
>
> For a single process browser, it's not worth the effort; I think  
> it's the only way to know how to account for shared memory.


> The closest thing I can find is the "Working Set" counter, which  
> uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and  
> shows up in the Vista Task Manager as "Working Set (Memory)"
>
> For multi-proc browsers like chrome, this will way overstate RAM;  
> there is a good 5-6MB of shared working set in each process.  So for  
> 10 tabs, you'd could an extra 50MB for Chrome if you do it this way.
>
> Looking both in Task Manager and about:memory, when I have 30 tabs  
> open I'm not seeing 30 processes. Are you sure you're right about  
> this point?
>
> You don't always get a new process for every tab.  If two tabs are  
> connected via javascript, then they'll be in the same process (the  
> about:memory shows which tabs are in the same process).  So,  
> clicking a link, for example, will open in the same tab, but typing  
> the URL in the omnibox will create a new process.  Others could tell  
> you more about the exact policy for when you get a new process and  
> when you don't.

Someone just did in IRC, actually. Apparently in addition to what you  
said, as soon as a page is in cache, processes get pooled. I clear  
caches between test runs, but it sounds like since we're calling these  
with window.open() in our test, they all get placed in the same process.

Overall, though, that should mean that we're *not* double counting  
memory. In fact, when I observed as the test ran, there were only  
three processes: one for the browser, one for the single content  
process from which all tabs were spawned, and one for Shockwave/Flash.  
Good news, I guess, in terms of reporting accurately!

> OK - I think this might basically use one renderer process in  
> chrome?  Because of the new-process creation policy, it may not be  
> representative of real world usage.  Darin?

Right, but AIUI, it's an erring on the side of reporting less, not  
more. If there's a better way to automate pageloads that represents  
real world usage, please let me know.

> The whole while, we measure the amount of memory taken using the  
> PROCESS_MEMORY_COUNTERS structure, summating over processes when  
> multiple exist (as they do in the case of Internet Explorer 8 and  
> Chrome 2)
>
> Ok - that will double count shared memory.  I'd estimate 3-5MB per  
> process.

So we're talking about over-reporting by 9-15MB across the test.  
Again, good to know.

> I'll try to take a closer look at your test, but I'm not sure when  
> I'll have time :-(

No rush here, and I appreciate your time and candor to date!

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: Memory usage in chrome

[Mike Belshe]

On Thu, Jun 25, 2009 at 3:26 PM, Mike Beltzner  wrote:

> On 25-Jun-09, at 12:52 PM, Mike Belshe wrote:
>
>  Yeah, the APIs all have constraints.  We end up walking the pages and
>> adding them up.  See process_util_win.cc in the chromium tree.  Be sure to
>> check about:memory and hover over the little "?" icons to see what we
>> measure.
>>
>
> This screen actually confuses me a little, as the Summary statistics don't
> match the summation of the process based statistics. Do you mean to say your
> summary statistics take into account the memory that's being shared across
> the various processes?


Correct.

The "shared" across all processes is a bit of a hack, because you can't know
exactly which pages are shared across every single process.  We do a
heuristic.


>
>
> If so, is there any command-line switch that will output those summary
> stats to console on a regular basis?


You can use --enable-logging --log-level=0  - each time you refresh the
about:memory page, it will drop a line to the log file.  This can be useful
for plots over time.


>
>
>
>> If someone measures the "Private Bytes" counter, which uses the
>> PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map to the
>> Task Manager "Commit Size" which isn't the thing I believe we want to
>> measure.
>>
>> Right.
>>
>
> Interestingly, as I watched this value change while webpages were loading,
> it tracked the same pattern of growth/decline as "Memory (Private Working
> Set)" in the Task Manager, though the values were usually about 2x or so
> more. I suppose this is due to the heap sharing you were speaking of
> earlier?


I'm not quite sure what you mean.

But of course, as you load more tabs, you'll see the memory use go up.


>
>
>  The "Working Set - Private" counter doesn't seem to have a structure
>> according to the MSDN document; that's what maps to the "Memory (Private
>> Working Set)" column in the TaskManager.
>>
>> Right, I think you have to use QueryWorkingSet, walk the pages and
>> categorize them yourself.
>>
>
> OK, I can look into trying that. Though I'm wondering if it's worth the
> bother, as the meta-pattern, to me, is more interesting than the precise
> megabyte count.


For a single process browser, it's not worth the effort; I think it's the
only way to know how to account for shared memory.


>
>
>
>> The closest thing I can find is the "Working Set" counter, which uses the
>> PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up in the
>> Vista Task Manager as "Working Set (Memory)"
>>
>> For multi-proc browsers like chrome, this will way overstate RAM; there is
>> a good 5-6MB of shared working set in each process.  So for 10 tabs, you'd
>> could an extra 50MB for Chrome if you do it this way.
>>
>
> Looking both in Task Manager and about:memory, when I have 30 tabs open I'm
> not seeing 30 processes. Are you sure you're right about this point?
>

You don't always get a new process for every tab.  If two tabs are connected
via javascript, then they'll be in the same process (the about:memory shows
which tabs are in the same process).  So, clicking a link, for example, will
open in the same tab, but typing the URL in the omnibox will create a new
process.  Others could tell you more about the exact policy for when you get
a new process and when you don't.



>
>
>  If you come up with a better way, please let me know!
>>
>
> Well, I can tell you what we've done and what we're doing, just trying to
> get confidence on various metrics. We've replicated the "membuster" test we
> used around the release of Firefox 3 (see
> http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ ) as a way of
> measuring Firefox's ability to hold a "steady" state of memory across a
> browsing session (ie: not leak) and then release that memory when the
> session ends (ie: not bogart system resources). The test:
>
>  - runs on Windows 7, using Python and our Standalone Talos code to make
> measurements
>  - uses a local web proxy to ensure we're always viewing the same web
> content
>  - uses the JS at view-source:
> http://random.pavlov.net/membuster/index.html to:
>  --- open 30 pages using window.open() calls
>  --- load ~300 pages, opening and closing windows with each load (always 30
> open)
>  --- close all 30 windows when done cycling


OK - I think this might basically use one renderer process in chrome?
 Because of the new-process creation policy, it may not be representative of
real world usage.  Darin?


> The whole while, we measure the amount of memory taken using the
> PROCESS_MEMORY_COUNTERS structure, summating over processes when multiple
> exist (as they do in the case of Internet Explorer 8 and Chrome 2)


Ok - that will double count shared memory.  I'd estimate 3-5MB per process.


> The results can be seen here, using both the PrivateUsage (shows as "Commit
> Size" in Windows 7 Task Manager) and WorkingSet (shows as "Working Set
> (Memory)" in Windows 7 Task Manager) counters:
>
> http://p

[chromium-dev] Landing two sided patches

[Adam Langley]

Dear Lords of the WebKit, I come to you seeking guidance about how
best to avoid the mess that the tree got into this afternoon.

Japhet and I both had two sided patches to land (where one needs to
land both the WebKit and Chromium sides together). We emailed the
merger for the day (jianli) and asked him to email us when the merge
landed.

He did so and I closed the tree. japhet and I both started landing
upstream. I landed r45191 and the Chromium side (including a large
DEPS roll) in r19287. japhet landed upstream in r45193 and r19291.

The tree went red because V8IsolatedWorld had landed upstream in the
mean time and needed an include file changed because of japhet's
upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295).
However, that pulled in several other upstream patches, one of which
broke the build in another way! So I TBRed upstream to fix that
(r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness
of keyboard, no other patches landed upstream in the mean time.

In the past, for small patches, I've emailed the WebKit merger with
the patch to land. However, for larger patches, esp those which might
have conflicts, this seems unfortunate. It also breaks the SVN
log/blame for the future.

How best to deal with this now that we pull directly from upstream?
Should I just have reverted Chromium at the first sign of trouble?


AGL

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Memory usage in chrome

[Mike Beltzner]

On 25-Jun-09, at 6:26 PM, Mike Beltzner wrote:

> here's a ZIP with the
> required code (needs Python 2.5 or later to be installed on your
> system):

Oops, forgot the link!

http://people.mozilla.org/~beltzner/membuster-talos.rar

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: Memory usage in chrome

[Mike Beltzner]

On 25-Jun-09, at 12:52 PM, Mike Belshe wrote:

> Yeah, the APIs all have constraints.  We end up walking the pages  
> and adding them up.  See process_util_win.cc in the chromium tree.   
> Be sure to check about:memory and hover over the little "?" icons to  
> see what we measure.

This screen actually confuses me a little, as the Summary statistics  
don't match the summation of the process based statistics. Do you mean  
to say your summary statistics take into account the memory that's  
being shared across the various processes?

If so, is there any command-line switch that will output those summary  
stats to console on a regular basis?

>
> If someone measures the "Private Bytes" counter, which uses the  
> PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map  
> to the Task Manager "Commit Size" which isn't the thing I believe we  
> want to measure.
>
> Right.

Interestingly, as I watched this value change while webpages were  
loading, it tracked the same pattern of growth/decline as "Memory  
(Private Working Set)" in the Task Manager, though the values were  
usually about 2x or so more. I suppose this is due to the heap sharing  
you were speaking of earlier?

> The "Working Set - Private" counter doesn't seem to have a structure  
> according to the MSDN document; that's what maps to the "Memory  
> (Private Working Set)" column in the TaskManager.
>
> Right, I think you have to use QueryWorkingSet, walk the pages and  
> categorize them yourself.

OK, I can look into trying that. Though I'm wondering if it's worth  
the bother, as the meta-pattern, to me, is more interesting than the  
precise megabyte count.

>
> The closest thing I can find is the "Working Set" counter, which  
> uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and  
> shows up in the Vista Task Manager as "Working Set (Memory)"
>
> For multi-proc browsers like chrome, this will way overstate RAM;  
> there is a good 5-6MB of shared working set in each process.  So for  
> 10 tabs, you'd could an extra 50MB for Chrome if you do it this way.

Looking both in Task Manager and about:memory, when I have 30 tabs  
open I'm not seeing 30 processes. Are you sure you're right about this  
point?

> If you come up with a better way, please let me know!

Well, I can tell you what we've done and what we're doing, just trying  
to get confidence on various metrics. We've replicated the "membuster"  
test we used around the release of Firefox 3 (see 
http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ 
  ) as a way of measuring Firefox's ability to hold a "steady" state  
of memory across a browsing session (ie: not leak) and then release  
that memory when the session ends (ie: not bogart system resources).  
The test:

  - runs on Windows 7, using Python and our Standalone Talos code to  
make measurements
  - uses a local web proxy to ensure we're always viewing the same web  
content
  - uses the JS at view-source:http://random.pavlov.net/membuster/index.html 
  to:
  --- open 30 pages using window.open() calls
  --- load ~300 pages, opening and closing windows with each load  
(always 30 open)
  --- close all 30 windows when done cycling

The whole while, we measure the amount of memory taken using the  
PROCESS_MEMORY_COUNTERS structure, summating over processes when  
multiple exist (as they do in the case of Internet Explorer 8 and  
Chrome 2)

The results can be seen here, using both the PrivateUsage (shows as  
"Commit Size" in Windows 7 Task Manager) and WorkingSet (shows as  
"Working Set (Memory)" in Windows 7 Task Manager) counters:

http://people.mozilla.com/~beltzner/images/private-usage.png
http://people.mozilla.com/~beltzner/images/working-set.png

The datapoint we wanted to get out of this was primarily about Firefox  
3.5 vs Firefox 3.0.11, and as you can see we actually take slightly  
(7-10MB) more memory during the page cycling, but manage to release  
more when done. Safari had previously been unable to complete this  
test, but now does.

I'd love to get your feedback on how we can improve our recording  
here. I think we're going to try and bundle together the test and  
files into an easier-to-use-tool than our delicately cobbled together  
solution, but if you wanted to try it yourself, here's a ZIP with the  
required code (needs Python 2.5 or later to be installed on your  
system):

Once unzipped, enter the directory and run the following commands:

\path\to\python\python.exe proxyserver.py -v -l -u proxy-cache.db
\path\to\python\python.exe measure_any_windows_app.py > \path\to 
\resultsfile\resultsfile.txt

You'll want to edit measure_any_windows_app.py to have the correct  
paths to the various applications, and you'll also want to make sure  
your browsers are set to use 127.0.0.1 port 8000 as a proxy (under  
Advanced > Network > Settings in Firefox, Internet Properties >  
Connections > LAN Settings for Chrome/IE/Safari)

(Thanks to David Dahl for modifying the re

[chromium-dev] Purify/Valgrind FIXIT

[Huan Ren]

For people looking for FIXIT items next week, these are lists of
Purify/Valgrind
FIXIT bugs without owner assigned.

http://code.google.com/p/chromium/issues/list?can=2&q=purify+label:fixit+-has:owner&sort=pri&colspec=ID+Stars+Pri+Area+Type+Status+Summary+Modified+Owner+Mstone&x=mstone&y=area&cells=tiles

http://code.google.com/p/chromium/issues/list?can=2&q=valgrind+label:fixit+-has:owner&sort=pri&colspec=ID+Stars+Pri+Area+Type+Status+Summary+Modified+Owner+Mstone&x=mstone&y=area&cells=tiles

Huan

--~--~-~--~~~---~--~~
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 is down

[dhhwai]

And the chromium-bugs list has also been blacklisted for the same
reason.

On Jun 25, 11:05 am, "Mark Larson (Google)"  wrote:
> The chromium-reviews emailing list has been blacklisted (for spam
> apparently).
> No review email is going out. We're working to get the list restored, but
> don't have an ETA at this point.
>
> In the meantime, you'll need to ping people directly to let them know about
> pending reviews and comments.
>
> --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: How do I deploy an NPAPI plugin over the internet from HTML ?

[John Abd-El-Malek]

On Thu, Jun 25, 2009 at 1:54 AM, Non-Stick  wrote:

>
> OK.  Thanks for that Matt.  At least now I know I was using the wrong
> mechanism.
>
> So what is the recommended way to download and install an NPAPI Plugin
> over the internet under Chrome ?


There's no way to make Chrome download your plugin automatically.  You're
going to have to build an installer for your plugin and point your users to
it if it's not available.


>
>
> There are 4 files that I need to download (the plugin dll plus 3
> helper files):
> npmyplugin.dll
> mylibrary.dll
> myprogA.exe
> myprogB.exe
>
> >
>

--~--~-~--~~~---~--~~
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: Gmock compilation errors on VS2008SP1

[王重傑]

I haven't heard back about any more VS2008 issues.

I'm going to remove boost tuple from the chromium tree next week, which will
break the workaround nakro posted earlier.  If there any more VS2008 issues,
please let me know soon so I don't break you. :)

Thanks,
Albert

On Tue, Jun 23, 2009 at 9:49 PM, Albert J. Wong (王重傑)
wrote:

> Hi Thiago,
>
> Did you sync pas revision 19049?  And did you do a clean build?
>
> Thanks,
> Albert
>
>
>
> On Tue, Jun 23, 2009 at 9:37 AM, Thiago Farina wrote:
>
>>
>> I have the same problem with tuple.
>>
>> On Jun 15, 1:24 pm, Marc-Antoine Ruel  wrote:
>> > I'm fine with that if necessary.
>> >
>> > On Mon, Jun 15, 2009 at 12:11 PM, Albert J. Wong(王重傑)<
>> ajw...@chromium.org> wrote:
>> >
>> > > On Mon, Jun 15, 2009 at 9:03 AM, nakro 
>> wrote:
>> >
>> > >> Hi albret,
>> >
>> > >> projects that fail :
>> > >> gmockj
>> > >> gmockmain
>> >
>> > >> here is an example out from gmockmain
>> >
>> > >> C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) :
>> > >> error C2065: '_Is_swap_move' : undeclared identifier
>> > >> 1>C:\Program Files\Microsoft Visual Studio
>> 9.0\VC\include\tuple
>> > >> (504) : see reference to class template instantiation
>> >
>> > >>
>> 'std::_Move_operation_category> 4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9>>'
>> > >> being compiled
>> > >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499)
>> :
>> > >> error C2226: syntax error : unexpected type
>> > >> 'std::_Move_operation_category<_Value>::_Move_cat'
>> > >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503)
>> :
>> > >> error C2947: expecting '>' to terminate template-argument-list, found
>> > >> '>'
>> > >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503)
>> :
>> > >> error C2976: 'std::_If' : too few template arguments
>> > >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include
>> > >> \xutility(1018) : see declaration of 'std::_If'
>> >
>> > >> the solution on my machine is this
>> > >> to do HAS_TR1=0 (you have 1 by default)
>> > >> and to change
>> >
>> > >> gmock_port.h
>> >
>> > >> to include the boost version even on 2008, which initially your code
>> > >> goes to the  path
>> >
>> > > That's a good workaround.  Switching to the boost implementation would
>> > > almost certainly work for now.
>> >
>> > > I'll attempt to reproduce and figure out a long term fix (including
>> just
>> > > whacking the tr1 dependency out of gmock...started a discussion with
>> > > zhanyong about this last week).
>> >
>> > > If it gets bad enough, we could consider changing over the VS2008
>> builds to
>> > > use boost as well, and then disable _HAS_TR1 as you described above,
>> but
>> > > that'll require a full clobber from everyone due to precompiled header
>> > > issues.
>> >
>> > > -Albert
>> >
>> > >> but i must have something wrong with my machine if i am the only one
>> > >> who is having this
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 helpwanted items (how it works)

[Marc-Antoine Ruel]

In any case, make sure to ping the @chromium.org person that added the
HelpWanted flag!

M-A

On Thu, Jun 25, 2009 at 11:29 AM, Finnur
Thorarinsson wrote:
> I wasn't suggesting we should add a UI in addition/instead of a keyboard
> modifier.
> Since there is no standard modifier you should do as Evan suggested an just
> pick one. We can always change it.
>
> On Thu, Jun 25, 2009 at 08:14, nakro  wrote:
>>
>> I agree, but no browser has a keyboard shortcut for this
>> what FF and Safari have is a menu option to change the behavior of
>> Zoom (via a check box)
>> and IE only does full page zoom
>>
>> since chrome is so religious about minimal UI, i thought to have these
>> options with no UI at all
>> but i can easily add this feature to windows if needed
>> but i think it makes more sense to have both options available via the
>> keyboard
>> as some pages are better for Full page zoom, while others look better
>> with text only zoom
>>
>> but whatever you chose is fine by me,
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: about gtest's main in chromium

[Marc-Antoine Ruel]

It's set through .sln dependencies;

src\chrome>python tools\build\win\sln_deps.py chrome.sln printing_unittests
printing_unittests
  base
  gtest
  gtestmain
  icui18n
  icuuc
  printing


M-A

2009/6/25 Jickae Davis :
> ah, in fact, I don't really understand what the .gyp files do.
> Could the gtestmain be found in printing_unittests' project properties under
> VS2005?
> I have check that, and didn't find a gtestmain.lib in "Configuration
> Properties"-->"Linker"-->"Input".
> 2009/6/25 William Chan (陈智昌) 
>>
>> printing_unittests depends on gtestmain.lib.  See
>> src/printing/printing.gyp.
>>
>> On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davis wrote:
>> > yep, for base_unittests, that's true.
>> > But what I want to know is how chromium uses GTest. An important problem
>> > is
>> > how it runs all the GTest projects.
>> > Take the simplest GTest project printing_unittests as an example, I know
>> > it's run via GTest's main in run_all_unittests.cc. But I don't know how
>> > it
>> > invokes the main. I checked the project properties of
>> > printing_unittests,
>> > and didn't find a link to gtestmain.lib as I always do while writing
>> > GTest
>> > tests.
>> >
>> >
>> > 2009/6/23 Adam Langley 
>> >>
>> >> On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davis wrote:
>> >> > But I find something weird in the chromiun's GTest projects, they
>> >> > neither
>> >> > write a main nor link a gtest_main.lib.
>> >> >
>> >> > How do they start GTest?
>> >>
>> >> Well, you can always set a breakpoint at main and see where you end
>> >> up. For base_unittests, it's base/run_all_unittests.cc for example.
>> >>
>> >>
>> >> AGL
>> >
>> >
>> > >
>> >
>
>
> >
>

--~--~-~--~~~---~--~~
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 possible to do a gclient sync without running hooks?

[Marc-Antoine Ruel]

Send patches to gclient.py to 'disable automatic runhooks on sync' to
me. You can hack directly inside your depot_tools and use 'gcl change
bleh' and 'gcl upload bleh --send-mail -r mar...@chromium.org'.

You'll need to update the unit tests.

M-A

On Tue, Jun 23, 2009 at 9:01 PM, Nicolas Sylvain wrote:
>
>
> On Tue, Jun 23, 2009 at 5:53 PM, Daniel Cowx  wrote:
>>
>> When I run "gclient sync", it automatically runs the hooks; which
>> causes various non-versioned files to get generated within my tree
>> (most notably *.vcproj and *.sln files, but there may be others). I'd
>> like to be able to do a sync *without* generating any files (i.e. so
>> that if I do a "svn status" immediately after a "gclient sync", I see
>> a pristine unmodified tree). Short of going into src/DEPS and
>> commenting out the "hooks" section, can this be done?
>
> I don't think we have this capability at this time.
> But in theory if you "gclient sync ; svn status" you should not see
> anything, since all the
> generated files should be in the svn:ignore. If they are not, then someone
> forgot to add them,
> and we should fix that.
> Nicolas

--~--~-~--~~~---~--~~
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 is down

[dhhwai]

And chromium-bugs has also been blacklisted for the same reason.

On Jun 25, 11:10 am, Evan Martin  wrote:
> You can also point a feed reader at
>  http://codereview.chromium.org/rss/all
> I think.
>
>
>
> On Thu, Jun 25, 2009 at 11:05 AM, Mark Larson (Google) 
> wrote:
> > The chromium-reviews emailing list has been blacklisted (for spam
> > apparently).
> > No review email is going out. We're working to get the list restored, but
> > don't have an ETA at this point.
> > In the meantime, you'll need to ping people directly to let them know about
> > pending reviews and comments.
> > --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: Chromium-reviews is down

[Evan Martin]

You can also point a feed reader at
  http://codereview.chromium.org/rss/all
I think.

On Thu, Jun 25, 2009 at 11:05 AM, Mark Larson (Google) wrote:
> The chromium-reviews emailing list has been blacklisted (for spam
> apparently).
> No review email is going out. We're working to get the list restored, but
> don't have an ETA at this point.
> In the meantime, you'll need to ping people directly to let them know about
> pending reviews and comments.
> --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] Chromium-reviews is down

[Mark Larson (Google)]

The chromium-reviews emailing list has been blacklisted (for spam
apparently).
No review email is going out. We're working to get the list restored, but
don't have an ETA at this point.

In the meantime, you'll need to ping people directly to let them know about
pending reviews and comments.

--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: HTML5 Web Socket design doc

[Michael Nordman]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) 

> Thanks for review.
>
> 2009/6/25 Michael Nordman 
>
>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>
> Sure.  I've added a diagram in webkit part.
>
>
>> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
>> is a refcounted object and this design looks modeled off of that (which may
>> be why you've spec'd it this way). Unless your design actually needs
>> refcounting on this class, you may be able to simplify things without it.
>> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>>
>
> Yes.  I missed to add public RefCounted as base class of
> WebSocketHandle.
>  Thanks.
>

I was suggesting that perhaps the WebSocketHandle does not need to be
refcounted.


>
>
>  > should we reuse WebCore/loader instead of adding new component?
>>
>> The loader is somewhat notorious for its complexity. I think you've made a
>> good decision to keep this out of there and to design the websocket system
>> in a good clean modular fashion.
>>
>> > which component is responsible of web socket protocol framing?  This
>> design assumes WebSocketChannel serializes/deserializes message in web
>> socket frame.
>>
>> Since WebSocketHandle is inevitably going to be platform specific, any
>> code you want to be shared code shouldn't be slated for that class. To the
>> extent the 'web socket protocol framing' can be done indepedent of the
>> 'platform' socket handle (which it looks like it can be), it would be a good
>> thing to put it in WebSocketChannel so its shared core common code goodness.
>>
>
> I see.
> I've one question: Web socket handshaking is also platform independent.
> Should we do the handshaking in WebSocketChannel and WebSocketHandle just
> provides almost raw TCP socket?
> Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
> platform code?
>

I haven't read the web sockets spec, so I don't know what the  'handshaking'
entails?

OS level socket creation/destruction and tcp connection opening/closing
needs to be per-platform. Once you have a full-duplex connection and are
sending application 'protocol' data back and forth (message framing), that
probably wants to be common code. Which camp does the 'handshaking' fall
into?




>
>
> > Regarding the "WebKit API", note that no WebCore data types can be used
>> there. So you'll need to create wrapper classes.
>>
>> I see you have speced WebKit:: wrapper classes with the same name as the
>> corresponding WebCore:: classes.
>>
>> I wonder if that same naming could be confusingt? The naming convention
>> darin has been employing would be WebKit::WebWebSocketHandle, which
>> certainly looks odd.
>>
>
> Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.
>
>
>>  * virtual void didReceiveData(const String& msg) {}
>>
>> Maybe rename this to channel client api to didReceiveMessage() to help
>> distinguish between raw 'data' being surface by the 'handle', and complete
>> 'messages' being surfaced by the 'channel'.
>>
>
> Sure. Fixed.
>
> Thanks!
> ukai
>
>
>>
>>
>> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > > wrote:
>>
>>> Hi,
>>>
>>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and
>>> write design docs
>>>
>>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>>
>>> We'll send WebKit part to webkit-dev, if it looks ok.
>>> We'd welcome if you could give us feedback on our design docs.
>>>
>>> Thanks,
>>> ukai
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[John Abd-El-Malek]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) 

> Thanks for review.
>
> 2009/6/25 Michael Nordman 
>
>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>
> Sure.  I've added a diagram in webkit part.
>
>
>> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
>> is a refcounted object and this design looks modeled off of that (which may
>> be why you've spec'd it this way). Unless your design actually needs
>> refcounting on this class, you may be able to simplify things without it.
>> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>>
>
> Yes.  I missed to add public RefCounted as base class of
> WebSocketHandle.
>  Thanks.
>
>  > 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?
>
> > Regarding the "WebKit API", note that no WebCore data types can be used
>> there. So you'll need to create wrapper classes.
>>
>
The WebKit API classes still derive from WebCore, which isn't possible.  The
WebKit API is an abstraction around WebCore classes, so it can't use any
WebCore types in it.


>> 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.
>

hmm, I actually find WebWeb very unwieldy.  I vote for
WebKit::WebSocketHandle.


>
>
>>  * virtual void didReceiveData(const String& msg) {}
>>
>> Maybe rename this to channel client api to didReceiveMessage() to help
>> distinguish between raw 'data' being surface by the 'handle', and complete
>> 'messages' being surfaced by the 'channel'.
>>
>
> Sure. Fixed.
>
> Thanks!
> ukai
>
>
>>
>>
>> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > > wrote:
>>
>>> Hi,
>>>
>>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and
>>> write design docs
>>>
>>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>>
>>> We'll send WebKit part to webkit-dev, if it looks ok.
>>> We'd welcome if you could give us feedback on our design docs.
>>>
>>> Thanks,
>>> ukai
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Memory usage in chrome

[Mike Belshe]

On Thu, Jun 25, 2009 at 9:40 AM, Mike Beltzner  wrote:

> On 22-Jun-09, at 12:57 PM, Mike Belshe wrote:
>
>  Yes, that accurately represents the private memory for a process, but it
>> doesn't reflect the user's experience.  Windows generally tracks working
>> set.  Why?  Because the working set is the amount of memory *not available
>> to other apps*.  If other apps can have the memory, then using the bytes is
>> inconsequential.
>>
>
> Figuring out how to track this is a bit of a terminology mess ;) Referring
> to the following document:
>
> http://msdn.microsoft.com/en-us/library/aa965225(VS.85).aspx


Yeah, the APIs all have constraints.  We end up walking the pages and adding
them up.  See process_util_win.cc in the chromium tree.  Be sure to check
about:memory and hover over the little "?" icons to see what we measure.



>
> If someone measures the "Private Bytes" counter, which uses the
> PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map to the
> Task Manager "Commit Size" which isn't the thing I believe we want to
> measure.


Right.


>
>
> The "Working Set - Private" counter doesn't seem to have a structure
> according to the MSDN document; that's what maps to the "Memory (Private
> Working Set)" column in the TaskManager.


Right, I think you have to use QueryWorkingSet, walk the pages and
categorize them yourself.


>
>
> The closest thing I can find is the "Working Set" counter, which uses the
> PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up in the
> Vista Task Manager as "Working Set (Memory)"


For multi-proc browsers like chrome, this will way overstate RAM; there is a
good 5-6MB of shared working set in each process.  So for 10 tabs, you'd
could an extra 50MB for Chrome if you do it this way.

I wish it were easier too.  In Vista's task manager, the primary metric is
"Memory (Private Working Set)", and I believe the only way to get this
number is to call QueryWorkingSet, walk the pages, and add up the ones which
are marked as private.

If you come up with a better way, please let me know!

Mike



>
>
> Would you agree that summating the data from the
> PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure would give a fair
> indication of memory usage?
>
> 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: Memory usage in chrome

[Mike Beltzner]

On 22-Jun-09, at 12:57 PM, Mike Belshe wrote:

> Yes, that accurately represents the private memory for a process,  
> but it doesn't reflect the user's experience.  Windows generally  
> tracks working set.  Why?  Because the working set is the amount of  
> memory *not available to other apps*.  If other apps can have the  
> memory, then using the bytes is inconsequential.

Figuring out how to track this is a bit of a terminology mess ;)  
Referring to the following document:

http://msdn.microsoft.com/en-us/library/aa965225(VS.85).aspx

If someone measures the "Private Bytes" counter, which uses the  
PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map  
to the Task Manager "Commit Size" which isn't the thing I believe we  
want to measure.

The "Working Set - Private" counter doesn't seem to have a structure  
according to the MSDN document; that's what maps to the "Memory  
(Private Working Set)" column in the TaskManager.

The closest thing I can find is the "Working Set" counter, which uses  
the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up  
in the Vista Task Manager as "Working Set (Memory)"

Would you agree that summating the data from the  
PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure would give a fair  
indication of memory usage?

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: question about helpwanted items (how it works)

[Finnur Thorarinsson]

I wasn't suggesting we should add a UI in addition/instead of a keyboard
modifier.
Since there is no standard modifier you should do as Evan suggested an just
pick one. We can always change it.


On Thu, Jun 25, 2009 at 08:14, nakro  wrote:

>
> I agree, but no browser has a keyboard shortcut for this
> what FF and Safari have is a menu option to change the behavior of
> Zoom (via a check box)
> and IE only does full page zoom
>
> since chrome is so religious about minimal UI, i thought to have these
> options with no UI at all
> but i can easily add this feature to windows if needed
> but i think it makes more sense to have both options available via the
> keyboard
> as some pages are better for Full page zoom, while others look better
> with text only zoom
>
> but whatever you chose is fine by me,
> >
>

--~--~-~--~~~---~--~~
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 helpwanted items (how it works)

[nakro]

I agree, but no browser has a keyboard shortcut for this
what FF and Safari have is a menu option to change the behavior of
Zoom (via a check box)
and IE only does full page zoom

since chrome is so religious about minimal UI, i thought to have these
options with no UI at all
but i can easily add this feature to windows if needed
but i think it makes more sense to have both options available via the
keyboard
as some pages are better for Full page zoom, while others look better
with text only zoom

but whatever you chose is fine by me,
--~--~-~--~~~---~--~~
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 helpwanted items (how it works)

[Finnur Thorarinsson]

> The options, from the bug, are Ctrl+Alt or Ctrl+Shift.  I don't know
> how we'd choose, so I'd just pick one for your patch, implement it,
> and if there's a reason to change it it'd be pretty easy to switch.
As a general rule, it is good to be consistent with the keyboard shortcuts
that other browsers use. I'm not sure which browsers implement this and what
key combination they use, but that's should part of the research work for
this.

-F


On Thu, Jun 25, 2009 at 07:01, Evan Martin  wrote:

>
> On Thu, Jun 25, 2009 at 3:37 AM, nakro wrote:
> > when you mark an itemm as helpWanted, how is it supposed to work from
> > there ?
>
> If it's an obvious bug, like "page fails to scroll if screen is in 16
> bit color mode", then you can just comment on the bug that you're
> looking into it and then submit a patch.
>
> If it's a larger design issue, or feature request that changes the UI,
> it's good to bring it up on chromium-dev for discussion.  Which you've
> done.  :)
>
> > for example, i replied to
> http://code.google.com/p/chromium/issues/detail?id=6383
> > a week ago, saying i want to do it and got to response
>
> If someone else was thinking about working on that bug, they would now
> look at it and see that you had mentioned you were working on it.
> They would then likely ask you if you were still working on it, or if
> you had given up and forgotten to update the bug.  So it's effectively
> yours to work on, now.
>
> > (btw, if you will respond to this, i prefer Ctrl+Shift for text only
> > zoom)
>
> The options, from the bug, are Ctrl+Alt or Ctrl+Shift.  I don't know
> how we'd choose, so I'd just pick one for your patch, implement it,
> and if there's a reason to change it it'd be pretty easy to switch.
>
> >
>

--~--~-~--~~~---~--~~
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 buildbots, which locale?

[Nicolas Sylvain]

On Thu, Jun 25, 2009 at 7:03 AM, Evan Martin  wrote:

> On Thu, Jun 25, 2009 at 6:27 AM, Nicolas Sylvain
> wrote:
> >
> >
> > On Thu, Jun 25, 2009 at 5:27 AM, Dean McNamee 
> wrote:
> >>
> >> I just took a look at what was happening on one of the Linux
> >> buildbots.  It looks like we completely clear the env and just
> >> explicitly set a few things.  We need to add LANG=en_US.UTF-8 to that
> >> list of things.  Any takers?
> >
> > I can add LANG to the list of whitelisted env var to keep.  Would that
> work?
>
> If any of our tests depend on a particular locale, we should have them
> set that locale first.
>  man setlocale   (and man 7 locale)
> Be sure to reset the locale in the tear-down.
>

I made the bot at least keep the current lang, but I agree that it should be
set by the test if it needs to be something specific.

Nicolas

--~--~-~--~~~---~--~~
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 buildbots, which locale?

[Evan Martin]

On Thu, Jun 25, 2009 at 6:27 AM, Nicolas Sylvain wrote:
>
>
> On Thu, Jun 25, 2009 at 5:27 AM, Dean McNamee  wrote:
>>
>> I just took a look at what was happening on one of the Linux
>> buildbots.  It looks like we completely clear the env and just
>> explicitly set a few things.  We need to add LANG=en_US.UTF-8 to that
>> list of things.  Any takers?
>
> I can add LANG to the list of whitelisted env var to keep.  Would that work?

If any of our tests depend on a particular locale, we should have them
set that locale first.
  man setlocale   (and man 7 locale)
Be sure to reset the locale in the tear-down.

--~--~-~--~~~---~--~~
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 helpwanted items (how it works)

[Evan Martin]

On Thu, Jun 25, 2009 at 3:37 AM, nakro wrote:
> when you mark an itemm as helpWanted, how is it supposed to work from
> there ?

If it's an obvious bug, like "page fails to scroll if screen is in 16
bit color mode", then you can just comment on the bug that you're
looking into it and then submit a patch.

If it's a larger design issue, or feature request that changes the UI,
it's good to bring it up on chromium-dev for discussion.  Which you've
done.  :)

> for example, i replied to 
> http://code.google.com/p/chromium/issues/detail?id=6383
> a week ago, saying i want to do it and got to response

If someone else was thinking about working on that bug, they would now
look at it and see that you had mentioned you were working on it.
They would then likely ask you if you were still working on it, or if
you had given up and forgotten to update the bug.  So it's effectively
yours to work on, now.

> (btw, if you will respond to this, i prefer Ctrl+Shift for text only
> zoom)

The options, from the bug, are Ctrl+Alt or Ctrl+Shift.  I don't know
how we'd choose, so I'd just pick one for your patch, implement it,
and if there's a reason to change it it'd be pretty easy to switch.

--~--~-~--~~~---~--~~
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: What's the real reason of giving up Windows 2000 support?

[Dan Kegel]

On Wed, Jun 24, 2009 at 10:50 PM, pi wrote:
> I presume that Chromium decided to support Windows 2000 when the
> project started in 2006. The reasons may be:
>
> (1) The profit is big. There were 6% Windows 2000 users in 2006.

I suspect this wasn't really on their minds; even back then, Windows 2000
wasn't really important on the desktop.

> (2) The cost is small. There should not be too many differences
> between Windows 2000 (5.0) and Windows XP (5.1).

That sounds more like it.

> Afterward, Chromium decided to cut out Windows 2000 when the project
> grew up in 2008. The reasons may be:
>
> (1) The profit is small. There were only 2% Windows 2000 users in
> 2008. Surely, there would be fewer users in future. Furthermore, most
> of these remaining users were in corporate environments that were
> locked-down against using chrome as a third party program.
>
> (2) The cost is big. Certain of functions need to be implemented
> cumbersomely for compatibility with Windows 2000. Moreover, some
> undocumented features of Windows 2000 lead to extra failures. For
> example, when initializing an impersonated thread of a restricted
> sandbox process, nt!ZwMapViewOfSection succeeds on Windows XP, but
> fails as 0xc022 STATUS_ACCESS_DENIED on Windows 2000.

Those seem reasonable.

> Is it right?

You forgot the other reason cost is big:

> cpu wrote:
>> Yes, the real reason is that there is an ongoing cost of keep that
>> version working including extra QA cycles for each release.

QA costs are significant.

Also, developer attention span is important.  If none of the
developers uses Win2K daily, it's semiexpensive for them to
switch context and think about Win2k issues.  (And by
extension, it's expensive for them to keep having to field
questions about Win2K :-)
- 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: Linux buildbots, which locale?

[Nicolas Sylvain]

On Thu, Jun 25, 2009 at 5:27 AM, Dean McNamee  wrote:

>
> I just took a look at what was happening on one of the Linux
> buildbots.  It looks like we completely clear the env and just
> explicitly set a few things.  We need to add LANG=en_US.UTF-8 to that
> list of things.  Any takers?


I can add LANG to the list of whitelisted env var to keep.  Would that work?

Nicolas

>
>
> Thanks
>
> On Thu, Jun 25, 2009 at 2:12 PM, Dean McNamee wrote:
> >
> http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio
> >
> http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio
> >
> > I just committed a change that converted our
> > sys_string_conversion_linux from using ICU UTF-8 (assuming that the
> > system locale was always UTF-8) to calling the system APIs that will
> > vary depending on the locale.  I believe this is technically what we
> > want, we want these APIs to do the conversion to whatever locale your
> > system is set to.
> >
> > On my machine these all pass fine.  I don't know what locale we have
> > set on the buildbots, but it all seems to fail.  It is also kind of
> > curious that some of our net/file tests depend on locale, but I
> > suppose that makes sense.
> >
> > For now I'll pull out my changes until we can get the buildbots on a
> > utf-8 locale (like en_US.UTF-8).
> >
> > -- 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] Re: about gtest's main in chromium

[Dan Kegel]

2009/6/24 Jickae Davis :
> ah, in fact, I don't really understand what the .gyp files do.
> Could the gtestmain be found in printing_unittests' project properties under
> VS2005?
> I have check that, and didn't find a gtestmain.lib in "Configuration
> Properties"-->"Linker"-->"Input".

I don't know about visual studio, but printing_unittests.mk (generated
on linux), I see

$(OBJS): | $(obj)/base/libbase.a
$(obj)/third_party/libevent/liblibevent.a
$(obj)/third_party/icu38/libicui18n.a
$(obj)/third_party/icu38/libicudata.a
$(obj)/third_party/icu38/libicuuc.a $(obj)/printing/libprinting.a
$(obj)/testing/libgtest.a $(obj)/testing/libgtestmain.a

If the visual studio gyp generator is similar,
gtestmain ought to end up in the same place libbase does.
- 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: Linux buildbots, which locale?

[Dean McNamee]

I just took a look at what was happening on one of the Linux
buildbots.  It looks like we completely clear the env and just
explicitly set a few things.  We need to add LANG=en_US.UTF-8 to that
list of things.  Any takers?

Thanks

On Thu, Jun 25, 2009 at 2:12 PM, Dean McNamee wrote:
> http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio
> http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio
>
> I just committed a change that converted our
> sys_string_conversion_linux from using ICU UTF-8 (assuming that the
> system locale was always UTF-8) to calling the system APIs that will
> vary depending on the locale.  I believe this is technically what we
> want, we want these APIs to do the conversion to whatever locale your
> system is set to.
>
> On my machine these all pass fine.  I don't know what locale we have
> set on the buildbots, but it all seems to fail.  It is also kind of
> curious that some of our net/file tests depend on locale, but I
> suppose that makes sense.
>
> For now I'll pull out my changes until we can get the buildbots on a
> utf-8 locale (like en_US.UTF-8).
>
> -- 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] Linux buildbots, which locale?

[Dean McNamee]

http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio

I just committed a change that converted our
sys_string_conversion_linux from using ICU UTF-8 (assuming that the
system locale was always UTF-8) to calling the system APIs that will
vary depending on the locale.  I believe this is technically what we
want, we want these APIs to do the conversion to whatever locale your
system is set to.

On my machine these all pass fine.  I don't know what locale we have
set on the buildbots, but it all seems to fail.  It is also kind of
curious that some of our net/file tests depend on locale, but I
suppose that makes sense.

For now I'll pull out my changes until we can get the buildbots on a
utf-8 locale (like en_US.UTF-8).

-- 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] Re: question about helpwanted items (how it works)

[PhistucK]

It means that it is a good bug to send patches for, that will not be fixed
soon by a Chromium developer.
If you want to start handling it, you should post a message to chromium-dev,
after you briefly thought about how to implement it and show some kind of a
brief design document, if needed, or just write briefly about the way you
are going to implement it.

If it is a small code change and nothing big, you can simply send a patch,
but it is always good to announce here or in the bug itself (or both?) that
you are starting to work on it, so it will be marked as "Started" and so
that the work will not be duplicated (even among contributors).

☆PhistucK


On Thu, Jun 25, 2009 at 13:37, nakro  wrote:

>
> when you mark an itemm as helpWanted, how is it supposed to work from
> there ?
>
> for example, i replied to
> http://code.google.com/p/chromium/issues/detail?id=6383
> a week ago, saying i want to do it and got to response
> or do you expect one to submit code for review and link it to the help
> wanted item ?
>
> (btw, if you will respond to this, i prefer Ctrl+Shift for text only
> zoom)
>
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] question about helpwanted items (how it works)

[nakro]

when you mark an itemm as helpWanted, how is it supposed to work from
there ?

for example, i replied to 
http://code.google.com/p/chromium/issues/detail?id=6383
a week ago, saying i want to do it and got to response
or do you expect one to submit code for review and link it to the help
wanted item ?

(btw, if you will respond to this, i prefer Ctrl+Shift for text only
zoom)



--~--~-~--~~~---~--~~
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: How do I deploy an NPAPI plugin over the internet from HTML ?

[Non-Stick]

OK.  Thanks for that Matt.  At least now I know I was using the wrong
mechanism.

So what is the recommended way to download and install an NPAPI Plugin
over the internet under Chrome ?

There are 4 files that I need to download (the plugin dll plus 3
helper files):
 npmyplugin.dll
 mylibrary.dll
 myprogA.exe
 myprogB.exe

--~--~-~--~~~---~--~~
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

[鵜飼文敏]

Hi,

2009/6/25 Hironori Bono (坊野 博典) 

> Hi Ukai-san,
>
> > ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
> > ViewHostMsg_WebSocketOpen: open a new Web Socket. called by
> WebSocketHandle::connect().
> > int request_id  // idenfity WebSocket object {GURL url, std::wstring
> protocol, std::wstring origin, bool secure, [...]}
> > ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web
> Socket connection.  called by WebSocketHandle::send().
> > int request_id  // Identify WebSocket object
> > std::vector data
> > ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection.
> called by WebSocketHandle destructor.
> > int request_id  // Identify WebSocket object
> > ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
> > ViewMsg_WebSocketConnect: New Web Socket connection is established. will
> call WebSocketHandle::client()->didConnect().
> > int request_id  // Identify WebSocket object
> > ViewMsg_WebSocketRecv: a frame containing data is received on the Web
> Socket connection. will add data into > WebSocketHandle::bufferedData().
>  Process all complete Web Socket frames, call
> WebSocketHandle::client()->didReceive().
> > int request_id  // Identify WebSocket object
> > std::vector data
> > ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other
> side).  will call WebSocketHandle::client()->didClose().
> > int request_id  // Identify WebSocket object
>
> I'm a little wondering whether  these messages are async messages or
> sync ones. Is it possible to add notes about their message types?


Yes.  I think all of these messages are "routed" and async messages.
Thanks for pointing it out.
-- 
ukai


>
>
> Regards,
>
> Hironori Bono
> E-mail: hb...@chromium.org
>

--~--~-~--~~~---~--~~
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

[坊野 博典]

Hi Ukai-san,

> ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
> ViewHostMsg_WebSocketOpen: open a new Web Socket. called by 
> WebSocketHandle::connect().
> int request_id  // idenfity WebSocket object {GURL url, std::wstring 
> protocol, std::wstring origin, bool secure, [...]}
> ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web 
> Socket connection.  called by WebSocketHandle::send().
> int request_id  // Identify WebSocket object
> std::vector data
> ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection. called 
> by WebSocketHandle destructor.
> int request_id  // Identify WebSocket object
> ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
> ViewMsg_WebSocketConnect: New Web Socket connection is established. will call 
> WebSocketHandle::client()->didConnect().
> int request_id  // Identify WebSocket object
> ViewMsg_WebSocketRecv: a frame containing data is received on the Web Socket 
> connection. will add data into > WebSocketHandle::bufferedData().  Process 
> all complete Web Socket frames, call WebSocketHandle::client()->didReceive().
> int request_id  // Identify WebSocket object
> std::vector data
> ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other 
> side).  will call WebSocketHandle::client()->didClose().
> int request_id  // Identify WebSocket object

I'm a little wondering whether  these messages are async messages or
sync ones. Is it possible to add notes about their message types?

Regards,

Hironori Bono
E-mail: hb...@chromium.org

--~--~-~--~~~---~--~~
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 Chris Evans 

> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
> wrote:
>
>> Hi,
>>
>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
>> design docs
>>
>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>
>> We'll send WebKit part to webkit-dev, if it looks ok.
>> We'd welcome if you could give us feedback on our design docs.
>
>
> Interesting feature :) It's hard to tell at first glance, because the
> security section is empty -- but it appears like security has been
> considered at least in
> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17.
>

>
> It might be worth being more explicit about security in our WebKit doc
> (i.e. creating a new security section).
>

Ok, I added the security section.
Anyway, the websocket protocol doc has "security considerations" section,
but no information there yet..


> Possible tests we'll want include:
>
> - Connect a web socket to some ordinary HTTP server and confirm that the
> connect fails.
> - Connect a web socket to a real web socket server that fails to return a
> websocket-origin header, and validate that the connect fails (if it didn't,
> a simple server bug could open up responses to all origins)
> - Check we respect the origin sent from the server.
> - What about redirectors? Assuming unsupported, verify that connecting to a
> redirector does not cause any redirection.
> - URL integration: what happens if a ws:// or wss:// URL is entered into
> the URL bar, or any other place an URL is accepted? (img tags, script tags
> etc).
> - What about embedded newline characters in the various strings the client
> gets to specify (URL, resource name, protocol etc). Ensure that no lines
> sent to the server can be caused to be split by doing this.
> - Length encoding: ensure we handle excessively long length encodings, e.g.
> 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that
> happen to be negative (or very large) when assigned to int32, int64, uint32,
> uint64.
> - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted
> ws:// channel, if that cookie was marked Secure. Similar test for
> Authorization headers.
>

Thanks for valuable test cases!  We'll test these case.

Thanks,
ukai

>
>
> Cheers
> Chris
>
>
>>
>> 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

[鵜飼文敏]

Hi,

2009/6/25 Drew Wilson 

> BTW, I checked in with IanH - it sounds like WebSockets are also on the
> Worker roadmap, so that's something to keep in mind while you iterate on
> your design.


Ok, I see.


> +1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
> common code as possible cross-platform - I'm looking at the Chromium worker
> code now, and there's a chunk of duplicated logic from the WebKit worker
> implementation, which is a bit of a maintenance headache.
>

Sure.
-- 
ukai



> -atw
>
> 2009/6/24 Michael Nordman 
>
> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
>> is a refcounted object and this design looks modeled off of that (which may
>> be why you've spec'd it this way). Unless your design actually needs
>> refcounting on this class, you may be able to simplify things without it.
>> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>>
>> > should we reuse WebCore/loader instead of adding new component?
>>
>> The loader is somewhat notorious for its complexity. I think you've made a
>> good decision to keep this out of there and to design the websocket system
>> in a good clean modular fashion.
>>
>> > which component is responsible of web socket protocol framing?  This
>> design assumes WebSocketChannel serializes/deserializes message in web
>> socket frame.
>>
>> Since WebSocketHandle is inevitably going to be platform specific, any
>> code you want to be shared code shouldn't be slated for that class. To the
>> extent the 'web socket protocol framing' can be done indepedent of the
>> 'platform' socket handle (which it looks like it can be), it would be a good
>> thing to put it in WebSocketChannel so its shared core common code goodness.
>>
>> > Regarding the "WebKit API", note that no WebCore data types can be used
>> there. So you'll need to create wrapper classes.
>>
>> I see you have speced WebKit:: wrapper classes with the same name as the
>> corresponding WebCore:: classes.
>>
>> I wonder if that same naming could be confusingt? The naming convention
>> darin has been employing would be WebKit::WebWebSocketHandle, which
>> certainly looks odd.
>>
>> * virtual void didReceiveData(const String& msg) {}
>>
>> Maybe rename this to channel client api to didReceiveMessage() to help
>> distinguish between raw 'data' being surface by the 'handle', and complete
>> 'messages' being surfaced by the 'channel'.
>>
>>
>> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > > wrote:
>>
>>> Hi,
>>>
>>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and
>>> write design docs
>>>
>>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>>
>>> We'll send WebKit part to webkit-dev, if it looks ok.
>>> We'd welcome if you could give us feedback on our design docs.
>>>
>>> Thanks,
>>> ukai
>>>
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

Thanks for review.

2009/6/25 Michael Nordman 

> Only skimmed thusfar as well... but from what i've seen, looks reasonable
> to me.
> * A version of the diagram you have in the chrome doc would be nice in the
> webkit doc too.
>

Sure.  I've added a diagram in webkit part.


> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
> is a refcounted object and this design looks modeled off of that (which may
> be why you've spec'd it this way). Unless your design actually needs
> refcounting on this class, you may be able to simplify things without it.
> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>

Yes.  I missed to add public RefCounted as base class of
WebSocketHandle.
 Thanks.

> 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?

> Regarding the "WebKit API", note that no WebCore data types can be used
> there. So you'll need to create wrapper classes.
>
> I see you have speced WebKit:: wrapper classes with the same name as the
> corresponding WebCore:: classes.
>
> I wonder if that same naming could be confusingt? The naming convention
> darin has been employing would be WebKit::WebWebSocketHandle, which
> certainly looks odd.
>

Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.


> * virtual void didReceiveData(const String& msg) {}
>
> Maybe rename this to channel client api to didReceiveMessage() to help
> distinguish between raw 'data' being surface by the 'handle', and complete
> 'messages' being surfaced by the 'channel'.
>

Sure. Fixed.

Thanks!
ukai


>
>
> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
> wrote:
>
>> Hi,
>>
>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
>> design docs
>>
>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>
>> We'll send WebKit part to webkit-dev, if it looks ok.
>> We'd welcome if you could give us feedback on our design docs.
>>
>> Thanks,
>> ukai
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

Hi,
Thanks for review.

2009/6/25 Jeremy Orlow 

> I only skimmed, but it looks well thought out.
> One question though:
> is this going to be functional for non-Chromium browsers?  Given that your 
> design doc mentions v8 and hooks into Chromium's network
> stack, but no mention of JavaScriptCore or WebKit's resource loading code,
> I'm worried that the answer is no.
>



> I strongly recommend that your design doc include details for full
> integration into "normal" WebKit and that you offer to write the necessary
> code.  If it's Chromium only, you'll definitely get more push back on the
> design and people will be less willing to review.  Probably to the extent
> that it would have been easier to just write the code to begin with.
>

v8 and hooks into chromium's network stack was written in chromium part
only.
I planed to send webkit part to webkit-dev.
I've mentioned what platform code is required in WebSocketHandle in webkit
part design doc.
I just added JavaScript binding section.
Do we need more detailed information for these part?

Thanks,
ukai


> J
>
> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
> wrote:
>
>> Hi,
>>
>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
>> design docs
>>
>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>
>> We'll send WebKit part to webkit-dev, if it looks ok.
>> We'd welcome if you could give us feedback on our design docs.
>>
>> Thanks,
>> ukai
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---