Re: [webkit-dev] Disable Javascript security warnings?

2011-09-12 Thread Adam Barth 
There is a setting to disable security.  I'm not sure whether it is exposed
in the API you're using.

Adam
 On Sep 12, 2011 7:13 PM, "Devara, Kavitha"  wrote:
>
> From your javascript, perhaps you can set the "referring URL" in the HTTP
Headers of the request( to get IFrames) to " http://www.google.com";,
> or whichever URL you are requesting the frames for? You will have to
create your own XHR object for the HTTP Request.
>
> Thanks,
> -Kavitha
>
> From: webkit-dev-boun...@lists.webkit.org [mailto:
webkit-dev-boun...@lists.webkit.org] On Behalf Of Rob Crowell
> Sent: Monday, September 12, 2011 6:42 PM
> To: webkit-dev@lists.webkit.org
> Subject: [webkit-dev] Disable Javascript security warnings?
>
> Hey all,
>
> I'm working on a web scraper that embeds WebKit directly (via pyWebKitGTK
if it matters, though I don't think my question is specific to that
library). I'm trying to extract image metadata (domains, dimensions,
location on the page, etc) from a page, including any iframes that are
embedded there.
>
> Because WebKit already knows everything about the data I want (image
dimensions, position on page), I'm extracting content by executing
javascript via the webkit_web_view_execute_script call described here:
http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-execute-script
>
> My javascript works when the iframes are on the same domain, but fails
(obviously) when they're not. How can I disable the "Unsafe JavaScript
attempt to access frame with URL http://www.google.com/ from frame with URL
http://10.0.0.50/js_test.html. Domains, protocols and ports must match."
error message?
>
> I've come across the WebKitSecurityOrigin object and I've been able to
extract the host/port/protocol of my current page, but I haven't found a way
to spoof this mechanism...
>
> I know too that Chrome has the --disable-web-security flag, but I can't
quite put my finger on what I need to do to replicate this functionality
when working with WebKit directly.
>
> Can anyone offer a pointer or suggestion?
>
> Thanks so much!
>
> --Rob
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Disable Javascript security warnings?

2011-09-12 Thread Devara, Kavitha 

>From your javascript, perhaps you can set the "referring URL" in the HTTP 
>Headers of the request( to get IFrames) to " http://www.google.com";,
or whichever URL you are requesting the frames for?  You will have to create 
your  own XHR object for the HTTP Request.

Thanks,
-Kavitha

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Rob Crowell
Sent: Monday, September 12, 2011 6:42 PM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Disable Javascript security warnings?

Hey all,

I'm working on a web scraper that embeds WebKit directly (via pyWebKitGTK if it 
matters, though I don't think my question is specific to that library).  I'm 
trying to extract image metadata (domains, dimensions, location on the page, 
etc) from a page, including any iframes that are embedded there.

Because WebKit already knows everything about the data I want (image 
dimensions, position on page), I'm extracting content by executing javascript 
via the webkit_web_view_execute_script call described here: 
http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-execute-script

My javascript works when the iframes are on the same domain, but fails 
(obviously) when they're not.  How can I disable the "Unsafe JavaScript attempt 
to access frame with URL http://www.google.com/ from frame with URL 
http://10.0.0.50/js_test.html. Domains, protocols and ports must match." error 
message?

I've come across the WebKitSecurityOrigin object and I've been able to extract 
the host/port/protocol of my current page, but I haven't found a way to spoof 
this mechanism...

I know too that Chrome has the --disable-web-security flag, but I can't quite 
put my finger on what I need to do to replicate this functionality when working 
with WebKit directly.

Can anyone offer a pointer or suggestion?

Thanks so much!

--Rob

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

[webkit-dev] Disable Javascript security warnings?

2011-09-12 Thread Rob Crowell 
Hey all,

I'm working on a web scraper that embeds WebKit directly (via pyWebKitGTK if
it matters, though I don't think my question is specific to that library).
 I'm trying to extract image metadata (domains, dimensions, location on the
page, etc) from a page, including any iframes that are embedded there.

Because WebKit already knows everything about the data I want (image
dimensions, position on page), I'm extracting content by executing
javascript via the webkit_web_view_execute_script call described here:
http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-execute-script

My javascript works when the iframes are on the same domain, but fails
(obviously) when they're not.  How can I disable the "Unsafe JavaScript
attempt to access frame with URL http://www.google.com/ from frame with URL
http://10.0.0.50/js_test.html. Domains, protocols and ports must match."
error message?

