crosswalk-project / crosswalk Goto Github PK

HTML favicon feature allows web page to add favorite icon and tell browser showing it on address bar and window title bar.
See http://stackoverflow.com/questions/9943771/adding-a-favicon-to-a-static-html-page

As the first step, Cameo is designed to use favicon as app window icon.

Next step in future:

1. Read the icon file path from app manifest file
2. Use meta tag (may need to implement it in chrome). -- Done
3. Add "--app-icon" option to allow user specify the icon file from command line

Run external extension code in a separate process. If this code crashes, it won't make the whole runtime go down. We could benefit by:

• Showing better diagnostic information
• In some cases, simply reloading the extension process and the application itself

If they are still not, make the external extension code run on the Browser Process. After this task, Brackets should be able to run (after adapting the external extension) when Cameo have sandbox turned on.

Setup the buildbot to build against trunk of cameo repository and any downstream repositories (chromium-cameo).

Code change in each of these repo will trigger build. The build result will email to a blame list and administrators.

A link to buildbot waterfall should be posted at project font page.

Calling navigator.geolocation.getCurrentPosition causes cameo launcher crash.
The root cause is default content::ContentBrowserClient::CreateAccessTokenStore returns NULL.

Including file pickers and color chooser.
file picker sample and
color chooser sample can be test cases.

Currently, getUserMedia can't work on Cameo, because the virtual method WebContentsDelegate::RequestMediaAccessPermission wasn't implementated on Runtime Class.

We can implement it just like what CEF3 is doing.

Trybot is triggered by pull requests' creation, code update or command (via comment).

For each new pull request (via github.com API http://developer.github.com/v3/), trybot pulls the changeset locally, applies on pull request target and starts to build.

The build results will be added as a comment to pull request for contributor and reviewers' reference.

A good reference is OpenCV project: http://pullrequest.opencv.org/

The linux trybot is always blocked by CameoDevToolsTest.RemoteDebugging test.

• What we have identified?

  On my local machine, the CameoDevToolsTest.RemoteDebugging test can pass in both Debug and Release mode with running 100 times repeatedly.

  @wang16 tried to run it on linux trybot by manual, the test can also pass.

• Possible reason

  Since the test is trying to access http://127.0.0.1:9222, if the loopback address or the 9222 port is occupied by accident, the test will fail but need to identify further.

• Next action

  Figure out what happens on linux trybot.

We already used the IDL parser, but with a custom code generator for CEF3 API. If we are using the Content API and Chromium internals, it is possible that we can reuse their internal script if it's not too coupled with Chrome.

The goal here is to generate boilerplate for APIs like Tizen (and SysApps until we can upstream it). A good definition of done for this task would be having one of this APIs generated from IDL and with a "dummy" implementation.

• Can we generate boilerplate for message passing between Renderer and Browser process?

Developers deploying the runtime (as part of a platform or their own app) should be able to expose extra APIs for JS client code. This is the model we expect that Brackets expose its extra
brackets.* code.

The word initial here refers to the extent of C++ API we will exposing. It should be enough to achieve:

• Implementation of brackets extensions (or similar) as external extensions.
• Allow exposing new objects to JS client code.
• Allow exposing new functions to JS client code.

At this stage, it is OK to run this as part of renderer process, so depending on the nature of the extension, sandbox should be turned off (--no-sandbox).

chromium-cameo is the downstream fork of chromium for cameo development.

Buildbot for chromium-cameo should build conent_shell, run layout tests and content layer tests.

The url in DEPS.cameo is ssh://github.com. It should be using [email protected] to be more compatible.

Tests in Chromium: http://code.google.com/p/chromium/wiki/TestDescriptions

For cameo, as the initial step, the test framework could target unit test and integration test (browser test).

Some references:

1. gtest for unit test: http://code.google.com/p/googletest/
2. Chromium browser test: http://www.chromium.org/developers/testing/browser-tests

Builtin extensions are those that will be part of cameo repository, like SysApps.

While in the long run we expect to re-use chromium machinery for this, that might have to wait the effor to decouple it from 'chrome' upstream. So a solution that doesn't share code with Chromium is also acceptable for now.

Implementation of one of SysApps extension should serve as example.

We have a few options to go today:

• Copy minimal amount of Extension subsystem to Cameo (like ningxin branch).
• Hack the buildsystem and use chrome's Extension subsystem/
• Make a solution of our own

Cameo should define its own version scheme.

Chromium uses
MAJOR.MINOR.BUILD.PATCH

https://github.com/otcshare/chromium-cameo/blob/lkgr/chrome/VERSION

Ideally, Crosswalk version could include the version of underlying Chromium.

It basically does:

1. Fetch LKGR periodly (daily?)
2. Rebase downstream patches, notify any conflicts to developer who is blamed, involve him/her to resolve. (This part could be complex, maybe a simplified version in first step)
3. Trigger downstream bot (e.g. chromium-crosswalk bot)
4. Trigger crosswalk bot

Our long-term goal is to share as much code as possible with Chromium project. Currently the extension subsystem is tied with chrome/. There's on going work upstream to decouple it.

• Can we use it for both builtin and external extensions?

We could use Aura (NOT Aura Shell) to create native windows in Win and Linux. Investigate whether this is enough for our purposes and whether we can create Mac windows the same way.

• Can we create windows without client side decoration?
• Can we reuse platform dialogs? (This might need some upstream work see issue for Linux)
• Do menus/combos work correctly?

The goal is to reuse this bits from Chromium for native window creation instead of writing our own code. Currently there's different GTK code for src/chrome and src/content/shell.

The mailing list discussion indicates Aura will be used for content_shell/chrome in Windows

https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-dev/A-5Jgv3DDO4

and there are plans for Linux on Desktop

http://code.google.com/p/chromium/issues/detail?id=125106

Aura is also used in ChromeOS.

Requirement is from Alexis:
As we are a global team we need to make sure that the code is consistent. As we
are a downstream of Chromium project I believe we should use the coding style
of Chromium so it will ease any potential upstreaming work. Despite Blink uses the coding style of WebKit, they plan to slowly migrate to Chromium's one. A problem today is that we don't have code-checking enforced when a pull request is submitted. An very needed task would be to create a style bot to apply the patch locally, check the style using the Chromium code checking style (we can just copy the script in cameo repo for now) and using
http://developer.github.com/v3/pulls/ we could comment on the pull request.

This bug is for the first step, have the script in cameo repo, developer use the script to check style before pull request.

When depot_tools path in PATH env is end of slash like "/home/myname/depot_tools/". Function FindDepotToolsInPath in util.py will fail.

The first step could be to import Chromium content shell as the base of Cameo launcher.

Beyond vanilla content shell, it should be adapted to Cameo project.
It includes:

1. Setup the gyp files.
2. Separate from content shell, such as namespace change, naming change, unused methods and files removing
3. Remove unused layout test support. The layout test should be tested on chromium content layer.

Expected results:

1. Able to build cameo launcher on Windows and Linux (ubuntu first).
2. Able to launch remote or local HTML file.

What is needed to integrate Cameo to EFL?

We need to do the following:

1. Study and analysis work to find the optimal design.
2. Implementation proposal
3. Implementation

The manifest format of application should follow the sysapps spec at http://manifest.sysapps.org/

Similar to trybot, stylebot is triggered by pull requests creation, code update and command, but coding style check.

The coding style checking results will be added as a comment to pull request for contributor and reviewers' reference.

stylebot might be a step of trybot.