[webkit-dev] Feature Announcement: Adding

[Adam Barth]

Per http://www.webkit.org/coding/adding-features.html

I'm working on adding  support to WebKit:
.
 Because I'm enamored with GitHub at the moment, I'm working on the
feature on a branch:
.

Since we already have  and Eric is working on , adding  will let us complete the trifecta of
HTML sandboxing.

Please let me know if you have any questions or concerns.

Thanks,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Darin Fisher]

[Oops, I meant to reply on list.]

I think it is a risky practice for WebKit to have half-baked "webkit"
prefixed
features enabled by default on trunk.  It puts the burden on all WebKit
ports
to know which features are half-baked, whereas individual authors of new
features would know best how stable their features are.

Once a port ships a feature, however baked the feature may be, if it becomes
popular (to some degree), we risk having to support it.  I don't think web
developers necessarily understand that they should regard "webkit" prefixed
features as buyer-beware given that there are so many "webkit" prefixed
features that we all tell developers to use.  How can developers tell the
difference between the stable ones and unstable ones?

It seems safest to ENABLE-guard all half-baked features on trunk, vendor
prefixed or otherwise.  The only reason to vendor prefix is if there is not
a
stable well established spec with multi-vendor support.  In the case of
, which seems quite well specified as part of HTML5,
perhaps there is no need to vendor prefix at all?  Just hide behind a guard
until it is ready?

-Darin


On Fri, Mar 30, 2012 at 6:34 PM, Eric Seidel  wrote:

> We certainly could add an ENABLE.  My impression is that we have many
> half-baked -webkit- features, and that use there-of is buyer-beware
> anyway?
>
> My expectation is that this may be a rather short implementation
> effort.  Ideally I'd be able to finish it next week.  Maybe we should
> revisit this question next Friday?
>
> (It's also probably better to discuss this on webkit-dev, but I didn't
> know if you had intended this email as private.)
>
> -eric
>
> On Fri, Mar 30, 2012 at 4:59 PM, Darin Fisher  wrote:
> >
> >
> > On Fri, Mar 30, 2012 at 4:01 PM, Eric Seidel  wrote:
> >>
> >> Per http://www.webkit.org/coding/adding-features.html
> >>
> >>
> >> I'm working on adding  support to WebKit.
> >> http://www.whatwg.org/specs/web-apps/current-work/#dom-iframe-seamless
> >>
> >> Folks interested can follow along at home:
> >> https://bugs.webkit.org/show_bug.cgi?id=45950
> >>
> >> It's currently accessible only via  /
> >> iframe.webkitseamless, but once the implementation is complete it will
> >> move to its spec name "seamless".  I have no plans to add a feature
> >> define, as it should be on for all ports.
> >
> >
> > Wouldn't it be better to hide the feature from shipping products until
> it is
> > complete?
> >
> > I realize this complicates testing, but it seems problematic to ship an
> > incomplete
> > feature that websites might end up depending on.  Once we ship a vendor
> > prefixed
> > API, if folks start depending on it, we need to keep supporting it.  It
> > seems safer to
> > hide the feature until we can ship it unprefixed in this case since the
> > feature is already
> > well known and specified in a standard.
> >
> > -Darin
> >
> >>
> >>
> >> Let me know if I can answer any questions!
> >>
> >> -eric
> >> ___
> >> 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] Why does PositionIterator iterates until the end of the document when selecting?

[Sergiy Byelozyorov]

Hi,

