Re: [webkit-dev] Web inspector images

[Michael Catanzaro]

On Tue, 2016-02-09 at 11:44 -0800, Timothy Hatcher wrote:
> Hi Michael,
> 
> I am looking into our options for the license of the images. Stay
> tuned.
> 
> — Timothy Hatcher

Hi Timothy,

Any update on this?

We should really remove these images from OpenSource if Apple does not
want to relicense them.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Web inspector images

[Timothy Hatcher]

Hi Michael,

I am looking into our options for the license of the images. Stay tuned.

— Timothy Hatcher

> On Feb 6, 2016, at 8:23 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> I'd like to address the problem with the license for the web inspector
> images. The background on this is that a WebKitGTK+ release was
> rejected by the legal department of one of our distributors after it
> discovered the file Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf,
> which covers the images under
> Source/WebInspectorUI/UserInterface/Images. From a cursory glance at
> the license, it's clear that not only is this license not open source
> compatible (and therefore not compatible with the acceptable content
> policies of major WebKitGTK+ distributors), the images are also not
> distributable. I don't believe this is consistent with the values of
> the WebKit open source project.
> 
> In response to this issue, we created similar but freely-licensed
> replacement images under
> Source/WebInspectorUI/UserInterface/Images/gtk, took down our hosted
> tarballs for several previous WebKitGTK+ releases, reissued those
> tarballs with the images replaced, and posted a notice to alert some of
> our distributors to the issue. This was sufficient for our port, so we
> just... stopped at that. But it would be good if other ports did not
> have to address this problem individually, especially since there is no
> obvious warning when downloading WebKit as to the legal status of this
> content.
> 
> Since the images are not usable except by Apple, it would be nice to
> remove these images from the public repository to reduce the risk of
> other ports accidentally including these image files. Therefore, I
> propose to simply overwrite the images under Images with the images
> under Images/gtk. As part of this, we would need to create a few new
> images that do not currently exist under Images/gtk. Also, Apple's
> internal build process would need to be modified to include the Apple
> images from elsewhere.
> 
> If I am remembering correctly, I spoke to Joe Pecoraro about this at
> the WebKit Contributors Meeting, and he liked this idea. Would anyone
> object to this change?
> 
> A couple alternative solutions:
> 
>  * Apple could relicense its images. I suspect the set of similar but
> freely-licensed gtk images defeats the purpose of using a restrictive
> license for the Apple images. This would be the best solution.
> Possible?
> 
> * We could move the license file up from WebInspectorImages to the
> toplevel project directory. This would make it very difficult to
> accidentally distribute the Apple images without knowing the license.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Web inspector images

[Michael Catanzaro]

Hi,

I'd like to address the problem with the license for the web inspector
images. The background on this is that a WebKitGTK+ release was
rejected by the legal department of one of our distributors after it
discovered the file Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf,
which covers the images under
Source/WebInspectorUI/UserInterface/Images. From a cursory glance at
the license, it's clear that not only is this license not open source
compatible (and therefore not compatible with the acceptable content
policies of major WebKitGTK+ distributors), the images are also not
distributable. I don't believe this is consistent with the values of
the WebKit open source project.

In response to this issue, we created similar but freely-licensed
replacement images under
Source/WebInspectorUI/UserInterface/Images/gtk, took down our hosted
tarballs for several previous WebKitGTK+ releases, reissued those
tarballs with the images replaced, and posted a notice to alert some of
our distributors to the issue. This was sufficient for our port, so we
just... stopped at that. But it would be good if other ports did not
have to address this problem individually, especially since there is no
obvious warning when downloading WebKit as to the legal status of this
content.

Since the images are not usable except by Apple, it would be nice to
remove these images from the public repository to reduce the risk of
other ports accidentally including these image files. Therefore, I
propose to simply overwrite the images under Images with the images
under Images/gtk. As part of this, we would need to create a few new
images that do not currently exist under Images/gtk. Also, Apple's
internal build process would need to be modified to include the Apple
images from elsewhere.

If I am remembering correctly, I spoke to Joe Pecoraro about this at
the WebKit Contributors Meeting, and he liked this idea. Would anyone
object to this change?

A couple alternative solutions:

 * Apple could relicense its images. I suspect the set of similar but
freely-licensed gtk images defeats the purpose of using a restrictive
license for the Apple images. This would be the best solution.
Possible?