I've come across the WebKitSecurityOrigin object and I've been able to
extract the host/port/protocol of my current page, but I haven't found a way
to spoof this mechanism…

I know too that Chrome has the --disable-web-security flag, but I can't
quite put my finger on what I need to do to replicate this functionality
when working with WebKit directly.

Can anyone offer a pointer or suggestion?

Thanks so much!

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

[webkit-dev] Mouse Lock API

2011-09-12 Thread Vincent Scheib 
A Mouse Lock API has been under discussion on the W3 public-webapps list
"Mouse Lock"(1) and earlier "Mouse Capture for Canvas"(2).

The primary goal is to enable use cases such as first person perspective 3D
applications. This is done by providing scripted access to mouse movement
data while locking the target of mouse events to a single element and
removing the cursor from view.

I have been working to formalize the discussions into a draft
specification: http://goo.gl/9G8pd, and have a work in progress prototype
for WebKit | Chrome. I will publish a WIP patch when it is ready for more
eyes. It will be developed behind a compile (and runtime) time flag.

I'd like to invite any specification discussion to the Mouse Lock thread
(1), and WebKit implementation discussion here.

Cheers, -Vince

--
1.
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960
2.
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437

W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557
Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Do you maintain OS(WINCE)?

2011-09-12 Thread Geoffrey Garen 
Hi folks.

It looks like another build variant that relies on threads not existing in 
WebKit and JavaScriptCore is OS(WINCE).

Do you maintain OS(WINCE)? If so, are you interested in implemented 
JavaScriptCore threading primitives for it?

If nobody maintains OS(WINCE), I'm inclined to remove it in a follow-up patch.

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

Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk

2011-09-12 Thread Evan Martin 
On Mon, Sep 12, 2011 at 4:11 PM, Jarred Nicholls  wrote:
> git-svn would be the fallback - I'd rather take razor blades to my eyes.
>  But this is a noble effort in general, thanks.
> Do we need to do anything to alleviate history in the git mirror?  I'd love
> to clone 25MB and not 2.1GB.

Once the baselines are out, git clone --depth 1.
I urge you to not spend much too much time ratholing this into git
questions; I think the first problems Adam listed under "Problems" are
the real killers, and without a good answer for those the whole idea
is a nonstarter.

