[chromium-dev] Re: [LTTF] Flaky tests and setTimeout
Most awesome. Very good catch. On Fri, Oct 9, 2009 at 9:52 PM, Julie Parent 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 loaded. > This leads to slower running, flaky tests. To address this, change the > tests upstream to use onload instead and make the world a better place :) > I'm converting all of the editing tests now. > > Julie > > > > -- "Portability is generally the result of advance planning rather than trench warfare involving #ifdef" -- Henry Spencer (1992) --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
On Fri, Oct 9, 2009 at 10:28 PM, Jickae Davis 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 dynamically-updating bar with a fraction of > "files-already-loaded/files-needed", just like Opera does. > Files-needed would have to get updated on the fly as well. While this might be possible, it's hard to say how useful it is--among other things, simply displaying a dynamic bar with loaded/needed could cause the progress bar to go backwards at certain points, which is not very informative. > But the problem is : where are the count-numbers of files? > There is no explicit count. As WebKit parses HTML, we queue up requests for resources that are encountered in that HTML. We only know we're "done" when there are no more pending requests. There is no way to tell in advance. --Amanda --~--~-~--~~~---~--~~ 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: [LTTF] Flaky tests and setTimeout
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 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 loaded. > This leads to slower running, flaky tests. To address this, change the > tests upstream to use onload instead and make the world a better place :) > I'm converting all of the editing tests now. > Julie > > > --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
> 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 the Chromium codebase. I know we left > out the progress bar on purpose, so I'd hate to see you spend a lot of time > to figure out how to implement this only to have the idea rejected at the > review stage because the UX team is not on board with the change. > > If this is intended for some port of the Chromium code, then you can ignore > this message. :) > I'm just curious about the problem of how to create such an overall progress bar for page loading. To contribute to chromiun as a team member is beautiful, but I'm afraid I can't think about that now, :). --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
> > 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 "files-already-loaded/files-needed", just like Opera does. But the problem is : where are the count-numbers of files? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [LTTF] Flaky tests and setTimeout
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 instead and make the world a better place :) I'm converting all of the editing tests now. Julie --~--~-~--~~~---~--~~ 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: Does Chromium MacOSX always create NSButtonCell for each html input submit button
On Fri, Oct 9, 2009 at 7:02 PM, hap 497 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 widget for each input submit button > so that each one of them can respond to user clicking. Chromium does not create any native UI widgets for input submit buttons. Neither does Safari. On the Mac they both use an NSButtonCell to help draw buttons that are not highly styled with CSS, but it's not a full featured native UI element (and as Avi noted, there's only one NSButtonCell, which is used to draw all unstyled buttons. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 28646
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" <=-- Revision: 28637, 28638, 28639, 28642, 28643, 28644, 28645, 28646 Blame list: hc...@chromium.org,j...@chromium.org,j...@chromium.org,mbel...@chromium.org,o...@chromium.org,t...@chromium.org Buildbot waterfall: http://build.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: Does Chromium MacOSX always create NSButtonCell for each html input submit button
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 pointer.
On Fri, Oct 9, 2009 at 4:55 PM, Stefan Nuxoll wrote:
> 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 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 widget for each input submit button
>> so that each one of them can respond to user clicking.
>>
>> I think I should have asked for 'NSButton' instead?
>>
>> Regarding www.google.com, it think it does use input submit button, so
>> why I am not see chromium calling ThemeChromiumMac.mm's paintButton()
>> or button() functions for www.google.com?
>> > name=btnI type=submit value="I'm Feeling Lucky" class=lsb>
>>
>> Thank you.
>>
>>
>> On Fri, Oct 9, 2009 at 2:20 PM, Avi Drissman wrote:
>>> 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 wrote:
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 wrote:
>
> 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 a input submit button
> when i load this test page:
>
>
>
>
> But when I load www.google.com (which has 2 input buttons), I don't
> see the same button() function gets called to create NSButtonCell.
>
> Can you please tell me where is the code which create native gui
> widget for input submit button for the case of www.google.com?
>
> Thank you.
>
> >>>
>>>
>>>
>>
>> >>
>>
>
>
>
> --
> Stefan Nuxoll
>
--~--~-~--~~~---~--~~
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: Does Chromium MacOSX always create NSButtonCell for each html input submit button
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 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 widget for each input submit button
> so that each one of them can respond to user clicking.
>
> I think I should have asked for 'NSButton' instead?
>
> Regarding www.google.com, it think it does use input submit button, so
> why I am not see chromium calling ThemeChromiumMac.mm's paintButton()
> or button() functions for www.google.com?
> name=btnI type=submit value="I'm Feeling Lucky" class=lsb>
>
> Thank you.
>
>
> On Fri, Oct 9, 2009 at 2:20 PM, Avi Drissman wrote:
>> 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 wrote:
>>>
>>> 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 wrote:
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 a input submit button
when i load this test page:
But when I load www.google.com (which has 2 input buttons), I don't
see the same button() function gets called to create NSButtonCell.
Can you please tell me where is the code which create native gui
widget for input submit button for the case of www.google.com?
Thank you.
>>>
>>>
>>
>>
>
> >
>
--
Stefan Nuxoll
--~--~-~--~~~---~--~~
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 expensive is setting a crash key for breakpad?
http://codereview.chromium.org/269039 ... On Wed, Oct 7, 2009 at 11:13 PM, Jeremy Moskovich 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. Generally this is used > // to configure Breakpad's internal operation, such as whether the > // crash_sender should prompt the user, or the filesystem location for > // the minidump file. See Breakpad.h for some parameters that can be > // set. Anything longer than 255 bytes will be truncated. Note that > // the string is converted to UTF8 before truncation, so any multibyte > // character that straddles the 255(256 - 1 for terminator) byte limit > // will be mangled. > // > // A maximum number of 64 key/value pairs are supported. An assert() > // will fire if more than this number are set. Unfortunately, right > // now, the same dictionary is used for both Breakpad's parameters AND > // the Upload parameters. > """ > If you look at the code that logs URLs you'll note that a URL is split over > several keys. > Best regards, > Jeremy > > On Wed, Oct 7, 2009 at 10:48 PM, Scott Hess wrote: >> >> In fixing a Mac bug, I recently added a layer to intercept >> -[NSApplication sendAction:to:from:] and make sure a certain message >> wasn't forwarded if the target was known to be freed. Since this is >> sort of a core function for event dispatch, now we're seeing >> crashdumps with my new method on the stack. I don't think it's a new >> problem. >> >> In researching it, I realize that it maybe gives us a hook for >> tracking down some very random browser crashers we see, where there's >> a stack of generic Cocoa methods. I could register a crash key which >> would report the action that is being sent, and the class of the >> sender. If there is anything interesting which could be derived about >> the potentially-freed target, that could be reported, too. AFAICT, >> it's a matter of calling SetCrashKeyValue() and ClearCrashKeyValue() >> at the appropriate spots. >> >> AFAICT, we don't dynamically call SetCrashKeyValue() anywhere, we >> mostly just call it a couple times at startup. Is the approach I >> suggest feasible? >> >> -scott >> >> PS: The kind of backtrace I'm speaking of are those associated with >> http://crbug.com/13111 . They used to look like: >> 0x9518c688 [libobjc.A.dylib + 0x00015688] objc_msgSend >> 0x953fddcb [AppKit + 0x00111dcb] -[NSControl >> sendAction:to:] >> 0x953fdc51 [AppKit + 0x00111c51] -[NSCell >> _sendActionFrom:] >> 0x953fd2aa [AppKit + 0x001112aa] -[NSCell >> trackMouse:inRect:ofView:untilMouseUp:] >> 0x953fcafd [AppKit + 0x00110afd] -[NSButtonCell >> trackMouse:inRect:ofView:untilMouseUp:] >> 0x953fc3b7 [AppKit + 0x001103b7] -[NSControl mouseDown:] >> 0x953faaf6 [AppKit + 0x0010eaf6] -[NSWindow sendEvent:] >> 0x953c76a4 [AppKit + 0x000db6a4] -[NSApplication >> sendEvent:] >> 0x95324fe6 [AppKit + 0x00038fe6] -[NSApplication run] >> 0x02517eb2 [Google Chrome Framework - >> message_pump_mac.mm:482] >> base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) >> 0x02517f97 [Google Chrome Framework - >> message_pump_mac.mm:146] >> base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) >> 0x025148f3 [Google Chrome Framework - >> message_loop.cc:199] MessageLoop::Run() >> 0x0218a0da [Google Chrome Framework - >> browser_main.cc:152] BrowserMain(MainFunctionParams const&) >> 0x020cadcf [Google Chrome Framework - >> chrome_dll_main.cc:603] ChromeMain >> 0x1fc5 [Google Chrome + 0x0fc5] >> >> Now they'll have a line like this at the top: >> 0x000ec978 [Google Chrome Framework - >> chrome_application_mac.mm:83] -[CrApplication sendAction:to:from:] >> >> That's where I can hook in to record a bit for breakpad. >> >> >> > > --~--~-~--~~~---~--~~ 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: Does Chromium MacOSX always create NSButtonCell for each html input submit button
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 respond to user clicking.
I think I should have asked for 'NSButton' instead?
Regarding www.google.com, it think it does use input submit button, so
why I am not see chromium calling ThemeChromiumMac.mm's paintButton()
or button() functions for www.google.com?
Thank you.
On Fri, Oct 9, 2009 at 2:20 PM, Avi Drissman wrote:
> 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 wrote:
>>
>> 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 wrote:
>>>
>>> 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 a input submit button
>>> when i load this test page:
>>>
>>>
>>>
>>>
>>> But when I load www.google.com (which has 2 input buttons), I don't
>>> see the same button() function gets called to create NSButtonCell.
>>>
>>> Can you please tell me where is the code which create native gui
>>> widget for input submit button for the case of www.google.com?
>>>
>>> Thank you.
>>>
>>> >>>
>>
>
>
--~--~-~--~~~---~--~~
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: Does Chromium MacOSX always create NSButtonCell for each html input submit button
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 wrote:
> 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 wrote:
>
>>
>> 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 a input submit button
>> when i load this test page:
>>
>>
>>
>>
>> But when I load www.google.com (which has 2 input buttons), I don't
>> see the same button() function gets called to create NSButtonCell.
>>
>> Can you please tell me where is the code which create native gui
>> widget for input submit button for the case of www.google.com?
>>
>> Thank you.
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Modules Linux, revision 28593
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" <=-- Revision: 28588, 28589, 28590, 28592, 28593 Blame list: e...@chromium.org,hc...@chromium.org,thes...@chromium.org Buildbot waterfall: http://build.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: Does Chromium MacOSX always create NSButtonCell for each html input submit button
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 wrote:
>
> 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 a input submit button
> when i load this test page:
>
>
>
>
> But when I load www.google.com (which has 2 input buttons), I don't
> see the same button() function gets called to create NSButtonCell.
>
> Can you please tell me where is the code which create native gui
> widget for input submit button for the case of www.google.com?
>
> Thank you.
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Does Chromium MacOSX always create NSButtonCell for each html input submit button
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 a input submit button when i load this test page: But when I load www.google.com (which has 2 input buttons), I don't see the same button() function gets called to create NSButtonCell. Can you please tell me where is the code which create native gui widget for input submit button for the case of www.google.com? Thank you. --~--~-~--~~~---~--~~ 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: Stack trace wrapping when filing bugs
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, Ojan Vafai wrote: > 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 wrote: > >> 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 >> textarea to be wide enough to not wrap lines when pasting in a stack trace. >> >> That way you get a readable stack trace in the bug. >> >> Best regards, >> Jeremy >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Stack trace wrapping when filing bugs
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 wrote: > 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 > textarea to be wide enough to not wrap lines when pasting in a stack trace. > > That way you get a readable stack trace in the bug. > > Best regards, > Jeremy > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
On Fri, Oct 9, 2009 at 11:15 AM, Jay Campan 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 > > shortcuts, and we're just frustrating them by not letting them use > standard > > control navigation keys (like Tab and Shift+Tab) that work throughout > > Windows. > I'll let Jonas comment as I am not sure I remember how we came up with > that design. Definitely. BTW, I just joined the accessibility team and I'm hoping to help continue much of the great work Jonas has done so far. He's thought about this a lot more than I have so far, though! > > 2. In addition, when any control in the toolbar gains focus via the > keyboard > > (or maybe always), the whole toolbar highlights in some subtle way > > indicating the whole toolbar is the containing region to the focused > > control. This enables the user to press left and right arrow keys as an > > additional way to move the focus to other controls in the toolbar - this > is > > similar to how when you have a radio button active, you can use arrows to > > change the selected radio button. However, if at any point they press > Tab > > or Shift+Tab, they'll navigate among all controls, on or off the toolbar, > > exactly as one would expect. > I see your point with the radio-buttons, but I am not entirely > convinced it would be good for the toolbar. > With radio buttons, using the arrows is the only way to focus another > button (when tab traversing only the selected radio-buttons of a group > gets focused). > Agreed. Personally I would prefer just supporting Tab and Shift+Tab, plus some extra shortcuts to jump to one or more controls - but I think there's a lot of room for innovation and compromise as long as Tab navigation isn't broken. - Dominic --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 28569
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 "compile" on "Chromium Builder (dbg)" <=-- Revision: 28562, 28564, 28565, 28566, 28567, 28568, 28569 Blame list: bre...@chromium.org,choc...@google.com,mpcompl...@chromium.org,osh...@chromium.org,pkast...@chromium.org,timur...@chromium.org,y...@chromium.org Buildbot waterfall: http://build.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] Stack trace wrapping when filing bugs
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 textarea to be wide enough to not wrap lines when pasting in a stack trace. That way you get a readable stack trace in the bug. Best regards, Jeremy --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
> +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 standard > control navigation keys (like Tab and Shift+Tab) that work throughout > Windows. I'll let Jonas comment as I am not sure I remember how we came up with that design. > 2. In addition, when any control in the toolbar gains focus via the keyboard > (or maybe always), the whole toolbar highlights in some subtle way > indicating the whole toolbar is the containing region to the focused > control. This enables the user to press left and right arrow keys as an > additional way to move the focus to other controls in the toolbar - this is > similar to how when you have a radio button active, you can use arrows to > change the selected radio button. However, if at any point they press Tab > or Shift+Tab, they'll navigate among all controls, on or off the toolbar, > exactly as one would expect. I see your point with the radio-buttons, but I am not entirely convinced it would be good for the toolbar. With radio buttons, using the arrows is the only way to focus another button (when tab traversing only the selected radio-buttons of a group gets focused). Jay --~--~-~--~~~---~--~~ 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: Chrome Keyboard Access, opinions?
On Fri, Oct 9, 2009 at 10:40 AM, Peter Kasting wrote: > On Fri, Oct 9, 2009 at 10:36 AM, Jay Campan wrote: > >> On Thu, Oct 8, 2009 at 6:32 PM, Finnur Thorarinsson >> wrote: >> >>> 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 to have a mode where you could switch between the buttons of >> the Toolbar using the left/right key, making them hot tracked when they are >> selected. >> > > That doesn't sound like any focus interface I've ever seen in Windows. > Therefore it seems like it will be confusing. Windows uses tab and > shift-tab to change focus. > +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 standard control navigation keys (like Tab and Shift+Tab) that work throughout Windows. I think we can do both. Here's one idea of how to merge both ideas: 1. The toolbar itself doesn't actually ever get focus. Pressing Alt+Shift+T focuses the first element in the toolbar, and Tab and Shift+Tab cycles through all possible controls. (I think if you keep pressing Tab you should end up in the browser content, but that's a separate discussion.) 2. In addition, when any control in the toolbar gains focus via the keyboard (or maybe always), the whole toolbar highlights in some subtle way indicating the whole toolbar is the containing region to the focused control. This enables the user to press left and right arrow keys as an additional way to move the focus to other controls in the toolbar - this is similar to how when you have a radio button active, you can use arrows to change the selected radio button. However, if at any point they press Tab or Shift+Tab, they'll navigate among all controls, on or off the toolbar, exactly as one would expect. - Dominic > If we focus the buttons, they'll have to deal with the keyboard events and >> traversal themselves. >> It's easier to have the ToolbarView doing it. >> > > I don't care how the underlying implementation works as long as the > appearance to the user matches normal conventions. But isn't there already > a concept of a taborder that buttons can sit in and have the focus manager > handle focus traversal automatically? > > PK > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
On Fri, Oct 9, 2009 at 10:36 AM, Jay Campan wrote: > On Thu, Oct 8, 2009 at 6:32 PM, Finnur Thorarinsson > wrote: > >> 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 to have a mode where you could switch between the buttons of > the Toolbar using the left/right key, making them hot tracked when they are > selected. > That doesn't sound like any focus interface I've ever seen in Windows. Therefore it seems like it will be confusing. Windows uses tab and shift-tab to change focus. If we focus the buttons, they'll have to deal with the keyboard events and > traversal themselves. > It's easier to have the ToolbarView doing it. > I don't care how the underlying implementation works as long as the appearance to the user matches normal conventions. But isn't there already a concept of a taborder that buttons can sit in and have the focus manager handle focus traversal automatically? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
On Thu, Oct 8, 2009 at 6:32 PM, Finnur Thorarinsson wrote: > 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 to have a mode where you could switch between the buttons of the Toolbar using the left/right key, making them hot tracked when they are selected. That's why the ToolbarView gets focused, so it receives the keyboard events and can deal with the traversal. If we focus the buttons, they'll have to deal with the keyboard events and traversal themselves. It's easier to have the ToolbarView doing it. Jay --~--~-~--~~~---~--~~ 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: Chrome Keyboard Access, opinions?
On Thu, Oct 8, 2009 at 6:32 PM, Finnur Thorarinsson wrote: > 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 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Linux, revision 28549
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" <=-- Revision: 28542, 28543, 28544, 28545, 28546, 28547, 28548, 28549 Blame list: ajw...@chromium.org,da...@chromium.org,mm...@chromium.org,pinker...@chromium.org,s...@chromium.org,tha...@chromium.org,t...@chromium.org Buildbot waterfall: http://build.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: Why SOCK_SEQPACKET?
On Fri, Oct 9, 2009 at 4:33 PM, Evan Martin wrote: > On Fri, Oct 9, 2009 at 7:42 AM, Ben Laurie 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 since the tree's > always closed. :( Dammit! :-) --~--~-~--~~~---~--~~ 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: My Linux experience got better with a new version of flash.
On Fri, Oct 9, 2009 at 9:06 AM, Scott Hess wrote: > On Fri, Oct 9, 2009 at 8:55 AM, Evan Martin 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 displayed is not the list of plugins >> that are *loaded* -- we only actually plugins in a per-plugin process, >> and only the first match, so having multiple libflashplayer.so should >> be fine. > > Hmm. Maybe I should try to re-create my setup, then. When I had the > 10.x player in /usr/whatever and the 7.x player in ~/.mozilla/plugins Probably http://code.google.com/p/chromium/issues/detail?id=21340 then. --~--~-~--~~~---~--~~ 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: My Linux experience got better with a new version of flash.
On Fri, Oct 9, 2009 at 8:55 AM, Evan Martin 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 displayed is not the list of plugins > that are *loaded* -- we only actually plugins in a per-plugin process, > and only the first match, so having multiple libflashplayer.so should > be fine. Hmm. Maybe I should try to re-create my setup, then. When I had the 10.x player in /usr/whatever and the 7.x player in ~/.mozilla/plugins (*), things like Google Finance would tell me to get flash to get the interactive graphs, and I'd get a LOT of plug-in-crashed infobars. When I removed the ~/.mozilla/plugins .so and restarted Chrome, Google Finance started showing me the whizzy graphs. (*) libflashplayer.so dated 2004-08-03. Yeah, I've surely been haxor'ed. [I don't know how relevant it is, but I used many versions of Firefox for years on this system, and have never felt excessively held back by flash. Don't get me wrong, less reliable than I'd have liked, but I cobbled together the system out of individual atoms found in my backyard, so I expected it to lack polish.] -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: My Linux experience got better with a new version of flash.
On Fri, Oct 9, 2009 at 7:59 AM, Scott Hess 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 newer deb from Adobe. > > Of course, that didn't fix it either. Eventually it bugged me enough > to do something else, so I figured "Maybe about:plugins?", and it gave > me a page, and I noticed that I had two flash plug-ins. Didn't tell > me where they were coming from, though. Eventually I found the second > plug-in in .mozilla/plugins. Being confident in my ability to restore > Firefox from the ground up, I nuked it from orbit. I would like this too. Part of the problem is that about:plugins is a plain HTML page -- it has no special privs -- so the information we provide on the page is constrained by the API and information we're willing to provide to random websites. It would be useful to have a more powerful page that includes plugin paths, but (as you mention before) it's not especially discoverable and we shouldn't expect every user to debug this themselves. (Also: the page also has a silly "enabled" column that is meaningless for us since (AFAIK) there's no way to change it.) The which-plugin-am-I-getting situation on Linux is *incredibly* confusing, in no small part due to the variety found on real-world systems. Check out this code: http://svn.beauchesne.info/gwenole/projects/nspluginwrapper/trunk/src/npw-config.c?revision=881&view=markup search for "usr" in there (and then keep jamming on ctl-g) to see the variety of paths that have existed. On top of that, on Debian systems you have two layers of symlinks around the alternatives system, and then seven different setups of that for just Flash: $ ls /etc/alternatives/*flash* | wc -l 7 And then there's also nspluginwrapper, and *also* that we only load plugins matching the bit-ness (32/64) of the browser binary, so some are silently dropped on startup... And *then* that if we print any diagnostic information about this while loading, that output ends up in layout tests so all tests fail. There's a --debug-plugin-loading flag I sometimes get users to use to help track down what a bug report is exactly reporting. > Given the history of ways to install things on Linux, I wonder if it > wouldn't be worth having additional information for that platform > about stuff like this. about:plugins tells me the filename to look > for, but not where to look. And about:plugins isn't very > discoverable, even if you know that you should be looking for > something - I think that if we see two versions of libflashplayer.so, > we can be pretty sure something is wrong. 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 displayed is not the list of plugins that are *loaded* -- we only actually plugins in a per-plugin process, and only the first match, so having multiple libflashplayer.so should be fine. --~--~-~--~~~---~--~~ 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: Building chromium stable
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 wrote: > Adding a few potentially interested people. > > On Fri, Oct 9, 2009 at 6:45 AM, Rozenkraft 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 dependencies. I could update the >> dependencies until chromium builds, but I would like to use the exact >> same version of every dependency than Google, since I chose chromium >> for my project (an internet kiosk prototype) because it leaks less >> memory and it's more secure, which are very important things for >> public computers with long uptimes. So having stable dependencies it's >> important for us. >> >> Anyway, I opened this issue: >> http://code.google.com/p/chromium/issues/detail?id=23038 >> and maruel tells me that somebody is working on the alternative >> solution proposed in one of the >> comments, so thanks. >> >> But given that the you are producing those automated DEPS for the 4.x >> branches but not for the 3.x stable branch, I'm starting to think that >> this isn't gonna happen in the current release cycle and I'll have to >> wait for the 4.x stable release, which again, is understandable cause >> I'm sure there are pretty solid technical reasons. >> >> So I'm wondering, whether in the meantime you could offer some kind of >> temporal fix for those of us in my same situation. For example, >> committing to the branch the DEPS used by google as "DEPS.internal". >> That way I can take a look, ignore the google specific stuff and make >> my own DEPS. I don't think it would take you more than 20 seconds per >> stable release (if I'm right in my assumptions about the nature of the >> problem) and it would be very appreciated. >> > > > > > --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 9, 2009 at 7:42 AM, Ben Laurie 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 since the tree's always closed. :( --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
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 the progress bar on purpose, so I'd hate to see you spend a lot of time to figure out how to implement this only to have the idea rejected at the review stage because the UX team is not on board with the change. If this is intended for some port of the Chromium code, then you can ignore this message. :) On Fri, Oct 9, 2009 at 06:12, Amanda Walker wrote: > On Fri, Oct 9, 2009 at 5:01 AM, Jickae Davis 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 be loaded and >> the size of the resources already loaded? >> > > 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. > > --Amanda > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] My Linux experience got better with a new version of flash.
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 bugged me enough to do something else, so I figured "Maybe about:plugins?", and it gave me a page, and I noticed that I had two flash plug-ins. Didn't tell me where they were coming from, though. Eventually I found the second plug-in in .mozilla/plugins. Being confident in my ability to restore Firefox from the ground up, I nuked it from orbit. Given the history of ways to install things on Linux, I wonder if it wouldn't be worth having additional information for that platform about stuff like this. about:plugins tells me the filename to look for, but not where to look. And about:plugins isn't very discoverable, even if you know that you should be looking for something - I think that if we see two versions of libflashplayer.so, we can be pretty sure something is wrong. [And I'm getting tired of not being able to use C-n in my compose windows. I had to dismiss four New Windows from just this email. I'm sure printing support will make me additionally happy on this front :-). Yes, I'll go file a bug or something.] -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Wed, Oct 7, 2009 at 8:09 PM, Evan Martin wrote: > On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley wrote: >> >> On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie wrote: >>> Why will it certainly not work? From what (little) I understand, >>> SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably >>> one could simulate that over SOCK_STREAM? >> >> There are multiple, concurrent writers to the socket. If you make >> assumptions about the kernel's behaviour, you might be able to come up >> with a workable framing protocol, but it's much better to use the >> correct socket type. > > 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 > --~--~-~--~~~---~--~~ 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: MSVC2005 vs Win7 PlatformSDK
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 wrote: > > 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 pm, "yu...@chromium.org" wrote: > > I tried this one: > > VS80sp1-KB949009-X64-INTL.exe > > > > On Oct 9, 12:06 am, Marc-Antoine Ruel wrote: > > > > > > > > > Did you try the right file? > > > > > On Thu, Oct 8, 2009 at 1:20 PM, yu...@chromium.org >wrote: > > > > > > When trying to install the hotfix on Win7/64 I'm getting following > > > > message: > > > > > > "The upgrade patch cannot be installed by the Windows Installer > > > > service > > > > because the program to be upgraded may be missing, or the upgrade > > > > patch > > > > may update a different version of the program. Verify that the > > > > program to be > > > > upgraded exists on your computer and that you have the correct > > > > upgrade patch." > > > > > > Any ideas how to fix that? > > > > > > Thanks, > > > > Yury > > > > > > On Sep 30, 9:39 pm, Stephen White wrote: > > > > > Just in case someone else runs into this: I recently installed > MSVC2005 > > > > and > > > > > the Win7 Platform SDK on my win7/64 machine and it gave me this > error at > > > > > link time: > > > > > shell32.lib(shguid.obj) : fatal error LNK1103: debugging > information > > > > > corrupt; recompile module > > > > > > > Installing hotfix 949009 ( > > > > > https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails) > > > > > fixed it. We currently have that hotfix listed in the build > instructions > > > > as > > > > > "to be confirmed" (it's still in beta). > > > > > > > Stephen > > > > > > > -- > > > > > All truth passes through three stages. First, it is ridiculed. > Second, it > > > > is > > > > > violently opposed. Third, it is accepted as being self-evident. -- > > > > > Schopenhauer > > > --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
On Fri, Oct 9, 2009 at 5:01 AM, Jickae Davis 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 be loaded and the > size of the resources already loaded? > 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. --Amanda --~--~-~--~~~---~--~~ 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: Building chromium stable
Adding a few potentially interested people. On Fri, Oct 9, 2009 at 6:45 AM, Rozenkraft 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 dependencies. I could update the > dependencies until chromium builds, but I would like to use the exact > same version of every dependency than Google, since I chose chromium > for my project (an internet kiosk prototype) because it leaks less > memory and it's more secure, which are very important things for > public computers with long uptimes. So having stable dependencies it's > important for us. > > Anyway, I opened this issue: > http://code.google.com/p/chromium/issues/detail?id=23038 > and maruel tells me that somebody is working on the alternative > solution proposed in one of the > comments, so thanks. > > But given that the you are producing those automated DEPS for the 4.x > branches but not for the 3.x stable branch, I'm starting to think that > this isn't gonna happen in the current release cycle and I'll have to > wait for the 4.x stable release, which again, is understandable cause > I'm sure there are pretty solid technical reasons. > > So I'm wondering, whether in the meantime you could offer some kind of > temporal fix for those of us in my same situation. For example, > committing to the branch the DEPS used by google as "DEPS.internal". > That way I can take a look, ignore the google specific stuff and make > my own DEPS. I don't think it would take you more than 20 seconds per > stable release (if I'm right in my assumptions about the nature of the > problem) and it would be very appreciated. > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Building chromium stable
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 dependency than Google, since I chose chromium for my project (an internet kiosk prototype) because it leaks less memory and it's more secure, which are very important things for public computers with long uptimes. So having stable dependencies it's important for us. Anyway, I opened this issue: http://code.google.com/p/chromium/issues/detail?id=23038 and maruel tells me that somebody is working on the alternative solution proposed in one of the comments, so thanks. But given that the you are producing those automated DEPS for the 4.x branches but not for the 3.x stable branch, I'm starting to think that this isn't gonna happen in the current release cycle and I'll have to wait for the 4.x stable release, which again, is understandable cause I'm sure there are pretty solid technical reasons. So I'm wondering, whether in the meantime you could offer some kind of temporal fix for those of us in my same situation. For example, committing to the branch the DEPS used by google as "DEPS.internal". That way I can take a look, ignore the google specific stuff and make my own DEPS. I don't think it would take you more than 20 seconds per stable release (if I'm right in my assumptions about the nature of the problem) and it would be very appreciated. --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
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. > On Fri, Oct 9, 2009 at 11:01, Jickae Davis 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 be loaded and >> the size of the resources already loaded? >> > > If you're trying to debug some slow-loading pages, or slow-network issues, > then about:net-internals page may be helpful. You can see outstanding > requests there, as well as recently completed requests and which part of > each request was most time-consuming etc. > --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
On Fri, Oct 9, 2009 at 11:01, Jickae Davis 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 be loaded and the > size of the resources already loaded? > If you're trying to debug some slow-loading pages, or slow-network issues, then about:net-internals page may be helpful. You can see outstanding requests there, as well as recently completed requests and which part of each request was most time-consuming etc. --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
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 Kasting > > On Mon, Sep 28, 2009 at 9:48 AM, Mike Pinkerton > wrote: > > On Mon, Sep 28, 2009 at 12:21 PM, PhistucK wrote: > >> Yeah, but some indication will be helpful, even the one IE has been > giving - > >> Do you not agree? > > > > I do not agree. > > I agree with pinkerton. This is useless detail. > > The thing I think users conceivably want is "when the page is really > slow to load, what's going on? Can I speed something up?" To some > degree, we get that with our status bubble, which pops up saying what > the browser is currently doing if it's been waiting a while. I > believe Glen had some ideas long ago about finding a way to indicate > this kind of thing better in the throbber, or if you hovered it, or > something. > > PK > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: MSVC2005 vs Win7 PlatformSDK
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 pm, "yu...@chromium.org" wrote: > I tried this one: > VS80sp1-KB949009-X64-INTL.exe > > On Oct 9, 12:06 am, Marc-Antoine Ruel wrote: > > > > > Did you try the right file? > > > On Thu, Oct 8, 2009 at 1:20 PM, yu...@chromium.org > > wrote: > > > > When trying to install the hotfix on Win7/64 I'm getting following > > > message: > > > > "The upgrade patch cannot be installed by the Windows Installer > > > service > > > because the program to be upgraded may be missing, or the upgrade > > > patch > > > may update a different version of the program. Verify that the > > > program to be > > > upgraded exists on your computer and that you have the correct > > > upgrade patch." > > > > Any ideas how to fix that? > > > > Thanks, > > > Yury > > > > On Sep 30, 9:39 pm, Stephen White wrote: > > > > Just in case someone else runs into this: I recently installed MSVC2005 > > > and > > > > the Win7 Platform SDK on my win7/64 machine and it gave me this error at > > > > link time: > > > > shell32.lib(shguid.obj) : fatal error LNK1103: debugging information > > > > corrupt; recompile module > > > > > Installing hotfix 949009 ( > > >https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails) > > > > fixed it. We currently have that hotfix listed in the build instructions > > > as > > > > "to be confirmed" (it's still in beta). > > > > > Stephen > > > > > -- > > > > All truth passes through three stages. First, it is ridiculed. Second, > > > > it > > > is > > > > violently opposed. Third, it is accepted as being self-evident. -- > > > > Schopenhauer --~--~-~--~~~---~--~~ 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: MSVC2005 vs Win7 PlatformSDK
I tried this one: VS80sp1-KB949009-X64-INTL.exe On Oct 9, 12:06 am, Marc-Antoine Ruel wrote: > Did you try the right file? > > On Thu, Oct 8, 2009 at 1:20 PM, yu...@chromium.org wrote: > > > > > > > When trying to install the hotfix on Win7/64 I'm getting following > > message: > > > "The upgrade patch cannot be installed by the Windows Installer > > service > > because the program to be upgraded may be missing, or the upgrade > > patch > > may update a different version of the program. Verify that the > > program to be > > upgraded exists on your computer and that you have the correct > > upgrade patch." > > > Any ideas how to fix that? > > > Thanks, > > Yury > > > On Sep 30, 9:39 pm, Stephen White wrote: > > > Just in case someone else runs into this: I recently installed MSVC2005 > > and > > > the Win7 Platform SDK on my win7/64 machine and it gave me this error at > > > link time: > > > shell32.lib(shguid.obj) : fatal error LNK1103: debugging information > > > corrupt; recompile module > > > > Installing hotfix 949009 ( > >https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails) > > > fixed it. We currently have that hotfix listed in the build instructions > > as > > > "to be confirmed" (it's still in beta). > > > > Stephen > > > > -- > > > All truth passes through three stages. First, it is ridiculed. Second, it > > is > > > violently opposed. Third, it is accepted as being self-evident. -- > > > Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