* We could move the license file up from WebInspectorImages to the
toplevel project directory. This would make it very difficult to
accidentally distribute the Apple images without knowing the license.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Web Inspector Memory Tools

[Vienneau, Christopher]

Hi,

I was taking a look at the feature set that the web inspector offers, hoping to 
find something showing how memory is being used for a given page (images, JS, 
CSS ect).  I couldn't find what I was looking for.  I notice in chrome they 
have something that allows you to take  a heap snapshot which is a step in that 
direction.  Are there any plans for memory profiling features?

Thanks

Chris Vienneau
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Web Inspector

[Timothy Hatcher]

Sorry for the duplicate message.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Web Inspector

[Timothy Hatcher]

On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a 
new top-level project — WebInspectorUI. This version of Web Inspector is nearly 
two years in the making. We now feel it is time to share our hard work with the 
WebKit project and further accelerate developer tool innovation with help from 
all of you.

The previous Web Inspector UI is still part of WebCore and is used by a number 
of ports currently. However, the previous version of Web Inspector is largely 
unmaintained at this point — since the departure of Chromium back in April. At 
this time, we would like to deprecate the previous Web Inspector and encourage 
ports to move over to using the new WebInspectorUI project.

We realize a transition like this can't happen overnight. For starters, the 
current UI assumes the Mac platform with keyboard shortcuts and other 
conventions. Another area would be making it work with the Inspector protocol 
vended over a WebSocket. To facilitate a smooth transition for ports, we are 
ready to help and review patches to get issues resolved as quickly as possible.

We hope you are as excited about this as we are, and are looking forward to 
working with all of you to make Web Inspector even better!

— Timothy Hatcher

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

[webkit-dev] Web Inspector

[Timothy Hatcher]

On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a 
new top-level project — WebInspectorUI. This version of Web Inspector is nearly 
two years in the making. We now feel it is time to share our hard work with the 
WebKit project and further accelerate developer tool innovation with help from 
all of you.

The previous Web Inspector UI is still part of WebCore and is used by a number 
of ports currently. However, the previous version of Web Inspector is largely 
unmaintained at this point — since the departure of Chromium back in April. At 
this time, we would like to deprecate the previous Web Inspector and encourage 
ports to move over to using the new WebInspectorUI project.

We realize a transition like this can't happen overnight. For starters, the 
current UI assumes the Mac platform with keyboard shortcuts and other 
conventions. Another area would be making it work with the Inspector protocol 
vended over a WebSocket. To facilitate a smooth transition for ports, we are 
ready to help and review patches to get issues resolved as quickly as possible.

We hope you are as excited about this as we are, and are looking forward to 
working with all of you to make Web Inspector even better!

— Timothy Hatcher

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

Re: [webkit-dev] Web Inspector files

[Pavel Feldman]

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"  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 
> *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"  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] Web Inspector files

[Konrad Piascik]

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 
Subject: Re: [webkit-dev] Web Inspector files


[From chromium.org<http://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" 
mailto: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<mailto: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] Web Inspector files

[Pavel Feldman]

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

[webkit-dev] Web Inspector files

[Konrad Piascik]

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

Re: [webkit-dev] Web Inspector tests for DOM node highlights

[Max Vujovic]

(CC-ing webkit-dev)


> I would not do that. We should not add methods for testing into the
>inspector protocol. Also, having the highlight figures right does not
>guarantee proper rendering (scrollbars, etc. might affect things).

Ok. That makes sense. A lot can go wrong between having the correct quad
values and getting them on the screen. I'll keep going with the pixel
tests approach.

Thanks for feedback,
Max

On 2/24/12 12:10 AM, "Pavel Feldman"  wrote:

>
>
>On Fri, Feb 24, 2012 at 2:00 AM, Max Vujovic  wrote:
>
>Hi Pavel,
>
>I'd like your opinion on another approach to enable highlight tests
>without using pixel tests.
>
>We could expose the highlight data to the inspector via a new method in
>InspectorDOMAgent.h called "getHighlight". This would enable us to test
>the position and size of highlight quadrants programmatically, like the
>other inspector tests.
>
>
>
>
>I would not do that. We should not add methods for testing into the
>inspector protocol. Also, having the highlight figures right does not
>guarantee proper rendering (scrollbars, etc. might affect things).
>
>
>I would define "getHighlight" next to InspectorDOMAgent.h's other
>highlight-related methods (hideHighlight, highlightRect, highlightNode,
>and highlightFrame).
>
>A variant to this approach is that instead of defining a new method, the
>highlightNode method could return the highlight data. However, this
>approach is perhaps not as flexible or elegant in case the highlight
>changes (e.g. page zoom changes, the node changes).
>
>I'm bringing all of this up because I usually try to avoid pixel tests
>because of the associated platform maintenance, and the PNGs that make
>WebKit bigger.
>
>
>
>In this case, you are validating the result of the paint, so I think
>pixel tests are appropriate.
>
>
>
>
>What are your thoughts? Do you think we should expose the highlight
>information or create pixel tests?
>
>(Also, do you mind if we re-CC webkit-dev on this? I noticed we start
>emailing each other directly, and I have some colleagues at work who have
>become interested in this discussion.)
>
>
>
>Sure I don't mind.
>
>Regards
>Pavel
> 
>
>
>Thanks,
>Max
>
>On 2/23/12 11:21 AM, "Max Vujovic"  wrote:
>
>>Hi Pavel,
>>
>>Thanks for the guidance. I'll try the approach you described for grabbing
>>pixels. I've been digging into the inspector harness lately
>>(inspector-test.js), and it's making sense so far, but I'll inevitably
>>have some questions for you when I hit a snag :).
>>
>>Thanks,
>>Max
>>
>>On 2/23/12 11:05 AM, "Pavel Feldman"  wrote:
>>
>>>Hi Max,
>>>
>>>Got it. I hate to say it, but implementing a harness for this case is
>>>likely to be more expensive than the fix itself. In your case,
>>>DOMNodeHighlighter::drawHighlight receives proper data (the node), but
>>>converts it into the graphics context poorly.
>>>
>>>As you suggested, I would probably go for a pixel test. Inspector's
>>>harness is fairly complex: our tests live under LayoutTests/inspector
>>>and
>>>LayoutTests/http/tests/inspector. I'd create a page like in your use
>>>case, pass node's handle to the front-end (as in many tests under
>>>inspector/elements), issue a DOMAgent.highlightNode(nodeId) followed by
>>>a
>>>RuntimeAgent.evaluate that would call a method on a page that tells
>>>layoutTestController to grab pixels. We don't have pixel tests for
>>>inspector, so I'd expect this last step to be challenging.
>>>
>>>If you are willing to give it a try, please go ahead. If you hit an
>>>issue, I'll be happy to help you out. Otherwise, I am now feeling bad
>>>for
>>>the lack of the highlight tests, so I'll probably put an effort into
>>>doing it myself.
>>>
>>>Regards
>>>Pavel
>>>
>>>On Thu, Feb 23, 2012 at 10:53 PM, Max Vujovic 
>>>wrote:
>>>
>>>Hi Pavel,
>>>
>>>I'm trying to test the position and size of the highlight quadrants (not
>>>the node).
>>>
>>>This screenshot of the bug I'm working on might make it more clear:
>>>https://bug-78037-attachments.webkit.org/attachment.cgi?id=128501
>>>Here's direct link to the bug:
>>>https://bugs.webkit.org/show_bug.cgi?id=78037
>>>
>>>
>>>In the screenshot, the blue, green, yellow, and orange quadrants should
>>>line up with the SVG element when the bug is fixed, and I'd like to
>>>create
>>>a test for that.
>>>
>>>Thanks,
>>>Max
>>>
>>>On 2/23/12 4:00 AM, "Pavel Feldman"  wrote:
>>>
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 
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 nee

Re: [webkit-dev] Web Inspector tests for DOM node highlights

[Sergio Villar Senin]

En 22/02/12 20:10, Max Vujovic escribiu:
> 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.

Could be also useful to test text highlighting in searches.

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

[Pavel Feldman]

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

[webkit-dev] Web Inspector tests for DOM node highlights

[Max Vujovic]

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

Re: [webkit-dev] Web Inspector blog post draft

[Maciej Stachowiak]

We don't have any approval process.

 - Maciej

On Feb 15, 2011, at 10:16 AM, Darin Adler wrote:

> On Feb 15, 2011, at 8:05 AM, Alexander Pavlov wrote:
> 
>> A few edits have been applied to the text (thanks to everyone who 
>> contributed!)
>> 
>> What is the official approval process for the Webkit blog posts? Should I 
>> mark it as "Pending Review"?
> 
> I don’t think we have any approval process. You could double check that with 
> Maciej.
> 
>-- Darin
> 
> ___
> 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 blog post draft