(I would love to solve this too, I just also don't see a good way to handle it.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] run-bindings-tests

2011-09-12 Thread Darin Adler 
On Sep 12, 2011, at 4:23 PM, Maciej Stachowiak wrote:

> Notwithstanding all the later discussion, I think run-bindings-tests would 
> still be more effective as a build step that updates a source file rather 
> than a test step.

I see, a build step that updates a checked-in source file. Sounds like a great 
idea to me. I did not see that proposal earlier!

-- Darin

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

Re: [webkit-dev] run-bindings-tests

2011-09-12 Thread Maciej Stachowiak 

On Sep 8, 2011, at 12:25 PM, Darin Adler wrote:

> On Sep 8, 2011, at 11:49 AM, Alexey Proskuryakov wrote:
> 
>> As discussed on IRC, I do not think that bots should run this test at all. 
>> It has a non-trivial maintenance cost, but provides very little benefit. 
>> Even the time spent by multiple engineers on IRC today discussing bot 
>> complaints is likely more than the test could save in the lifetime of the 
>> project, at my guesstimate.
> 
> I find the bindings tests quite helpful. Because the perl script is so hard 
> to read, it’s the changes in bindings script test results that I look at when 
> reviewing changes to the bindings scripts. The fact that the results are 
> checked in helps me review patches.
> 
> It would be better to plug them in to the testing machinery in a better way. 
> I don’t think contributors should have to learn how to run different types of 
> commands.

Notwithstanding all the later discussion, I think run-bindings-tests would 
still be more effective as a build step that updates a source file rather than 
a test step. Recompiling after changing the bindings generator would then 
regenerate this file, and the diffs would be present in uploaded patches (as 
well as being obtainable to developers working locally by using svn diff or git 
diff respectively). That way, it's much harder to "do it wrong" and cause bot 
redness downstream. It's possible that this way you could cause bindings 
changes unintentionally, but presumably you and your reviewer will spot these 
when looking at the patch. It seems to me we shouldn't require an extra manual 
step to say "I really meant to change the text of the generated bindings".

Regards,
Maciej

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

Re: [webkit-dev] Implementing

2011-09-12 Thread Dimitri Glazkov 
On Mon, Sep 12, 2011 at 4:11 PM, Maciej Stachowiak  wrote:
>
> On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote:
>
> Hi all,
> After several discussions on the whatwg@ mailing list and others, we would
> like to go forward with adding

Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk

2011-09-12 Thread Adam Barth 
On Mon, Sep 12, 2011 at 4:11 PM, Jarred Nicholls  wrote:
> On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth  wrote:
>>
>> Leandro's recent message reminded me that there was some discussion on
>> this list about the burden caused by storing and maintaining pixel
>> baselines for an ever-growing list of configurations.  I've been
>> working on a proposal for moving pixel baselines to a "branch" so that
>> they don't bother most folks.
>>
>> Unfortunately, I haven't been able to work out all the details yet.
>> Here's a somewhat rough, work-in-progress proposal.  If you like this
>> approach, I can spend more time trying to solve the remaining
>> problems.
>>
>> == Motivation ==
>>
>> Maintaining pixel test results in svn.webkit.org for the various
>> Chromium configuration imposes a number of costs on the WebKit
>> community:
>>
>> All members of the community need to store these results locally when
>> they create a checkout of WebKit.
>> Updating the pixel results creates churn in the project that increases
>> the time required to update a working copy and makes it more difficult
>> to understand what is actually changing in the project.
>>
>> As the Chromium port grows in complexity, there is pressure from the
>> Chromium project to expand the number of test configurations,
>> increasing these costs on the WebKit community.
>>
>> == Proposal (Work-in-progress) ==
>>
>> One option is to stop running pixel test altogether, but that
>> decreases test coverage and costs correctness.  Another possibility is
>> to store the pixel results in a location where they are largely
>> invisible to the rest of the WebKit community.  For example, we could
>> store the pixel results for chromium-linux the following location:
>>
>> http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux
>>
>> Chromium contributors could then use gclient and DEPS to map these
>> results into their working copies and non-chromium contributors could
>> safely ignore any changes in the PixelResults “branch”.
>>
>> FIXME: What about non-platform specific results?
>>
>> == Problems ==
>>
>> The main reason this proposal is half-baked is I haven't quite been
>> able to work out how folks can do some common operations:
>>
>> 1) Land patch with expected image failures (+ revert)
>> 2) Land patch with new image baselines (+ revert)
>> 3) Land new baselines
>>
>> Because the pixel results and trunk are in the same SVN repo, we
>> should be able to do these things atomically, but dealing with the
>> sparse checkout is kind of tricky.
>>
>> Another big question mark is how this would work for contributors who
>> use git.  When git mirrors an SVN repro, it only mirrors "trunk", so
>> the PixelResults directory wouldn't exist in the git version of the
>> repository.
>
> git-svn would be the fallback - I'd rather take razor blades to my eyes.
>  But this is a noble effort in general, thanks.
> Do we need to do anything to alleviate history in the git mirror?  I'd love
> to clone 25MB and not 2.1GB.

I'm not a git expert, so I'm not sure if there's any way to repair the
sins of the past (e.g., with filter-branch) while still keeping
git-svn working.

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

Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk

2011-09-12 Thread Jarred Nicholls 
On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth  wrote:

