TIP: -webkit-app-region CSS property

While looking through the source of windows sample (https://github.com/GoogleChrome/chrome-app-samples/tree/master/windows ) I noticed a CSS property:

-webkit-app-region: drag;

What this does is that if you drag on any element with this style, it moves the whole app window around. No other mouse and keyboard interactions with the elements area are possible though. To work around that you have to use the style:

-webkit-app-region: no-drag;

on the sub-element with which you want to allow normal keyboard and mouse interaction.

This is very handy when you create chrome app windows with 'frame' : 'none' window creation option. In fact, -webkit-app-region works only when you create the window with 'frame' : 'none' . You don't have to implement the logic to support window move.

BTW even when using with 'frame' : 'none' which results in lack of system supplied titlebar and borders, the system menu to move, resize, minimize, maximize, restore and close the window is available by right clicking on the areas defined by:

-webkit-app-region: drag;

The standard keyboard shortcut such as Alt+SPACE on windows can be used to invoke the menu also. The window can be resized using the window edges.

I used it in smart phone browser simulator apps, Desktop App for YouTube and Chrome Packaged App Manifest Version 2 Editor App.

Hope this helps other Chrome App writers.

Try Chrome Developer Tools Enhancement - Scope Varibles section

In this blog entry I talked about enhancing the Scope Variables section of Chrome Developer tools. If you want to try the enhancement yourself you can easily do so by following this procedure:

• Download and install Chrome Canary. My changes are compatible with Chrome canary only.
• Configure its launch with following parameters:

chrome.exe --remote-debugging-port=9222 --remote-debugging-frontend="http://chrome-developer-tools.googlecode.com/git/inspector/front-end/inspector.html"

The

--remote-debugging-frontend="http://chrome-developer-tools.googlecode.com/git/inspector/front-end/inspector.html"

parameter basically tells the Chrome debugger back-end to use the Developer Tools located at:

http://chrome-developer-tools.googlecode.com/git/inspector/front-end/inspector.html

which is where I have put my modified code for developer tools.

UPDATE: It appears that the runtime flag `—remote-debugging-frontend` was recently removed. Instead, custom frontend url needs to be specified after a pound sign in address of remote debugging server when connecting to the server running at 9222 due to the flag -remote-debugging-port=9222. Instead of navigating to “localhost:9222", go to “localhost:9222#http://localhost:8088/front_end/inspector.html?experiments=true”.

So the new invocation should look like this:

chrome.exe --remote-debugging-port=9222 --no-first-run --user-data-dir=C:\devtoolsprofile

• Launch the page you want to debug in one tab

• Launch another tab with the following URL

http://localhost:9222

UPDATE:

http://localhost:9222#http://localhost:8088/front_end/inspector.html?experiments=true

• Select the page you want to debug in the grid that is shown - in my case it is test.html from above

• Set breakpoints and run the action in page to be debugged that will cause the break point to be hit. Try out my enhancement to the Scope Variable section. The enhancement is to highlight the scope variables that are new or changed their value since the last time the debugee was suspended.

Please provide feedback.

Here is a simple packaged app that wraps Developer Tools:

If you are interested you can download it here.

Enjoy!

Hacking Chrome Developer Tools

In the Contributing to Chrome Developer Tools > Setting up section it talks about:

• :
• Clone WebKit git repo from git://git.webkit.org/WebKit.git
• Set up a local web server that would serve files from WebKit/Source/WebCore/inspector on some port (8090)

I wanted a simple web server. To do this here is what I did:

• Cloned WebKit git repo from git://git.webkit.org/WebKit.git

> cd c:\

> git clone git://git.webkit.org/WebKit.git

• Installed node,js
• Installed connect like so

> cd c:\WebKit\Source\WebCore\inspector

> npm install connect

• Created a front-end-server.js file with content which basically sets up a simple web server:

var connect = require('connect');

connect.createServer(

    connect.static(__dirname)

).listen(8090);

• The __dirname basically serves the files relative to c:\WebKit\Source\WebCore\inspector
• Ran the server like so

> node front-end-server.js

• Followed rest of the instructions on the page Contributing to Chrome Developer Tools
• Download and run Chrome Canary

> ...\chrome.exe --user-data-dir=C:\canary-profile --remote-debugging-port=9222 --remote-debugging-frontend="http://localhost:8090/front-end/inspector.html". BTW, it is a good idea to run with --user-data-dir=C:\canary-profile parameter so that this instance does not interfere with your desktop Chrome you use for your regular use.

• Launch another Chrome (this does not have to be the Chrome Canary) window on http://localhost:9222 . This shows a grid menu of pages to select from to debug. Please note that this menu is served by a small Web server running inside the first instance of Chrome Canary due to the --remote-debugging-port=9222 command line parameter passed to it when it was started

• Clicking on test.html launches the debugger which is using my copy of devtools from C:\WebKit\Source\WebCore\inspector\front-end . Please note that the link address of the test.html in the http://localhost:8090/front-end/inspector.html?ws=localhost:9222/devtools/page/1. Why http://localhost:8090/front-end/inspector.html you ask? That is because of the --remote-debugging-frontend="http://localhost:8090/front-end/inspector.html" command line parameter passed in when first instance of Chrome canary was started.

• I was able to edit the Chrome Developer Tools front-end code in the following directory iteratively  C:\WebKit\Source\WebCore\inspector\front-end

Voila! I was in business...

Chrome Developer Tools Enhancement - Scope Varibles section

I just submitted an enhancement patch to the Chrome Developer tools issue:

• 29714 - apply a style change to scope variables as they change from step to step

The patch implements the following functionality. As you step through the JavaScript code:

• When a new property comes into scope it's name and value is highlighted. For example on line 10 a new propety j was added to object o. Hence it's name and value is highlighted.

• When a property is modified since the last suspension the value is highlighted. For example in line 11 the values of both properties i and j were modified, hence their values are highlighted.

• The value is highlighted when the type of the value changes (not shown). For example, i = 1; and i = '1'; are same in terms of == operator, such a change is highlighted.

This functionality is (better) similar to the Eclipse JDT Java Debugger.

How does it work

The implementation is fairly simple. It keeps track of the set of properties and their values and types that are shown in the Scope variables section. Next time when the debugee is suspended it compares the new set of properties with the old set. That is how detects new properties as well as changes in values and types. The implementation is fairly efficient as long as the user has not expanded too may nodes of the Scope Variables tree.


I do not have commit permissions, but I hope the Chrome Developer Tools team accepts my patch.

If anyone is adventurous enough here is the patch, please give it a try and send me feedback. The patch applies to .ObjectPropertiesSection.js and WatchExpressionsSidebarPane.js.

You can also apply the changes in the patch in the Sources tab source editor of the DevTools.js. For this you will have to invoke Chrome Developer Tools (meta instance) on the window of the Chrome Developer Tools (first instance) that you are using to debug your web page. Kind of meta debugging. For this to work easily your first instance of Chrome Developer Tools has to be running in separate window.


Here is a related issue, once solved will make the implementation more precise becuase the eaxct identity of the objects in the debugee will be reliabliy maintained be the backend:

• 109908 - Web Inspector: support stable remote object ids

Enjoy!