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
>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: webki
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 embedd
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 locki
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
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 th
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 li
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 multip
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
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
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 pi
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
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 bu
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
>> p
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
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?
>
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
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 insid
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
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 objec
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 fo
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
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 b
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 result
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 libra
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
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 t
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/ t
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 enjo
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 windo
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
> cho
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
___
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 defin
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 u
34 matches
Mail list logo