> Leandro's recent message reminded me that there was some discussion on
> this list about the burden caused by storing and maintaining pixel
> baselines for an ever-growing list of configurations.  I've been
> working on a proposal for moving pixel baselines to a "branch" so that
> they don't bother most folks.
>
> Unfortunately, I haven't been able to work out all the details yet.
> Here's a somewhat rough, work-in-progress proposal.  If you like this
> approach, I can spend more time trying to solve the remaining
> problems.
>
> == Motivation ==
>
> Maintaining pixel test results in svn.webkit.org for the various
> Chromium configuration imposes a number of costs on the WebKit
> community:
>
> All members of the community need to store these results locally when
> they create a checkout of WebKit.
> Updating the pixel results creates churn in the project that increases
> the time required to update a working copy and makes it more difficult
> to understand what is actually changing in the project.
>
> As the Chromium port grows in complexity, there is pressure from the
> Chromium project to expand the number of test configurations,
> increasing these costs on the WebKit community.
>
> == Proposal (Work-in-progress) ==
>
> One option is to stop running pixel test altogether, but that
> decreases test coverage and costs correctness.  Another possibility is
> to store the pixel results in a location where they are largely
> invisible to the rest of the WebKit community.  For example, we could
> store the pixel results for chromium-linux the following location:
>
> http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux
>
> Chromium contributors could then use gclient and DEPS to map these
> results into their working copies and non-chromium contributors could
> safely ignore any changes in the PixelResults “branch”.
>
> FIXME: What about non-platform specific results?
>
> == Problems ==
>
> The main reason this proposal is half-baked is I haven't quite been
> able to work out how folks can do some common operations:
>
> 1) Land patch with expected image failures (+ revert)
> 2) Land patch with new image baselines (+ revert)
> 3) Land new baselines
>
> Because the pixel results and trunk are in the same SVN repo, we
> should be able to do these things atomically, but dealing with the
> sparse checkout is kind of tricky.
>
> Another big question mark is how this would work for contributors who
> use git.  When git mirrors an SVN repro, it only mirrors "trunk", so
> the PixelResults directory wouldn't exist in the git version of the
> repository.
>

git-svn would be the fallback - I'd rather take razor blades to my eyes.
 But this is a noble effort in general, thanks.

Do we need to do anything to alleviate history in the git mirror?  I'd love
to clone 25MB and not 2.1GB.


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



-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls

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

Re: [webkit-dev] Implementing

2011-09-12 Thread Maciej Stachowiak 

On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote:

> Hi all,
> 
> After several discussions on the whatwg@ mailing list and others, we would 
> like to go forward with adding

Re: [webkit-dev] make-script-test-wrappers not being maintained

2011-09-12 Thread Maciej Stachowiak 

On Sep 8, 2011, at 11:15 AM, Eric Seidel wrote:

> It seems the "sucessfullyParsed" question could also be answered by
> some intelligent onerror handler added to the right script tag.

The "successfullyParsed" thing was originally added to benefit JS tests running 
in the browser. If you get a bunch of passes and then an exception which 
prevents further output, you wouldn't think that everything passed solely 
because the output is truncated. If it's possible to achieve this with onerror, 
and if this technique works cross-browser (an important use case for 
assertion-style layout tests is to load them in other browsers), then that 
would be fine by me. Last I heard, Opera didn't support onerror properly, but 
this may have changed.

 - Maciej

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

Re: [webkit-dev] Implementing

2011-09-12 Thread Edward O'Connor 
Ryosuke Niwa wrote:

>>> Why do diverge? It seems like we should at least prefix the
>>> attribute with webkit in the case spec changes in the future.
>
>> See above linked discussion for details. In the end we felt limiting
>> the selector matching to the scope is more natural, and - with the
>> proposed exception providued by :root and :scope - is more flexible.
>> 
>> However, naming the attribute 'webkit-scoped' may certainly be a good
>> idea. 
>
> Yes, please use webkitscoped (no - since this is content attribute?).

The spec requests that vendor-specific attributes take names of the form
"x-vendor-feature":

http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility

So x-webkit-scoped would be the way to go.


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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread Ryosuke Niwa 
On Mon, Sep 12, 2011 at 2:50 PM, Leandro Pereira wrote:
>
> Most differences are because the EFL port doesn't change the viewport size
> because of the scrollbar: it is drawn on top of the content on the EFL port
> by default. So there is a little more room horizontally, and then text
> results are slightly different from GTK+'s (which uses the same font
> backends, for instance).
>
> In those tests that only draws colored rectangles, the render tree is
> pretty much the same as any other port's. However, in these tests, the pixel
> results are rendered with colors slightly different from the expected.
> Almost no difference to the naked eye. I suspect either some rounding
> problems inside Cairo, or wrong color profile.
>

Chromium port has made a significant effort into matching scrollbar/color
with Mac port to mitigate this issue. Maybe you can talk to one of our
friendly contributors and get some help in reducing the number of baselines
you need to check in.

I don't intend to claim that you're obligated to do this but if you check in
a lot of port-specific baselines, then you're very likely end up having to
rebaseline hundreds of tests each day to catch up with new changes landed in
trunk. This is a very tedious job and people from other ports spend a
significant engineering time into this.

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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread Leandro Pereira 

On 09/12/2011 05:36 PM, Ryosuke Niwa wrote:

On our internal EFL tree, there is about 125MB of baselines for both
pixel and text tests. Unfortunately we were unable to share our
baselines with similar ports, due to slight differences in results.


What are differences you're seeing?

>

Most differences are because the EFL port doesn't change the viewport 
size because of the scrollbar: it is drawn on top of the content on the 
EFL port by default. So there is a little more room horizontally, and 
then text results are slightly different from GTK+'s (which uses the 
same font backends, for instance).


In those tests that only draws colored rectangles, the render tree is 
pretty much the same as any other port's. However, in these tests, the 
pixel results are rendered with colors slightly different from the 
expected. Almost no difference to the naked eye. I suspect either some 
rounding problems inside Cairo, or wrong color profile.


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

Re: [webkit-dev] Color profiles in expected.png files

2011-09-12 Thread Peter Kasting 
On Fri, Sep 9, 2011 at 7:21 PM, Simon Fraser  wrote:

> I think we should be consistent about color profiles, and in a way that
> doesn't break pixel tests. Does anyone want to vote one way or the other?


I suspect "no profiles" is the only way that will work across both ports
that handle embedded color profiles and ports that do not.  (AFAIK some
Chromium ports currently do not.)

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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread Peter Kasting 
On Mon, Sep 12, 2011 at 1:56 PM, David Levin  wrote:

> On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting wrote:
>
>> In particular, if we have pixel tests that don't need to be pixel tests at
>> all, or font rendering differences due to explanatory text that could be
>> moved to an HTML comment inside the test itself, we can obviate the need for
>> port-specific baselines in many of those cases (and eliminate more baselines
>> from ports already in the tree, and reduce the burden on other ports that
>> want to run pixel tests, and reduce the maintenance cost of changing the
>> tests).
>>
>
> Are y'all suggesting that efl port should do these items (converting pixel
> tests to non-pixel tests) before committing their baselines?
>

I don't think it's fair to force the EFL folks to do all this.  I do think
all ports would benefit from it and all ports should be spending some effort
on this kind of thing.  Inasmuch as there is an opportunity here for doing
this work to minimize the landing cost for the EFL baselines, I'm raising
this so that those folks can keep the option in mind and make use of it
opportunistically.

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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread Ryosuke Niwa 
On Mon, Sep 12, 2011 at 1:56 PM, David Levin  wrote:
>
> On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting wrote:
>
>> On Mon, Sep 12, 2011 at 1:36 PM, Ryosuke Niwa  wrote:
>>
>>> This is pretty much unreviewable, so I pretend to commit this directly,
 in batches (one commit per toplevel directory in LayoutTests/platform/efl)
 in the next weeks. Any objections or suggestions?

>>>
>>> It'll be nice if we could spend some time analyzing the differences
>>> between EFL and other ports to minimize the size of patch first.
>>>
>>
>> In particular, if we have pixel tests that don't need to be pixel tests at
>> all, or font rendering differences due to explanatory text that could be
>> moved to an HTML comment inside the test itself, we can obviate the need for
>> port-specific baselines in many of those cases (and eliminate more baselines
>> from ports already in the tree, and reduce the burden on other ports that
>> want to run pixel tests, and reduce the maintenance cost of changing the
>> tests).
>>
>
> Are y'all suggesting that efl port should do these items (converting pixel
> tests to non-pixel tests) before committing their baselines?
>

No. But in general, we try to match DRT's behavior to that of Mac port to
avoid adding redundant baselines so EFL port should do the same.

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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread David Levin 
On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting wrote:

> On Mon, Sep 12, 2011 at 1:36 PM, Ryosuke Niwa  wrote:
>
>> This is pretty much unreviewable, so I pretend to commit this directly, in
>>> batches (one commit per toplevel directory in LayoutTests/platform/efl) in
>>> the next weeks. Any objections or suggestions?
>>>
>>
>> It'll be nice if we could spend some time analyzing the differences
>> between EFL and other ports to minimize the size of patch first.
>>
>
> In particular, if we have pixel tests that don't need to be pixel tests at
> all, or font rendering differences due to explanatory text that could be
> moved to an HTML comment inside the test itself, we can obviate the need for
> port-specific baselines in many of those cases (and eliminate more baselines
> from ports already in the tree, and reduce the burden on other ports that
> want to run pixel tests, and reduce the maintenance cost of changing the
> tests).
>

Are y'all suggesting that efl port should do these items (converting pixel
tests to non-pixel tests) before committing their baselines?

dave

PS fwiw, at one point, I did some work to figure out which tests were
changing most often to see where people would get the most return on their
investment and to my memory many tests with a high churn rate were svg
(which seem like they would be harder to convert to a non-pixel test
format).


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

[webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk

2011-09-12 Thread Adam Barth 
Leandro's recent message reminded me that there was some discussion on
this list about the burden caused by storing and maintaining pixel
baselines for an ever-growing list of configurations.  I've been
working on a proposal for moving pixel baselines to a "branch" so that
they don't bother most folks.

Unfortunately, I haven't been able to work out all the details yet.
Here's a somewhat rough, work-in-progress proposal.  If you like this
approach, I can spend more time trying to solve the remaining
problems.

== Motivation ==

Maintaining pixel test results in svn.webkit.org for the various
Chromium configuration imposes a number of costs on the WebKit
community:

All members of the community need to store these results locally when
they create a checkout of WebKit.
Updating the pixel results creates churn in the project that increases
the time required to update a working copy and makes it more difficult
to understand what is actually changing in the project.

As the Chromium port grows in complexity, there is pressure from the
Chromium project to expand the number of test configurations,
increasing these costs on the WebKit community.

== Proposal (Work-in-progress) ==

One option is to stop running pixel test altogether, but that
decreases test coverage and costs correctness.  Another possibility is
to store the pixel results in a location where they are largely
invisible to the rest of the WebKit community.  For example, we could
store the pixel results for chromium-linux the following location:

http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux

Chromium contributors could then use gclient and DEPS to map these
results into their working copies and non-chromium contributors could
safely ignore any changes in the PixelResults “branch”.

FIXME: What about non-platform specific results?

== Problems ==

The main reason this proposal is half-baked is I haven't quite been
able to work out how folks can do some common operations:

1) Land patch with expected image failures (+ revert)
2) Land patch with new image baselines (+ revert)
3) Land new baselines

Because the pixel results and trunk are in the same SVN repo, we
should be able to do these things atomically, but dealing with the
sparse checkout is kind of tricky.

Another big question mark is how this would work for contributors who
use git.  When git mirrors an SVN repro, it only mirrors "trunk", so
the PixelResults directory wouldn't exist in the git version of the
repository.

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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread Peter Kasting 
On Mon, Sep 12, 2011 at 1:36 PM, Ryosuke Niwa  wrote:

> This is pretty much unreviewable, so I pretend to commit this directly, in
>> batches (one commit per toplevel directory in LayoutTests/platform/efl) in
>> the next weeks. Any objections or suggestions?
>>
>
> It'll be nice if we could spend some time analyzing the differences between
> EFL and other ports to minimize the size of patch first.
>

In particular, if we have pixel tests that don't need to be pixel tests at
all, or font rendering differences due to explanatory text that could be
moved to an HTML comment inside the test itself, we can obviate the need for
port-specific baselines in many of those cases (and eliminate more baselines
from ports already in the tree, and reduce the burden on other ports that
want to run pixel tests, and reduce the maintenance cost of changing the
tests).

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

Re: [webkit-dev] Committing EFL baselines

2011-09-12 Thread Ryosuke Niwa 
On Mon, Sep 12, 2011 at 1:32 PM, Leandro Pereira wrote:

> Hi.
>
> What's the preferred way to commit a ton of baselines for a port that
> currently has none?
>
> On our internal EFL tree, there is about 125MB of baselines for both pixel
> and text tests. Unfortunately we were unable to share our baselines with
> similar ports, due to slight differences in results.


What are differences you're seeing?

This is pretty much unreviewable, so I pretend to commit this directly, in
> batches (one commit per toplevel directory in LayoutTests/platform/efl) in
> the next weeks. Any objections or suggestions?
>

It'll be nice if we could spend some time analyzing the differences between
EFL and other ports to minimize the size of patch first.

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

[webkit-dev] Committing EFL baselines

2011-09-12 Thread Leandro Pereira 

Hi.

What's the preferred way to commit a ton of baselines for a port that 
currently has none?


On our internal EFL tree, there is about 125MB of baselines for both 
pixel and text tests. Unfortunately we were unable to share our 
baselines with similar ports, due to slight differences in results.


