Hi all,
I had a doubt regardingFrameView::setBaseBackgroundColor. Is it used to
set the default background color of the web page? say for example if
background css property is not preset, I can use this API is override the
default white color?
Thanks,
--Vineeth
___
On Oct 26, 2012, at 9:04 PM, Adam Barth wrote:
> On Fri, Oct 26, 2012 at 9:08 AM, Dirk Schulze wrote:
>> Hi WebKit folks,
>>
>> I have a question to origin restriction and CSS. First the context:
>>
>> CSS Masking[1] aims to combine the two different 'mask' property
>> implementations from W
Hello webkit-dev'ers,
In response to the email “Improving autocomplete” to wha...@whatwg.org
[1], I plan to implement an experimental version of the proposed API
(HTMLFormElement#requestAutocomplete, onautocomplete,
onautocompleteerror).
This feature uses information derived from the new autocomp
26.10.2012, в 14:57, Dirk Pranke написал(а):
> Perhaps a slight variant of this is that we can agree to make the
> changes on the Chromium port to clear the cache (much like the Qt and
> EFL ports already do), and you can continue to not clear the cache on
> the Apple Mac port until you feel com
On Fri, Oct 26, 2012 at 3:02 PM, Ryosuke Niwa wrote:
> On Fri, Oct 26, 2012 at 2:57 PM, Dirk Pranke wrote:
>>
>> Perhaps a slight variant of this is that we can agree to make the
>> changes on the Chromium port to clear the cache (much like the Qt and
>> EFL ports already do), and you can continu
On Fri, Oct 26, 2012 at 2:57 PM, Dirk Pranke wrote:
> Perhaps a slight variant of this is that we can agree to make the
> changes on the Chromium port to clear the cache (much like the Qt and
> EFL ports already do), and you can continue to not clear the cache on
> the Apple Mac port until you fe
On Fri, Oct 26, 2012 at 12:43 PM, Alexey Proskuryakov wrote:
>
> 26.10.2012, в 11:04, Antti Koivisto написал(а):
>
>> The reality is that this "test coverage" today shows up as flakiness and
>> so is ignored anyway, meaning we don't actually have useful coverage here.
>> Even when flakiness is in
On Fri, Oct 26, 2012 at 2:11 PM, Ryosuke Niwa wrote:
> Is there any reason we can’t wait for another couple of weeks or months
> until we add more loader & cache tests before making the behavior change?
>
There is no time pressure here other than a desire to avoid this falling
between the cracks
On Fri, Oct 26, 2012 at 11:43 AM, Dirk Pranke wrote:
> On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa wrote:
> > On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn
> > wrote:
> >>
> >> On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa
> wrote:
> >> > ...
> >> >
> >> > I agree this is a good change
Should we add random sleeps to DRT? It'll certainly help find some
regressions (and even security bugs).
Of course the down-side is that it makes tests non-repeatable and difficult
to reason about.
I'm baffled by your priorities and don't know how to continue this
conversation productively. Sorr
26.10.2012, в 11:04, Antti Koivisto написал(а):
> The reality is that this "test coverage" today shows up as flakiness and so
> is ignored anyway, meaning we don't actually have useful coverage here. Even
> when flakiness is investigated, the "fix" is to cache-bust using unique URL
> params,
On Fri, Oct 26, 2012 at 9:08 AM, Dirk Schulze wrote:
> Hi WebKit folks,
>
> I have a question to origin restriction and CSS. First the context:
>
> CSS Masking[1] aims to combine the two different 'mask' property
> implementations from WebKit and Firefox. To make it short, 'mask' takes an
> URL
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa wrote:
> I agree this is a good change but it appears that we should add more
> cache/loader tests before changing DRT's behavior given that there are
> active contributors who rely on the current DRT behaviors to detect
> regressions.
Not knowing
On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa wrote:
> On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn
> wrote:
>>
>> On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa wrote:
>> > ...
>> >
>> > I agree this is a good change but it appears that we should add more
>> > cache/loader tests before cha
On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn wrote:
> On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa wrote:
> > ...
> >
> > I agree this is a good change but it appears that we should add more
> > cache/loader tests before changing DRT's behavior given that there are
> > active contributors w
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa wrote:
> ...
>
> I agree this is a good change but it appears that we should add more
> cache/loader tests before changing DRT's behavior given that there are
> active contributors who rely on the current DRT behaviors to detect
> regressions.
>
Can
On Fri, Oct 26, 2012 at 11:09 AM, Ami Fischman wrote:
> On Fri, Oct 26, 2012 at 11:04 AM, Antti Koivisto wrote:
>
>> When making cache related changes I have frequently found bugs from my
>> patches because some seemingly random test started failing and I
>> investigated. Without the test coverag
On Fri, Oct 26, 2012 at 11:04 AM, Antti Koivisto wrote:
> When making cache related changes I have frequently found bugs from my
> patches because some seemingly random test started failing and I
> investigated. Without the test coverage some of those bugs would probably
> now be in the tree.
>
On Fri, Oct 26, 2012 at 10:59 AM, Dirk Pranke wrote:
> I don't know that there was consensus that every port had to be
> updated at the same time; in fact Balazs said Qt and EFL already clear
> the cache.
>
Yes; the implication I took from the feedback on the bug was that if they
can't all be ma
On Fri, Oct 26, 2012 at 6:09 PM, Ami Fischman wrote:
> The reality is that this "test coverage" today shows up as flakiness and
> so is ignored anyway, meaning we don't actually have useful coverage here.
> Even when flakiness is investigated, the "fix" is to cache-bust using
> unique URL params
I don't know that there was consensus that every port had to be
updated at the same time; in fact Balazs said Qt and EFL already clear
the cache.
I think you should just land the change for Chromium and let others
update their ports as needed. The value in reduced flakiness and more
predictability
On Fri, Oct 26, 2012 at 9:06 AM, Peter Kasting wrote:
> On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier wrote:
>
>> It is valid for a const method to return you a new object ie a const
>> factory object.
>> In that case, const-ness would not be desired.
>>
>
> Not really. The point of this thread
Hi WebKit folks,
I have a question to origin restriction and CSS. First the context:
CSS Masking[1] aims to combine the two different 'mask' property
implementations from WebKit and Firefox. To make it short, 'mask' takes an URL
and this can either be a reference to an image, or to an element:
On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier wrote:
> It is valid for a const method to return you a new object ie a const
> factory object.
> In that case, const-ness would not be desired.
>
Not really. The point of this thread is that such functions may not modify
an object's state themselve
It is valid for a const method to return you a new object ie a const
factory object.
In that case, const-ness would not be desired.
Rik
On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling wrote:
> Yo WebKittens!
>
> After some mild morning discussion in #webkit, I'm wondering if we should
> amend ou
On Fri, Oct 26, 2012 at 1:44 AM, Antti Koivisto wrote:
> Cache has subtle interactions with other things being tested
> (->flakiness). More explicit cache tests would be nice but we can't hope
> the replicate all the accidental testing we now get. We are going to lose a
> large chunk of existing
On Fri, Oct 26, 2012 at 11:35 AM, Luka Napotnik wrote:
> Hello.
>
> I used Webkitgtk3 (webkit 1.8) on my Ubuntu 12.04 for a program I'm
> developing. I used the
> webkit_dom_html_element_click() function call to trigger click events
> on elements.
>
> But now, when I look into the newer code (webk
I'm happy to take a look at clearing the cache for the GTK+ port, but I
won't be able to do anything for mac unfortunately.
Brian
From: webkit-dev-boun...@lists.webkit.org
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ami Fischman
Sent: 26 October 2012 09:20
To: Dirk Pranke
Cc:
On Wed, Aug 8, 2012 at 9:54 PM, Eric U wrote:
> On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov
> wrote:
> > I can see some downsides to emptying the cache before each test:
> >
> > - we won't be getting any test coverage for cache behavior when it hits
> > non-trivial size;
>
> Then let's
Hello.
I used Webkitgtk3 (webkit 1.8) on my Ubuntu 12.04 for a program I'm
developing. I used the
webkit_dom_html_element_click() function call to trigger click events
on elements.
But now, when I look into the newer code (webkit 1.10) there's no
trace of these API calls. What happened?
Greets,
This thread stalled out because although there seemed to be majority
agreement that hermetic/repeatable tests are a good thing, there was a
requirement that all ports be updated to the new behavior at the same time,
and I'm only competent to do the chromium DRT (see
https://bugs.webkit.org/show_bug
We could have both const and non-const versions. For document(), we will
certainly need both.
I think these APIs can become less useful because the strict const-ness is
yet to be deployed widely. We can apply the rule for fresh classes line new
Web APIs since these rule worry little about older, l
32 matches
Mail list logo
