Hi WebKit folks,
We've been vendor-prefixing Blob.slice() since we changed the semantics of
slice() to make it alike Array.slice, i.e. from start, length to start,
end semantics in r83873 [1]. The non-prefixed version had only been
shipped in Chrome and must have helped apps migrate into the new
Happy to see us support unprefixed too. With other vendors on board, it
seems like a straightforward addition to the platform.
I'm not sure if you are proposing to also remove the prefixed form. I'm
not sure what it would take to remove the prefixed version. We'd need some
way to know when it
On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org wrote:
Happy to see us support unprefixed too. With other vendors on board, it
seems like a straightforward addition to the platform.
I'm not sure if you are proposing to also remove the prefixed form. I'm
not sure what it
Hello WebKit community,
We want to announce a European WebKit Hackathon event hosted by Adobe. The
event will take place in Adobe office in Bucharest on September 20th - 22nd.
We hope that this hackathon will offer attendees the opportunity to know each
other better, share WebKit expertise,
Hi,
I realized that there are a whole bunch of tests in LayoutTests/css3 that
use layoutTestController (e.g. css3/calc, css3/filters, etc...), which
appears to mean that they're our own tests. However, css3/selectors3 is an
imported W3C test suite. It's very confusing to mix imported tests and
On Mon, Jun 11, 2012 at 2:08 AM, TAMURA, Kent tk...@chromium.org wrote:
Do you want WebExposed for a simple bug fix of an existing feature? Do you
want it for bugs with no patches?
If the change might impact Web Developers - yes. Of course, use your own
judgement here; it won't have much
On 2012-06-10 19:09, Žan Doberšek wrote:
I think it would suffice to replace all the FAIL occurrences with
TEXT, except for the failing reftests - those should have FAIL turned
into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE
failures could perhaps be addressed at later time.
I think imported tests should be outside of LayoutTests/fast.
Simon
On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote:
Hi,
I realized that there are a whole bunch of tests in LayoutTests/css3 that use
layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to
mean that
On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser simon.fra...@apple.com wrote:
I think imported tests should be outside of LayoutTests/fast.
I agree a dedicated folder seems more appropriate.
My two cents.
Simon
On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote:
Hi,
I realized that there
On 6/11/12 11:11 AM, Alexis Menard alexis.men...@openbossa.org wrote:
On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser simon.fra...@apple.com
wrote:
I think imported tests should be outside of LayoutTests/fast.
I agree a dedicated folder seems more appropriate.
My two cents.
Simon
On Jun 11,
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.com wrote:
Can we just create an imported-w3c folder at the same level as LayoutTests?
You mean at trunk? I don't think that makes sense, and our testing
infrastructure doesn't support that.
- Ryosuke
On 6/11/12 2:24 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org
wrote:
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein
jac...@adobe.commailto:jac...@adobe.com wrote:
Can we just create an imported-w3c folder at the same level as LayoutTests?
You mean at trunk? I don't think that
On Mon, Jun 11, 2012 at 2:25 PM, Jacob Goldstein jac...@adobe.com wrote:
On 6/11/12 2:24 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.comwrote:
Can we just create an imported-w3c folder at the same level as
LayoutTests?
You mean
On Mon, Jun 11, 2012 at 2:24 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.com wrote:
Can we just create an imported-w3c folder at the same level as
LayoutTests?
You mean at trunk? I don't think that makes sense, and our testing
On Mon, Jun 11, 2012 at 2:33 PM, Dirk Pranke dpra...@chromium.org wrote:
Technically, it does (at least NRWT does), but I wouldn't recommend
it. NRWT is designed to allow tests to live in multiple repos, but it
seems like all of the tests in the webkit repo should be under a
single top-level
On 6/11/12 2:37 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org
wrote:
On Mon, Jun 11, 2012 at 2:33 PM, Dirk Pranke
dpra...@chromium.orgmailto:dpra...@chromium.org wrote:
Technically, it does (at least NRWT does), but I wouldn't recommend
it. NRWT is designed to allow tests to live in
On Jun 10, 2012, at 9:26 AM, Ojan Vafai o...@chromium.org wrote:
On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen kbal...@webkit.org wrote:
So the unit tests are superfluous. In particular, if I had to pick between
only having unit tests or only having regression tests, I might pick unit
On Jun 6, 2012, at 6:27 PM, Darin Adler da...@apple.com wrote:
On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote:
IMHO, (a) would be the best semantics.
I agree, and I think that the specification actually does require this.
The real issue here is how to fix this bug
On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak m...@apple.com wrote:
not a self-only reference (at some point renamed to guardRef).
BTW I was able to find where it was renamed but not a good explanation of why.
I think selfOnlyRef() was a much clearer name.
The history seems to be that it
Thanks Maciej
I am trying to implement a WIP patch that guarantees Reachable DOM nodes
are kept alive, without regressing performance nor without adding member
variables to Node objects. The patch will remove guardRef() as a natural
consequence. Although I'm not 100% sure if the work succeeds or
On Jun 7, 2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org
wrote:
I wanted to let you know that I plan to add support for
navigator.buildType
On Mon, Jun 11, 2012 at 6:29 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 7, 2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org
wrote:
I wanted
I'm the guy that added css3/calc tests.
I did so because I not all my tests are 'text only' tests, but I still
wanted them all together. My understanding was that the 'fast' directory
was intended for 'text only' tests only.
Does having the 'fast' directory still serve a useful purpose? I reckon
On Mon, Jun 11, 2012 at 7:33 PM, Mike Lawther mikelawt...@chromium.orgwrote:
I did so because I not all my tests are 'text only' tests, but I still
wanted them all together. My understanding was that the 'fast' directory
was intended for 'text only' tests only.
That's not the case. The
Thanks ggaren!
I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=88834
I believe you could achieve (a) (i.e., preserve all reachable nodes without
help from the JavaScript garbage collector) with these semantics in the C++
DOM:
= Design =
ref():
++this-refCount
IMHO, (a) would be the best semantics.
I agree, and I think that the specification actually does require this.
The real issue here is how to fix this bug efficiently. I believe that Geoff
Garen has been contemplating this and also has a proposal for how to do it.
I believe you could
Actually I've tried the approach yesterday but confirmed 25.9%
performance regression, even if I have TreeShared hold a pointer to
the root. Please look at the WIP patch and the performance test in
https://bugs.webkit.org/show_bug.cgi?id=88834.
What I've learned is that we must not insert
I think that a lot of the performance penalty can be alleviated by:
1) Moving rarely executed paths into non-inlineable methods.
2) Marking the various refing methods ALWAYS_INLINE, after you've moved as much
as possible out of line.
3) Using LIKELY and UNLIKELY where appropriate.
The
Hi ggaren and pizlo
Sorry for posting a not-yet-optimized WIP patch. I'll re-post it after
optimization you suggested.
Also, I described the algorithm I am now implementing. I guess that
this algorithm would have less overhead:
https://bugs.webkit.org/show_bug.cgi?id=88834#c3
On Tue, Jun
There are plenty of non-text tests in fast/, even entire directories of
them (fast/repaint). My understanding of the meaning of fast/ is that it is
where new tests that are not imported should go. This meaning is not
universally applied.
- James
On Jun 11, 2012 7:33 PM, Mike Lawther
30 matches
Mail list logo