This is pretty much unreviewable, so I pretend to commit this directly, 
in batches (one commit per toplevel directory in 
LayoutTests/platform/efl) in the next weeks. Any objections or suggestions?



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

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Jarred Nicholls 
On Mon, Sep 12, 2011 at 12:53 PM, Konstantin Tokarev wrote:

>
>
> 12.09.2011, 23:18, "Leandro Pereira":
>
> > OTOH, providing binary packages for Linux isn't an easy task. Different
> > packaging standards, ABI differences, etc, makes binary distribution a
> > nightmare: even if a new set of libraries are installed, there is no
> > warranty that the browsers will pick those up or even if it will work at
> > all (not really an issue for nightly builds but annoying nonetheless).
>
> Not really. One can perform a build on CentOS 5 and bundle every library
> ldd shows with resulting binaries (with exception of libc, libdl, and
> librt) with
> application.
>

True enough, I also build my products on CentOS 5 and it works on all the
other major distributions quite well.  It's got sufficiently old glibc, etc.
 But, there's the occasional issue in edge distros.


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



-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls

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

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Jarred Nicholls 
On Mon, Sep 12, 2011 at 11:57 AM, Ryosuke Niwa  wrote:

> Also, I often encounter regressions or bugs only reproduce on certain ports
> but I haven't been able to confirm those bugs because I don't have a luxury
> of building those ports just to confirm bugs.  Providing nightlies for those
> ports will greatly enhance our ability to narrow down regression windows and
> triage bugs.


Massive point.


>
> - Ryosuke
>
> On Mon, Sep 12, 2011 at 11:38 AM, Kaustubh Atrawalkar  > wrote:
>
>> Yes, I second Ryosuke and really would like to support this idea. Not even
>> just end user but developers like us would also like to have sneak in these
>> nightly builds. It will not only help to test the nightly on daily basis but
>> also will help to improve and contribute more. I m ready to help for this in
>> any way possible.
>>
>> - Kaustubh
>>
>> On 12-Sep-2011, at 11:43 PM, Ryosuke Niwa  wrote:
>>
>> An excellent idea!
>>
>> - Ryosuke
>>
>> On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth < 
>> aba...@webkit.org> wrote:
>>
>>> Do any ports besides the Apple ports produce nightly builds that
>>> end-users might be interested in using?  If so, it might make sense to
>>> expand the offerings on 
>>> http://nightly.webkit.org/ to include more
>>> choices.  For example, Linux users might enjoy a nightly build that
>>> runs on Linux.
>>>
>>> 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
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls

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

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Konstantin Tokarev 


12.09.2011, 23:18, "Leandro Pereira":

> OTOH, providing binary packages for Linux isn't an easy task. Different
> packaging standards, ABI differences, etc, makes binary distribution a
> nightmare: even if a new set of libraries are installed, there is no
> warranty that the browsers will pick those up or even if it will work at
> all (not really an issue for nightly builds but annoying nonetheless).

Not really. One can perform a build on CentOS 5 and bundle every library
ldd shows with resulting binaries (with exception of libc, libdl, and librt) 
with
application.

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

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Adam Barth 
On Mon, Sep 12, 2011 at 12:18 PM, Leandro Pereira
 wrote:
> On 09/12/2011 03:10 PM, Adam Barth wrote:
>> Do any ports besides the Apple ports produce nightly builds that
>> end-users might be interested in using?  If so, it might make sense to
>> expand the offerings on http://nightly.webkit.org/ to include more
>> choices.  For example, Linux users might enjoy a nightly build that
>> runs on Linux.
>
> Excellent. I can provide at least WebKit-EFL/Linux packages. If it's easy to
> generate packages for other Linux ports as well (GTK and Qt ports I know
> that are easy to build; never tried Wx and Chromium), I can give a try in
> writing and maintaining a bot that does that.
>
> OTOH, providing binary packages for Linux isn't an easy task. Different
> packaging standards, ABI differences, etc, makes binary distribution a
> nightmare: even if a new set of libraries are installed, there is no
> warranty that the browsers will pick those up or even if it will work at all
> (not really an issue for nightly builds but annoying nonetheless).
>
> If there's an agreement of which Linux distribution should be supported by
> n.w.o, things will be a lot easier.

My sense is that each port can make that decision on its own.  For
example, binary builds of Chrome are available for Debian, Ubuntu,
Fedora, and openSUSE.  If you wanted to provide binary builds of the
EFL port for those or different flavors of Linux, that's up to you.

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

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Leandro Pereira 

