I tried this one:
VS80sp1-KB949009-X64-INTL.exe
On Oct 9, 12:06 am, Marc-Antoine Ruel mar...@chromium.org wrote:
Did you try the right file?
On Thu, Oct 8, 2009 at 1:20 PM, yu...@chromium.org yu...@chromium.orgwrote:
When trying to install the hotfix on Win7/64 I'm getting following
Well, I agree with PhistucK. I think a progress bar may help though it's not
so accurate.
By the way, if I want to add such a bar with chromium, how should I start?
Is there a method that tells the size of the resources to be loaded and the
size of the resources already loaded?
2009/9/29 Peter
On Fri, Oct 9, 2009 at 11:01, Jickae Davis jick...@gmail.com wrote:
Well, I agree with PhistucK. I think a progress bar may help though it's
not so accurate.
By the way, if I want to add such a bar with chromium, how should I start?
Is there a method that tells the size of the resources to
3x,Paweł .
I'm not trying to debug slow-loading pages. I'm reading chromium's src codes
and wondering how to add a loading-progress bar based on chromium.
Maybe I will to give a try to add such a bar.
2009/10/9 Paweł Hajdan Jr. phajdan...@chromium.org
On Fri, Oct 9, 2009 at 11:01, Jickae Davis
As a few of you know, I've been trying to build a stable version of
chromium for a month now. The problem is the DEPS file of the 195
branch is outdated so it has wrong dependencies. I could update the
dependencies until chromium builds, but I would like to use the exact
same version of every
Adding a few potentially interested people.
On Fri, Oct 9, 2009 at 6:45 AM, Rozenkraft rozenkr...@gmail.com wrote:
As a few of you know, I've been trying to build a stable version of
chromium for a month now. The problem is the DEPS file of the 195
branch is outdated so it has wrong
On Fri, Oct 9, 2009 at 5:01 AM, Jickae Davis jick...@gmail.com wrote:
Well, I agree with PhistucK. I think a progress bar may help though it's
not so accurate.
By the way, if I want to add such a bar with chromium, how should I start?
Is there a method that tells the size of the resources to
Ah, I let Microsoft update to do all the updates for me and it worked fine.
-Mohamed
On Fri, Oct 9, 2009 at 4:44 AM, yu...@chromium.org yu...@chromium.orgwrote:
I installed VS80sp1-KB949009-X86-INTL.exe and it works fine. Sorry, I
forgot that VS is 32 bit.
Thanks,
Yury
On Oct 9, 12:21
On Wed, Oct 7, 2009 at 8:09 PM, Evan Martin e...@chromium.org wrote:
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote:
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote:
Why will it certainly not work? From what (little) I understand,
SOCK_SEQPACKET adds
Of course, it didn't ACTUALLY get better until I got annoyed enough to
figure out how to upgrade my system's version of flash. I went out
and followed web instructions for apt-removing the older version and
installed the newer deb from Adobe.
Of course, that didn't fix it either. Eventually it
As I understand it, you are talking about adding an overall progress bar for
page loading and showing the progress bar somewhere in the Chrome UI.
If that is the case, then bear in mind that you need buy-in from the UX team
before you add the UI element to the Chromium codebase. I know we left out
On Fri, Oct 9, 2009 at 7:42 AM, Ben Laurie b...@chromium.org wrote:
If anyone gets the chance, I would happily pre-LGTM a change that
stuffs some comments near this code explaining the reasoning for this.
http://codereview.chromium.org/270041
AGL beat you to it, but maybe he didn't commit it
I hate to be a pest about this, but I've asked about this more than
once because I think it's really really important.
How can I help make it happen?
On Fri, Oct 9, 2009 at 5:49 AM, Marc-Antoine Ruel mar...@chromium.org wrote:
Adding a few potentially interested people.
On Fri, Oct 9, 2009
On Fri, Oct 9, 2009 at 7:59 AM, Scott Hess sh...@chromium.org wrote:
Of course, it didn't ACTUALLY get better until I got annoyed enough to
figure out how to upgrade my system's version of flash. I went out
and followed web instructions for apt-removing the older version and
installed the
On Fri, Oct 9, 2009 at 8:55 AM, Evan Martin e...@chromium.org wrote:
We de-duplicate multiple instances of the same file. If you have
multiple copies of the same file we attempt to prioritize
non-nspluginwrapper versions over nspluginwrapper-wrapped versions.
After that, the list of plugins
On Fri, Oct 9, 2009 at 9:06 AM, Scott Hess sh...@chromium.org wrote:
On Fri, Oct 9, 2009 at 8:55 AM, Evan Martin e...@chromium.org wrote:
We de-duplicate multiple instances of the same file. If you have
multiple copies of the same file we attempt to prioritize
non-nspluginwrapper versions
On Fri, Oct 9, 2009 at 4:33 PM, Evan Martin e...@chromium.org wrote:
On Fri, Oct 9, 2009 at 7:42 AM, Ben Laurie b...@chromium.org wrote:
If anyone gets the chance, I would happily pre-LGTM a change that
stuffs some comments near this code explaining the reasoning for this.
Automatically closing tree for unit_tests on Chromium Linux
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux/builds/6670
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux
--= Automatically closing tree for unit_tests on Chromium Linux =--
On Thu, Oct 8, 2009 at 6:32 PM, Finnur Thorarinsson fin...@chromium.orgwrote:
Maybe it's just me, but I don't see the point in making a toolbar as a
whole focusable. The keyboard shortcut should put focus on the first element
in the toolbar and tab should cycle focus from there.
^^^ this
PK
On Thu, Oct 8, 2009 at 6:32 PM, Finnur Thorarinsson fin...@chromium.orgwrote:
Maybe it's just me, but I don't see the point in making a toolbar as a
whole focusable. The keyboard shortcut should put focus on the first element
in the toolbar and tab should cycle focus from there.
The goal was
+1. To a beginner, left and right arrow might be more intuitive and an
opportunity for us to innovate. But millions of people use screenreaders,
have trouble using the mouse, or are just power users who love keyboard
shortcuts, and we're just frustrating them by not letting them use
crbug.com appears to wrap input to the width of it's textarea, that means
that if you paste a stack trace into a bug at the default width the output
is wrapped and becomes really hard to read. e.g. http://crbug.com/24172 .
It would be really helpful if people dragged the little grabber on the
Automatically closing tree for compile on Chromium Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/11772
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29
--= Automatically closing tree for
On Fri, Oct 9, 2009 at 11:15 AM, Jay Campan jcam...@chromium.org wrote:
+1. To a beginner, left and right arrow might be more intuitive and an
opportunity for us to innovate. But millions of people use
screenreaders,
have trouble using the mouse, or are just power users who love keyboard
This seems like a Google Code bug to me. Pasting stacktraces should be a
use-case Google Code cares about. Have you filed a bug with them?
Ojan
On Fri, Oct 9, 2009 at 11:17 AM, Jeremy Moskovich jer...@chromium.orgwrote:
crbug.com appears to wrap input to the width of it's textarea, that means
The relevant bug on Google Code's issue tracker is
http://code.google.com/p/support/issues/detail?id=1972 .
Until they get a chance to implement this, could people please take care to
resize the text input field so we get readable stack traces?
Thanks,
Jeremy
On Fri, Oct 9, 2009 at 12:16 PM,
Hi,
Does Chromium MacOSX always create NSButtonCell for each html input
submit button?
I put a printf() statement in ThemeChromiumMac.mm:
static NSButtonCell* button(ControlPart part, ControlStates states,
const IntRect zoomedRect, float zoomFactor).
It gets called and create a NSButtonCell for
You found it.
At the beginning of the function you see:
*static* NSButtonCell *buttonCell;
//...
if (!buttonCell) {
There is only one cell created ever, and it's reused.
Avi
On Fri, Oct 9, 2009 at 4:20 PM, hap 497 hap...@gmail.com wrote:
Hi,
Does Chromium MacOSX always
Automatically closing tree for unit_tests on Modules Linux
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux/builds/11960
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20Linux
--= Automatically closing tree for unit_tests on Modules Linux =--
Oh, and google.com has custom buttons which may or may not go through that
function at all (I haven't checked).
Avi
On Fri, Oct 9, 2009 at 4:44 PM, Avi Drissman a...@chromium.org wrote:
You found it.
At the beginning of the function you see:
*static* NSButtonCell *buttonCell;
Sorry, maybe I used a wrong term in asking my question.
I think I am looking for the code which chormium create a native UI
widget for each html input submit button in the html source. I assume
chromium needs to use 1 native UI widget for each input submit button
so that each one of them can
http://codereview.chromium.org/269039 ...
On Wed, Oct 7, 2009 at 11:13 PM, Jeremy Moskovich jer...@chromium.org wrote:
That sounds like a great idea!!
Note that there are some limits on crash keys, here's the relevant quote
from breakpad.h:
// User defined key and value string storage.
Google.com uses custom styling, so chances are a NSButton is not being
created since you can't style OS X widgets (without considerable
resource hacking, at least). It would be better if you just made a
local HTML test page for this.
On Fri, Oct 9, 2009 at 5:02 PM, hap 497 hap...@gmail.com
Thank you. I did test it with a local test page which just 1 input
submit button.
But for the case of button with custom styling (like google.com), what
kind of widget, which respond to mouse clicking, chromium will create
to put that on the page during renderering?
Thank you for any more
Automatically closing tree for archived build on Chromium XP
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/7913
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP
--= Automatically closing tree for archived build on Chromium XP =--
On Fri, Oct 9, 2009 at 7:02 PM, hap 497 hap...@gmail.com wrote:
Sorry, maybe I used a wrong term in asking my question.
I think I am looking for the code which chormium create a native UI
widget for each html input submit button in the html source. I assume
chromium needs to use 1 native UI
For those of you looking into flaky tests -
I've found a surprising number of tests that are flaky because they use a
setTimeout to guarantee that a resource (usually an iframe) has loaded.
This leads to slower running, flaky tests. To address this, change the
tests upstream to use onload
No--there is in fact no way to determine that in advance. Each resource
can reference other resources, and even for a single resource we often don't
know what size it is until we finish loading it.
We could provide a dynamically-updating bar with a fraction of
As I understand it, you are talking about adding an overall progress bar
for page loading and showing the progress bar somewhere in the Chrome UI.
yes, I'm interested in chromium.
If that is the case, then bear in mind that you need buy-in from the UX
team before you add the UI element to
YAY! :) Begone ye setTimeout!
setTimeout is also lame because it makes the tests run slower.
-eric
On Fri, Oct 9, 2009 at 9:52 PM, Julie Parent jpar...@chromium.org wrote:
For those of you looking into flaky tests -
I've found a surprising number of tests that are flaky because they use a
On Fri, Oct 9, 2009 at 10:28 PM, Jickae Davis jick...@gmail.com wrote:
No--there is in fact no way to determine that in advance. Each resource
can reference other resources, and even for a single resource we often don't
know what size it is until we finish loading it.
We could provide a
Most awesome. Very good catch.
On Fri, Oct 9, 2009 at 9:52 PM, Julie Parent jpar...@chromium.org wrote:
For those of you looking into flaky tests -
I've found a surprising number of tests that are flaky because they use a
setTimeout to guarantee that a resource (usually an iframe) has
42 matches
Mail list logo
