Re: [chromium-dev] Generate extensions _locale directories from grd files?

[Erik Arvidsson]

On Tue, Jan 12, 2010 at 13:57, Aaron Boodman  wrote:
> Nobody has considered it before.
>
> An easier workaround would be to just expose a custom API to yourself
> that sends the dictionary into your extension.

That is indeed easier and that was my initial plan before I looked
into the i18n extension API. I guess I'll go for the experimental
extension API for now.

Thanks for your input.

-- 
erik

> On Tue, Jan 12, 2010 at 1:43 PM, Erik Arvidsson  wrote:
>> I'm currently working on the new bookmark manager which is being
>> developed as an extension.
>>
>> For the extension I am using the i18n extension APIs which works
>> great. However, we currently have all the bookmark manager messages in
>> generated_resources.grd and I would like to generate the extension
>> _locales files from the grd file. It seems like the Grit supports
>> different output types and I was wondering if anyone has considered
>> doing this before?
>>
>> erik
>>
>> --
>> 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] Generate extensions _locale directories from grd files?

[Erik Arvidsson]

I'm currently working on the new bookmark manager which is being
developed as an extension.

For the extension I am using the i18n extension APIs which works
great. However, we currently have all the bookmark manager messages in
generated_resources.grd and I would like to generate the extension
_locales files from the grd file. It seems like the Grit supports
different output types and I was wondering if anyone has considered
doing this before?

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: buildbot failure in Chromium on Linux Perf, revision 35651

[Erik Arvidsson]

Brett, any progress? If I don't hear anything from you soon I'll revert
the patch.

erik


On Wed, Jan 6, 2010 at 13:49,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "compile" on "Linux Perf"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/4806
>
> Revision: 35649, 35650, 35651
> Blame list: aka...@chromium.org,bre...@chromium.org,d...@chromium.org
>
>  Linux Perf
> Build 
> 4806
>   update
> scripts
> stdio
> update
> stdio
> compile
> failed
> stdio
>
> Changed by: *bre...@chromium.org*
> Changed at: *Wed 06 Jan 2010 13:10:24*
> Branch: *src*
> Revision: 
> *35649*
> Changed files:
>
>- *build/all.gyp*
>- *chrome/renderer/render_view.cc*
>- *chrome/renderer/webplugin_delegate_pepper.cc*
>- *webkit/tools/pepper_test_plugin/event_handler.cc*
>- *webkit/tools/pepper_test_plugin/main.cc*
>- *webkit/tools/pepper_test_plugin/pepper_test_plugin.gyp*
>- *webkit/tools/pepper_test_plugin/plugin_object.cc*
>- *webkit/tools/pepper_test_plugin/plugin_object.h*
>
> Comments:
>
> Make Pepper plugins work on Linux.
>
> - fix pepper_test_plugin so that it is loaded on Linux
>
> - remove skia & base dependency in test plugin so that it can be compiled 
> with -fPIC
> - remove ifdef WIN in pepper code
>
> Patch by n...@chromium.org
> Original review: http://codereview.chromium.org/501124/show
> BUG=none
> TEST=none 
>
> Properties:
>
>
>  Changed by: *aka...@chromium.org*
> Changed at: *Wed 06 Jan 2010 13:13:34*
> Branch: *src*
> Revision: 
> *35650*
> Changed files:
>
>- *net/socket/ssl_client_socket_mac.cc*
>
> Comments:
>
> Changed catch-all Mac SSL OSStatus error to paramErr.
>
> Added net::ERR_UNEXPECTED <=> errSSLInternal mapping.
>
> Added net::ERR_INVALID_ARGUMENT => paramErr mapping.
>
> BUG=none
> TEST=trybots
>
> Review URL: http://codereview.chromium.org/515049
>
> Properties:
>
>
>  Changed by: *d...@chromium.org*
> Changed at: *Wed 06 Jan 2010 13:16:04*
> Branch: *src*
> Revision: 
> *35651*
> Changed files:
>
>- *chrome/browser/renderer_host/database_dispatcher_host.cc*
>- *chrome/browser/renderer_host/database_dispatcher_host.h*
>- *webkit/database/database_connections.cc*
>- *webkit/database/database_connections.h*
>- *webkit/database/database_tracker.cc*
>- *webkit/database/database_tracker.h*
>- *webkit/database/database_tracker_unittest.cc*
>- *webkit/database/databases_table.cc*
>- *webkit/database/databases_table.h*
>- *webkit/database/databases_table_unittest.cc*
>- *webkit/database/quota_table.cc*
>- *webkit/database/quota_table.h*
>- *webkit/database/quota_table_unittest.cc*
>- *webkit/tools/test_shell/simple_database_system.cc*
>- *webkit/tools/test_shell/simple_database_system.h*
>- *webkit/tools/test_shell/test_shell.gyp*
>- *webkit/webkit.gyp*
>
> Comments:
>
> Adding methods that will be used by the quota management UI.
>
> TEST=none
> BUG=none
>
>
> Review URL: http://codereview.chromium.org/507014
>
> Properties:
>
>
>
-- 
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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?

[Erik Arvidsson]

I think it should be OK to move these to DOMUI. NTP can also link to
local HTML files and we already mark the chrome protocol in such a way
that it cannot be accessed by any other scheme.

erik



On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
 wrote:
> That's why I wanted to check before starting any work. So the question is
> now whether it we'd rather use a DOM UI page or create a similar API that
> would be used solely by file:// and ftp://. What is needed for
> http://crbug.com/24421 is simply access to the favicon data for file types.
> I'm not sure if these are available through WebCore or not. The drag and
> drop functionality required by http://crbug.com/27772 seems like it would be
> a lot of work without using a DOM UI page.
> Any opinions on this part of my original post?:
> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't
> be generalized to
> be used for these other directory listing pages?
> It just seems to me that it would be rather redundant handle 3 separate
> instances of a file browse HTML page (ftp://, file:// and
> chrome://filebrowse) in 3 separate ways.
> Thanks.
> 2010/1/5 Evan Martin 
>>
>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy  wrote:
>> > I don't think anyone has any objection to DOMUIifying those pages, and
>> > I don't think it would be a large amount of work. The only reason
>> > they're not is that there hasn't been a reason to do so.
>>
>> DOM UI (at least when I last looked) just means that that renderer
>> ("the page") gets extra privileges necessary for doing special browser
>> calls, such as access to your browsing history for the History
>> implementation.
>>
>> We went to some effort to keep these sorts of pages distinct from
>> network content with the hope of reducing the security surface.  I
>> worry changing this for FTP would be going in the wrong direction.
>>
>> It might make more sense to do something *like* DOM UI but with a
>> different API just to keep things distinct.  But then we reencounter
>> the same sorts of problems we have with DOM UI, like for example if
>> you click a link from an FTP site to an HTML file, how to prevent the
>> FTP privileges from bleeding into the HTML file.
>>
>> I feel like Darin is the person who would best know how to address this.
>>  :)
>
>
>
> --
> Pierre.
>
> --
> 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] Re: Exposing Chrome Extensions APIs to DOM UI.

[Erik Arvidsson]

On Mon, Dec 14, 2009 at 18:24, Aaron Boodman  wrote:
> On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay  wrote:
>> On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman  wrote:
>>>
>>> Seems like a bad idea.
>>>
>>> Extensions and DOMUI are basically two competing systems for doing the
>>> same thing, it would get confusing combining them.
>>
>> While I can see this in principle, I'm not sure I see what the problems are
>> in practice.  What kinds of problems do you envision?
>> I think it would be nice for our current DOMUI pages to be built on top of
>> the extensions APIs, but potentially have access to a few special APIs that
>> extensions don't.  It seems like it would be painful to try to cut them over
>> to such a system all at once, so adding extensions APIs to DOMUI pages could
>> be a nice bridge.
>
> When you say "built on top of the extensions APIs" do you mean have
> access to, eg, chrome.tabs.*? Or do you mean use our
> ExtensionFunctionDispatcher and json schema infrastructure, but not
> use any of our APIs? I looked at the latter once before and it was a
> serious project. There is a lot of knowledge about the extension
> system baked into ExtensionFunctionDispatcher, such as who the current
> extension is and knowledge of the json schema system in the renderer.
>
> I think a simpler approach to get the benefits of the extension system
> is to just make the bookmark manager an extension. We'd have to filter
> it out of the chrome://extensions/ page and change its icon in the
> task manager, but those are fairly trivial changes compared to tearing
> all the knowledge of extensions out of ExtensionFunctionDispatcher
> system.
>
> If we want the bookmark manager to have some special APIs that other
> extensions don't, that also seems fairly easy to do once the bookmark
> manager is indeed an extension.
>
> To be clear, I'm also open to lower-level refactorings. I'm just
> warning that I suspect it's a serious project. A couple weeks at
> least.

The goal is to have a working bookmark manager at the end of January
and a complete one at the end of Q1. That makes me think that making a
DOM UI version that uses the extension API would not be feasible. I
also don't think that doing it as an extension is something that can
be done in the same time frame due to lacking APIs.

I think I'll just do an old school DOM UI and emulate the extensions
bookmark API so that the same code can be used.

>
> - a
>

-- 
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: Exposing Chrome Extensions APIs to DOM UI.

[Erik Arvidsson]

On Mon, Dec 14, 2009 at 16:48, Aaron Boodman  wrote:
> Seems like a bad idea.
>
> Extensions and DOMUI are basically two competing systems for doing the
> same thing, it would get confusing combining them. I would rather
> either:
>
> a) add new (possibly experimental) APIs for the issues you've run into.
> b) manually plumb the extension APIs you need through DOMUI (this is
> basically composition instead of inheritance)

Seems like b then. However, the extensions APIs are much nicer than
all the ad-hoc chrome.send + CallJavascriptFunction we are currently
using and having the same API seems like a win for maintainability.

>
> Is this the complete list of bugs?
> http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv
>
> Context menu is potentially on the M5 list. Depending on how complex a
> context menu API you want, this might not be too bad. We should just
> implement the chrome:// urls one I guess.

If we make the bookmark manager completely as an extension extensions
need to be able to hook up global keyboard shortcuts (27702) as well
as some way to hook into the wrench and system menus on mac.


>
> - a
>
> On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson  wrote:
>> I'm in the process of writing a bookmark manager in HTML. So far I've
>> written it as an extension but I'm now considering changing this to a
>> DOM UI page instead. [*]
>>
>> I would like to be able to expose the extensions API for bookmarks to
>> the DOM UI (and eventually make all DOM UI pages use extension APIs).
>> Where do I start? Is this a bad idea?
>>
>> Another option is to keep the bookmarks manager as a special extension
>> that is always turned on.
>>
>> [*] Extensions do not have enough privileges and there aren't enough
>> hooks to allow extensions to do all the things the bookmark manager
>> needs to do. I've filed bugs for everything I've run into.
>>
>> 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] Exposing Chrome Extensions APIs to DOM UI.

[Erik Arvidsson]

I'm in the process of writing a bookmark manager in HTML. So far I've
written it as an extension but I'm now considering changing this to a
DOM UI page instead. [*]

I would like to be able to expose the extensions API for bookmarks to
the DOM UI (and eventually make all DOM UI pages use extension APIs).
Where do I start? Is this a bad idea?

Another option is to keep the bookmarks manager as a special extension
that is always turned on.

[*] Extensions do not have enough privileges and there aren't enough
hooks to allow extensions to do all the things the bookmark manager
needs to do. I've filed bugs for everything I've run into.

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: Preventing keypress after accellerator?

[Erik Arvidsson]

I'm tempted to mark http://crbug.com/13891 as fixed. If we really want to
prevent the keypress after a command was handled by the renderer or the
browser we now work correctly. There used to be a few exceptions but I think
James fixed these in r29857.

On Sat, Nov 7, 2009 at 18:40, James Su  wrote:

>
>
> 2009/11/8 Peter Kasting 
>
> On Fri, Nov 6, 2009 at 6:51 PM, James Su  wrote:
>>
>>>  One example: the default behavior of Ctrl+M keypress event is
> "insertNewLine", and it'll always be performed in editor_client_impl.cc if
> the keypress event is not handled or prevented by the web app. Then the
> result is we can never use Ctrl+M as an browser accelerator.
>
> Is above explanation clear enough?
>

>> If we're in an editable area, wouldn't we _want_ ctrl-m to insert a new
>> line, and ctrl-b to toggle bold, etc.?  The description above sounds
>> desirable rather than problematic.
>>
> ctrl-b behaves exactly like what you said, because the toggle bold action
> is bound to its key down event. If we want ctrl-m to behave like it as well,
> we can add an entry in keyDownEntries in editor_client_impl.cc to achieve
> it.
>
>
>>
>> PK
>>
>
>
> >
>


-- 
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: Preventing keypress after accellerator?

[Erik Arvidsson]

On Thu, Nov 5, 2009 at 17:58, James Su  wrote:

> You may refer to following bug reports:
> http://crbug.com/21624
> http://crbug.com/21471
>
> 2009/11/6 Erik Arvidsson 
>
> We have code to suppress the keypress event if keydown triggered a browser
>> accelerator both inside and outside of WebKit. I don't understand why we
>> want to prevent a keypress after a Ctrl+A or Ctrl+B keydown?
>>
> Because Ctrl+A and Ctrl+B are special key accelerators which will be
> handled by the WebKit or the Browser. For example, Ctrl+B is for toggling
> bookmark bar. When pressing Ctrl+B, the key down event will be sent to the
> WebKit first, then it'll be forwarded to the Browser if the WebKit didn't
> handle or prevent it. Then the Browser will handle it and open or close the
> bookmark bar. Then if we still send the key press event of Ctrl+B to the
> WebKit, it might be handled by some javascript code in the web page and
> perform a specified action. Then the user will notice that two actions were
> triggered by pressing Ctrl+B. In most time, such behavior will confuse the
> user. Especially if the key triggers tab switching or other dramatic UI
> change.
>

I don't really agree with that argument. Neither Firefox nor Safari prevents
the keypress after a command. IE just don't fire keypress events for
Ctrl+Key with some exceptions.

We don't send Ctrl+n, Ctrl+t nor Ctrl+w to the render view which I'm not
considering changing. These should not be sent to the current view since
they all remove or moves the user to a new view.


>
>> --
>> 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] Preventing keypress after accellerator?

[Erik Arvidsson]

We have code to suppress the keypress event if keydown triggered a browser
accelerator both inside and outside of WebKit. I don't understand why we
want to prevent a keypress after a Ctrl+A or Ctrl+B keydown?

-- 
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: Tab Thumbnails and Aero Peek (of Windows 7)

[Erik Arvidsson]

2009/10/22 Hironori Bono (坊野 博典) 

> How to treat resize events of a browser window?
>
> The biggest problems of my current prototype are caused by my prototype
> that doesn’t handle resize events of a browser window. (Figure 4 may be
> acceptable. But, I think Figure 5 is unacceptable for many users.) The
> easiest solution for this problem is forcing a background tab to redraw when
> we need an image used for Aero Peek or Tab Thumbnails. Unfortunately, this
> solution probably hurts the rendering performance of Chromium. Another
> solution (or a workaround) is displaying a message “the preview image for
> the selected tab is not available” instead of showing a broken image. Any
> opinions or suggestions are definitely helpful.
>
Firefox nightlies now supports tab preview. If you resize the window the
background tabs keep their old thumbnails which I think is acceptable.

-- 
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: LTTF helping the GTTF make cycle times *minutes* faster

[Erik Arvidsson]

I looked at LayoutTests/fast/dom/cssTarget-crash.html earlier. It is a
webkit bug related to the frame loader so I was planning to take
another look when abarth was done with the frame loader refactoring.

On Fri, Oct 16, 2009 at 15:09, Ojan Vafai  wrote:
> Sweet. Down to 10 unassigned. Promise I'll stop spamming chromium-dev soon.
> :)
> WIN/LINUX/MAC
> LayoutTests/fast/dom/cssTarget-crash.html
> LayoutTests/fast/events/add-event-without-document.html
> LayoutTests/http/tests/history/back-to-post.php
> LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html
> LayoutTests/http/tests/security/cross-frame-access-document-direct.html
> LayoutTests/http/tests/security/xss-DENIED-defineProperty.html
> LayoutTests/http/tests/xmlhttprequest/methods-async.html
> LayoutTests/loader/go-back-to-different-window-size.html
> LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html
> LINUX/MAC
> LayoutTests/http/tests/misc/timer-vs-loading.html
> JORLOW
> LayoutTests/storage/domstorage/localstorage/iframe-events.html
> LayoutTests/storage/domstorage/sessionstorage/iframe-events.html
> AWALKER
> LayoutTests/http/tests/plugins/get-url.html
> LayoutTests/http/tests/plugins/interrupted-get-url.html
> LayoutTests/http/tests/plugins/npapi-response-headers.html
> LayoutTests/http/tests/plugins/post-url-file.html
> LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html
> LayoutTests/plugins/destroy-stream-twice.html
> LayoutTests/plugins/embed-inside-object.html
> LayoutTests/plugins/geturl-replace-query.html
> LayoutTests/plugins/npruntime.html
> LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html
> ANTONM
> LayoutTests/fast/dom/Window/window-property-shadowing-name.html
> YUTAK
> LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html
> LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html
> LayoutTests/http/tests/navigation/onload-navigation-iframe.html
> On Fri, Oct 16, 2009 at 2:42 PM, Jeremy Orlow  wrote:
>>
>> On Fri, Oct 16, 2009 at 2:34 PM, Ojan Vafai  wrote:
>>>
>>> Thanks for everyone's help. Good overnight progress. 6 media tests
>>> skipped. 2 tests marked SLOW. 5 assigned.
>>> 12 unassigned general tests.
>>> 10 unassigned Mac plugin tests.
>>> Any takers?
>>> WIN/LINUX/MAC
>>> LayoutTests/fast/dom/cssTarget-crash.html
>>> LayoutTests/fast/events/add-event-without-document.html
>>> LayoutTests/http/tests/history/back-to-post.php
>>>
>>> LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html
>>> LayoutTests/http/tests/security/cross-frame-access-document-direct.html
>>> LayoutTests/http/tests/security/xss-DENIED-defineProperty.html
>>> LayoutTests/http/tests/xmlhttprequest/methods-async.html
>>> LayoutTests/loader/go-back-to-different-window-size.html
>>>
>>> LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html
>>
>>
>>>
>>> LayoutTests/storage/domstorage/localstorage/iframe-events.html
>>> LayoutTests/storage/domstorage/sessionstorage/iframe-events.html
>>
>> I'll try to look at this within the next week.
>>
>>>
>>> LINUX/MAC
>>> LayoutTests/http/tests/misc/timer-vs-loading.html
>>> MAC
>>> LayoutTests/http/tests/plugins/get-url.html
>>> LayoutTests/http/tests/plugins/interrupted-get-url.html
>>> LayoutTests/http/tests/plugins/npapi-response-headers.html
>>> LayoutTests/http/tests/plugins/post-url-file.html
>>>
>>> LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html
>>> LayoutTests/plugins/destroy-stream-twice.html
>>> LayoutTests/plugins/embed-inside-object.html
>>> LayoutTests/plugins/geturl-replace-query.html
>>> LayoutTests/plugins/npruntime.html
>>>
>>> LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html
>>>
>>> ANTONM
>>> LayoutTests/fast/dom/Window/window-property-shadowing-name.html
>>> YUTAK
>>> LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html
>>> LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html
>>> LayoutTests/http/tests/navigation/onload-navigation-iframe.html
>>> YUZO
>>> LayoutTests/fast/loader/local-JavaScript-from-local.html
>>>
>>> On Thu, Oct 15, 2009 at 6:38 PM, Ojan Vafai  wrote:

 There are a lot of tests that consistently (i.e. not flaky) timeout.
 They eat up significant percentage (~10%!) of the cycle time for the test
 bots (e.g., >1 minute on Windows release). If LTTF folk focus some effort 
 on
 fixing these first, it would help all of us move forward faster as the bot
 cycle times would be improved as would the times to run the tests locally.
 To make this easier, I compiled the list of all the tests that
 consistently timeout. I excluded the flaky timeouts since the LTTF is
 currently focused on non-flaky failures. Any takers?
 Ojan

 ALL PLATFORMS:
 LayoutTests/fast/dom/Window/window-property-shadowing-name.html
 LayoutTests/fast

[chromium-dev] Re: New Tab Cold 20% perf regression on xp-release

[Erik Arvidsson]

According to Evan this was caused by Tony's fix to use a profile with
recent data.

http://src.chromium.org/viewvc/chrome?view=rev&revision=28924

It is still strange that it did no affect Mac or Linux.

On Fri, Oct 16, 2009 at 14:39, Nicolas Sylvain  wrote:
>
>
> On Fri, Oct 16, 2009 at 2:35 PM, Erik Arvidsson  wrote:
>>
>> The performance for New Tab Cold has regressed without about 20%
>> sometime before rev28918.
>
> This seems to be when i changed the hardware where this test is running.
> Where is
> the reference build?
> Nicolas
>
>>
>>
>> http://build.chromium.org/buildbot/perf/xp-release/new-tab-ui-cold/report.html?history=150
>>
>> The graph tells us that it is something in the rendering path. My main
>> suspect atm is the change to use system colors on windows since
>> neither Linux nor Mac was affected by this.
>>
>> --
>> 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] New Tab Cold 20% perf regression on xp-release

[Erik Arvidsson]

The performance for New Tab Cold has regressed without about 20%
sometime before rev28918.

http://build.chromium.org/buildbot/perf/xp-release/new-tab-ui-cold/report.html?history=150

The graph tells us that it is something in the rendering path. My main
suspect atm is the change to use system colors on windows since
neither Linux nor Mac was affected by this.

-- 
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: Question about UI and "classic views"

[Erik Arvidsson]

On Thu, Sep 24, 2009 at 00:26, Mike Belshe  wrote:

> On Thu, Sep 24, 2009 at 12:11 AM, Darin Fisher  wrote:
>
>> Do websites provide users with previous versions after overhauling their
>> UX?  Some do (gmail seems to), but most do not.  You just get to surf the
>> latest.  Hopefully, the website changes for the better.  That's our burden
>> to bear.
>
>
> I suspect it has to do with apps that contain your personal information
> (web history, contacts, email, etc).  Users come to expect their information
> is found in certain places, and when you change that around, you can
> alienate some users.  I suspect that is why GMail has backward compatible
> UIs but sites like CNN do not.
>

Gmail still has the old UI for browsers that are too slow and does not
support the required features.

Like Ben said --old-new-tab-page was there during the transition and should
be removed (I volunteer).

The NTP can also be totally* replaced using extensions so one way to cater
to these few but vocal users is to redirect them to extensions.

* The extension system does not yet have access to all the needed data to
rebuild the current NTP.

>
> It sounds like Alice and others will figure out if there is something that
> needs to change.
>
> Mike
>
>
>
>>
>> -Darin
>>
>>
>> On Wed, Sep 23, 2009 at 8:59 PM, Mike Belshe  wrote:
>>
>>> I just got a fairly angry email from my sister about the new tab page UI.
>>> She writes:
>>>
 "What’s up with the Chrome Tab page change?  I thought I screwed up my
 page at home, but now my page at work has changed too.
>>>
>>>  I don’t like it.
>>>
>>>  Why do I have to have my tabs arranged 4x2 ? I liked 3x3.
>>>
>>>  What happened to the delete tabs?
>>>
>>>  Do we get no say in what our page looks like?  Google just gets to make
>>> the change without so much as a notice, “Your page has changed for the
>>> worse”.
>>>
>>>  Sorry to dump on you  but, it sure is nice thinking that I can gripe to
>>> someone at a giant company like Google and there actually might be someone
>>> listening."
>>>
>>>
>>> This is probably a good point; why didn't we offer a "classic view"
>>> option to users?  It is not like the current new-tab-page is all that
>>> radically different.  I'm sure we were aware that some users would feel this
>>> way?  But we think we know better than they do what this page should look
>>> like?
>>>
>>> BTW - I liked 3x3 better than 4x2 better too.
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>
>
> >
>


-- 
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

[Erik Arvidsson]

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 :
> [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:
> 
>    Download:   jscontent="url"> http://www.some.com/...
> 
> 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
> 
>    Download:   jscontent="url"> http://www.some.com/...
> 
> after injecting Spanish strings, it would be
> 
>    Descarga:   jscontent="url"> http://www.some.com/...
> 
> 2009/7/8 Erik Arvidsson 
>>
>> 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 (신정식, 申政湜) :
>> >
>> >
>> > 2009/7/8 Erik Arvidsson 
>> >>
>> >> 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 Boodman wrote:
>> >> > On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodman
>> >> > 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
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rewrite of DOMUI l10n strings

[Erik Arvidsson]

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 (신정식, 申政湜) :
>
>
> 2009/7/8 Erik Arvidsson 
>>
>> 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 Boodman wrote:
>> > On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodman 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

[Erik Arvidsson]

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?

On Wed, Jul 8, 2009 at 12:00, Aaron Boodman wrote:
> On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodman wrote:
>> Agree with Erik that it seems like we should share this code between
>> DOMUI and the extensions system.
>
> (Erik Kay)
>

-- 
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

[Erik Arvidsson]

On Wed, Jul 8, 2009 at 11:51, Adam Barth wrote:
> Ideally we would use an existing library instead of rolling our own.
> One major benefit of using existing code is that all the XSS holes
> will have been worked out already.

Replacing JST with something custom is something I am totally comfortable with.

If we end up doing the string replacing on the front end I do agree
that we should use some existing library since this is a much harder
problem.

>
> Adam
>
>
> On Wed, Jul 8, 2009 at 11:36 AM, Tony Chang wrote:
>>
>> No objections from me-- a faster new tab page sounds great!  A couple
>> side goals to consider:
>> - Maybe move this new js code into a pseudo protocol rather than
>> appending the js blob into every html file.  I think e.g., the
>> devtools does this already.
>> - It would be nice if this would some day completely replace
>> jstemplate, but maybe that's not really worth the effort.
>>
>> On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidsson wrote:
>>> On Wed, Jul 8, 2009 at 11:13, Tony Chang wrote:
>>>>
>>>> What are the more advanced things that we use JST for?  Off the top of
>>>> my head, all I can think of is bulleted lists.
>>>
>>> jsselect -  which allows iteration. This is used for bulleted lists and the 
>>> like
>>>
>>> eval/switch - this is used to allowed arbitrary JS expressions but it
>>> is only used inside jsselect at the moments.
>>>
>>>> I think we went with a JS solution because it seemed easier and safer
>>>> at the time.
>>>>
>>>> I'm ok with doing string injection in the front end (i.e., a C++ HTML
>>>> templating library), I'm just concerned about XSS.  Is there a good
>>>> existing library that would integrate well into chromium?
>>>
>>> I'm not sure.
>>>
>>> I think a small js solution is something I can do in a day or two and
>>> it will buy us about 30ms on every DOMUI page.
>>>
>>> Any objections to me going ahead with my initial plan?
>>>
>>>>
>>>> On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidsson wrote:
>>>>> On Wed, Jul 8, 2009 at 11:05, Glen Murphy wrote:
>>>>>> This time from a Chromium account:
>>>>>>
>>>>>> It would be nice if we didn't have to use JS and could just embed the
>>>>>> strings live so that they could be cached, etc. Our CSS (and maybe
>>>>>> even JS) files could use something like this, (currently we're just
>>>>>> doing $0-$9 replacement).
>>>>>
>>>>> I'm not sure what you mean be "embed the > strings live so that they
>>>>> could be cached"?
>>>>>
>>>>>> This may be separate to what you're looking for.
>>>>>
>>>>> It was different from what I had in mind but maybe we should do the
>>>>> string injection on the front end instead of JS?
>>>>>
>>>>> What was the reason for doing it in JS in the first place?
>>>>>
>>>>>> On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson wrote:
>>>>>>> Currently we use JsTemplate
>>>>>>> (http://code.google.com/p/google-jstemplate/) to do our l10n of the
>>>>>>> DOMUI. JST has been working well but it is a bit of an overkill to do
>>>>>>> l10n of our UI. It has a couple of features that makes it slow down
>>>>>>> the UI:
>>>>>>>
>>>>>>> 1. It uses eval for every single RHS
>>>>>>> 2. It uses two nested with statements
>>>>>>> 3. It traverses the whole DOM using JavaScript
>>>>>>>
>>>>>>> It also has some advanced features like jsselect, which allows
>>>>>>> iteration, that we are using for non l10n things.
>>>>>>>
>>>>>>> My plan is to create a simpler solution, with almost exactly the same
>>>>>>> syntax that solves the 3 bullet points above. It will not allow
>>>>>>> arbitrary expressions on the RHS and it will only support jsvalues and
>>>>>>> jscontent. Instead of traversing the entire tree it ill use
>>>>>>> document.querySelector which does the tree traversal in C++ and uses
>>>>>>> CSS selectors as the matching which is a lot faster than doing the
>>>>>>> tree traversal in JS.
>>>>>>>
>>>>>>> Since there are still cases where we use JST to do more advanced
>>>>>>> templating it will still be available but it will require opt in.
>>>>>>>
>>>>>>> Any thoughts?
>>>>>>>
>>>>>>> --
>>>>>>> erik
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rewrite of DOMUI l10n strings

[Erik Arvidsson]

I reread the thread and the design doc and it does not really cover
when string replacements should happen.

Doing a JST lite for l10n is something that can be used in extensions
but I think the long term solution is to do this on the front end.

On Wed, Jul 8, 2009 at 11:33, Erik Arvidsson wrote:
> On Wed, Jul 8, 2009 at 11:29, Erik Kay wrote:
>> This seems like a reasonable plan.
>> It would be cool if whatever mechanism you chose could be leveraged by
>> extensions as well (see the earlier extensions i18n proposal that was sent
>> around last week).  For this reason I'd prefer that if we moved to a C++
>> solution (as others in this thread have suggested) that it run in the
>> renderer and not in the browser process (for security reasons).
>
> I'll go back and reread that design doc to see how that might change things.
>
>> On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson  wrote:
>>>
>>> Currently we use JsTemplate
>>> (http://code.google.com/p/google-jstemplate/) to do our l10n of the
>>> DOMUI. JST has been working well but it is a bit of an overkill to do
>>> l10n of our UI. It has a couple of features that makes it slow down
>>> the UI:
>>>
>>> 1. It uses eval for every single RHS
>>> 2. It uses two nested with statements
>>> 3. It traverses the whole DOM using JavaScript
>>>
>>> It also has some advanced features like jsselect, which allows
>>> iteration, that we are using for non l10n things.
>>>
>>> My plan is to create a simpler solution, with almost exactly the same
>>> syntax that solves the 3 bullet points above. It will not allow
>>> arbitrary expressions on the RHS and it will only support jsvalues and
>>> jscontent. Instead of traversing the entire tree it ill use
>>> document.querySelector which does the tree traversal in C++ and uses
>>> CSS selectors as the matching which is a lot faster than doing the
>>> tree traversal in JS.
>>>
>>> Since there are still cases where we use JST to do more advanced
>>> templating it will still be available but it will require opt in.
>>>
>>> Any thoughts?
>>>
>>> --
>>> 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
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rewrite of DOMUI l10n strings

[Erik Arvidsson]

On Wed, Jul 8, 2009 at 11:29, Erik Kay wrote:
> This seems like a reasonable plan.
> It would be cool if whatever mechanism you chose could be leveraged by
> extensions as well (see the earlier extensions i18n proposal that was sent
> around last week).  For this reason I'd prefer that if we moved to a C++
> solution (as others in this thread have suggested) that it run in the
> renderer and not in the browser process (for security reasons).

I'll go back and reread that design doc to see how that might change things.

> On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson  wrote:
>>
>> Currently we use JsTemplate
>> (http://code.google.com/p/google-jstemplate/) to do our l10n of the
>> DOMUI. JST has been working well but it is a bit of an overkill to do
>> l10n of our UI. It has a couple of features that makes it slow down
>> the UI:
>>
>> 1. It uses eval for every single RHS
>> 2. It uses two nested with statements
>> 3. It traverses the whole DOM using JavaScript
>>
>> It also has some advanced features like jsselect, which allows
>> iteration, that we are using for non l10n things.
>>
>> My plan is to create a simpler solution, with almost exactly the same
>> syntax that solves the 3 bullet points above. It will not allow
>> arbitrary expressions on the RHS and it will only support jsvalues and
>> jscontent. Instead of traversing the entire tree it ill use
>> document.querySelector which does the tree traversal in C++ and uses
>> CSS selectors as the matching which is a lot faster than doing the
>> tree traversal in JS.
>>
>> Since there are still cases where we use JST to do more advanced
>> templating it will still be available but it will require opt in.
>>
>> Any thoughts?
>>
>> --
>> 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

[Erik Arvidsson]

On Wed, Jul 8, 2009 at 11:13, Tony Chang wrote:
>
> What are the more advanced things that we use JST for?  Off the top of
> my head, all I can think of is bulleted lists.

jsselect -  which allows iteration. This is used for bulleted lists and the like

eval/switch - this is used to allowed arbitrary JS expressions but it
is only used inside jsselect at the moments.

> I think we went with a JS solution because it seemed easier and safer
> at the time.
>
> I'm ok with doing string injection in the front end (i.e., a C++ HTML
> templating library), I'm just concerned about XSS.  Is there a good
> existing library that would integrate well into chromium?

I'm not sure.

I think a small js solution is something I can do in a day or two and
it will buy us about 30ms on every DOMUI page.

Any objections to me going ahead with my initial plan?

>
> On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidsson wrote:
>> On Wed, Jul 8, 2009 at 11:05, Glen Murphy wrote:
>>> This time from a Chromium account:
>>>
>>> It would be nice if we didn't have to use JS and could just embed the
>>> strings live so that they could be cached, etc. Our CSS (and maybe
>>> even JS) files could use something like this, (currently we're just
>>> doing $0-$9 replacement).
>>
>> I'm not sure what you mean be "embed the > strings live so that they
>> could be cached"?
>>
>>> This may be separate to what you're looking for.
>>
>> It was different from what I had in mind but maybe we should do the
>> string injection on the front end instead of JS?
>>
>> What was the reason for doing it in JS in the first place?
>>
>>> On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson wrote:
>>>> Currently we use JsTemplate
>>>> (http://code.google.com/p/google-jstemplate/) to do our l10n of the
>>>> DOMUI. JST has been working well but it is a bit of an overkill to do
>>>> l10n of our UI. It has a couple of features that makes it slow down
>>>> the UI:
>>>>
>>>> 1. It uses eval for every single RHS
>>>> 2. It uses two nested with statements
>>>> 3. It traverses the whole DOM using JavaScript
>>>>
>>>> It also has some advanced features like jsselect, which allows
>>>> iteration, that we are using for non l10n things.
>>>>
>>>> My plan is to create a simpler solution, with almost exactly the same
>>>> syntax that solves the 3 bullet points above. It will not allow
>>>> arbitrary expressions on the RHS and it will only support jsvalues and
>>>> jscontent. Instead of traversing the entire tree it ill use
>>>> document.querySelector which does the tree traversal in C++ and uses
>>>> CSS selectors as the matching which is a lot faster than doing the
>>>> tree traversal in JS.
>>>>
>>>> Since there are still cases where we use JST to do more advanced
>>>> templating it will still be available but it will require opt in.
>>>>
>>>> Any thoughts?
>>>>
>>>> --
>>>> 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
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rewrite of DOMUI l10n strings

[Erik Arvidsson]

On Wed, Jul 8, 2009 at 11:05, Glen Murphy wrote:
> This time from a Chromium account:
>
> It would be nice if we didn't have to use JS and could just embed the
> strings live so that they could be cached, etc. Our CSS (and maybe
> even JS) files could use something like this, (currently we're just
> doing $0-$9 replacement).

I'm not sure what you mean be "embed the > strings live so that they
could be cached"?

> This may be separate to what you're looking for.

It was different from what I had in mind but maybe we should do the
string injection on the front end instead of JS?

What was the reason for doing it in JS in the first place?

> On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson wrote:
>> Currently we use JsTemplate
>> (http://code.google.com/p/google-jstemplate/) to do our l10n of the
>> DOMUI. JST has been working well but it is a bit of an overkill to do
>> l10n of our UI. It has a couple of features that makes it slow down
>> the UI:
>>
>> 1. It uses eval for every single RHS
>> 2. It uses two nested with statements
>> 3. It traverses the whole DOM using JavaScript
>>
>> It also has some advanced features like jsselect, which allows
>> iteration, that we are using for non l10n things.
>>
>> My plan is to create a simpler solution, with almost exactly the same
>> syntax that solves the 3 bullet points above. It will not allow
>> arbitrary expressions on the RHS and it will only support jsvalues and
>> jscontent. Instead of traversing the entire tree it ill use
>> document.querySelector which does the tree traversal in C++ and uses
>> CSS selectors as the matching which is a lot faster than doing the
>> tree traversal in JS.
>>
>> Since there are still cases where we use JST to do more advanced
>> templating it will still be available but it will require opt in.
>>
>> Any thoughts?
>>
>> --
>> 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

[Erik Arvidsson]

Currently we use JsTemplate
(http://code.google.com/p/google-jstemplate/) to do our l10n of the
DOMUI. JST has been working well but it is a bit of an overkill to do
l10n of our UI. It has a couple of features that makes it slow down
the UI:

1. It uses eval for every single RHS
2. It uses two nested with statements
3. It traverses the whole DOM using JavaScript

It also has some advanced features like jsselect, which allows
iteration, that we are using for non l10n things.

My plan is to create a simpler solution, with almost exactly the same
syntax that solves the 3 bullet points above. It will not allow
arbitrary expressions on the RHS and it will only support jsvalues and
jscontent. Instead of traversing the entire tree it ill use
document.querySelector which does the tree traversal in C++ and uses
CSS selectors as the matching which is a lot faster than doing the
tree traversal in JS.

Since there are still cases where we use JST to do more advanced
templating it will still be available but it will require opt in.

Any thoughts?

--
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] New New Tab Page submitted

[Erik Arvidsson]

On Monday I submitted the New New Tab Page.

To run it start chrome with --new-new-tab-page

There are some known issues:

- Edit link is not implemented
- Theme/attribution support needs to be implemented and tested
- RTL needs more testing
- No dragover animations at the moment
- The recommendation backend has not been hooked up to the UI
- Hiding and showing the recent and recommendations work but the
content needs to update to show more data.
- Keyboard navigation of the options menu is not yet implemented.
- Chrome drag and drop only support the copyLink action which gives
wrong UI feedback
- more, see tracking bug.

It would be good if people started to run with this command line flag
and started reporting bugs so we can get this polished for 3.0.

The tracking bug is http://crbug.com/13362

Thanks,

erik

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---