Thanks for the link. I think it would be sufficient help in my case already
to skip content of nodes without a renderer (I have few thousands of them,
but it's far less than number of characters). I was also using outdated
version of WebKit - revisition 101748. I will try to either integrate your
patch in the version that I have or update to the newest version.

Sergiy Byelozyorov
Computer Graphics Chair
Universitat des Saarlandes
Tel.: +49 (681) 302-3837
Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/



On Fri, Mar 30, 2012 at 19:41, Yong Li  wrote:

> I tried skipping hidden nodes bug didn't finish the task
> (https://bugs.webkit.org/show_bug.cgi?id=65377).
>
> It would be very nice we can skip entire nodes when possible.
>
>
> 2012/3/30 Sergiy Byelozyorov :
> > I see now. However, this creates a problem if the nearest position is
> really
> > far. In my case we are having a huge document with over ~300 million
> > characters all of which are not selectable. Just iterating over all of
> these
> > characters takes over 10 seconds.
> >
> > I think the solution would be to add a possibility to skip the element
> with
> > its children alltogether into increment function by calling
> > new Node::areChildrenSelectable method. This would return true by default
> > and will be overriden in some element types. Do you think it's a feasible
> > solution? I am worried about the cost to the virtual function call,
> however
> > it should only cause problems if there are really many elements as well.
> Is
> > PositionInterator used somewhere else other than in selecting charaters?
> >
> > P.S. All of this text is actually not even displayed - it is used as 3D
> > vertex arrays for geometry.
> >
> >
> > Sergiy Byelozyorov
> > Computer Graphics Chair
> > Universitat des Saarlandes
> > Tel.: +49 (681) 302-3837
> > Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
> >
> >
> >
> > On Thu, Mar 29, 2012 at 22:56, Ojan Vafai  wrote:
> >>
> >> One case where this matters:  >> style="-webkit-user-select:none">foobar
> >>
> >> If you mousedown on foo and drag right, you want to start selecting
> >> bar. In the common case, we don't do any walking. The next position we
> grab
> >> from the iterator is valid and we use it.
> >>
> >> On Thu, Mar 29, 2012 at 7:27 AM, Sergiy Byelozyorov
> >>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> When searching for the character to be selected (on mouse click), we
> run
> >>> an interator over the characters to determine the one under the
> cursor. I am
> >>> trying to understand why does PositionInterator that is used in this
> case
> >>> iterates over all characters starting from the element that was
> clicked and
> >>> until the end of the document(!). The following method is called to
> verify
> >>> whether PositionIterator has finished traversing the characters (see
> >>> comments inline):
> >>>
> >>> bool PositionIterator::atEnd() const
> >>>
> >>> {
> >>>
> >>> if (!m_anchorNode) // This is clear - if we don't have an an
> anchor -
> >>> then we are done.
> >>>
> >>> return true;
> >>>
> >>> if (m_nodeAfterPositionInAnchor) // This is also understandable -
> if
> >>> there is a next position then we are not at the end.
> >>>
> >>> return false;
> >>>
> >>> // This is what puzzles me. First check will be true until we will
> >>> reach the root of the Document.
> >>>
> >>> return !m_anchorNode->parentNode() &&
> (m_anchorNode->hasChildNodes()
> >>> || m_offsetInAnchor >= lastOffsetForEditing(m_anchorNode));
> >>>
> >>> }
> >>>
> >>>
> >>> Is this the intended behaviour? Why wouldn't we just stay within the
> >>> element that was clicked on? This would save us a lot of CPU cycles
> because
> >>> we won't be checking text that in all other elements until the end of
> the
> >>> document, wouldn't it? This check has been around since at least 2004,
> so I
> >>> doub't that it's wrong, but I don't get the logic here. Please explain
> this
> >>> to me. Thanks.
> >>>
> >>> Sergiy Byelozyorov
> >>> Computer Graphics Chair
> >>> Universitat des Saarlandes
> >>> Tel.: +49 (681) 302-3837
> >>> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
> >>>
> >>>
> >>> ___
> >>> 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] Feature Announcement: Adding

[Eric Seidel]

Per http://www.webkit.org/coding/adding-features.html


I'm working on adding  support to WebKit.
http://www.whatwg.org/specs/web-apps/current-work/#dom-iframe-seamless

Folks interested can follow along at home:
https://bugs.webkit.org/show_bug.cgi?id=45950

It's currently accessible only via  /
iframe.webkitseamless, but once the implementation is complete it will
move to its spec name "seamless".  I have no plans to add a feature
define, as it should be on for all ports.

Let me know if I can answer any questions!

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does PositionIterator iterates until the end of the document when selecting?

[Yong Li]

I tried skipping hidden nodes bug didn't finish the task
(https://bugs.webkit.org/show_bug.cgi?id=65377).

It would be very nice we can skip entire nodes when possible.


2012/3/30 Sergiy Byelozyorov :
> I see now. However, this creates a problem if the nearest position is really
> far. In my case we are having a huge document with over ~300 million
> characters all of which are not selectable. Just iterating over all of these
> characters takes over 10 seconds.
>
> I think the solution would be to add a possibility to skip the element with
> its children alltogether into increment function by calling
> new Node::areChildrenSelectable method. This would return true by default
> and will be overriden in some element types. Do you think it's a feasible
> solution? I am worried about the cost to the virtual function call, however
> it should only cause problems if there are really many elements as well. Is
> PositionInterator used somewhere else other than in selecting charaters?
>
> P.S. All of this text is actually not even displayed - it is used as 3D
> vertex arrays for geometry.
>
>
> Sergiy Byelozyorov
> Computer Graphics Chair
> Universitat des Saarlandes
> Tel.: +49 (681) 302-3837
> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
>
>
>
> On Thu, Mar 29, 2012 at 22:56, Ojan Vafai  wrote:
>>
>> One case where this matters: > style="-webkit-user-select:none">foobar
>>
>> If you mousedown on foo and drag right, you want to start selecting
>> bar. In the common case, we don't do any walking. The next position we grab
>> from the iterator is valid and we use it.
>>
>> On Thu, Mar 29, 2012 at 7:27 AM, Sergiy Byelozyorov
>>  wrote:
>>>
>>> Hi,
>>>
>>> When searching for the character to be selected (on mouse click), we run
>>> an interator over the characters to determine the one under the cursor. I am
>>> trying to understand why does PositionInterator that is used in this case
>>> iterates over all characters starting from the element that was clicked and
>>> until the end of the document(!). The following method is called to verify
>>> whether PositionIterator has finished traversing the characters (see
>>> comments inline):
>>>
>>> bool PositionIterator::atEnd() const
>>>
>>> {
>>>
>>>     if (!m_anchorNode) // This is clear - if we don't have an an anchor -
>>> then we are done.
>>>
>>>     return true;
>>>
>>>     if (m_nodeAfterPositionInAnchor) // This is also understandable - if
>>> there is a next position then we are not at the end.
>>>
>>>     return false;
>>>
>>>     // This is what puzzles me. First check will be true until we will
>>> reach the root of the Document.
>>>
>>>     return !m_anchorNode->parentNode() && (m_anchorNode->hasChildNodes()
>>> || m_offsetInAnchor >= lastOffsetForEditing(m_anchorNode));
>>>
>>> }
>>>
>>>
>>> Is this the intended behaviour? Why wouldn't we just stay within the
>>> element that was clicked on? This would save us a lot of CPU cycles because
>>> we won't be checking text that in all other elements until the end of the
>>> document, wouldn't it? This check has been around since at least 2004, so I
>>> doub't that it's wrong, but I don't get the logic here. Please explain this
>>> to me. Thanks.
>>>
>>> Sergiy Byelozyorov
>>> Computer Graphics Chair
>>> Universitat des Saarlandes
>>> Tel.: +49 (681) 302-3837
>>> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
>>>
>>>
>>> ___
>>> 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] Reg: DRT output for border properties

[M Rahaman]

Hi All,

 

Recently I have made an observation regarding the DRT output for border
properties for various html element e.g. consider the following

RenderTableCell {TD} at (2,2) size 30 [border: none (2px solid #FF)
none]

Please note that the border properties are printed 

. In the order of Top, Right, Bottom & Left

. Also, if two consecutive properties are same, they are printed
once => if my right.border==bottom.border, either of right/bottom are
printed e.g. [border: (Top-border-properties), (Right-border-properties),(
Left-border-properties)] & if no border is drawn, it is shown as none (in
WebCore/rendering/RenderTreeAsText.cpp)

 

So if we consider the below table,





DRT o/p

Top 

Right

Bottom

Left


#1

none (2px solid #FF) none

none

none

(2px solid #FF)

none


none

(2px solid #FF)

none

none


none 

(2px solid #FF)

(2px solid #FF)

none



#2

none (2px solid #FF)

none

none

none

(2px solid #FF)


none

none

(2px solid #FF)

(2px solid #FF)


none

(2px solid #FF)

(2px solid #FF)

(2px solid #FF)

 

 

 

 

 




 

 

 

 

 

 



It basically shows that one DRT o/p does not convey enough information about
the various border properties.

1.   My question: Is this observation correct or if I am missing
anything here?

2.   And if the above understanding is correct, then I propose that we
only print those border info that are being drawn (with addition info like
which border) & don't print "none" at all, so that it is easier to interpret
the info.

 

Any suggestion is always welcome J

Regs,

Rahaman

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 



 

 

 

 

 

 




 

 

 

 

 

 




 

 

 

 

 

 




 

 

 

 

 

 




 

 

 

 

 

 




 

 

 

 

 

 





 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 


 

 

 

 

 

 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does PositionIterator iterates until the end of the document when selecting?

[Sergiy Byelozyorov]

I see now. However, this creates a problem if the nearest position is
really far. In my case we are having a huge document with over ~300 million
characters all of which are not selectable. Just iterating over all of
these characters takes over 10 seconds.

I think the solution would be to add a possibility to skip the element with
its children alltogether into increment function by calling
new Node::areChildrenSelectable method. This would return true by default
and will be overriden in some element types. Do you think it's a feasible
solution? I am worried about the cost to the virtual function call, however
it should only cause problems if there are really many elements as well. Is
PositionInterator used somewhere else other than in selecting charaters?

P.S. All of this text is actually not even displayed - it is used as 3D
vertex arrays for geometry.

Sergiy Byelozyorov
Computer Graphics Chair
Universitat des Saarlandes
Tel.: +49 (681) 302-3837
Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/



On Thu, Mar 29, 2012 at 22:56, Ojan Vafai  wrote:

> One case where this matters:  style="-webkit-user-select:none">foobar
>
> If you mousedown on foo and drag right, you want to start selecting
> bar. In the common case, we don't do any walking. The next position we grab
> from the iterator is valid and we use it.
>
> On Thu, Mar 29, 2012 at 7:27 AM, Sergiy Byelozyorov <
> byelozyo...@cs.uni-saarland.de> wrote:
>
>> Hi,
>>
>> When searching for the character to be selected (on mouse click), we run
>> an interator over the characters to determine the one under the cursor. I
>> am trying to understand why does PositionInterator that is used in this
>> case iterates over all characters starting from the element that was
>> clicked and until the end of the document(!). The following method is
>> called to verify whether PositionIterator has finished traversing the
>> characters (see comments inline):
>>
>> bool PositionIterator::atEnd() const
>>
>> {
>>
>> if (!m_anchorNode) // This is clear - if we don't have an an anchor
>> - then we are done.
>>
>> return true;
>>
>> if (m_nodeAfterPositionInAnchor) // This is also understandable - if
>> there is a next position then we are not at the end.
>>
>> return false;
>>
>> // This is what puzzles me. First check will be true until we will
>> reach the root of the Document.
>>
>> return !m_anchorNode->parentNode() && (m_anchorNode->hasChildNodes()
>> || m_offsetInAnchor >= lastOffsetForEditing(m_anchorNode));
>>
>> }
>>
>> Is this the intended behaviour? Why wouldn't we just stay within the
>> element that was clicked on? This would save us a lot of CPU cycles because
>> we won't be checking text that in all other elements until the end of the
>> document, wouldn't it? This check has been around since at least 2004, so I
>> doub't that it's wrong, but I don't get the logic here. Please explain this
>> to me. Thanks.
>>
>> Sergiy Byelozyorov
>> Computer Graphics Chair
>> Universitat des Saarlandes
>> Tel.: +49 (681) 302-3837
>> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
>>
>>
>> ___
>> 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] Debugging inspector injected scripts

[Vivek Galatage]

Yeah sure.. I will follow the respective procedures to get this working.

Thank you for the right pointers.

Vivek

On Fri, Mar 30, 2012 at 5:07 PM, Pavel Feldman wrote:

> 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 
> wrote:
>
>> 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 
>> wrote:
>>
>>> 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 wrote:
>>>
 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 
 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 
 > 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 
 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 
 >> 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. 

Re: [webkit-dev] Debugging inspector injected scripts

[Pavel Feldman]

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

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