[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 36338
Automatically closing tree for compile on Chromium Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15588 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29 --= Automatically closing tree for compile on Chromium Builder (dbg) =-- Revision: 36337, 36338 Blame list: a...@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
Re: [chromium-dev] Re: Keyboard codes to use for a chrome extension api that enables automation?
I still believe that basing anything on keycode, although an obvious
thing to do, will leave lead to unnecessary fragility in the users of
this API. I understand that we ultimately will be generating
WebInputEvents, but the level of abstraction used by the API should be
a level higher than as proposed here.
I say this as a potential user of the API --- this would allow me to
significantly reduce the amount of code necessary for providing good
browser automation support for Chrome via WebDriver. With the current
suggested API, I'd have to wrap it with a large amount of additional
code to ensure it does what my users expect when the keyboard mapping
isn't a straight 104 key Windows US keyboard.
Please reconsider.
Simon
On Fri, Jan 15, 2010 at 7:27 AM, Darin Fisher da...@chromium.org wrote:
Ultimately, I believe we'll need to generate a sequence of WebKeyboardEvent
objects from this data.
(See http://trac.webkit.org/browser/trunk/WebKit/chromium/public/WebInputEvent.h)
WebKeyboardEvent is the data that we send to WebKit corresponding to a
keyboard event. I think it is reasonable to base the extension API on this
structure.
-Darin
On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni dmazz...@google.com
wrote:
Hi Darin,
Erik suggested you might have some thoughts. In my proposed extension
api for accessibility (http://codereview.chromium.org/402099) one of
the functions is to simulate a key press. How should the client
express the key they would like to press? The current proposed
function prototype is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Date of M5 drop?
I agree, it would be helpful, that is part of why the calendar was set up in the first place (it seems). ☆PhistucK On Thu, Jan 14, 2010 at 23:35, Robert Sesek rse...@chromium.org wrote: On Thu, Jan 14, 2010 at 4:21 PM, Peter Kasting pkast...@google.comwrote: On Thu, Jan 14, 2010 at 4:48 AM, OwenCM owencmo...@googlemail.comwrote: Hi, I've been scouring the groups and can't find the answer anywhere, what time scale are we looking at until the dev branch hits m5? If you're looking for a branch date for version 5, we don't generally announce those, I don't think. There used to be dates for M4 on the release calendarhttp://dev.chromium.org/developers/calendar. There aren't any events for M5, though. As an external contributor, I think it'd be helpful to have this information available. rsesek / @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 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 rebuild after modifying extension_api.json?
I've observed that after modifying extension_api.json and rebuilding on Linux (using make via distcc), often the entire extension api stops working, with no error message. A clean build always solves the problem. Is there some file I need to touch after modifying extension_api.json in order for the correct dependencies to rebuild? I noticed that json_schema.js has a note at the top saying you should touch renderer_resources.grd after modifying it. Is this related? How hard would it be to make the build system handle this? - Dominic -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How to rebuild after modifying extension_api.json?
On Fri, Jan 15, 2010 at 9:19 AM, Dominic Mazzoni dmazz...@google.com wrote: I've observed that after modifying extension_api.json and rebuilding on Linux (using make via distcc), often the entire extension api stops working, with no error message. A clean build always solves the problem. Is there some file I need to touch after modifying extension_api.json in order for the correct dependencies to rebuild? $ git grep extension_api.json -- '*.gyp*' | wc -l 0 That is, this file is not ever mentioned to the build system. The problem is that a .grd file uses the .json file when building but that isn't explicitly told to gyp. In C++ we rely on the per-platform build system to figure out they do the same thing (an #include); for gyp we should just require people to keep the gyp file in sync. The place to look at fixing this is the .gyp* files where common_resources.grd is built; it should list this .json file as an input and it doesn't. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How to rebuild after modifying extension_api.json?
Actually, it think it's sorta captured -- chrome.gyp has chrome_resources_inputs, which is created by running a script to figure out the input from the grd files. Looking at my xcode project, there is a dependency on common/extensions/api/extension_api.json for the grd files listed in chrome_resources_grds. TVL On Fri, Jan 15, 2010 at 12:50 PM, Evan Martin e...@chromium.org wrote: On Fri, Jan 15, 2010 at 9:19 AM, Dominic Mazzoni dmazz...@google.com wrote: I've observed that after modifying extension_api.json and rebuilding on Linux (using make via distcc), often the entire extension api stops working, with no error message. A clean build always solves the problem. Is there some file I need to touch after modifying extension_api.json in order for the correct dependencies to rebuild? $ git grep extension_api.json -- '*.gyp*' | wc -l 0 That is, this file is not ever mentioned to the build system. The problem is that a .grd file uses the .json file when building but that isn't explicitly told to gyp. In C++ we rely on the per-platform build system to figure out they do the same thing (an #include); for gyp we should just require people to keep the gyp file in sync. The place to look at fixing this is the .gyp* files where common_resources.grd is built; it should list this .json file as an input and it doesn't. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How to rebuild after modifying extension_api.json?
On Fri, Jan 15, 2010 at 9:57 AM, Thomas Van Lenten thoma...@chromium.org wrote: Actually, it think it's sorta captured -- chrome.gyp has chrome_resources_inputs, which is created by running a script to figure out the input from the grd files. Looking at my xcode project, there is a dependency on common/extensions/api/extension_api.json for the grd files listed in chrome_resources_grds. I stand corrected! In the makefile it ends up with a layer of indirection due to grit having two outputs, so it works like this: - gen/chrome/grit/browser_resources.h depends on the .json - gen/chrome/browser_resources.pak depends on gen/chrome/grit/browser_resources.h - and then the eventual browser .pak files depend on those I would try: build once, touch, the .json file, then build again and see which piece is failing to rebuild. (Also try the same but try running the build twice in a row; there are probably still some bugs there.) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
Hey everyone, My name's Alex Gartrell and my friend Mark Hahnenberg and I are taking a class at CMU called Software Engineering Practicum, and the sole purpose of this class is to participate in a large project. This semester, they've opened the door to working with open source projects, and we would really love to do work on Chrome, a browser we both use. For this project, we'll be offering up 20 hours a week (10 hours each) in exchange for weekly guidance from a 'client' as well as two progress reports for our professor. More information is available at http://www.cs.cmu.edu/~aldrich/courses/15-413/clients.html Experience: - We're juniors at Carnegie Mellon and have worked our way through many of the hard project courses, including Operating Systems Implementation - We both submitted patches that were accepted to Mozilla as part of the prerequisite course to this one (So we know about dvcs, the patch submission process, etc.) - We both have worked as interns in industry after our Sophomore Year (Mark at Mozilla, myself at Cisco) We're pretty open minded as far as the actual project is concerned. One thing that was suggested to me in the irc by rubenbb was working with SPDY. I'm kind of a networks geek (doing some research stuff in that arena), so that'd be cool. But really, anything cool would be good. Another thing worth noting is that I also TA'ed the prereq course last semester and two students (one of whom actually lives with us) were able to submit some patches that were accepted to Chromium, so we know that people have had good experiences working with you guys, and we're excited to continue that. Thanks! Alex Gartrell (agartr...@cmu.edu) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
The problem I have with using only explicitly defined action functions
is that the whole point of simulating keyboard events is to test
whether or not the user interface is accessible using the keyboard!
(This is not just an issue for people using assistive technology like
a screen reader: there are a few things in Chrome that are impossible
to access without using a mouse now.)
I want to be able to write tests that try to edit bookmarks using the
Bookmark Manager, or change settings using the Options dialog, for
example. Having functions like selectNextBookmark() wouldn't help test
that they're actually accessible via the keyboard.
There aren't that many different keys needed for keyboard
accessibility: off the top of my head, you mostly need tab, shift-tab,
space, enter, and arrow keys - plus a few shortcuts to open a menu or
move the focus to a certain panel. What about having functions for
each of these keys plus other actions that can be triggered via a
keyboard shortcut?
tabToNextControl()
tabToPreviousControl()
pressSpaceBar()
pressEnterKey()
pressEscapeKey()
arrowUp()
arrowDown()
arrowLeft()
arrowRight()
openOptionsDialog()
openBookmarksManager()
focusLocationBar()
...
Then, in order to enter text into a text box in a dialog, perhaps a
function that pastes unicode text at the current cursor position would
be much easier than trying to deal with key codes and input methods.
- Dominic
On Fri, Jan 15, 2010 at 3:24 AM, James Su su...@google.com wrote:
Hi Nico,
I totally agree with your point. Using fake keyboard events for
accessibility things would lead to compatibility nightmare. We should
consider the approach of using explicitly defined action functions rather
than emulating keyboard events. The keyboard events approach has at least
following unsolvable problems:
1. Compatibility issue among different OS platforms.
2. Compatibility issue caused by user customized shortcuts.
3. Supports of different keyboard layouts.
4. Supports of inputting non-Latin text.
Regards
James Su
2010/1/15 Nico Weber tha...@chromium.org
On Thu, Jan 14, 2010 at 8:37 AM, Dominic Mazzoni dmazz...@google.com
wrote:
On Thu, Jan 14, 2010 at 8:19 AM, Nico Weber tha...@google.com wrote:
It probably depends if you want to use this for text input or action
inputs. A text-to-speech extension would probably want to set unicode
characters, while something that (say) hits cmd-f to open the find bar
probably wants to use keycodes.
Text-to-speech is a different problem; this is for actions.
For example, on OS X hitting cmd-f with a hiragana keyboard layout
opens the findbar, while just pressing f opens an IME.
If you want to use this for actons, I would find it more useful to
have a performUiAction() function instead though, since keyboard
shortcuts are different across platforms (all mac shortcuts use cmd
instead of ctrl for example, and the letters for a few shortcuts are
different on OS X too for various reasons).
I completely agree; I would like to add many functions along the lines
of performUiAction. However, there are a few actions for which typing
a key really is the right thing to do - for example pressing Tab to
move to the next control.
Maybe performUiAction('focusNextViewInKeyLoop')?
(By the way, OS X has a system-level setting that configures if tab
should focus only text fields or all controls such as buttons etc. I
don't think Chrome/Mac honors it, but I think there are plans to
support it. Stuff like this is surprising for a caller that sends
tab characters, while an explicit focus next element function
could have clearly defined semantics).
There's also testing. This function will allow you to use only
javascript to test that a particular capability can be accessed using
only the keyboard. I'm already using this for testing this API, by
simulating pressing Ctrl+L to focus the location bar and then checking
to see that the proper focus event is generated.
Some (most?) accessibility shortcuts will vary by platform too. For
example, focus toolbar is ctrl-f5 on OS X, but only if full keyboard
access has been enabled (ctrl-f1). Cocoa the OS X framework don't
always trigger with synthetic keyboard events. (I'm not an a11y expert
– Avi, comments?)
So the way I look at it is: there are some great uses for this
function. There are also things that this function could be used for
but there'd be a better way. It could also be abused to do things that
make no sense.
I don't think that's an argument not to allow the function; I think it
just means we should make sure it's defined properly for the intended
use, and over time try to provide better alternatives for other
possible uses.
- Dominic
Nico
On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni dmazz...@google.com
wrote:
Hi Darin,
Erik suggested you might have some thoughts. In my proposed extension
api for accessibility
[chromium-dev] Ajax maximum response size
Hello, I am implementing 3D rendering engine for Chromium and I need to download huge scenes via Ajax. However I've noticed that asyncronous Ajax requests are limited to 7-8 MB in size. If I try to download more -- tab crashes (and in --single-process-mode everything crashes in onNoMemory function). Synchronous requests work better -- I was able to download 100M file, but the browser footprint in memory grew like a monster -- it took a whole of 3GB to download a single 100M file. Interesting enough that after downloading it it remained to take all this place. Does it make 30 copies out of it? There should be something wring with it. I am using jQuery for ajax and the code is here http://tinypaste.com/6f7d9. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
On Thu, Jan 14, 2010 at 9:54 PM, Alex Gartrell alexgartr...@gmail.comwrote: - We both submitted patches that were accepted to Mozilla as part of the prerequisite course to this one (So we know about dvcs, the patch submission process, etc.) One thing to note is that Chromium uses neither a distributed VC system nor Bugzilla, so your development process will look a little different than with Mozilla patches. That said, hopefully it shouldn't be hard to accommodate. We're pretty open minded as far as the actual project is concerned. One thing that was suggested to me in the irc by rubenbb was working with SPDY. I'm kind of a networks geek (doing some research stuff in that arena), so that'd be cool. But really, anything cool would be good. Are you looking to work together on the project or separately? And are you looking for a single, larger task, or a lot of smaller issues? I have a number of smaller bugs I could throw at you but I'd only want to do that if that's your interest :) Your first task should be to get the code checked out, built, and perhaps running in a debugger. Start at http://dev.chromium.org/Home and look for your OS of choice in the second bullet point; that should get you going. The majority of Chromium developers work in Windows with MSVC, but there are healthy numbers of Mac and Linux folks too. If you have problems, come hang out on irc.freenode.net #chromium; that's the best place to get quick answers. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Ajax maximum response size
Ever think of using Web Sockets? 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 Builder, revision 36378
Automatically closing tree for compile on Chromium Builder http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder --= Automatically closing tree for compile on Chromium Builder =-- Revision: 36378 Blame list: jia...@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: buildbot failure in Chromium on Chromium Builder, revision 36378
Fix is in as of r36382; reopening. Stephen On Fri, Jan 15, 2010 at 1:57 PM, build...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/ Automatically closing tree for compile on Chromium Builder http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515 Revision: 36378 Blame list: jia...@chromium.org Chromium Builder Build 21515http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515/steps/shell_1/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515/steps/shell_2/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515/steps/gclient/logs/stdio compile failed stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/21515/steps/compile/logs/stdio Changed by: *jia...@chromium.org* Changed at: *Fri 15 Jan 2010 10:50:08* Branch: *src* Revision: *36378*http://src.chromium.org/viewvc/chrome?view=revrevision=36378 Changed files: - *app/clipboard/clipboard_util_win.cc* - *app/os_exchange_data.cc* - *app/os_exchange_data.h* - *app/os_exchange_data_provider_win.cc* - *app/os_exchange_data_provider_win.h* - *app/os_exchange_data_win_unittest.cc* - *base/base_drag_source.cc* - *base/base_drag_source.h* - *base/base_drop_target.cc* - *base/base_drop_target.h* - *base/file_util.h* - *base/file_util_win.cc* - *base/message_loop_unittest.cc* - *base/message_pump_win.cc* - *base/message_pump_win.h* - *chrome/browser/cocoa/download_item_mac.h* - *chrome/browser/dom_ui/downloads_dom_handler.h* - *chrome/browser/download/download_exe.cc* - *chrome/browser/download/download_file.cc* - *chrome/browser/download/download_file.h* - *chrome/browser/download/download_manager.cc* - *chrome/browser/download/download_manager.h* - *chrome/browser/download/download_manager_unittest.cc* - *chrome/browser/download/download_util.h* - *chrome/browser/download/drag_download_file_win.cc* - *chrome/browser/download/drag_download_file_win.h* - *chrome/browser/download/save_package.cc* - *chrome/browser/download/save_package.h* - *chrome/browser/download/save_package_unittest.cc* - *chrome/browser/gtk/download_item_gtk.h* - *chrome/browser/history/download_types.h* - *chrome/browser/renderer_host/download_resource_handler.cc* - *chrome/browser/renderer_host/download_resource_handler.h* - *chrome/browser/renderer_host/download_throttling_resource_handler.cc * - *chrome/browser/renderer_host/resource_dispatcher_host.cc* - *chrome/browser/renderer_host/resource_dispatcher_host.h* - *chrome/browser/renderer_host/resource_message_filter.cc* - *chrome/browser/tab_contents/web_drag_source_win.cc* - *chrome/browser/views/download_item_view.h* - *chrome/browser/views/tab_contents/tab_contents_drag_win.cc* - *chrome/browser/views/tab_contents/tab_contents_drag_win.h* - *chrome/browser/views/tab_contents/tab_contents_view_win.cc* - *chrome/browser/views/tab_contents/tab_contents_view_win.h* - *chrome/chrome_browser.gypi* - *chrome/common/render_messages.h* - *chrome/test/ui_test_utils.cc* - *webkit/glue/webdropdata.cc* - *webkit/glue/webdropdata.h* Comments: Support dragging a virtual file out of the browser. BUG=none TEST=none Review URL: http://codereview.chromium.org/351029 Properties: -- 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
Re: [chromium-dev] Ajax maximum response size
Either way, it seems like these are bugs that are worthy of being filed. Greg, any advice? J On Fri, Jan 15, 2010 at 10:20 AM, Rryk rryk...@gmail.com wrote: Hello, I am implementing 3D rendering engine for Chromium and I need to download huge scenes via Ajax. However I've noticed that asyncronous Ajax requests are limited to 7-8 MB in size. If I try to download more -- tab crashes (and in --single-process-mode everything crashes in onNoMemory function). Synchronous requests work better -- I was able to download 100M file, but the browser footprint in memory grew like a monster -- it took a whole of 3GB to download a single 100M file. Interesting enough that after downloading it it remained to take all this place. Does it make 30 copies out of it? There should be something wring with it. I am using jQuery for ajax and the code is here http://tinypaste.com/6f7d9. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
On Jan 15, 2010, at 10:37 AM, Peter Kasting wrote: One thing to note is that Chromium uses neither a distributed VC system nor Bugzilla, so your development process will look a little different than with Mozilla patches. Actually you can work on Chrome using git; it just takes a bit more work to get it set up, and you have to use special commands to push or pull. But IMHO it's worth the up-front cost. You should probably decide beforehand whether to use git or SVN, since the two checkouts aren't compatible, so switching from one to the other requires a lengthy download. —Jens-- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Ajax maximum response size
On Fri, Jan 15, 2010 at 10:20 AM, Rryk rryk...@gmail.com wrote: I am implementing 3D rendering engine for Chromium and I need to download huge scenes via Ajax. However I've noticed that asyncronous Ajax requests are limited to 7-8 MB in size. If I try to download more -- tab crashes (and in --single-process-mode everything crashes in onNoMemory function). Synchronous requests work better -- I was able to download 100M file, but the browser footprint in memory grew like a monster -- it took a whole of 3GB to download a single 100M file. Interesting enough that after downloading it it remained to take all this place. Does it make 30 copies out of it? There should be something wring with it. I am using jQuery for ajax and the code is here http://tinypaste.com/6f7d9. These sound like known issues with XMLHTTPRequest and tcmalloc that were fixed a few months ago by James Robinson. What version of Chrome are you using? This should be fixed in any build from December or later. (Also, which OS? The tcmalloc issue only affected Windows, IIRC.) —Jens-- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Process Model Extension API Proposal
LGTM also. One thought: I've seen a few requests on the crx-dev mailing list for API capabilities for both finding out when a process has crashed and also when it has become unresponsive. I'm unfamiliar with our code that checks for a hung renderer. Would the process.cpu value be a proxy for this? Would there be another way to expose it? Also, my preference would be for avoiding adding processId to Tab and using processes.get(tabId) instead, just for the sake of keeping the API completely contained within the experimental namespace. R On Wed, Jan 13, 2010 at 2:49 PM, Erik Kay erik...@chromium.org wrote: On Wed, Jan 13, 2010 at 1:21 PM, Charlie Reis cr...@chromium.org wrote: Thanks. I've updated the proposal doc based on suggestions from this discussion, including a global onUpdated event, notes about only providing cross-platform statistics, and adding a tabs array to each Process for the tabs associated with it (at least for renderer processes). http://docs.google.com/View?id=dhr988kp_4f76886hc As Aaron mentions, most of this can start out in the chrome.experimental namespace. I'd like to add the processId property to Tab, which has value on its own without the rest of the chrome.experimental.processes module. (e.g., I used it to build the first example use case: a Browser Action that shows all the tabs sharing the current tab's process.) Can I add that property to Tab directly, or should I temporarily add an experimental API to get a processId given a tabId? Yeah, unfortunately we don't have a way of adding experimental fields to non-experimental APIs. In this case, I'd say processId is a relatively safe addition, so go for it. Erik Charlie On Tue, Jan 12, 2010 at 5:09 PM, Erik Kay erik...@chromium.org wrote: LGTM. I agree that you should look into the broad (global, not per-process) onUpdated event. For any active monitoring extension (vs. static display), I would wager that this would result in a more efficient implementation than having them poll. I also agree with Aaron's answers to your open questions. Erik On Tue, Jan 12, 2010 at 1:08 PM, Charlie Reis cr...@chromium.org wrote: On Tue, Jan 12, 2010 at 12:44 PM, James Robinson jam...@google.com wrote: Getting this information in a cross-platform way is a huge pain (do we even do it properly for mac yet?), so it seems like a decent idea to let extensions reuse the work done rather than reimplementing everything. I agree. Plus NPAPI is a really big hammer that throws out most of the protections that Chromium's process model and sandbox offer extensions, so I'd find it ironic to rely on that for people interested in data about the process model... I'd suggest having the browser fire some sort of update event to the extension whenever the metrics are updated rather than forcing the extension to poll. This is how the task manager works currently. - James I'm happy to add an onUpdated event, but I thought it might be fired too often to expose it as an extension event. If we're not concerned about the frequency, I'll put it in the proposal. Charlie On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry mpcompl...@chromium.org wrote: Would it be possible to implement the same functionality using an NPAPI plugin? Extensions are allowed to bundle native plugins and interact with them from script. On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis cr...@chromium.org wrote: Hi folks-- I've put together a proposal for a Chromium extensions module that exposes data about the browser's processes. I think this could be useful for things like per-tab CPU/memory utilization graphs, custom task managers, or visualizing which tabs are sharing processes. http://docs.google.com/View?id=dhr988kp_4f76886hc Please let me know what you think. Thanks! Charlie Reis -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Ajax maximum response size
On Fri, Jan 15, 2010 at 11:47 AM, Jens Alfke s...@google.com wrote: On Fri, Jan 15, 2010 at 10:20 AM, Rryk rryk...@gmail.com wrote: I am implementing 3D rendering engine for Chromium and I need to download huge scenes via Ajax. However I've noticed that asyncronous Ajax requests are limited to 7-8 MB in size. If I try to download more -- tab crashes (and in --single-process-mode everything crashes in onNoMemory function). Synchronous requests work better -- I was able to download 100M file, but the browser footprint in memory grew like a monster -- it took a whole of 3GB to download a single 100M file. Interesting enough that after downloading it it remained to take all this place. Does it make 30 copies out of it? There should be something wring with it. I am using jQuery for ajax and the code is here http://tinypaste.com/6f7d9. What version of Chromium are you using on what OS? Given that you mentioned 3GB of memory, I'm guessing this is a 64 bit system? What's the content of the payload (i.e. text, binary, some special encoding)? Synchronous requests are going to be terrible, memory wise. The whole thing's buffered in the browser process due to some code structure issues. You should not be doing this anyway - it's really bad for the users to have the page locked up while a 100MB download occurs. - James These sound like known issues with XMLHTTPRequest and tcmalloc that were fixed a few months ago by James Robinson. What version of Chrome are you using? This should be fixed in any build from December or later. (Also, which OS? The tcmalloc issue only affected Windows, IIRC.) —Jens -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
Not to put words into Alex's mouth, but my impression from his first email is that he and Mark are mostly looking for the weekly guidance from a 'client' piece -- i.e., a Chromium mentor for the semester. I'd gladly volunteer, but I won't be around the whole time. - Pam On Fri, Jan 15, 2010 at 11:42 AM, Jens Alfke s...@google.com wrote: On Jan 15, 2010, at 10:37 AM, Peter Kasting wrote: One thing to note is that Chromium uses neither a distributed VC system nor Bugzilla, so your development process will look a little different than with Mozilla patches. Actually you can work on Chrome using githttp://code.google.com/p/chromium/wiki/UsingGit; it just takes a bit more work to get it set up, and you have to use special commands to push or pull. But IMHO it's worth the up-front cost. You should probably decide beforehand whether to use git or SVN, since the two checkouts aren't compatible, so switching from one to the other requires a lengthy download. —Jens -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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 36400
Automatically closing tree for compile on Chromium Linux http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux/builds/9132 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux --= Automatically closing tree for compile on Chromium Linux =-- Revision: 36394, 36395, 36396, 36397, 36398, 36399, 36400 Blame list: aka...@chromium.org,al...@chromium.org,avay...@google.com,hc...@chromium.org,jsc...@chromium.org,mun...@chromium.org,pi...@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: Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
Pam's right in that we're looking for a 'Chromium mentor'. This is kind of a new idea for this school, so I guess Mark and I are kind of refining is for the benefit of future generations or something. The downside (and arguably the upside) to this is that there's not really an established way of doing anything, so we're more or less writing the book as we go. We were also interested to see what suggestions you had for things to work on. Right now, we're thinking about taking on a couple 'lay of the land' type bugs and then hopefully doing a more non-trivial patch later. Of course, we're still trying to figure stuff out with our professor right now, but we're very interested in hearing suggestions. As far as the technical stuff, we're getting the necessary tools together this afternoon (downloading and building the tree, getting the appropriate IDEs, etc.). We'll likely build for both windows 7 and OS X for right now. Thanks for all the help and suggestions! Alex On Jan 15, 3:19 pm, Pam Greene p...@chromium.org wrote: Not to put words into Alex's mouth, but my impression from his first email is that he and Mark are mostly looking for the weekly guidance from a 'client' piece -- i.e., a Chromium mentor for the semester. I'd gladly volunteer, but I won't be around the whole time. - Pam On Fri, Jan 15, 2010 at 11:42 AM, Jens Alfke s...@google.com wrote: On Jan 15, 2010, at 10:37 AM, Peter Kasting wrote: One thing to note is that Chromium uses neither a distributed VC system nor Bugzilla, so your development process will look a little different than with Mozilla patches. Actually you can work on Chrome using githttp://code.google.com/p/chromium/wiki/UsingGit; it just takes a bit more work to get it set up, and you have to use special commands to push or pull. But IMHO it's worth the up-front cost. You should probably decide beforehand whether to use git or SVN, since the two checkouts aren't compatible, so switching from one to the other requires a lengthy download. —Jens -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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 XP Tests, revision 36403
Automatically closing tree for unit_tests on XP Tests http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests --= Automatically closing tree for unit_tests on XP Tests =-- Revision: 36401, 36402, 36403 Blame list: a...@chromium.org,hc...@chromium.org,jhawk...@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
Re: [chromium-dev] Process Model Extension API Proposal
On Fri, Jan 15, 2010 at 12:04 PM, Rafael Weinstein rafa...@chromium.orgwrote: LGTM also. One thought: I've seen a few requests on the crx-dev mailing list for API capabilities for both finding out when a process has crashed and also when it has become unresponsive. I'm unfamiliar with our code that checks for a hung renderer. Would the process.cpu value be a proxy for this? Would there be another way to expose it? I have the onExited event to listen for crashed tabs. For hung tabs, I don't think cpu is a good proxy for it. Maybe we could add a onHung event that fires when Chrome decides a process is unresponsive? Also, my preference would be for avoiding adding processId to Tab and using processes.get(tabId) instead, just for the sake of keeping the API completely contained within the experimental namespace. R Darn, I was just getting ready to submit that CL for review. :) I'd like to still pass a process ID to the get() method, so that it can be useful for browser, plugin, and renderer processes as well. Maybe chrome.experimental.processes.getProcessId(tabId), with the expectation that it will be removed when processId is later added to Tab? Charlie On Wed, Jan 13, 2010 at 2:49 PM, Erik Kay erik...@chromium.org wrote: On Wed, Jan 13, 2010 at 1:21 PM, Charlie Reis cr...@chromium.org wrote: Thanks. I've updated the proposal doc based on suggestions from this discussion, including a global onUpdated event, notes about only providing cross-platform statistics, and adding a tabs array to each Process for the tabs associated with it (at least for renderer processes). http://docs.google.com/View?id=dhr988kp_4f76886hc As Aaron mentions, most of this can start out in the chrome.experimental namespace. I'd like to add the processId property to Tab, which has value on its own without the rest of the chrome.experimental.processes module. (e.g., I used it to build the first example use case: a Browser Action that shows all the tabs sharing the current tab's process.) Can I add that property to Tab directly, or should I temporarily add an experimental API to get a processId given a tabId? Yeah, unfortunately we don't have a way of adding experimental fields to non-experimental APIs. In this case, I'd say processId is a relatively safe addition, so go for it. Erik Charlie On Tue, Jan 12, 2010 at 5:09 PM, Erik Kay erik...@chromium.org wrote: LGTM. I agree that you should look into the broad (global, not per-process) onUpdated event. For any active monitoring extension (vs. static display), I would wager that this would result in a more efficient implementation than having them poll. I also agree with Aaron's answers to your open questions. Erik On Tue, Jan 12, 2010 at 1:08 PM, Charlie Reis cr...@chromium.org wrote: On Tue, Jan 12, 2010 at 12:44 PM, James Robinson jam...@google.com wrote: Getting this information in a cross-platform way is a huge pain (do we even do it properly for mac yet?), so it seems like a decent idea to let extensions reuse the work done rather than reimplementing everything. I agree. Plus NPAPI is a really big hammer that throws out most of the protections that Chromium's process model and sandbox offer extensions, so I'd find it ironic to rely on that for people interested in data about the process model... I'd suggest having the browser fire some sort of update event to the extension whenever the metrics are updated rather than forcing the extension to poll. This is how the task manager works currently. - James I'm happy to add an onUpdated event, but I thought it might be fired too often to expose it as an extension event. If we're not concerned about the frequency, I'll put it in the proposal. Charlie On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry mpcompl...@chromium.org wrote: Would it be possible to implement the same functionality using an NPAPI plugin? Extensions are allowed to bundle native plugins and interact with them from script. On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis cr...@chromium.org wrote: Hi folks-- I've put together a proposal for a Chromium extensions module that exposes data about the browser's processes. I think this could be useful for things like per-tab CPU/memory utilization graphs, custom task managers, or visualizing which tabs are sharing processes. http://docs.google.com/View?id=dhr988kp_4f76886hc Please let me know what you think. Thanks! Charlie Reis -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers
[chromium-dev] Re: buildbot failure in Chromium on XP Tests, revision 36403
XP Tests clobbered due to .grd changes; should cycle green. Tree reopened as of r36407. Stephen On Fri, Jan 15, 2010 at 4:21 PM, build...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/ Automatically closing tree for unit_tests on XP Tests http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429 Revision: 36401, 36402, 36403 Blame list: a...@chromium.org,hc...@chromium.org,jhawk...@chromium.org XP Tests Build 16429http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/shell_1/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/shell_2/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/gclient/logs/stdio extract build stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/extract%20build/logs/stdio Start Crash Handler stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/Start%20Crash%20Handler/logs/stdio ipc_tests stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/ipc_tests/logs/stdio installer_util_unittests stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/installer_util_unittests/logs/stdio mini_installer_test stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/mini_installer_test/logs/stdio sync_unit_tests 1 disabled stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/sync_unit_tests/logs/stdio unit_tests 15 disabled 1 flaky failed 1 stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/unit_tests/logs/stdio TestDownloadFilenamehttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16429/steps/unit_tests/logs/TestDownloadFilename Changed by: *hc...@chromium.org* Changed at: *Fri 15 Jan 2010 12:48:30* Branch: *src* Revision: *36401*http://src.chromium.org/viewvc/chrome?view=revrevision=36401 Changed files: - *media/omx/omx_test.cc* Comments: Fix build caused by omx_test TBR=scherkus Initialize struct variables by memset()ing them. Review URL: http://codereview.chromium.org/552017 Properties: Changed by: *jhawk...@chromium.org* Changed at: *Fri 15 Jan 2010 12:58:48* Branch: *src* Revision: *36402*http://src.chromium.org/viewvc/chrome?view=revrevision=36402 Changed files: - *chrome/app/generated_resources.grd* - *chrome/app/resources/locale_settings.grd* - *chrome/browser/autofill/autofill_dialog_gtk.cc* - *chrome/browser/gtk/bookmark_manager_gtk.cc* - *chrome/browser/gtk/clear_browsing_data_dialog_gtk.cc* - *chrome/browser/gtk/create_application_shortcuts_dialog_gtk.cc* - *chrome/browser/gtk/first_run_dialog.cc* - *chrome/browser/gtk/import_dialog_gtk.cc* - *chrome/browser/gtk/keyword_editor_view.cc* - *chrome/browser/gtk/options/passwords_exceptions_window_gtk.cc* - *chrome/browser/gtk/options/url_picker_dialog_gtk.cc* - *chrome/common/gtk_util.cc* - *chrome/common/gtk_util.h* Comments: Simplify the gtk AutoFill dialog and bring it more in line with the mocks. BUG=none TEST=none Review URL: http://codereview.chromium.org/551034 Properties: Changed by: *a...@chromium.org* Changed at: *Fri 15 Jan 2010 12:59:18* Branch: *src* Revision: *36403*http://src.chromium.org/viewvc/chrome?view=revrevision=36403 Changed files: - *chrome_frame/crash_reporting/crash_report.cc* - *chrome_frame/crash_reporting/crash_report.h* - *chrome_frame/crash_reporting/crash_reporting.gyp* - *chrome_frame/crash_reporting/vectored_handler-impl.h* - *chrome_frame/crash_reporting/vectored_handler.h* - *chrome_frame/crash_reporting/vectored_handler_unittest.cc* Comments: Suppress crash dump generation due to IsBadXXX functions. IsBad[Read/Write]Ptr etc functions cause access violations which we catch and take crash dump if we are on stack. Adding code to suppress these false positives. BUG=none TEST=added new tests cases to ChromeFrame.ExceptionReport Review URL: http://codereview.chromium.org/536073 Properties: -- 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
Re: [chromium-dev] Process Model Extension API Proposal
On Fri, Jan 15, 2010 at 1:27 PM, Charlie Reis cr...@chromium.org wrote: On Fri, Jan 15, 2010 at 12:04 PM, Rafael Weinstein rafa...@chromium.org wrote: LGTM also. One thought: I've seen a few requests on the crx-dev mailing list for API capabilities for both finding out when a process has crashed and also when it has become unresponsive. I'm unfamiliar with our code that checks for a hung renderer. Would the process.cpu value be a proxy for this? Would there be another way to expose it? I have the onExited event to listen for crashed tabs. For hung tabs, I don't think cpu is a good proxy for it. Maybe we could add a onHung event that fires when Chrome decides a process is unresponsive? Sounds good. Also, my preference would be for avoiding adding processId to Tab and using processes.get(tabId) instead, just for the sake of keeping the API completely contained within the experimental namespace. R Darn, I was just getting ready to submit that CL for review. :) I'd like to still pass a process ID to the get() method, so that it can be useful for browser, plugin, and renderer processes as well. Maybe chrome.experimental.processes.getProcessId(tabId), with the expectation that it will be removed when processId is later added to Tab? Charlie Sorry, I didn't noticed that get() was taking a processId (duh). Sound good. Or even getProcessForTab(tabId), just because it's most likely you'll just turn around and call processes.get() on the result of getProcessId() On Wed, Jan 13, 2010 at 2:49 PM, Erik Kay erik...@chromium.org wrote: On Wed, Jan 13, 2010 at 1:21 PM, Charlie Reis cr...@chromium.org wrote: Thanks. I've updated the proposal doc based on suggestions from this discussion, including a global onUpdated event, notes about only providing cross-platform statistics, and adding a tabs array to each Process for the tabs associated with it (at least for renderer processes). http://docs.google.com/View?id=dhr988kp_4f76886hc As Aaron mentions, most of this can start out in the chrome.experimental namespace. I'd like to add the processId property to Tab, which has value on its own without the rest of the chrome.experimental.processes module. (e.g., I used it to build the first example use case: a Browser Action that shows all the tabs sharing the current tab's process.) Can I add that property to Tab directly, or should I temporarily add an experimental API to get a processId given a tabId? Yeah, unfortunately we don't have a way of adding experimental fields to non-experimental APIs. In this case, I'd say processId is a relatively safe addition, so go for it. Erik Charlie On Tue, Jan 12, 2010 at 5:09 PM, Erik Kay erik...@chromium.org wrote: LGTM. I agree that you should look into the broad (global, not per-process) onUpdated event. For any active monitoring extension (vs. static display), I would wager that this would result in a more efficient implementation than having them poll. I also agree with Aaron's answers to your open questions. Erik On Tue, Jan 12, 2010 at 1:08 PM, Charlie Reis cr...@chromium.org wrote: On Tue, Jan 12, 2010 at 12:44 PM, James Robinson jam...@google.com wrote: Getting this information in a cross-platform way is a huge pain (do we even do it properly for mac yet?), so it seems like a decent idea to let extensions reuse the work done rather than reimplementing everything. I agree. Plus NPAPI is a really big hammer that throws out most of the protections that Chromium's process model and sandbox offer extensions, so I'd find it ironic to rely on that for people interested in data about the process model... I'd suggest having the browser fire some sort of update event to the extension whenever the metrics are updated rather than forcing the extension to poll. This is how the task manager works currently. - James I'm happy to add an onUpdated event, but I thought it might be fired too often to expose it as an extension event. If we're not concerned about the frequency, I'll put it in the proposal. Charlie On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry mpcompl...@chromium.org wrote: Would it be possible to implement the same functionality using an NPAPI plugin? Extensions are allowed to bundle native plugins and interact with them from script. On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis cr...@chromium.org wrote: Hi folks-- I've put together a proposal for a Chromium extensions module that exposes data about the browser's processes. I think this could be useful for things like per-tab CPU/memory utilization graphs, custom task managers, or visualizing which tabs are sharing processes. http://docs.google.com/View?id=dhr988kp_4f76886hc Please let me know what you think. Thanks! Charlie Reis -- Chromium Developers mailing list:
Re: [chromium-dev] Re: Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
On Fri, Jan 15, 2010 at 12:35 PM, Alex Gartrell alexgartr...@gmail.comwrote: Pam's right in that we're looking for a 'Chromium mentor'. Right. I understood that, and might be willing to do it; I was more concerned with what you were actually interested in working on (in terms of size and style) to get an idea of who'd be appropriate. We were also interested to see what suggestions you had for things to work on. Right now, we're thinking about taking on a couple 'lay of the land' type bugs and then hopefully doing a more non-trivial patch later. Of course, we're still trying to figure stuff out with our professor right now, but we're very interested in hearing suggestions. I once made a list of some of the smaller, but not completely pointless, bugs I was aware of that I thought someone coming up to speed might be able to handle. This list doesn't have anything from the last four months, and is heavily biased towards the areas I have worked on (== a lot of address bar stuff especially), but maybe there is something in here that catches your eye. Some of these are more difficult than others, but I would be happy to handhold you through solving any of them. They would probably prepare you for tackling bigger projects. crbug.com/4005 crbug.com/4095 crbug.com/6177 crbug.com/6770 *crbug.com/6872* crbug.com/6888 crbug.com/7438 crbug.com/7982 crbug.com/9044 crbug.com/9694 crbug.com/9885 crbug.com/12305 crbug.com/13279 crbug.com/13703 crbug.com/14748 crbug.com/16746 crbug.com/18107 crbug.com/18587 crbug.com/20005 crbug.com/20250 crbug.com/22853 crbug.com/22982 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 Modules Linux, revision 36414
Automatically closing tree for unit_tests on Modules Linux http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux/builds/15260 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20Linux --= Automatically closing tree for unit_tests on Modules Linux =-- Revision: 36410, 36411, 36412, 36413, 36414 Blame list: a...@chromium.org,al...@chromium.org,e...@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
Re: [chromium-dev] Process Model Extension API Proposal
On Fri, Jan 15, 2010 at 1:33 PM, Rafael Weinstein rafa...@chromium.orgwrote: On Fri, Jan 15, 2010 at 1:27 PM, Charlie Reis cr...@chromium.org wrote: On Fri, Jan 15, 2010 at 12:04 PM, Rafael Weinstein rafa...@chromium.org wrote: LGTM also. One thought: I've seen a few requests on the crx-dev mailing list for API capabilities for both finding out when a process has crashed and also when it has become unresponsive. I'm unfamiliar with our code that checks for a hung renderer. Would the process.cpu value be a proxy for this? Would there be another way to expose it? I have the onExited event to listen for crashed tabs. For hung tabs, I don't think cpu is a good proxy for it. Maybe we could add a onHung event that fires when Chrome decides a process is unresponsive? Sounds good. Also, my preference would be for avoiding adding processId to Tab and using processes.get(tabId) instead, just for the sake of keeping the API completely contained within the experimental namespace. R Darn, I was just getting ready to submit that CL for review. :) I'd like to still pass a process ID to the get() method, so that it can be useful for browser, plugin, and renderer processes as well. Maybe chrome.experimental.processes.getProcessId(tabId), with the expectation that it will be removed when processId is later added to Tab? Charlie Sorry, I didn't noticed that get() was taking a processId (duh). Sound good. Or even getProcessForTab(tabId), just because it's most likely you'll just turn around and call processes.get() on the result of getProcessId() Makes sense-- it's easy it get the processId from the Process object if that's what you want. I added it to the doc, along with a new onUnresponsive event (rather than onHung). Charlie On Wed, Jan 13, 2010 at 2:49 PM, Erik Kay erik...@chromium.org wrote: On Wed, Jan 13, 2010 at 1:21 PM, Charlie Reis cr...@chromium.org wrote: Thanks. I've updated the proposal doc based on suggestions from this discussion, including a global onUpdated event, notes about only providing cross-platform statistics, and adding a tabs array to each Process for the tabs associated with it (at least for renderer processes). http://docs.google.com/View?id=dhr988kp_4f76886hc As Aaron mentions, most of this can start out in the chrome.experimental namespace. I'd like to add the processId property to Tab, which has value on its own without the rest of the chrome.experimental.processes module. (e.g., I used it to build the first example use case: a Browser Action that shows all the tabs sharing the current tab's process.) Can I add that property to Tab directly, or should I temporarily add an experimental API to get a processId given a tabId? Yeah, unfortunately we don't have a way of adding experimental fields to non-experimental APIs. In this case, I'd say processId is a relatively safe addition, so go for it. Erik Charlie On Tue, Jan 12, 2010 at 5:09 PM, Erik Kay erik...@chromium.org wrote: LGTM. I agree that you should look into the broad (global, not per-process) onUpdated event. For any active monitoring extension (vs. static display), I would wager that this would result in a more efficient implementation than having them poll. I also agree with Aaron's answers to your open questions. Erik On Tue, Jan 12, 2010 at 1:08 PM, Charlie Reis cr...@chromium.org wrote: On Tue, Jan 12, 2010 at 12:44 PM, James Robinson jam...@google.com wrote: Getting this information in a cross-platform way is a huge pain (do we even do it properly for mac yet?), so it seems like a decent idea to let extensions reuse the work done rather than reimplementing everything. I agree. Plus NPAPI is a really big hammer that throws out most of the protections that Chromium's process model and sandbox offer extensions, so I'd find it ironic to rely on that for people interested in data about the process model... I'd suggest having the browser fire some sort of update event to the extension whenever the metrics are updated rather than forcing the extension to poll. This is how the task manager works currently. - James I'm happy to add an onUpdated event, but I thought it might be fired too often to expose it as an extension event. If we're not concerned about the frequency, I'll put it in the proposal. Charlie On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry mpcompl...@chromium.org wrote: Would it be possible to implement the same functionality using an NPAPI plugin? Extensions are allowed to bundle native plugins and interact with them from script. On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis cr...@chromium.org wrote: Hi folks-- I've put together a
Re: [chromium-dev] [LTTF] Finders Pool Drained, Under 300 Failures on Win XP Release
Dimitri, the LTTF, and anyone else involved, you are awesome, and I consider your work to have the largest importance / (satisfaction + recognition) value on the team. This is a thankless task. You have given me hope that someday we could conceivably reach 0 failures. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
What's the motivation of implementing such tests as extensions? The
automation framework already supports simulating keyboard events, can we
just use it for such kind of tests?
Regards
James Su
2010/1/16 Dominic Mazzoni dmazz...@google.com
The problem I have with using only explicitly defined action functions
is that the whole point of simulating keyboard events is to test
whether or not the user interface is accessible using the keyboard!
(This is not just an issue for people using assistive technology like
a screen reader: there are a few things in Chrome that are impossible
to access without using a mouse now.)
I want to be able to write tests that try to edit bookmarks using the
Bookmark Manager, or change settings using the Options dialog, for
example. Having functions like selectNextBookmark() wouldn't help test
that they're actually accessible via the keyboard.
There aren't that many different keys needed for keyboard
accessibility: off the top of my head, you mostly need tab, shift-tab,
space, enter, and arrow keys - plus a few shortcuts to open a menu or
move the focus to a certain panel. What about having functions for
each of these keys plus other actions that can be triggered via a
keyboard shortcut?
tabToNextControl()
tabToPreviousControl()
pressSpaceBar()
pressEnterKey()
pressEscapeKey()
arrowUp()
arrowDown()
arrowLeft()
arrowRight()
openOptionsDialog()
openBookmarksManager()
focusLocationBar()
...
Then, in order to enter text into a text box in a dialog, perhaps a
function that pastes unicode text at the current cursor position would
be much easier than trying to deal with key codes and input methods.
- Dominic
On Fri, Jan 15, 2010 at 3:24 AM, James Su su...@google.com wrote:
Hi Nico,
I totally agree with your point. Using fake keyboard events for
accessibility things would lead to compatibility nightmare. We should
consider the approach of using explicitly defined action functions rather
than emulating keyboard events. The keyboard events approach has at least
following unsolvable problems:
1. Compatibility issue among different OS platforms.
2. Compatibility issue caused by user customized shortcuts.
3. Supports of different keyboard layouts.
4. Supports of inputting non-Latin text.
Regards
James Su
2010/1/15 Nico Weber tha...@chromium.org
On Thu, Jan 14, 2010 at 8:37 AM, Dominic Mazzoni dmazz...@google.com
wrote:
On Thu, Jan 14, 2010 at 8:19 AM, Nico Weber tha...@google.com
wrote:
It probably depends if you want to use this for text input or
action
inputs. A text-to-speech extension would probably want to set unicode
characters, while something that (say) hits cmd-f to open the find
bar
probably wants to use keycodes.
Text-to-speech is a different problem; this is for actions.
For example, on OS X hitting cmd-f with a hiragana keyboard layout
opens the findbar, while just pressing f opens an IME.
If you want to use this for actons, I would find it more useful to
have a performUiAction() function instead though, since keyboard
shortcuts are different across platforms (all mac shortcuts use cmd
instead of ctrl for example, and the letters for a few shortcuts are
different on OS X too for various reasons).
I completely agree; I would like to add many functions along the lines
of performUiAction. However, there are a few actions for which typing
a key really is the right thing to do - for example pressing Tab to
move to the next control.
Maybe performUiAction('focusNextViewInKeyLoop')?
(By the way, OS X has a system-level setting that configures if tab
should focus only text fields or all controls such as buttons etc. I
don't think Chrome/Mac honors it, but I think there are plans to
support it. Stuff like this is surprising for a caller that sends
tab characters, while an explicit focus next element function
could have clearly defined semantics).
There's also testing. This function will allow you to use only
javascript to test that a particular capability can be accessed using
only the keyboard. I'm already using this for testing this API, by
simulating pressing Ctrl+L to focus the location bar and then checking
to see that the proper focus event is generated.
Some (most?) accessibility shortcuts will vary by platform too. For
example, focus toolbar is ctrl-f5 on OS X, but only if full keyboard
access has been enabled (ctrl-f1). Cocoa the OS X framework don't
always trigger with synthetic keyboard events. (I'm not an a11y expert
– Avi, comments?)
So the way I look at it is: there are some great uses for this
function. There are also things that this function could be used for
but there'd be a better way. It could also be abused to do things that
make no sense.
I don't think that's an argument not to allow the function; I think it
just means we should make sure
[chromium-dev] [LTTF] Finders Pool Drained, Under 300 Failures on Win XP Release
Dear Chromium Folk, Today, something vaguely significant happened -- if you're into numbers, statistic, and fixing layout tests. And you have to admit, all of us are. First, after a week of relentless triage, I finally drained the Finders pool. The Finders pool? you ask, flashing back to your last treasure hunt adventure. No, not that kind of finders pool -- well.. almost. See, over the time of project existence, we accumulated quite a few layout test failures. As the Layout Test Task Force was chartered, we split all of our failures into two pools: 1) the failures whose causes are known and are ready for fixing, or the Fixers Pool 2) the failures that fail for reasons that are yet to be found, or the Finders Pool We even have this really neat dashboard (http://chromiumlttf.appspot.com/ -- thanks for building it, dpranke!) that shows us these known knowns and known unknowns (http://www.brainyquote.com/quotes/quotes/d/donaldrums148142.html). Over the last few months, we've been diminishing the size of the Win XP Release Finders pool, and last week I decided that the time has come for it to say buh-bye. And id did! Now we _only_ have 159 bugs to fix and we'll have 0 layout test failures. But at least we know what to fix, right? I mean -- right? ;) Oh -- and we have to keep this pool empty. Any creepage of unknown failures will not be tolerated. Except when it's a flake -- we'll soon have a separate triaging bucket for those, but for now all flaky tests go into the Fixers pool. My sincere apologies to tkent, jar, nsylvain, jungshik, sdoyon, ericu, cevans, senorblanco and yuzo for inflicting the barrage of rebaselining and expectation tweaking commits during their sheriffing duty. That tree closing yesterday due to too many commits was partially my fault. Second, as a result of the aforementioned drainage, the Win XP Release bot is finally showing under 300 failures! Woo hoo! This means that over the last 4 months (or the entire length of its existence), the LTTF eliminated over 500 test failures from the tree. That's big stuff, folks. Kudos to you all, LTTF-ers. I salute you on behalf of the entire Chrome team and WebKit community, since a lot of tests fixed were not specific to Chrome. Anyhow, have a good night, y'all. Except for the WebKit gardeners -- who as it's widely known never sleep. :DG -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
