Please don't also copy chromium-dev on bugs you file, especially when
they're for esoteric cases like "there is a problem when I hack the DLL to
try and modify the keybindings".
PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubsc
Hi guys, I filed an issue here:
http://code.google.com/p/chromium/issues/detail?id=31048
The key conflict is very strange because it looks like terminal
function key escape codes
F1 ^[OP
F2 ^[OQ
F3 ^[OR
F4 ^[OS
Are there any terminal related source code mistakenly went into
Automatically closing tree for "compile" on "Chromium Builder (dbg)"
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15005
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29
--=> Automatically closing tree fo
This change is now complete. All of our LayoutTests are now
upstreamed, and there are no longer any tests under
src/webkit/data/layout_tests . The results are still under
webkit/data/layout_tests, however.
Note to webkit gardeners: you may see the newly-upstreamed tests show
up and start to fail,
Automatically closing tree for "compile" on "Chromium XP"
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/9352
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP
--=> Automatically closing tree for "compile" on "Chromium XP" <=--
Revision:
I noticed that the Linux printing implementation is not going through
the same PrintingContext framework.
Anyone know why?
I am interested in modifying the source to add the ability to suppress
printing in a cross-platform way. It looks like
PrintJobWorker::GetSettings implements a flag for
Automatically closing tree for "unit_tests" on "XP Tests"
http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/15885
http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests
--=> Automatically closing tree for "unit_tests" on "XP Tests" <=--
Revision: 35184
If you're in the Bay Area, you may find this interesting and/or worthwhile:
http://www.yuiblog.com/blog/2009/12/22/crockford-on-javascript/
Doug is brilliant and his talks are excellent. Most of them exist in
earlier versions available on video, if you can't make it or prefer
alternate viewing me
Automatically closing tree for "unit_tests" on "Modules Linux"
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux/builds/14690
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20Linux
--=> Automatically closing tree for "unit_tests" on "Modules Linux" <
On Tue, Dec 22, 2009 at 1:59 PM, Evan Martin wrote:
> For example close to my heart: my last stab at refactoring the way we
> query plugins ended up running into subtle issues with how the metrics
> service shuts down relative to the UI and IO loops. These pieces need
> to talk to one another bu
On Tue, Dec 22, 2009 at 9:05 AM, Jim Roskind wrote:
> I think it was a GIANT step forward when Chromium survived renderer crashes.
> I'm not all that clear that another level of process-division would
> increase robustness, and more importantly, increase customer satisfaction.
I think renderer p
By many accounts, Opera 10.5 (currently pre-alpha) provides excellent
Javascript performance competition and is faster than Chrome in many
performance benchmarks including Sunspider and Peacekeeper, and has
excellent competition in V8 benchmark.
http://www.google.com/search?q=opera+10.5+javascript
Hi PhistucK,
Chrome Frame is a good starting point for creating new CEF.
Unfortunately, it works only under Windows. And, as far as I
understand, there is no plans to support Chrome Frame for other OSes.
I investigated code a bit - as far as I got, Chromium Frame uses
Chrome Automation interface
I suspect that you could eventual create a minimal watchdog (uber browser?)
process, controlling a fleet of (more than one) browser process, each
browser process controlling one or more renderers (whew). The good news is
that such an architecture would probably get around some of CPU's sandbox
con
[bcc chromium-dev]
User questions are best sent to chromium-disc...@googlegroups.com.
chromium-dev@ is for engineering questions.
The continuous Chromium builds don't have h.264 support.
M-A
On Tue, Dec 22, 2009 at 6:13 AM, Richard Zhao wrote:
> I download
> http://build.chromium.org/buildbot
I download
http://build.chromium.org/buildbot/snapshots/chromium-rel-arm/35139/chrome-linux.zip.
It can not play html5 video. For example:
http://html5demos.com/video
http://www.youtube.com/html5
Thanks
Richard
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, c
16 matches
Mail list logo