Adam,

On 09/12/2011 03:10 PM, Adam Barth wrote:

Do any ports besides the Apple ports produce nightly builds that
end-users might be interested in using?  If so, it might make sense to
expand the offerings on http://nightly.webkit.org/ to include more
choices.  For example, Linux users might enjoy a nightly build that
runs on Linux.


Excellent. I can provide at least WebKit-EFL/Linux packages. If it's 
easy to generate packages for other Linux ports as well (GTK and Qt 
ports I know that are easy to build; never tried Wx and Chromium), I can 
give a try in writing and maintaining a bot that does that.


OTOH, providing binary packages for Linux isn't an easy task. Different 
packaging standards, ABI differences, etc, makes binary distribution a 
nightmare: even if a new set of libraries are installed, there is no 
warranty that the browsers will pick those up or even if it will work at 
all (not really an issue for nightly builds but annoying nonetheless).


If there's an agreement of which Linux distribution should be supported 
by n.w.o, things will be a lot easier.


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

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Ryosuke Niwa 
Also, I often encounter regressions or bugs only reproduce on certain ports
but I haven't been able to confirm those bugs because I don't have a luxury
of building those ports just to confirm bugs.  Providing nightlies for those
ports will greatly enhance our ability to narrow down regression windows and
triage bugs.

- Ryosuke

On Mon, Sep 12, 2011 at 11:38 AM, Kaustubh Atrawalkar
wrote:

> Yes, I second Ryosuke and really would like to support this idea. Not even
> just end user but developers like us would also like to have sneak in these
> nightly builds. It will not only help to test the nightly on daily basis but
> also will help to improve and contribute more. I m ready to help for this in
> any way possible.
>
> - Kaustubh
>
> On 12-Sep-2011, at 11:43 PM, Ryosuke Niwa  wrote:
>
> An excellent idea!
>
> - Ryosuke
>
> On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth < 
> aba...@webkit.org> wrote:
>
>> Do any ports besides the Apple ports produce nightly builds that
>> end-users might be interested in using?  If so, it might make sense to
>> expand the offerings on 
>> http://nightly.webkit.org/ to include more
>> choices.  For example, Linux users might enjoy a nightly build that
>> runs on Linux.
>>
>> 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Ryosuke Niwa 
An excellent idea!

- Ryosuke

On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth  wrote:

> Do any ports besides the Apple ports produce nightly builds that
> end-users might be interested in using?  If so, it might make sense to
> expand the offerings on http://nightly.webkit.org/ to include more
> choices.  For example, Linux users might enjoy a nightly build that
> runs on Linux.
>
> 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

[webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Adam Barth 
Do any ports besides the Apple ports produce nightly builds that
end-users might be interested in using?  If so, it might make sense to
expand the offerings on http://nightly.webkit.org/ to include more
choices.  For example, Linux users might enjoy a nightly build that
runs on Linux.

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

Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?

2011-09-12 Thread Dan Minor 
When doing ports to various embedded systems we often disable SVG to 
reduce the size of the resulting library.  It would be nice to retain 
the top level ENABLE_SVG define for this purpose.


Thanks,

Dan

On 09/09/2011 05:42 PM, Eric Seidel wrote:

I am interested in removing the ENABLE_SVG define, and all associated
sub-defines

ENABLE_SVG_ANIMATION
ENABLE_SVG_AS_IMAGE
ENABLE_SVG_FONTS
ENABLE_SVG_FOREIGN_OBJECT
ENABLE_SVG_USE

SVG is part of HTML5, and all major ports compile and ship with SVG
enabled (and have for years).

Please let me know if you are compiling with ENABLE_SVG disabled.

-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

[webkit-dev] Invitation to connect on LinkedIn

2011-09-12 Thread Hw H 
I'd like to add you to my professional network on LinkedIn.

- Hw

Hw H
Student at Nanjing University
China

Confirm that you know Hw H:
https://www.linkedin.com/e/-jnbvix-gshir909-4b/isd/4172438214/B_UjDLgk/?hs=false&tok=30copF8xZDEAU1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-jnbvix-gshir909-4b/qxt6X_WQtIhjU098J-t7a9l-QVVLSjg_CRCP9zASYX/goo/webkit-dev%40lists%2Ewebkit%2Eorg/20061/I1440539683_1/?hs=false&tok=1qgikbr7VDEAU1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev