Re: [webkit-dev] Experimental features in Safari Web Inspector
On Sep 27, 2012 1:56 AM, Dean Jackson dino d...@apple.com@d...@apple.com apple.com d...@apple.com wrote: On 26/09/2012, at 6:15 PM, Mihai Balan mibalan miba...@adobe.com@miba...@adobe.com adobe.com miba...@adobe.com wrote: We have recently been working on some WebInspector features related to CSS Regions. Most of the work was done using Chromium's Developer Tools, as this allowed us to have this work under a DevTools experiment flag. Now that this work has reached a more stable state, it would be useful to test it under Webkit/Safari, too. So, my question for you is this (ok, that's actually two questions): 1. Is there a way to enable / disable features in Safari DevTools the way it is in Chromium's? It doesn't have to be a GUI, though No. We should probably enable experiments in WebKit nightly (i.e. Experiments tab will be enabled in WebKit Web Inspector's settings at all times). I can do that for you or r+ such a patch. 2. What is the general policy for WebInspector features? How and when do they get enabled by default, at least in the nightlies? (Since regions are already enabled by default in the nightlies, IMO it would make sense to have the web inspector regions features, too) The process of adding features into WebKit Web Inspector is very lightweight. When you think the feature is ready for the prime time, make a patch moving it out of experimental. We will review it and suggest if something is missing. Regards Pavel Safari's Web Inspector lives in the Safari.app, so nightlies do not automatically get new features. The best thing to do is implement it in the Open Source inspector (as you've done) and Apple will (hopefully) merge it in. You can also file a bug at bugreporter.apple.com explicitly requesting it. Dean ___ webkit-dev mailing list webkit webkit-dev@lists.webkit.org-dev@ webkit-dev@lists.webkit.org lists.webkit.org webkit-dev@lists.webkit.org http:// http://lists.webkit.org/mailman/listinfo/webkit-dev lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev /mailman/ http://lists.webkit.org/mailman/listinfo/webkit-devlistinfohttp://lists.webkit.org/mailman/listinfo/webkit-dev / http://lists.webkit.org/mailman/listinfo/webkit-devwebkithttp://lists.webkit.org/mailman/listinfo/webkit-dev -dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)
By the way, in preparing the patch, I noticed that webkitSlice was used by the web inspector. Note that the data above includes the use by the web inspector. The usage was in the heap profiler's load snapshot routines, so I can imagine it not being invoked a lot. That matches the stats fine. We'll follow up on it. Regards Pavel Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Existing metrics for deprecated features
On Fri, Sep 14, 2012 at 4:13 AM, Adam Barth aba...@webkit.org wrote: In connection with the thread on webkitPostMessage, I took a look at what sorts of metrics we have currently for depreciated features. We have high quality data for two groups of APIs: For mutation events, we measure what percent of Documents have listeners for various kinds of mutation events: DOMAPI.PerDocumentMutationEventUsage.DOMCharacterDataModified: 2.85% of all Documents DOMAPI.PerDocumentMutationEventUsage.DOMNodeInserted: 4.78% of all Documents DOMAPI.PerDocumentMutationEventUsage.DOMNodeInsertedIntoDocument: 0.21% of all Documents DOMAPI.PerDocumentMutationEventUsage.DOMNodeRemoved: 0.07% of all Documents DOMAPI.PerDocumentMutationEventUsage.DOMNodeRemovedFromDocument: 0.0003% of all Documents DOMAPI.PerDocumentMutationEventUsage.DOMSubtreeModified: 2.30% of all Documents From this data, it's tempting to remove support for DOMNodeRemoved and DOMNodeRemovedFromDocument as those are used extremely rarely. We don't have any data for how much of this usage is attributable to extensions. It will be interesting to watch this data as we evangelize MutationObservers, especially among extension developers. Is there an absolute number for those 0.07%? How is it calculated? Like Web Inspector has been using DOMNodeRemoved for its viewport-based text editor until very recently, so your 0.07% is likely to include millions of users. Is that expected? I wonder what will the drop be with the next major Chrome release. Another metric we have is for Blob.webkitSlice: Ratio of Blob.webkitSlice calls to Blob.slice: 14.87% Ratio of Blob.webkitSlice calls to Document creation: 0.0053% It's difficult to know how to interpret this data because we don't actually correlate calls to webkitSlice with Documents or Pages. Instead, we just count the total number of calls across all Documents. This gives us an upper bound on how many Documents (or Pages) would be affected by deleting Blob.webkitSlice, but doesn't measure that information as accurately as the data we have for mutation events. We are also gathering metrics on the usage of vendor prefixes in CSS properties, but that histogram doesn't appear to have been in the field long enough to have meaningful data. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Inspector files
[From chromium.org] We throw away closure compiler output and use compilation step for type checking only. The best way to learn what files you should combine and bundle is via looking at WebCore.gyp(i) and WebKit.gyp(i). You basically need what is listed in inspector.html (these you can concatenate) + a bunch of standalone CSS files that are lazily loaded + a couple of web worker scripts. Regards Pavel On Jun 8, 2012 12:54 PM, Konrad Piascik kpias...@rim.com wrote: Hi, I'm trying to combine all the web inspector resources CSS, JS HTML into as few files as possible. I know that there are scripts in Source/WebCore/inspector but I'm not sure which ones should be used and some don't contain usage information. Also there's both combine-front-end.py and combine-front-end.sh iirc the shell script is to be deprecated in favour of python. Do any of these or other scripts use the closure compiler to even further compress or optimize the JavaScript? Thanks in advance, Konrad Sent from my BlackBerry on the Rogers Wireless Network - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector files
We don't consider front-end deployment a part of WebCore's responsibilities. But I do see where you are coming from. We could extract relevant gyp sub-project or maintain a separate python script that would deploy front-end. Or you could contribute one yourself! Regards Pavel On Jun 8, 2012 1:13 PM, Konrad Piascik kpias...@rim.com wrote: We're already using a homegrown script that does what you mention in PlatformBlackBerry.cmake lines 194-214 but wanted to switch to something that was maintained by the community. I'll look at the gyp/gypi files for more info. Thanks, Konrad Sent from my BlackBerry on the Rogers Wireless Network *From*: Pavel Feldman [mailto:pfeld...@chromium.org] *Sent*: Friday, June 08, 2012 07:59 AM *To*: Konrad Piascik *Cc*: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org *Subject*: Re: [webkit-dev] Web Inspector files [From chromium.org] We throw away closure compiler output and use compilation step for type checking only. The best way to learn what files you should combine and bundle is via looking at WebCore.gyp(i) and WebKit.gyp(i). You basically need what is listed in inspector.html (these you can concatenate) + a bunch of standalone CSS files that are lazily loaded + a couple of web worker scripts. Regards Pavel On Jun 8, 2012 12:54 PM, Konrad Piascik kpias...@rim.com wrote: Hi, I'm trying to combine all the web inspector resources CSS, JS HTML into as few files as possible. I know that there are scripts in Source/WebCore/inspector but I'm not sure which ones should be used and some don't contain usage information. Also there's both combine-front-end.py and combine-front-end.sh iirc the shell script is to be deprecated in favour of python. Do any of these or other scripts use the closure compiler to even further compress or optimize the JavaScript? Thanks in advance, Konrad Sent from my BlackBerry on the Rogers Wireless Network - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Deprecation of CSSStyleDeclaration - getPropertyShorthand method.
On Tue, May 22, 2012 at 12:17 AM, David Hyatt hy...@apple.com wrote:
Yup, no reason for it to be exposed any more. It was just needed way back
when the Inspector used JS.
dave
(hy...@apple.com)
On May 21, 2012, at 2:39 PM, Alexis Menard wrote:
On Mon, May 21, 2012 at 4:29 PM, Maciej Stachowiak m...@apple.com
wrote:
On May 21, 2012, at 11:09 AM, Alexis Menard
alexis.men...@openbossa.org wrote:
Hi,
Let's try the new deprecation process documented as
http://trac.webkit.org/wiki/DeprecatingFeatures.
I would like to propose the deprecation and removal of
getPropertyShorthand of CSSStyleDeclaration.
State of art :
- This method is exposed to the Web.
- Its purpose is to get whether a given CSS property was set from
within a shorthand (i.e.
shouldBeEqualToString(test0.style.getPropertyShorthand('overflow-x'),
overflow); is true if the CSS code is setting the overflow and not
overflow-x).
- It is used in 4 layout tests (fast/inspector-support/style.html,
fast/css/font-shorthand.html, fast/css/overflow-property.html,
fast/backgrounds/repeat/resources/background-repeat-shorthand.js)
- It is exposed in the Objective C API.
- It is not implemented by any other vendors (Opera, Firefox, Internet
Explorer).
- There is no specification about it.
- It was added in 2005 http://trac.webkit.org/changeset/11481.
[...]
This function was added by Dave Hyatt and reviewed by Maciej
Stachowiak, maybe you guys can tell us why you added it back then (if
your memory is very good as we are talking about 2005 material)?
I don't know of any reason for this to exist other than for benefit of
the inspector. It appears to no longer be used by the Web Inspector,
thought it has its own function with the same name (assuming I am reading
the code right). It would be fine to stop exposing it to the web if it is
in fact unused or hardly used.
I was looking at the code of the inspector and also assuming I'm
reading the code right it is not used.
The C++ method getPropertyShorthand seems to be used in
InspectorStyleSheet.cpp which then is used in
inspector/front-end/CSSStyleModel.js and its usage seems to be
confined in styleTextWithShorthands which is not used anywhere (at at
least grep says so).
styleTextWithShorthands looks like dead code, I'll remove it shortly. But
there also is a valid usage at
http://trac.webkit.org/browser/trunk/Source/WebCore/inspector/InspectorStyleSheet.cpp#L543.
Now that we are based on the CSS source code model, it can probably go
away, but it is not a trivial task.
Regards
Pavel
But Pavel and Vsevolod can confirm that.
- Maciej
--
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Blog post Announcing Remote Debugging Protocol v1.0
Hi guys,
I'd like to announce the remote debugging protocol v1 where we define
backward compatibility and commit to supporting it in a blog post. The
draft can be found here: http://www.webkit.org/blog/?p=1875preview=true.
Pasting its content for the sake of accessibility below.
Regards
Pavel
Announcing Remote Debugging Protocol
v1.0http://www.webkit.org/blog/?p=1875Posted
by *Pavel Feldman* on Monday, April 2nd, 2012 at 2:13 am
It has been almost a year since we
announcedhttp://www.webkit.org/blog/1620/webkit-remote-debugging/
the
support for WebKit remote debugging. It is now officially supported by
BlackBerry
PlayBookhttp://devblog.blackberry.com/2011/06/debugging-blackberry-web-apps/
and
in Chrome for
Androidhttps://developers.google.com/chrome/mobile/docs/debugging.
Latest
version of Chrome introduces new extensions
APIhttp://code.google.com/chrome/devtools/docs/remote-debugging.html
that
exposes it to the in-browser clients as well.
We are happy to announce that remote debugging protocol version is now
v1.0, and we can commit to supporting it and maintain its backward
compatibility. Since we receive a lot of questions on the remote debugging
from the port owners, protocol clients and WebKit contributors, I’d like to
provide a brief remote debugging 101 here. It will provide answers to the
questions such as:
- What is the structure of the remote debugging message?
- Is there a documentation of the protocol?
- Is remote debugging protocol versioned? How is backward compatibility
defined?
- What do I need to do in order to support remote debugging with
standard Web Inspector front-end in my WebKit port?
Protocol definitionProtocol schema
WebKit is using JSON-RPC 2.0 http://jsonrpc.org/specification protocol
for the remote debugging. Clients send commands to the backend and receive
responses in return. Backend can generate notifications upon particular
events on its own. Commands, responses and notifications are all
JSON-serialized objects.
The remote debugging protocol schema is defined by the
Inspector.jsonhttp://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json.
Protocol
documentationhttp://code.google.com/chrome/devtools/docs/protocol/tot/index.html
along
with parts of the inspector source code is generated from that file. We
group commands and events of a particular nature into domains such as
DOMhttp://code.google.com/chrome/devtools/docs/protocol/1.0/dom.html
,
Debuggerhttp://code.google.com/chrome/devtools/docs/protocol/1.0/debugger.html
, Networkhttp://code.google.com/chrome/devtools/docs/protocol/1.0/network.html
for
the convenience.
Commands and notifications
Here is a sample command that is setting a breakpoint:
{
id: 10, // -- command sequence number generated by the caller
method: Debugger.setBreakpointByUrl, // -- protocol method
params: { // -- named parameters map
lineNumber: 23,
url: http://www.webkit.org/index.html;
}
}
Backend responds to all the commands either with the result of with the
error message. For the above command, the backend will generate the
following response:
{
id: 10, // -- same id as in the command
result: { // -- command result
breakpointId: http://www.webkit.org/index.html:23;,
locations: [
{
lineNumber: 23,
columnNumber: 10
}
]
}
}
Notifications don’t have identifiers. For example, when JavaScript source
is evaluated in the virtual machine, following notification is sent to the
client:
{
method: Debugger.scriptParsed, // -- notification method
params: { // --notification parameters
scriptId: 15,
url: http://www.webkit.org/index.html;,
startLine: 22,
startColumn: 12,
endLine: 33,
endColumn: 4
}
}
Complete list of the protocol methods for the v1.0 of the protocol can be
found herehttp://code.google.com/chrome/devtools/docs/protocol/1.0/index.html
.
Hidden entities
If you look at the
Inspector.jsonhttp://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json
file
that defines the protocol schema, you will notice that some of the protocol
entities (domains, commands and parameters) are marked as “hidden”. We
don’t generate documentation for such entities. Although one can
technically use them, we are not yet ready to commit to maintaining their
backward compatibility. As the protocol matures, we will be polishing these
entities and making them public.
Protocol versioning and backward compatibility
With the revision r106352 http://trac.webkit.org/changeset/106352, we
updated the protocol version to
v1.0http://code.google.com/chrome/devtools/docs/protocol/1.0/index.html.
All subsequent v1.* versions of the protocol are going to be backward
compatible with v1.0. Protocol backward compatibility is defined as follows:
- No commands or notifications are removed from the protocol.
- No required parameters
Re: [webkit-dev] Debugging inspector injected scripts
devtools_frontend.zip is a quick and dirty way of hacking the front-end without the need to fetch and build WebKit or Chrome. If you'd like to apply changes to the backend (.cpp files), you need to follow WebKit (or Chromium) build instructions. Regards Pavel On Fri, Mar 30, 2012 at 2:35 AM, Vivek Galatage vivekgalat...@gmail.comwrote: Hi Pavel, I have one question regarding the webkit trunk and these inspector related changes. So as per the link, I downloaded the chromium continuous build archive and then followed the instructions to setup the frontend code for debugging. Can I achieve the same thing with webkit trunk build instead of downloading the chromium archive? As I would like to make changes in the inspector backend (.cpp changes) so how can I proceed with this? So do I need to build the webkit trunk for chromium port to get this working? Thank you, Vivek On Fri, Mar 30, 2012 at 3:50 AM, Vivek Galatage vivekgalat...@gmail.comwrote: Thank you Pavel and Konrad for your help. I followed the below link and was able to achieve the debugging the inspector script. Thank you, Vivek On Thu, Mar 29, 2012 at 7:12 PM, Pavel Feldman pfeld...@chromium.orgwrote: See http://code.google.com/chrome/devtools/docs/contributing.html for more info. Pavel On Thu, Mar 29, 2012 at 4:51 PM, Konrad Piascik kpias...@rim.com wrote: Ok, well I was only able to do this on chrome. I have heard of issues with Qt and debugging the inspector. The possible reason for your inability to debug may be their sub event loop. Can any Qt developers comment? Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 08:32 AM To: Konrad Piascik Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Debugging inspector injected scripts Hi Konrad, Thank you for your reply. Yes as you pointed out, I have tried this but was unable to do any live debugging of the javascript from inspector( such as ResourcesPanel.js etc ). I am able to inspect the inspector but debugging the script is what I am looking forward to.. I am working on webkit trunk revision 112378 on Qt port on ubuntu 11.10 as well as on Windows port. Thank you, Vivek On Thu, Mar 29, 2012 at 5:40 PM, Konrad Piascik kpias...@rim.com wrote: Hi Vivek, You can use the inspector to inspect itself. I've done this on chrome many times using the keyboard shortcut ctrl+shift+c (win linux) or command+shift+c (mac). In order for the keyboard shortcut to work you need to have the inspector undocked and the focus of the inspector be on the panel icons. Hope this helps you achieve what you're looking to do. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 07:23 AM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: [webkit-dev] Debugging inspector injected scripts Hello webkit-dev, I would like to debug the various scripts those are injected by inspector component. Lets say I load a page from xyz.com which has some script named xyz.js.. I am able to put breakpoints in this xyz.js and do the normal debugging. But what I am interested in is debugging the inspector injected scripts such as ResorucePanel.js etc by putting breakpoints. But whenever I try to do this, the inspector becomes non-responsive and I have to come out of the debug session by closing the browser. This I am experimenting on Windows port. So am I doing something wrong or is there any other method to achieve this? Any help? Thank you, Vivek - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete
Re: [webkit-dev] Debugging inspector injected scripts
See http://code.google.com/chrome/devtools/docs/contributing.html for more info. Pavel On Thu, Mar 29, 2012 at 4:51 PM, Konrad Piascik kpias...@rim.com wrote: Ok, well I was only able to do this on chrome. I have heard of issues with Qt and debugging the inspector. The possible reason for your inability to debug may be their sub event loop. Can any Qt developers comment? Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 08:32 AM To: Konrad Piascik Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Debugging inspector injected scripts Hi Konrad, Thank you for your reply. Yes as you pointed out, I have tried this but was unable to do any live debugging of the javascript from inspector( such as ResourcesPanel.js etc ). I am able to inspect the inspector but debugging the script is what I am looking forward to.. I am working on webkit trunk revision 112378 on Qt port on ubuntu 11.10 as well as on Windows port. Thank you, Vivek On Thu, Mar 29, 2012 at 5:40 PM, Konrad Piascik kpias...@rim.com wrote: Hi Vivek, You can use the inspector to inspect itself. I've done this on chrome many times using the keyboard shortcut ctrl+shift+c (win linux) or command+shift+c (mac). In order for the keyboard shortcut to work you need to have the inspector undocked and the focus of the inspector be on the panel icons. Hope this helps you achieve what you're looking to do. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 07:23 AM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: [webkit-dev] Debugging inspector injected scripts Hello webkit-dev, I would like to debug the various scripts those are injected by inspector component. Lets say I load a page from xyz.com which has some script named xyz.js.. I am able to put breakpoints in this xyz.js and do the normal debugging. But what I am interested in is debugging the inspector injected scripts such as ResorucePanel.js etc by putting breakpoints. But whenever I try to do this, the inspector becomes non-responsive and I have to come out of the debug session by closing the browser. This I am experimenting on Windows port. So am I doing something wrong or is there any other method to achieve this? Any help? Thank you, Vivek - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector tests for DOM node highlights
There are no tests covering the DOM Node highlight. It just paints quadrants for a given node. What are you trying to test, the highlight or the node position? Is there a bug you are fixing? Regards Pavel On Wed, Feb 22, 2012 at 11:10 PM, Max Vujovic mvujo...@adobe.com wrote: Hello, I was wondering if there are any Web Inspector tests that check the appearance, size, or position of a DOM node highlight. By DOM node highlight, I mean the translucent margin box, border box, padding box, and content box combination that WebKit draws over a DOM node when you inspect it. I need to write a test for a bug to check the size and position of the DOM node highlight for an SVG root element, and I've been searching for a similar test to imitate. I'd like to query the size and position of the DOM node highlight from JavaScript, but I'm not sure that information is exposed. I could probably do a pixel test if this isn't currently possible, but I was wondering if there's a better way. (The bug I'm working on is: https://bugs.webkit.org/show_bug.cgi?id=78037). Thanks, Max Vujovic ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
On Thu, Feb 23, 2012 at 10:24 PM, Adam Barth aba...@webkit.org wrote: On Thu, Feb 23, 2012 at 10:07 AM, Simon Fraser simon.fra...@apple.com wrote: On Feb 22, 2012, at 10:08 PM, Kentaro Hara wrote: TL;DR: We are starting WebKit modularization. Self-contained features like WebAudio, WebSocket, IndexedDB, File APIs ...etc will be moved from WebCore/ to WebCore/Modules/. What are the interfaces that a module uses to call into WebCore code, and vice versa? Currently, the plan is that there won't be any direct dependencies from WebCore into code in Modules, but code in Modules will be able to depend on anything in WebCore it likes. We've added a couple abstract Observer interfaces that Modules use to learn about what's happening in WebCore. So far, these have been very basic lifetime-related observations (e.g., a Page and/or a Frame being destroyed/disconnected): It means that we'll need to put inspector agents (FileSystem, IndexedDB, AppCache, etc.) into corresponding modules. As of today, they are instantiated by the InspectorController. We will also need to split InspectorInstrumentation into parts. This is all doable, but is an effort. Were you planning to do it on your own? Please keep inspector folks in the loop. http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameDestructionObserver.h The goal is to avoid adding much to these interfaces so that folks can work on WebCore proper without worrying too much about these ancillary features. This diagram describes the dependency relationships: https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?authkey=CP6plYAI Will these be developed in an ad hoc manner, or is the intent to create some kind of generic extensibility API that modules use to hook into WebCore? Ad-hoc. At least in the near-to-intermediate term, all this code is going to continue to live in Source/WebCore, so we're not creating any new API commitments. In the long term, we might benefit from moving some of it out of WebCore entirely, but that's not something we're planning to tackle any time soon. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] sheriffbot needs a kick
Does not seem to work for me: I did restart, I did rollout afterwards. Resulted in: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Pavel On Fri, Dec 16, 2011 at 5:20 AM, Adam Barth aba...@webkit.org wrote: Yes, before the changes I made just now, the restart command wasn't powerful enough to clear out the problem. Hopefully the new beefier restart will work better in the future. (Mostly I mentioned the restart command so that more folks would know about it and give it a try when they run into trouble.) Adam On Thu, Dec 15, 2011 at 5:16 PM, Kenneth Russell k...@google.com wrote: Great, thanks. I vaguely recall seeing somebody restart it on IRC but it seemed to not fix this particular problem. BTW, thanks for writing and maintaining it; it's a very useful tool as evidenced by how many people were trying and failing to use it recently. :) -Ken On Thu, Dec 15, 2011 at 4:46 PM, Adam Barth aba...@webkit.org wrote: I believe this is cleared up now. In the future, you can send sheriffbot the restart command, which can often clear up these sorts of issues: sheriffbot: restart I've just now made that command beefier so that it should be able to fix more problems. Adam On Thu, Dec 15, 2011 at 4:26 PM, Adam Barth aba...@webkit.org wrote: I'll take a look. Sorry for the disruption. Adam On Thu, Dec 15, 2011 at 4:24 PM, Kenneth Russell k...@google.com wrote: The sheriffbot has been failing to handle rollout commands for a few days now. The failures reported are: sheriffbot: Exception executing command: Failed to run ['Tools/Scripts/update-webkit'] exit_code: 9 Looks to me like the workspace on the machine running sheriffbot needs to be blown away. Adam, could you please look into this? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Internal JSON Parsing
On Thu, Dec 8, 2011 at 8:51 AM, Adam Barth aba...@webkit.org wrote: Check out InspectorValue. It should be renamed to JSONValue, but it should meet your needs. InspectorValue is not intended to be used as a full fledged JSON parser. It only covers subset of the standard that is sufficient for the inspector operation. The spec requires that you Return the result of invoking the parse function of the JSON object defined in ECMAScript and I wonder why you are willing to do otherwise. Pavel Adam On Dec 8, 2011 8:39 AM, Jarred Nicholls jar...@webkit.org wrote: Hey webkittens, I'm working on https://bugs.webkit.org/show_bug.cgi?id=73648 to support the json response entity from XHR.response. Unless I'm mistaken (the purpose of this inquiry) we don't appear to have a VM-agnostic interface for internal JSON parsing, i.e., straight to the parsers. If so, what does everyone think about adding in that basic interface? What I'd like to avoid is preprocessor branches directly in XHR talking to JSC and V8 directly; instead, what would be ideal I think is an interface to parse and return a ScriptObject. Any additional input is surely welcomed. Thanks, Jarred ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DocumentLoader::m_mainResourceData seems no need
On Tue, Aug 16, 2011 at 11:20 AM, Xianzhu Wang phnix...@gmail.com wrote: Hi, I found that DocumentLoader will hold m_mainResourceData during its whole life. I'm wondering if this is necessary. I searched all callers of DocumentLoader::mainResourceData() and DocumentLoader::mainResource() and they seem all called before or just after the document is loaded. This is not the case for the inspector and a number of other usages I can see here: http://codesearch.google.com/codesearch#search/exact_package=chromiumq=mainResourceData%5C(%5C)type=cs just after might be problematic to define as well. Regards Pavel If we remove DocumentLoader::m_mainResourceData, the main resource data could be freed if there is no other references (seems true if the page is not inspected) and will save memory. I tried to removing DocumentLoader::m_mainResourceData and run all layout tests in chromium-linux. I got 6 text mismatches and 1 timeout and will investigate the failures. However, can anyone describe the original intent of DocumentLoader::m_mainResourceData? What's the case that it is used after the document is loaded? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DocumentLoader::m_mainResourceData seems no need
On Tue, Aug 16, 2011 at 12:44 PM, Xianzhu Wang phnix...@gmail.com wrote: On Tue, Aug 16, 2011 at 3:41 PM, Pavel Feldman pfeld...@chromium.orgwrote: On Tue, Aug 16, 2011 at 11:20 AM, Xianzhu Wang phnix...@gmail.comwrote: Hi, I found that DocumentLoader will hold m_mainResourceData during its whole life. I'm wondering if this is necessary. I searched all callers of DocumentLoader::mainResourceData() and DocumentLoader::mainResource() and they seem all called before or just after the document is loaded. This is not the case for the inspector and a number of other usages I can see here: http://codesearch.google.com/codesearch#search/exact_package=chromiumq=mainResourceData%5C(%5C)type=cs Thanks. I missed some cases (like WebKit2 and WebDataSource ones) as I only searched the compiled files in my environment. And I did overlooked the first case in inspector. just after might be problematic to define as well. I meant just after that the function is called from somewhere xxxDidFinishLoading() etc. For these cases, by carefully adjust the sequence, we can let them depend on DocumentLoader::m_mainResourceLoader instead of m_mainResourceData. An (maybe incomplete) list of cases that might use DocumentLoader::mainResourceData() after loading is: WebDataSource::data() WebKit::WebFrame::source() WebKit::WebPage::getMainResourceDataOfFrame() InspectorPageAgent::resourceContent() As the amount of memory saved by removing m_mainResourceData could be significant on mobile devices, for these cases I think it might be reasonable to have some constraints on particular platforms. For example, use an alternative way like fetching from cache, reloading, etc., or simply don't support them. See https://bugs.webkit.org/show_bug.cgi?id=49246 as a relevant request. Regards Pavel If we remove DocumentLoader::m_mainResourceData, the main resource data could be freed if there is no other references (seems true if the page is not inspected) and will save memory. I tried to removing DocumentLoader::m_mainResourceData and run all layout tests in chromium-linux. I got 6 text mismatches and 1 timeout and will investigate the failures. However, can anyone describe the original intent of DocumentLoader::m_mainResourceData? What's the case that it is used after the document is loaded? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remote Debugging v8 - Android
Note that this solution is using V8-based protocol that we are deprecating in Chrome. Chrome DevTools for Java (Eclipse plugin being discussed) will support both: V8 protocol (for Node and other V8-based solutions) and WebKit Remote Debugging Protocol (for WebKit-based browsers) going forard. I would recommend using the latter for the complete remote debugging of the embedded browser. Regards Pavel On Tue, Aug 2, 2011 at 5:22 AM, Young Han Lee joybro...@gmail.com wrote: Hi, Jose. Our team had implemented the remote debugging feature on our custom Android port. This[1] is a brief article about that. I hope it will be helpful. (It is under development, so you cannot get the code yet) Regards, Young Han. [1] http://dev.dorothybrowser.com/2011/07/27/131175732.html On Thu, Jul 7, 2011 at 3:46 PM, JOSE MANUEL CANTERA FONSECA j...@tid.eswrote: Hi there, ** ** I have two technical questions concerning the Webkit Remote Debugging Protocol. ** ** a/ What is the difference / relationship between this protocol and the v8 remote debugging capabilities? ** ** b/ How this protocol could be enabled for an Android device? ** ** all the best ** ** thanks ** ** -- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remote Debugging v8 - Android
On Thu, Jul 7, 2011 at 10:46 AM, JOSE MANUEL CANTERA FONSECA j...@tid.eswrote: Hi there, ** ** I have two technical questions concerning the Webkit Remote Debugging Protocol. ** ** a/ What is the difference / relationship between this protocol and the v8 remote debugging capabilities? ** Webkit Remote Debugging Protocol is the one Web Inspector uses. It allows debugging all flavors of the running page, not only JavaScript. V8 protocol only exposes JavaScript debugging and is browser-agnostic. You should stick with the WebKit's one in case you are interested in WebKit-based browsers debugging. Use V8's one when you intend to debug applications such as node.js. ** b/ How this protocol could be enabled for an Android device? ** You need to check with Android port owners on whether they intend to enable INSPECTOR in their builds and expose remote debugging capabilities. ** all the best ** ** thanks ** ** -- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
An update. Pavel WebKit Remote Debugging http://www.webkit.org/blog/?p=1620Posted by *Pavel Feldman* on Saturday, April 30th, 2011 at 1:53 am As you might know, WebKit Web Inspector (aka Chrome Developer Tools) is implemented as an HTML + CSS + JavaScript web application. What you might not know is that Web Inspector can run outside of the rendering engine environment and still provide complete set of its features to the end user. Debugging over the wire Running debugger outside the rendering engine is interesting because mobile platforms do not often provide enough screen real estate for quality debugging; they have network stack and CPU specifics that often affect page load and runtime. Still, they are based on the WebCore rendering engine, they could have Web Inspector instrumentation running and hence expose valuable debugging information to the end user. Now that Web Inspector is functioning out-of-process over the serialized-message-channel, attaching Web Inspector window to the remote rendering engine is possible. Here is an example of the remote debugging session using Chrome Developer Tools: 1. Start your target browser (recent Chromium build or Google Chrome will do) with the remote-debugging-port command line switch: Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222 2. Open several pages there. 3. Navigate to the given port from your client browser instance (WebKit nightly or another Chrome instance will do) and it will list inspectable pages opened in the browser as web links. [image: Tab discovery page] 4. Follow any of these links to start remote debugging session for the corresponding page. [image: Tab attached page] You will find remote debugging interface very similar to the Web Inspector / Chrome Developer Tools and here is why: - Target Chrome browser acts as a web server bound to the port 9222 on the localhost. - Once you follow the link, your client browser fetches HTML, JavaScript and CSS files of the Developer Tools front-end over HTTP. - Upon load event, Developer Tools establishes Web Socket connection back to the target browser and starts interchanging JSON messages with it. In fact, pretty much the same scenario takes place within any WebKit-based browser when user opens Web Inspector. The only difference is that the transports being used for the JSON message interchange may vary. Note, that in case of mobile devices, front-end files can also be served from the cloud. Remote Debugging Protocol Another scenario for remote debugging is IDE integration. Web IDEs would like to provide seamless debugging experience integrated into their environments to the end user. Exposing unified WebKit remote debugging protocol would allow them to use alternate front-ends for the WebKit debugging. Under the hood, Web Inspector front-end is talking to the browser backend by means of the Remote Debugging Protocol. This protocol is based on the JSON-RPC 2.0 http://groups.google.com/group/json-rpc/web/json-rpc-2-0 specification. It is bidirectional: clients send asynchronous requests to the server, server responds to these requests and/or generates notifications. Since API surface for general purpose web debugging is huge, we divided it into a number of domains. Each domain contains requests and notifications specific to some area. Here is the list of the domains supported so far: - *Browser Debugger* – allows setting breakpoints on particular DOM operations and events. JavaScript execution will stop on these operations as if there was a regular breakpoint set. - *Console* – defines methods and events for interaction with the JavaScript console. - *CSS* – exposes raw CSS read / write operations. - *Debugger* – exposes JavaScript debugging functions; allows setting and removing breakpoints, stepping through execution, exploring stack traces, etc. - *DOM* – This domain exposes DOM read/write operations. - *Network* – allows tracking network activities of the page; exposes information about HTTP and WebSocket requests and responses, their headers, bodies, raw timing, etc. - *Page* – actions and events related to the inspected page. - *Runtime* – exposes JavaScript runtime by means of remote evaluation and mirror objects. - *Timeline* – provides its clients with instrumentation records that are generated during the page runtime. You can find JSON schema defining the protocol herehttp://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json. For your convenience, we generated documentation from this schema and published it on the Chrome DevTools pagehttp://code.google.com/chrome/devtools/docs/remote-debugging.html. Note that there are few unlisted domains such as Application Cache, DOM Storage, and Database, but they are not ready for the prime time yet. What’s next We are now open to the feedback on the WebKit Remote Debugging Protocol. We will collect all the feedback in the form
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
This is really about the Web Inspector + about the new protocol that is a part of Web Inspector. The whole point of the post is that the same protocol is used for any WebKit-based product. Chrome is there as a proof of concept demo only. We need some shiny demo material for post so that people could see it and try it themselves. Otherwise, it becomes a boring chunk of text. I could use screenshots with Playbook's capabilities ( http://www.berryreview.com/2011/04/15/hot-webkit-web-inspector-on-the-blackberry-playbook-for-web-developers/) or both Chrome and Playbook. Any RIM people around? Thanks Pavel On Sat, Apr 30, 2011 at 2:23 PM, Mark Rowe mr...@apple.com wrote: This seems rather Chrome-centric for a webkit.org blog post. - Mark On 2011-04-30, at 01:55, Pavel Feldman wrote: An update. Pavel WebKit Remote Debugging http://www.webkit.org/blog/?p=1620 Posted by *Pavel Feldman* on Saturday, April 30th, 2011 at 1:53 am As you might know, WebKit Web Inspector (aka Chrome Developer Tools) is implemented as an HTML + CSS + JavaScript web application. What you might not know is that Web Inspector can run outside of the rendering engine environment and still provide complete set of its features to the end user. Debugging over the wire Running debugger outside the rendering engine is interesting because mobile platforms do not often provide enough screen real estate for quality debugging; they have network stack and CPU specifics that often affect page load and runtime. Still, they are based on the WebCore rendering engine, they could have Web Inspector instrumentation running and hence expose valuable debugging information to the end user. Now that Web Inspector is functioning out-of-process over the serialized-message-channel, attaching Web Inspector window to the remote rendering engine is possible. Here is an example of the remote debugging session using Chrome Developer Tools: 1. Start your target browser (recent Chromium build or Google Chrome will do) with the remote-debugging-port command line switch: Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222 2. Open several pages there. 3. Navigate to the given port from your client browser instance (WebKit nightly or another Chrome instance will do) and it will list inspectable pages opened in the browser as web links. [image: Tab discovery page] 4. Follow any of these links to start remote debugging session for the corresponding page. [image: Tab attached page] You will find remote debugging interface very similar to the Web Inspector / Chrome Developer Tools and here is why: - Target Chrome browser acts as a web server bound to the port 9222 on the localhost. - Once you follow the link, your client browser fetches HTML, JavaScript and CSS files of the Developer Tools front-end over HTTP. - Upon load event, Developer Tools establishes Web Socket connection back to the target browser and starts interchanging JSON messages with it. In fact, pretty much the same scenario takes place within any WebKit-based browser when user opens Web Inspector. The only difference is that the transports being used for the JSON message interchange may vary. Note, that in case of mobile devices, front-end files can also be served from the cloud. Remote Debugging Protocol Another scenario for remote debugging is IDE integration. Web IDEs would like to provide seamless debugging experience integrated into their environments to the end user. Exposing unified WebKit remote debugging protocol would allow them to use alternate front-ends for the WebKit debugging. Under the hood, Web Inspector front-end is talking to the browser backend by means of the Remote Debugging Protocol. This protocol is based on the JSON-RPC 2.0 http://groups.google.com/group/json-rpc/web/json-rpc-2-0 specification. It is bidirectional: clients send asynchronous requests to the server, server responds to these requests and/or generates notifications. Since API surface for general purpose web debugging is huge, we divided it into a number of domains. Each domain contains requests and notifications specific to some area. Here is the list of the domains supported so far: - *Browser Debugger* – allows setting breakpoints on particular DOM operations and events. JavaScript execution will stop on these operations as if there was a regular breakpoint set. - *Console* – defines methods and events for interaction with the JavaScript console. - *CSS* – exposes raw CSS read / write operations. - *Debugger* – exposes JavaScript debugging functions; allows setting and removing breakpoints, stepping through execution, exploring stack traces, etc. - *DOM* – This domain exposes DOM read/write operations. - *Network* – allows tracking network activities of the page; exposes information about HTTP and WebSocket requests and responses, their headers, bodies, raw
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
I see. It might be unfortunate branding, but the large amount of Web Inspector users refer to it as Developer Tools. We use every opportunity to tell users that it is the same thing, but this is not enough. The first question we always get is Do you guys upstream any of your Chrome Dev Tools code into the WebKit?. Which sounds crazy, because 100% of the code is upstream. So it is probably just me trying to use both names to fix this. It sounds like I should be more formal in this case and make the letter of the post conform to its WebKit spirit. - I changed the phrasing to use Web Inspector only, there is no mention of Chrome Dev Tools anymore. - Removed all Chrome mentions as well - There is now single mention of Chromium in the example scenario that I am eager to keep. I truly believe that the example makes the post more lively. There is nothing easier than posting this whole thing at chromium.org, but it will harm the unified WebKit Remote Debugging Protocol message we are trying to deliver. provocativeIn return, can I ask to rename the WebKit blog from Surfin' Safari to something more WebKit-specific?/provocative So here is another update (posting the first topics that have changed). Mark, Evan, do you think it is better now? WebKit Remote Debugging http://www.webkit.org/blog/?p=1620Posted by *Pavel Feldman* on Saturday, April 30th, 2011 at 10:06 pm As you might know, WebKit Web Inspector is implemented as an HTML + CSS + JavaScript web application. What you might not know is that Web Inspector can run outside of the rendering engine environment and still provide complete set of its features to the end user. Debugging over the wire Running debugger outside the rendering engine is interesting because mobile platforms do not often provide enough screen real estate for quality debugging; they have network stack and CPU specifics that often affect page load and runtime. Still, they are based on the WebCore rendering engine, they could have Web Inspector instrumentation running and hence expose valuable debugging information to the end user. Now that Web Inspector is functioning out-of-process over the serialized-message-channel, attaching Web Inspector window to the remote rendering engine is possible. Here is an example of the remote debugging session using Chromium: 1. Start your target browser with the remote-debugging-port command line switch: Chromium --remote-debugging-port=9222 2. Open several pages there. 3. Navigate to the given port from your client browser instance (WebKit nightly will do) and it will list inspectable pages opened in the browser as web links. [image: Tab discovery page] 4. Follow any of these links to start remote debugging session for the corresponding page. [image: Tab attached page] You will find remote debugging interface very similar to the Web Inspector and here is why: - Target browser acts as a web server bound to the port 9222 on the localhost. - Once you follow the link, your client browser fetches HTML, JavaScript and CSS files of the Web Inspector front-end over HTTP. - Upon load event, Web Inspector establishes Web Socket connection back to the target browser and starts interchanging JSON messages with it. In fact, pretty much the same scenario takes place within any WebKit-based browser when user opens Web Inspector. The only difference is that the transports being used for the JSON message interchange may vary. Note, that in case of mobile devices, front-end files can also be served from the cloud. On Sun, May 1, 2011 at 1:32 AM, Evan Martin e...@chromium.org wrote: I think Mark's point was more about phrasing like WebKit Web Inspector (aka Chrome Developer Tools) or You will find remote debugging interface very similar to the Web Inspector / Chrome Developer Tools and here is why: Target Chrome browser acts as. I think that objection is reasonable. Perhaps you could rearrange the post to be solely about the WebKit-specific parts, and include a link to a Chrome blog post with details for Chrome users. On Sat, Apr 30, 2011 at 3:23 AM, Mark Rowe mr...@apple.com wrote: This seems rather Chrome-centric for a webkit.org blog post. - Mark On 2011-04-30, at 01:55, Pavel Feldman wrote: An update. Pavel WebKit Remote Debugging http://www.webkit.org/blog/?p=1620 Posted by *Pavel Feldman* on Saturday, April 30th, 2011 at 1:53 am As you might know, WebKit Web Inspector (aka Chrome Developer Tools) is implemented as an HTML + CSS + JavaScript web application. What you might not know is that Web Inspector can run outside of the rendering engine environment and still provide complete set of its features to the end user. Debugging over the wire Running debugger outside the rendering engine is interesting because mobile platforms do not often provide enough screen real estate for quality debugging; they have network stack and CPU specifics that often affect page load and runtime. Still, they are based
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Hi guys, I started drafting the blog post Remote Debugging with Web Inspector: http://www.webkit.org/blog/?p=1620preview=true. I'd like to cover following topics there: - ability to use Web Inspector front-end with remote / embedded devices - ability to implement alternate front-ends for IDEs - share the update on the protocol work progress Calling for the early feedback. Thanks Pavel On Mon, Aug 9, 2010 at 11:48 PM, Pavel Feldman pfeld...@chromium.orgwrote: Hi guys, As some of you know, we are working on a remote debugging feature in Web Inspector. There are many good reasons behind the project including the following: - Debugging WebKit on embedded devices - Shaping up a good protocol for ourselves - Introducing external SDKs on top of the protocol for IDE integrations and alternate front-ends We've had serialized interaction with the out-of-process inspector for quite a while in Chromium. We were upstreaming it into WebKit and have reached an important milestone recently: all the interaction between the inspected page and inspector is entirely serialized on the WebKit level. All the embedder needs to do is to implement a socket that would serve the inspector front-end files and provide our messaging with appropriate transport. Now this socket is likely to be platform-specific, implemented on the WebKit and/or host browser levels. It also makes more sense to implement socket on mobile platforms first. However, we've done a proof-of-concept implementation in Chromium and it is now in a demoable state! See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. The communication is established by means of a WebSocket. The interesting thing about the implementation is that inspector front-end is fetched from the host browser, so that there is no mess with protocol versioning and no need in exposing the interaction protocol any time soon. So I made the demo and it looked cool. I thought maybe we do a blog post on it. The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. Front-end is working as a pure HTML5 application (obviously full of WebKit-specific styles, but still) which is impressive. Now the project is nowhere complete in terms of finalizing the message format and the protocol itself, but there is no intention to expose it right now. We'd like to let it live with fetchable front-end and mature before we expose the protocol and commit to any level of interface support. What do you think, is it ready for a blog post? Thanks Pavel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Surfin' Safari Web Inspector: Understanding Stack Traceshttp://www.webkit.org/blog/1544/web-inspector-understanding-stack-traces/ Remote Debugging with Web Inspector http://www.webkit.org/blog/?p=1620Posted by *Pavel Feldman* on Friday, April 29th, 2011 at 12:59 pm As you might know, WebKit Web Inspector (aka Chrome Developer Tools) is implemented as an HTML + CSS + JavaScript web application. What you might not know is that Web Inspector can run outside of the rendering engine environment and still provide complete set of its features to the end user. Running outside the page context (and browser) is interesting, because mobile platforms do not often provide enough screen real estate for quality debugging; they have network stack and CPU specifics that often affect page load and runtime. Still, they are based on the WebCore rendering engine, they have Web Inspector backend instrumentation running and they can expose valuable debugging information to the user. Another scenario for remote debugging is IDE integration. Web IDEs would like to provide seamless debugging experience, integrated into their environments to the user. Exposing unified WebKit remote debugging protocol will allow them to use alternate front-ends for the WebKit debugging. Here is an example of the remote debugging session using Chrome Developer Tools: Debugging over the wire 1. Start your target browser (recent Chromium build or Google Chrome will do) with the remote-debugging-port command line switch: Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222 2. Navigate to the given port from your client browser instance (WebKit nightly or another Chrome instance will do) and it will list inspectable pages as web links. [image: Tab discovery page] Follow any of these links to start remote debugging session for the corresponding page. [image: Tab attached page] You will find remote debugging interface very similar to the Web Inspector / Chrome Developer Tools and here is why: - Target Chrome browser acts as a web server bound to the port 9222 on the localhost. - Once you follow the link, your client browser fetches HTML, JavaScript and CSS files of the Developer Tools front-end over HTTP. - Upon load event, Developer Tools establishes Web Socket connection back to the target browser and starts interchanging JSON messages with it. In fact, pretty much the same scenario takes place within any WebKit-based browser when user opens Web Inspector. The only difference is that the transports being used for the JSON message interchange may vary. Note, that in case of mobile devices, front-end files can also be served from the cloud. Remote Debugging Protocol Under the hood, Web Inspector front-end is talking to the browser backend by means of the Remote Debugging Protocol. This protocol is based on the JSON-RPC 2.0 http://groups.google.com/group/json-rpc/web/json-rpc-2-0 specification. It is bidirectional: clients send asynchronous requests to the server, server serves responses to these requests and generates notifications. Since API surface for general purpose web debugging is huge, we divided it into a number of domains. Each domain contains requests and notifications specific to some area. Here is the list of the domains supported at the moment: - *Browser Debugger* – allows setting breakpoints on particular DOM operations and events. JavaScript execution will stop on these operations as if there was a regular breakpoint set. - *Console* – defines methods and events for interaction with the JavaScript console. - *CSS* – exposes raw CSS read / write operations. - *Debugger* – exposes JavaScript debugging functions; allows setting and removing breakpoints, stepping through execution, exploring stack traces, etc. - *DOM* – This domain exposes DOM read/write operations. - *Network* – allows tracking network activities of the page; exposes information about HTTP and WebSocket requests and responses, their headers, bodies, raw timing, etc. - *Page* – actions and events related to the inspected page. - *Runtime* – exposes JavaScript runtime by means of remote evaluation and mirror objects. - *Timeline* – provides its clients with instrumentation records that are generated during the page runtime. You can find JSON schema defining the protocol herehttp://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json. For your convenience, we generated documentation from this schema and published it on the Chrome DevTools pagehttp://code.google.com/chrome/devtools/docs/remote-debugging.html. Note that there are few unlisted domains such as Application Cache, DOM Storage, and Database, but they are not ready for the prime time yet. What’s next - We are now open to the feedback on the WebKit Remote Debugging Protocol. We will collect all the feedback in the form of the bug reportshttp://webkit.org/new-inspector-bug and the Chrome DevTools
[webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
Hi WebKit, As you might know, we have a shortcut to the inspector bug entry form: webkit.org/new-inspector-bug. We use it all over the place, our users like simplicity it introduces. However, we ended up with 10 (and counting) people on the CC list. Fixed CC list has obvious drawbacks: - each time we want to add / remove a person from the template, we need to make explicit request - new guys don't get updates when old bugs change - old guys get updates even though they are not interested anymore. Can we migrate to a more flexible approach (such as introducing webkit-inspec...@lists.webkit.org) where we would be able to subscribe / unsubscribe? _wms suggested that we discuss it here first. Thanks Pavel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Hi guys, As some of you know, we are working on a remote debugging feature in Web Inspector. There are many good reasons behind the project including the following: - Debugging WebKit on embedded devices - Shaping up a good protocol for ourselves - Introducing external SDKs on top of the protocol for IDE integrations and alternate front-ends We've had serialized interaction with the out-of-process inspector for quite a while in Chromium. We were upstreaming it into WebKit and have reached an important milestone recently: all the interaction between the inspected page and inspector is entirely serialized on the WebKit level. All the embedder needs to do is to implement a socket that would serve the inspector front-end files and provide our messaging with appropriate transport. Now this socket is likely to be platform-specific, implemented on the WebKit and/or host browser levels. It also makes more sense to implement socket on mobile platforms first. However, we've done a proof-of-concept implementation in Chromium and it is now in a demoable state! See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. The communication is established by means of a WebSocket. The interesting thing about the implementation is that inspector front-end is fetched from the host browser, so that there is no mess with protocol versioning and no need in exposing the interaction protocol any time soon. So I made the demo and it looked cool. I thought maybe we do a blog post on it. The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. Front-end is working as a pure HTML5 application (obviously full of WebKit-specific styles, but still) which is impressive. Now the project is nowhere complete in terms of finalizing the message format and the protocol itself, but there is no intention to expose it right now. We'd like to let it live with fetchable front-end and mature before we expose the protocol and commit to any level of interface support. What do you think, is it ready for a blog post? Thanks Pavel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52439] trunk/WebCore
Sorry about that - it was git's decision. Pavel On Mon, Dec 21, 2009 at 6:24 PM, Dan Bernstein m...@apple.com wrote: On Dec 21, 2009, at 3:00 AM, pfeld...@chromium.org wrote: Revision 52439 http://trac.webkit.org/projects/webkit/changeset/52439 Author pfeld...@chromium.org Date 2009-12-21 03:00:06 -0800 (Mon, 21 Dec 2009) Log Message 2009-12-20 Pavel Feldman pfeld...@chromium.org Reviewed by Eric Seidel. Web Inspector: extract syntax highlighters into separate files. https://bugs.webkit.org/show_bug.cgi?id=32803 * WebCore.gypi: * WebCore.vcproj/WebCore.vcproj: * inspector/front-end/CSSSourceSyntaxHighlighter.js: Added. (WebInspector.CSSSourceSyntaxHighlighter): * inspector/front-end/JavaScriptSourceSyntaxHighlighter.js: Added. (WebInspector.JavaScriptSourceSyntaxHighlighter): (WebInspector.JavaScriptSourceSyntaxHighlighter.): * inspector/front-end/SourceFrame.js: * inspector/front-end/SourceSyntaxHighlighter.js: Added. (WebInspector.SourceSyntaxHighlighter): (WebInspector.SourceSyntaxHighlighter.prototype.createSpan): (WebInspector.SourceSyntaxHighlighter.prototype.process.processChunk): (WebInspector.SourceSyntaxHighlighter.prototype.process.moveToNextLine): (WebInspector.SourceSyntaxHighlighter.prototype.process): (WebInspector.SourceSyntaxHighlighter.prototype.lex): (WebInspector.SourceSyntaxHighlighter.prototype.appendNonToken): (WebInspector.SourceSyntaxHighlighter.prototype.syntaxHighlightNode): * inspector/front-end/WebKit.qrc: * inspector/front-end/inspector.html: Modified Paths - trunk/WebCore/ChangeLog - trunk/WebCore/WebCore.gypi - trunk/WebCore/WebCore.vcproj/WebCore.vcproj - trunk/WebCore/inspector/front-end/SourceFrame.js - trunk/WebCore/inspector/front-end/WebKit.qrc - trunk/WebCore/inspector/front-end/inspector.html Added Paths - trunk/WebCore/inspector/front-end/CSSSourceSyntaxHighlighter.js - trunk/WebCore/inspector/front-end/JavaScriptSourceSyntaxHighlighter.js - trunk/WebCore/inspector/front-end/SourceSyntaxHighlighter.js The preferred way to make this sort of change is to use 'svn copy' in order to preserve the history of the code being moved. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing WebTiming as a part of HTML5
Please see inline. Thanks Pavel On Thu, Oct 29, 2009 at 11:12 PM, Darin Adler da...@apple.com wrote: Has there been any discussion of or feedback about the web timing proposal? Not much of feedback yet. Would WebKit’s implementation of this be the first one? Variation of this is supported in Chromium. Is someone planning on building a benchmark that uses this new feature to evaluate browser speed? I am not aware of such plans. The idea is that web masters can get a clue on user-perceived client side latency, especially related to the initial loads and redirects. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