[Darin Adler]

On Feb 15, 2011, at 8:05 AM, Alexander Pavlov wrote:

> A few edits have been applied to the text (thanks to everyone who 
> contributed!)
> 
> What is the official approval process for the Webkit blog posts? Should I 
> mark it as "Pending Review"?

I don’t think we have any approval process. You could double check that with 
Maciej.

-- Darin

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

Re: [webkit-dev] Web Inspector blog post draft

[Alexander Pavlov]

A few edits have been applied to the text (thanks to everyone who
contributed!)

What is the official approval process for the Webkit blog posts? Should I
mark it as "Pending Review"?

On Wed, Feb 9, 2011 at 3:32 PM, Alexander Pavlov wrote:

> Hello everyone,
>
> I have put together a Web Inspector blog post draft (
> http://webkit.org/blog/?p=1463) concerning the latest style editing
> improvements. Please speak up if you think something should be changed,
> added, or removed.
>
> --
> Thanks,
> -alexander
>



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

Re: [webkit-dev] Web Inspector blog post draft

[Mihai Parparita]

For those who are interested in this, I've included the draft inline below.

Mihai

Web Inspector: Styles Enhanced Posted
by *Alexander
Pavlov* on Wednesday, February 9th, 2011 at 9:43 am

During the past months, we’ve been working hard to improve the CSS editing
experience for the Web Inspector users. Now, we are happy to provide you
with an update.
Style Presentation

Did you find yourself in a situation when you entered a big and complex
gradient definition for yourbackground property, and it disappeared once you
hit Return? The reason was that the Styles sidebar showed the style content
exactly the way the browser understood it, and if it did not understand it,
inspector showed nothing. This has now changed: inspector shows all the
properties declared in a style, and if the browser does not understand a
property name or value, the respective property is denoted by an exclamation
mark ([image: warning]) next to its name. Still, you can edit (or remove)
these properties along with the regular ones.

On a related note, Web Inspector can now show the colors in property values
exactly as they are written in the CSS – just use the “As Authored”
presentation option accessible via the Gear menu.

Editing Styles

Based on the feedback from our users, we have improved the editing of CSS
properties. Two separate fields are now used for a property name and value
instead of one, and you can navigate between them (as well as between
properties) back and forth with the Tab/Shift-Tab or Return keys. Available
keywords for property values are suggested as you type, and can be
auto-completed using the End or → keys, just like in the console view. The
previous/next suggestions can be selected with the ↑ and ↓ keys. If you wish
to accept the current suggestion and move on to another field, use the Tab/
Returnkeys.

Additionally, you can paste a compound “name: value” property text into the
name field, and inspector will break it up into “name” and “value”, putting
each in its own field for you.
Persisting Changes

Every time you modify a style from an external style sheet, the respective
resource text is updated in the Resources panel (this feature is
work-in-progress) and the history is tracked for such style sheet resources
while inspector remains open. Select any resource revision to see its
differences from the original one, highlighted line-wise.

A textual resource node (including stylesheet revisions) can be drag and
dropped onto most text editors to export the specific resource content.
Things You Might Not Know

Please let us take this opportunity to tell a few things you might not know.
While in the Styles pane, you can:

   - …add a new property to an editable style either by double-clicking in
   the blank space of the lines with opening and closing braces, or by hitting
   Tab while editing the last property value.
   - …add a new rule by selecting the “New Style Rule” item in the Gear
   menu.
   - …click a link in a property value (say, background-image) to navigate
   to the respective resource in the Resources panel.
   - …click a color swatch next to a color value to cycle through available
   color representation formats.

We are currently experimenting with more improvements to style handling
within Web Inspector. Stay tuned and check back often!

On Wed, Feb 9, 2011 at 11:27 AM, Patrick Mueller 
wrote:
> I'm logged in (as near as I can tell - link at the bottom says "Log out"),
> and still get the error.  I don't have posting rights to the blog, nor do
I
> want them.
>
> On 2/9/11 2:20 PM, Adele Peterson wrote:
>>
>> You have to be logged into the blog to read drafts.
>
> --
> Patrick Mueller - http://muellerware.org
>
> ___
> 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 blog post draft

[Patrick Mueller]

I'm logged in (as near as I can tell - link at the bottom says "Log 
out"), and still get the error.  I don't have posting rights to the 
blog, nor do I want them.


On 2/9/11 2:20 PM, Adele Peterson wrote:

You have to be logged into the blog to read drafts.


--
Patrick Mueller - http://muellerware.org

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

Re: [webkit-dev] Web Inspector blog post draft

[Adele Peterson]

You have to be logged into the blog to read drafts.

- Adele

On Feb 9, 2011, at 11:15 AM, Peter Kasting wrote:

> On Wed, Feb 9, 2011 at 4:32 AM, Alexander Pavlov  wrote:
> I have put together a Web Inspector blog post draft 
> (http://webkit.org/blog/?p=1463) concerning the latest style editing 
> improvements. Please speak up if you think something should be changed, 
> added, or removed.
> 
> I get an error page at this URL.
> 
> PK 
> ___
> 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 blog post draft

[Peter Kasting]

On Wed, Feb 9, 2011 at 4:32 AM, Alexander Pavlov wrote:

> I have put together a Web Inspector blog post draft (
> http://webkit.org/blog/?p=1463) concerning the latest style editing
> improvements. Please speak up if you think something should be changed,
> added, or removed.
>

I get an error page at this URL.

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

[webkit-dev] Web Inspector blog post draft

[Alexander Pavlov]

Hello everyone,

I have put together a Web Inspector blog post draft (
http://webkit.org/blog/?p=1463) concerning the latest style editing
improvements. Please speak up if you think something should be changed,
added, or removed.

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

[webkit-dev] Web Inspector Extension API description

[Danny Coates]

Hi,

I've been following the development of Web Inspector for a few months,
and I've got a basic understanding of most of the javascript code, but
I'm not understanding the Extension portions. Can anyone point me to a
resource or briefly explain it from a high level?

PS. I'm a huge Web Inspector fan. It's my favorite browser dev tool :)


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

[webkit-dev] Web Inspector Can't Save Images or Open Images in New Window

[Ben Mills]

I have no "abnormal" plugins installed. Just flash and quicktime as  
far as I know.

Sure I can submit a bug report. In Safari 3 I could even click on the  
images and drag them around. Meaning I could drag them to the desired  
folder I wanted to put it in. I can't even do that in Safari 3.1 with  
the latest webkit.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Web Inspector Can't Save Images or Open Images in New Window

[Timothy Hatcher]

If it worked before, this is is a regression. I confirmed they don't  
work in Safari 3.1, but I never tried this in Safari 3. Can you file a  
bug at bugs.webkit.org?


On Mar 18, 2008, at 3:07 PM, Ben Mills wrote:


After upgrading to Safari 3.1 why can I no longer open web inspector
and download images or open them in a new window. The contextual menu
has the options but they do nothing when selected and are not grayed
out. Everything worked perfectly in Safari 3.0.4 on OS X 10.4 -10.5.2
but the new version of webkit bundled with Safari 3.1 won't allow me
to do the fore-mentioned. I also tried the current nightly build and
it also has the same issue.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


— Timothy Hatcher


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

Re: [webkit-dev] Web Inspector Can't Save Images or Open Images in New Window

[David Hyatt]

I would guess that you have a misbehaving extension/add-on installed.

dave

On Mar 18, 2008, at 5:07 PM, Ben Mills wrote:

> After upgrading to Safari 3.1 why can I no longer open web inspector
> and download images or open them in a new window. The contextual menu
> has the options but they do nothing when selected and are not grayed
> out. Everything worked perfectly in Safari 3.0.4 on OS X 10.4 -10.5.2
> but the new version of webkit bundled with Safari 3.1 won't allow me
> to do the fore-mentioned. I also tried the current nightly build and
> it also has the same issue.
> ___
> 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] Web Inspector Can't Save Images or Open Images in New Window

[Ben Mills]

After upgrading to Safari 3.1 why can I no longer open web inspector  
and download images or open them in a new window. The contextual menu  
has the options but they do nothing when selected and are not grayed  
out. Everything worked perfectly in Safari 3.0.4 on OS X 10.4 -10.5.2  
but the new version of webkit bundled with Safari 3.1 won't allow me  
to do the fore-mentioned. I also tried the current nightly build and  
it also has the same issue.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev