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] 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
[chromium-dev] Re: FYI: Linux interactive_ui_tests a bit hosed
FYI: http://codereview.chromium.org/341078 http://codereview.chromium.org/341078Linux interactive tests have finally gone green. On Mon, Nov 2, 2009 at 10:08 AM, John Abd-El-Malek j...@chromium.org wrote: (CCing today's sheriffs + Jay) I was thinking of marking the bug to P1, except that won't change much if no one has the time to work on it now. I think to keep tree green, the entire test should be disabled until singletons are cleared between each test, or it's switched to browser_tests launcher. On Mon, Nov 2, 2009 at 12:44 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I think that the right fix is to switch interactive_ui_tests to browser_tests launcher (jcampan did some great work to make the launcher more flexible, it may be quite simple to do the switch now - if there are no UI tests in interactive_ui_tests). I also suggest bumping the priority of http://crbug.com/25997 to P1 and possibly marking it with FlakyTest label. On Mon, Nov 2, 2009 at 09:37, John Abd-El-Malek j...@chromium.org wrote: This is related to bug 25997. The tests are inherently flakey because singeltons aren't released between runs, so cached MessageLoop pointers are bogus. Sometimes they're ok when the order of construction/destruction of MessageLoop pointers is the same. But if that changes, or other memory allocations change, the tests start failing. Just wanted to send a heads up since I spent a day debugging this last week, and now they're failing again. --~--~-~--~~~---~--~~ 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 not to spend the day getting depot_tools, cygwin svn to play nicely...
If you're secure in your understanding of depot_tools, cygwin, svn, you can archive now. I'm still a relative newbie, but I thought I knew what to do... Still...I spent the better part of the day trying to get a correctly building checkout of chromium on a new windows7 64bit box, and in the hopes that I can save some other poor newbie the time, here's what I figured out (this has probably all been covered before). Cygwin svn was doing something horrible (probably permissions-related) to my third_party/python_24 that caused the python binary not to run. The visible symptom was that my build generated a ton of cryptic Error 24s from Cmd.exe. The solution was to use the windows svn binaries. The way I accomplished this was to run depot_tools for the first time from a regular windows command.exe so it installs win32 svn python [also, I needed to set my path so it depot_tools/svn appear first]. This fixed the svn checkout problem. Lastly, I had trouble running gclient from a cygwin bash shell. If you are using the windows binaries of svn python, gclient has to run gclient.bat so it sets paths correctly (otherwise python svn get paths with /cygdrive/... in them and give up). This will work correctly from a regular cygwin bash terminal -- however, if you are using putty, it'll report your TERM as xterm and the gclient script will call gclient.py and not set paths correctly. So, in summary -- for those who will soon be setting up shiny new machines -- here's what worked for me (I'm sure other's have working setups as well): 1) Download depot_tools 2) Run gclient for the first time from command.exe (so you get the windows binaries) 3) Put /cygdrive/path/to/depot_tools as the FIRST component of you cygwin path (from .profile or .bashrc) 4) If your gclient spits out errors about /cygdrive/... paths, try running gclient.bat directly (it's possible your TERM==xterm). --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.-1 on using
the same syntax (or at least the same directives) as JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %% %%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span jscontent=url
http://www.some.com/.. http://www.some.com/./span
/div
In the above the i18n_download span is intended to be a localized string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and* a
page composition value within a select directive. The jst replacements that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an obvious
suggestion is just to add another virtual JST directive called (i18n for
example), that behaves exactly like jscontent, but additionally removes the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span jscontent=url
http://www.some.com/.. http://www.some.com/./span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span jscontent=url
http://www.some.com/..http://www.some.com/
./span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--~--~-~--~~~---~--~~
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: Rewrite of DOMUI l10n strings
Fantastic. I'll look forward to using it.
On Thu, Jul 9, 2009 at 1:52 PM, Erik Arvidsson a...@chromium.org wrote:
I'm pursuing the js solution since it buys a performance boost in the
short term. It uses l10n-values and l10n-content which are almost
identical to jsvalues and jscontent except that it does not allow
arbitrary expressions.
I expect to send out a finished CL today.
2009/7/9 Rafael Weinstein rafa...@chromium.org:
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.
-1 on using the same syntax (or at least the same directives) as
JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments
programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %%
%%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I
realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives
can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
In the above the i18n_download span is intended to be a localized
string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and*
a
page composition value within a select directive. The jst replacements
that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text
being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few
humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an
obvious
suggestion is just to add another virtual JST directive called (i18n
for
example), that behaves exactly like jscontent, but additionally removes
the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span
jscontent=url http://www.some.com/.../span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n
support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much
simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code
between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
