Re: [webkit-dev] Force Click events

Beth gave a bunch of details of the feature, but I would like to expand a bit on our standards plans, and cross-platform potential of this feature: (1) We definitely plan to take this proposal to standards bodies. We decided to implement a prototype first, so we could ensure we have something t

Re: [webkit-dev] Force Click events

Beth gave a bunch of details of the feature, but I would like to expand a bit on our standards plans, and cross-platform potential of this feature: (1) We definitely plan to take this proposal to standards > On May 8, 2015, at 3:25 AM, Jonathan Rimmer wrote: > > [I originally posted this to

Re: [webkit-dev] Client Hints

> On May 6, 2015, at 4:49 AM, Yoav Weiss wrote: > > > > On Wed, May 6, 2015 at 8:41 AM, Ryosuke Niwa > wrote: > On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss > wrote: > On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa > wrote:

Re: [webkit-dev] Client Hints

spec) > later on. > > Yes, we should scope this discussion to RW and DPR. This is consistent with > Blink implementation [1], and to keep this thread focused I'll skip the > comments on MD/RQ/etc. That said, happy to discuss those in a separate thread > :) > > On T

Re: [webkit-dev] WTF USE(...) macro

> On Apr 29, 2015, at 9:56 AM, Martin Robinson wrote: > > Hi, please forgive my continuing quest into the realm of small build cleanups. > > We have some handy WTF macros to deal with build variables. For example > > #if ENABLE(WHATEVER) > > will be true if ENABLE_WHATEVER is defined and not

Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

> On Apr 23, 2015, at 1:07 PM, Brady Eidson wrote: > > >> On Apr 21, 2015, at 3:39 PM, Chris Dumez wrote: >> >> Hi, >> >> I would like to suggest we remove support for 'multipart/x-mixed-replace’ >> main resources while keeping support for multipart images. >> >> Based on Chrome usage data

Re: [webkit-dev] Client Hints

23, 2015, at 9:46 AM, Maciej Stachowiak wrote: > >> >> On Apr 23, 2015, at 12:48 AM, Yoav Weiss > <mailto:y...@yoav.ws>> wrote: >> >> Hi, >> >> As I've discussed during my session at the contributor's meetup, I'm >> i

Re: [webkit-dev] Client Hints

> On Apr 23, 2015, at 12:48 AM, Yoav Weiss wrote: > > Hi, > > As I've discussed during my session at the contributor's meetup, I'm > interested in implementing Client-Hints > in WebKit. > > For those unfamiliar with it, Client-Hints is a standa

Re: [webkit-dev] Filling the features.json files

> On Apr 8, 2015, at 5:42 AM, Antti Koivisto wrote: > > On Wed, Apr 8, 2015 at 7:09 AM, Benjamin Poulain > wrote: > Hi WebKit, > > The two features.json files are in the tree (WebCore/features.json and > JavaScriptCore/features.json). The style checker now checks t

Re: [webkit-dev] Please be careful with webkitpy changes!

e touched again — even if the other eight EWS bots are sitting dormant. > > Is there some other processing metric you are concerned about? > >  Brent Fulgham - Apple Inc. > > > >> On Apr 1, 2015, at 2:26 PM, Maciej Stachowiak wrote: >> >> >> Is

Re: [webkit-dev] Please be careful with webkitpy changes!

Is it possible to make EWS start processing changes more promptly? > On Apr 1, 2015, at 12:42 PM, Brent Fulgham wrote: > > Hi Everyone, > > We lost Windows EWS coverage for the past 36 hours due to a very > benign-appearing change to some webkitpy code. I haven’t yet figured out why > this p

Re: [webkit-dev] WebCore/platform standalone library

We’ll have times when we need to decide what goes into this library, and what goes into WTF. So I like the ones that fit the sentence “Is this really WTF or is it just __?” LOL, ROFL and ROFLCOPTER work well for this. I would also suggest: Web Abstraction Toolbox (it’s hard to tell the dif

Re: [webkit-dev] WebCore/platform standalone library

> On Mar 19, 2015, at 5:19 PM, Anders Carlsson wrote: > > >> On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote: >> >> This almost makes me want to suggest a jokey name for Platform. I can’t off >> the top of my head

Re: [webkit-dev] WebCore/platform standalone library

gt; Saam > > > On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak <mailto:m...@apple.com>> wrote: > > > > On Mar 19, 2015, at 1:47 PM, Benjamin Poulain wrote: > > > > On 3/18/15 9:43 PM, Myles C. Maxfield wrote: > >> Hello, all, >

Re: [webkit-dev] WebCore/platform standalone library

> On Mar 19, 2015, at 1:47 PM, Benjamin Poulain wrote: > > On 3/18/15 9:43 PM, Myles C. Maxfield wrote: >> Hello, all, >> >> I’d like to announce that I intend to create a standalone static library >> from the current contents of WebCore/platform over the coming months. This >> will involve c

Re: [webkit-dev] NEON_INTRINSICS

features we remove all the time. This > simple valuable code that happen to be untested because of the lack of ARMv7 > infrastructure on the public bots. > > Regarding maintenance, I'd be happy to fix bugs in that code. > > Benjamin > > On 3/9/15 11:34 AM, Maciej Sta

Re: [webkit-dev] NEON_INTRINSICS

Requiring a perf bot to be set up before removing unmaintained code seems like a really high bar. What would it take to do a one-shot test of whether NEON_INTRINSICS is a perf benefit? Would it show up on PLT or on JS perf benchmarks if you compiled with it? If it’s not a speedup in its existin

Re: [webkit-dev] Request for intuition: should switch statements be faster for the default case, or the explicit cases?

In case you still want an answer to the original question - I would expect good programming practice to be that you explicitly list all your relevant cases in a switch statement, so hitting default should never happen or should be a rare exception. But I don’t know if real programs are like tha

Re: [webkit-dev] Pattern for singleton classes instance getters

; be my preference. > > Kr, > -- > Chris Dumez - Apple Inc. > Cupertino, CA > >> On Jan 28, 2015, at 8:44 PM, Michael Catanzaro > <mailto:mcatanz...@igalia.com>> wrote: >> >> On Wed, Jan 28, 2015 at 8:11 PM, Maciej Stachowiak > <mail

Re: [webkit-dev] Pattern for singleton classes instance getters

> On Jan 28, 2015, at 4:28 PM, Darin Adler wrote: > > I like the economy of the smaller non-member function name; it seems overly > wordy to be constantly stating the class name as well as the nearly > meaningless word “shared”. I think the word “shared” is what I like least > about the membe

Re: [webkit-dev] Pattern for singleton classes instance getters

Perhaps we should document this in the coding style guidelines. I like consistency and static member function seems like a good way to go, particularly since it matches the Class::create() pattern we often use for non-singletons. > On Jan 28, 2015, at 12:10 PM, Ryosuke Niwa wrote: > > Class:

Re: [webkit-dev] review times

> On Dec 3, 2014, at 9:56 AM, Alexey Proskuryakov wrote: > > > 03 дек. 2014 г., в 2:32, Daniel Lazarenko написал(а): > >> Whatsoever it would be nice find a new reviewer for my patch. Does anybody >> want to take it? > > Just to be clear about this part, the reviewer should not be just "any

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

> On Nov 20, 2014, at 4:51 PM, Maciej Stachowiak wrote: > >> >> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote: >> >> >> 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov > <mailto:a...@webkit.org>>

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov wrote: > > > 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov > написал(а): > >> These and related uses are all over the place - see also Vectors in >> FormDataBuilder, data returned from FrameLoader::loadResourceSynchr

Re: [webkit-dev] Networking process scope

Sent from my iPad > On Nov 10, 2014, at 4:28 AM, youenn fablet wrote: > > Hi, > > I looked at the Networking process recently and am wondering what is > in scope/out of scope of this process. > > Currently, the networking process is used to load resources from: > - URLs resolved using platf

Re: [webkit-dev] Tagged assertions...

I appreciate that you’re thinking through how to solve the problem of matching bug reports to assertions in a general way. In my own experience, matching the bug to the right assertion is not that common a problem. I agree with others that most of the time, the function name, line number and

Re: [webkit-dev] SIMD support in JavaScript

Dan, you say that SIMD.js delivers performance portability, and Nadav says it doesn’t. Nadav’s argument seems to come down to (as I understand it): - The set of vector operations supported on different CPU architectures varies widely. - "Executing vector intrinsics on processors that don’t sup

Re: [webkit-dev] SIMD support in JavaScript

We will probably bring it up on es-discuss once we’ve had a chance to discuss it among WebKit folks. - Maciej > On Sep 28, 2014, at 8:39 AM, Anne van Kesteren wrote: > > Could this thread maybe be moved to es-discuss? > ___ > webkit-dev mailing lis

Re: [webkit-dev] FeatureDefines.h and .xcconfig

> > > (*) I think Apple's Windows port should probably continue with > FeatureDefines.h because it doesn't use Xcode. BTW, the canonical place (I think) for feature flags for the Windows port is in WebKitLibraries/win/tools/vsprops. Confusion about where the feature flag settings go for diff

Re: [webkit-dev] FeatureDefines.h and .xcconfig

> On Aug 6, 2014, at 2:22 PM, Dean Jackson wrote: > > Hi floks, > > Things are a bit confusing in the OS X and iOS build configurations because > we have both a FeatureDefines.h and a set of .xcconfig files, often defining > the same thing, and sometimes inconsistently (or at least I've made

Re: [webkit-dev] Swift in WebKit

> On Jul 28, 2014, at 8:44 PM, David Farler wrote: > > On Jul 28, 2014, at 17:10, Ryosuke Niwa wrote: > >> > >> In particular see Maciej's response in >> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html. > > From the second e-mail: > > "In conclusion, I think we sho

Re: [webkit-dev] Comment on the bug & email author/reviewer before reverting a patch

> On Jul 9, 2014, at 7:46 PM, Ryosuke Niwa wrote: > > On Wed, Jul 9, 2014 at 7:25 PM, Maciej Stachowiak wrote: > > What things need to be done in addition to using 'webkitbot rollout’ to meet > a sufficient standard of notification? I assume based on your comments tha

Re: [webkit-dev] Comment on the bug & email author/reviewer before reverting a patch

> On Jul 9, 2014, at 4:45 PM, Ryosuke Niwa wrote: > > On Wednesday, July 9, 2014, Brady Eidson wrote: > >> On Jul 9, 2014, at 4:15 PM, Ryosuke Niwa wrote: >> >> Again, im not requesting anything new here. The consensus on webkit-dev has >> been to ping the author/reviewer on IRC or via ema

Re: [webkit-dev] Comment on the bug & email author/reviewer before reverting a patch

Could we teach webkitbot to do an appropriate notification with a waiting period? Either as part of rollout or add a new command to do it. - Maciej > On Jul 9, 2014, at 11:40 AM, Ryosuke Niwa wrote: > > Yes. The point is to do these things before telling webkitbot to rollout a > patch. >

Re: [webkit-dev] Picture element implementation

In fairness I should note that enabling by default in nightlies doesn’t necessarily mean anyone will ship it right away. But it’s still a good thing to do to get better test coverage. - Maciej > On Jul 1, 2014, at 1:26 PM, Benjamin Poulain wrote: > > The barrier on entry is rather low to en

Re: [webkit-dev] Drop EFL WK1 port

> On Jun 19, 2014, at 7:07 AM, Darin Adler wrote: > > On Jun 19, 2014, at 5:27 AM, pulkomandy wrote: > >> Should existing WebKit ports that are WK1 based consider switching to WK2? > > Yes. > > WK1 will be around for the foreseeable future because, on both Mac and iOS, > it’s part of the pu

Re: [webkit-dev] CDMi interface for EME?

> On Jun 10, 2014, at 11:40 AM, Brendan Long wrote: > > > On 06/10/2014 12:51 PM, Maciej Stachowiak wrote: >> But I don’t think we’d want to support pluggable CDMs as an extension point >> on any of Apple’s ports (which is the whole point of CDMi), only the ones we &g

Re: [webkit-dev] CDMi interface for EME?

> On Jun 10, 2014, at 8:39 AM, Jer Noble wrote: > > >> On Jun 9, 2014, at 3:56 PM, Brendan Long wrote: >> >> I'm looking into EME and something I've been asked to investigate is >> Microsoft's proposed CDMi interface, and if we could use it in WebKit. The >> idea is that we would expose a f

Re: [webkit-dev] Exposing WebKit/Safari's unique full keyboard access setting to web applications

If we propose a way for web apps to detect the platform focus cycle behavior, it should be proposed as a standard. I would not want to add a proprietary eternally vendor-prefixed feature just for this. Regards, Maciej On May 12, 2014, at 6:44 PM, James Craig wrote: > WebKit Dev, > > Safari

Re: [webkit-dev] Style proposal for branch style for macros

On Apr 20, 2014, at 1:32 PM, Mark Rowe wrote: > > It’s also not possible to determine from context alone whether #if or if > should be used. When #if is used to remove members or functions you’re then > forced to use #if, rather than if, around all uses of those members or > functions since

Re: [webkit-dev] Style proposal for branch style for macros

On Apr 20, 2014, at 1:19 PM, Mark Rowe wrote: > > > Won’t compile: > > if (!MAYBE_DEFINED) { > … > } > > if (SOMETHING) { > void doSomething() { } > } > > if (SOMETHING) { > #include “Something.h" > } > > > Will result in unintended behavior: > > if (!FOO) { > … > #define

Re: [webkit-dev] DerivedSources.make: Another try?

On Mar 16, 2014, at 11:06 AM, Patrick Gansterer wrote: > > On 16.03.2014, at 18:50, Filip Pizlo wrote: > >> This discussion about DerivedSources is too abstract for me. >> >> If the only thing that DerivedSources.make looks for is python, perl, and >> ruby, then there has got to be a way f

Re: [webkit-dev] DerivedSources.make: Another try?

On Mar 16, 2014, at 8:18 AM, Patrick Gansterer wrote: > On 16.03.2014, at 16:10, Darin Adler wrote: >> On Mar 16, 2014, at 3:01 AM, Patrick Gansterer wrote: >> >>> a) Invoke make on DerivedSources.make and add a lot of custom target for >>> that to CMake >> >> I’d like to see what this woul

Re: [webkit-dev] Web Components development will continue in a branch in near future

On Feb 18, 2014, at 2:32 PM, Bem Jones-Bey wrote: >> Thanks, Adam. We hope that we will be successful implementing shadow DOM as >> well. >> >> Do you have any more specific pointers that Ryosuke et al could look at for >> the O(N^2) algorithm? Like a commit range or a function to look at? >

Re: [webkit-dev] Web Components development will continue in a branch in near future

On Feb 18, 2014, at 7:44 AM, Adam Barth wrote: > Hi Ryosuke, > > On Sat, Feb 15, 2014 at 4:07 PM, Ryosuke Niwa wrote: > Now that we've removed all of the existing shadow DOM implementations from > trunk in http://trac.webkit.org/changeset/164131, I'm intending to work on > new web components

Re: [webkit-dev] On web-exposing features disabled at runtime

On Feb 11, 2014, at 10:25 AM, Benjamin Poulain wrote: > On 2/11/14, 9:26 AM, Maciej Stachowiak wrote: >> On Feb 10, 2014, at 1:38 PM, Benjamin Poulain >> wrote: >>> >>> Can't we add a compile time flag instead? The chromium patch you >>> li

Re: [webkit-dev] On web-exposing features disabled at runtime

On Feb 10, 2014, at 1:38 PM, Benjamin Poulain wrote: > > Can't we add a compile time flag instead? > The chromium patch you linked is inelegant and it touches some hot paths. > > Another advantage of compile time flag is Andreas eventually notice when they > become useless and remove all the

Re: [webkit-dev] On web-exposing features disabled at runtime

On Feb 10, 2014, at 10:40 AM, Sergio Villar Senin wrote: > Hi folks, > > I'm sending this to the list because it might affect different > components inside the project. > > So as smfr correctly reported here[1] for all those features that don't > have a feature flag (like grid layout) we're we

[webkit-dev] Feature Announcement: URL API

Hi everyone, I would like to implement the URL API from the WHATWG URL spec, described here: http://url.spec.whatwg.org/#api I have a preliminary patch (not ready for review yet; needs tests and fixing build on other platforms) here: https://bugs.webkit.org/show_bug.cgi?id=127795 The patch imp

Re: [webkit-dev] Make accelerated compositing mandatory

ENABLE(DECELERATED_COMPOSITING) On Jan 28, 2014, at 10:15 AM, Darin Adler wrote: > If we can’t drop the non-accelerated-compositing mode immediately, I think > that non-accelerated-compositing should be the one that is treated as an > exception and be renamed to use the word “deprecated”. >

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

On Jan 11, 2014, at 3:50 PM, Darin Adler wrote: > > On Jan 11, 2014, at 3:36 PM, Maciej Stachowiak wrote: > >> >> Ideally it should be USE(THE_SPECIFIC_FRAMEWORK_IN_QUESTION). I would guess >> that much of PLATFORM(MAC) that is valid for both Mac and iOS

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

Ideally it should be USE(THE_SPECIFIC_FRAMEWORK_IN_QUESTION). I would guess that much of PLATFORM(MAC) that is valid for both Mac and iOS should actually be USE(FOUNDATION). PLATFORM really shouldn't be used for things other than terminal platform names. USE(COCOA) would be an ok stopgap if sor

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Jan 6, 2014, at 3:34 PM, Darin Adler wrote: > > On Jan 6, 2014, at 1:49 PM, Geoffrey Garen wrote: > >> FunctionParameters::FunctionParameters(ParameterNode* firstParameter, >> unsigned size) >> : m_size(size) >> { >> unsigned i = 0; >> for (ParameterNode* parameter = firstPara

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Jan 4, 2014, at 7:14 AM, Alex Christensen wrote: > Call me an extremist, but I would be in favor of a complete ban on auto. I'm not totally sold on using it almost everywhere, but auto is clearly a win for types that are obnoxiously long to spell but rarely interesting per se, such as ite

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Jan 3, 2014, at 10:11 AM, Alexey Proskuryakov wrote: > >> It might also cover smart pointer usage like your example and multiline >> expansions of setSize(foo->size()). >> >> - Use "auto" when type is obvious for people with basic familiarity with a >> subsystem: >> >> auto& style = rend

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Jan 2, 2014, at 2:48 PM, Filip Pizlo wrote: > I think that this article is one of many great examples of arguments in favor > of less explicit typing. These lines of reasoning are often used by > proponents of both dynamic languages (like Ruby) and type-inferred languages > (like ML or Ha

Re: [webkit-dev] Introducing RenderPtr!

If we comprehensively deploy smart pointers in place of raw pointers and manual memory management, then yes. The render tree does have places where non-owning references are held, and these can be some of the biggest security risks. One notable example is the m_floats member in RenderInlineBox

Re: [webkit-dev] The SrcN responsive images proposal

On Nov 8, 2013, at 9:06 AM, John Mellor wrote: > Most discussion so far seems to be bikeshedding the syntax. To make this more > productive, can we focus on the core issues? > > srcN brings two things to the table, compared to srcset: > 1. It handles viewport-switching better (easier to author

Re: [webkit-dev] The SrcN responsive images proposal

On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. wrote: > On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher wrote: >> As I replied before, there should only be one attribute — srcset. > > I have a serious suggestion - could we rename srcset to src-n > (literally, "src-n"), and then just ship it? This

Re: [webkit-dev] The SrcN responsive images proposal

> On Nov 7, 2013, at 4:27 PM, "Tab Atkins Jr." wrote: > >> On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher wrote: >>> On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. wrote: >>> srcset's parsing algorithm *cannot* be extended in the future. I gave >>> an example of how it would fail over on blink-d

Re: [webkit-dev] The SrcN responsive images proposal

On Nov 6, 2013, at 10:53 AM, John Mellor wrote: > On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak wrote: > > > > My initial impression is that it seems a bit overengineered. > > I sympathize. The issue of srcN appearing to be a complex solution to a > seemingl

Re: [webkit-dev] The SrcN responsive images proposal

On Oct 24, 2013, at 1:35 AM, Michael[tm] Smith wrote: > Ryosuke Niwa , 2013-10-23 13:22 -0700: > >> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: >>> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an

Re: [webkit-dev] The SrcN responsive images proposal

On Oct 23, 2013, at 11:24 PM, Yoav Weiss wrote: > > On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa wrote: > On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: > On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto wrote: > > Ignoring other aspects of this, the idea of making attribute name a

Re: [webkit-dev] The SrcN responsive images proposal

On Oct 22, 2013, at 1:50 PM, Tab Atkins Jr. wrote: > On Sat, Oct 19, 2013 at 7:00 PM, Maciej Stachowiak wrote: >> My initial impression is that it seems a bit overengineered. > > Can you elaborate on these concerns? - The syntax is effectively a list of lists, the outer level

Re: [webkit-dev] The SrcN responsive images proposal

My initial impression is that it seems a bit overengineered. - Maciej > On Oct 19, 2013, at 4:39 PM, Yoav Weiss wrote: > > Hello WebKiteers, > > I'd like to get the project's opinion on a recent responsive image proposal > by Tab Atkins dubbed srcN: > http://tabatkins.github.io/specs/respim

Re: [webkit-dev] WTF::fastMalloc

These days, pure JavaScript tests won't do a lot of malloc() calls, so it's more relevant to try a page load speed or DOM benchmark. - Maciej On Oct 4, 2013, at 6:10 AM, Osztrogonác Csaba wrote: > Hi, > > As Zoltan said this feature was introduced for Qt port. But now > EFL, GTK and Nix use

Re: [webkit-dev] WTF::fastMalloc

On Oct 2, 2013, at 2:41 AM, Andy Wingo wrote: > >> We need somebody to resolve these issues, otherwise our memory >> footprint will be unacceptably high, and/or our VM operations will be >> unacceptably slow. > > There is no memory footprint problem caused by mmap here -- to my > knowledge. I

Re: [webkit-dev] WTF::fastMalloc

On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev wrote: > > 02.10.2013, 03:18, "Zoltan Horvath" : >> On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen wrote: So are you proposing to use the system allocator on Windows? >>> >>> I’m proposing a two step process: >>> >>> (1) Use the system allo

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

Sounds ok to add it prefixed. - Maciej On Oct 1, 2013, at 4:53 PM, James Craig wrote: > Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should > we temporarily use “-webkit-alt” for the property name? I know there has been > a push to move away from vendor prefixes la

Re: [webkit-dev] WTF::fastMalloc

On Oct 1, 2013, at 3:47 PM, Geoffrey Garen wrote: >>> To access thread-specific data using pthreads, you first need to take a >>> lock and call pthread_key_create(). Since the whole point of >>> thread-specific data is to avoid taking a lock, the API is useless. >> >> The normal way to do it

Re: [webkit-dev] WTF::fastMalloc

On Oct 1, 2013, at 3:11 PM, Geoffrey Garen wrote: >>> (4) Find a fast API for aligned virtual memory allocation. >>> (5) Find a fast API for committing / decommitting physical memory without >>> releasing virtual memory pages. >> >> Hrm. Isn't this already available via OSAllocator or are you

Re: [webkit-dev] WTF::fastMalloc

On Oct 1, 2013, at 3:05 PM, Geoffrey Garen wrote: >>> (3) Find a fast thread-specific data API on the canonical GTK platform. >> >> Threading for GTK+ on non-Mac/non-Windows platforms is essentially >> pthreads. > > To access thread-specific data using pthreads, you first need to take a lock

Re: [webkit-dev] WTF::fastMalloc

On Oct 1, 2013, at 3:35 PM, Brent Fulgham wrote: > So are you proposing to use the system allocator on Windows? Or would we keep > using the existing FastMalloc implementation? > > The current malloc logic has been the source of a number of mysterious > crashes on Windows, so reverting to the

Re: [webkit-dev] WTF::fastMalloc

On Sep 30, 2013, at 2:48 PM, Geoffrey Garen wrote: > Hi folks. > > I’m planning to remove our years-out-of-date port of TCMalloc, and replace it > with something that takes maximum advantage of Mac and iOS virtual memory, > threading, and security APIs. > > I've heard that TCMalloc has cause

Re: [webkit-dev] Proposed feature: Network Service Discovery

I also don't think it should be added to WebKit. In addition to other reasons stated, the spec has obvious severe security risks which are not adequately addressed by a permissions dialog. Section 7 of the spec allows a webpage to bypass the same-origin security model to communicate with "dis

Re: [webkit-dev] Removing DIALOG_ELEMENT for now

On Aug 29, 2013, at 1:13 PM, Darin Adler wrote: > On Aug 29, 2013, at 1:11 PM, James Craig wrote: > >> @inert represents a subset of the implementation of > > OK. Sounds like we can do that first, then. They share mechanism, not API, so it's not really strictly a subset. (Showing a makes

Re: [webkit-dev] Implementing object-fit

Is the implementation likely to be correct enough that we wouldn't risk locking in buggy behavior? - Maciej On Aug 26, 2013, at 4:23 PM, Simon Fraser wrote: > Support for CSS object-fit has landed in Blink (runtime-enabled)[1] and I’d > like to land it in WebKit[2]. > > The spec[3] is at C

Re: [webkit-dev] ChangeLog format

On Aug 22, 2013, at 12:48 AM, Mark Rowe wrote: > > On 2013-08-22, at 12:46 AM, Carlos Garcia Campos wrote: > >> El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió: >>> On 2013-08-21, at 11:11 PM, Carlos Garcia Campos >>> wrote: >>> I see, I thought ChangeLog parser was used ever

Re: [webkit-dev] ChangeLog format

>From the new format, I like the shorter bug URL and the angle brackets, but I >don't care much either way about putting the bug URL and title on the same >line. One downside though is that, if you're composing a ChangeLog more manually, it's more awkward to construct the new-style URL since y

Re: [webkit-dev] Is anyone maintaining media source API in WebKit?

On Jul 12, 2013, at 11:24 PM, Ryosuke Niwa wrote: > Hi, > > I've noticed that we have media source API implemented under > Source/WebCore/Modules/mediasource/ behind MEDIA_SOURCE build flag. > > There has been patches like > https://chromium.googlesource.com/chromium/blink/+/5ab5f366cf981f30

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

On Jul 1, 2013, at 7:31 PM, Brady Eidson wrote: > > On Jul 1, 2013, at 5:27 PM, Ryosuke Niwa wrote: > >> I concur. Maybe >> StyleResolver* styleResolverIfExists() >> StyleResolver& styleResolver() >> ? > > I concur with this. > > For this entire discussion, this is where I was hoping it wa

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

On Jun 19, 2013, at 4:22 PM, Elliott Sprehn wrote: > > On Wed, Jun 19, 2013 at 9:46 AM, Andreas Kling wrote: > On Jun 19, 2013, at 6:37 PM, Timothy Hatcher wrote: > >> What about? >> >> StyleResolver* existingStyleResolver() >> StyleResolver& styleResolver() > > > This doesn't make sense

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa wrote: > On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser wrote: >> On Jun 18, 2013, at 7:11 PM, Darin Adler wrote: >> >>> On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa wrote: >>> Why don't we call it requireStyleResolver() instead? >>> >>> I’m warm

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

If the semantic is essentially that of a getter that just happens to lazily create what it gets on demand, then I don't think "require" or "required" is needed. It can just be named as a getter. If the side effect is very important and especially if clients ever call the function only for its si

Re: [webkit-dev] Adding document.currentScript to WebCore

Sounds good to me. - Maciej On Jun 17, 2013, at 1:24 AM, Kangil Han wrote: > Hi webkit-dev! > I wanted to let you know that I plan to add document.currentScript attribute > support to WebKit. > > At this moment, it’s been supported in chrome and firefox. > You can find this attribute detai

Re: [webkit-dev] When should I use AtomicString vs String?

On Jun 2, 2013, at 3:49 AM, Glenn Adams wrote: > > On Sun, Jun 2, 2013 at 2:48 AM, Maciej Stachowiak wrote: > > On Jun 1, 2013, at 8:54 PM, Glenn Adams wrote: >> You guys obviously never wrote any Lisp code. > > Um, why do you think I suggested "Symbol&qu

Re: [webkit-dev] When should I use AtomicString vs String?

On Jun 1, 2013, at 8:54 PM, Glenn Adams wrote: > You guys obviously never wrote any Lisp code. Um, why do you think I suggested "Symbol"? On Jun 1, 2013, at 9:09 PM, Glenn Adams wrote: > Seriously, if "Atomic" isn't jargon, Intern isn't either. Both are jargon. "Atom" and "Intern" in var

Re: [webkit-dev] When should I use AtomicString vs String?

On Jun 1, 2013, at 3:58 PM, Darin Adler wrote: > On May 31, 2013, at 8:01 PM, Glenn Adams wrote: > >> One thing that always threw me was the term "Atomic" in the class name. I >> wonder if the term "InternedString" would make it usage more apparent. > > I personally love the name AtomicStrin

Re: [webkit-dev] Ref counting questions

We could probably phase out TreeShared if we were really careful to avoid refcount thrash during tree construction/manipulation. I believe this can be done with careful use of PassRefPtr and swap() and it would likely be easier to understand if Nodes normally had a refcount of 1 instead of 0.

Re: [webkit-dev] Moving WebCore/accessibility code into WebCore/platform/

On May 21, 2013, at 7:34 AM, Mario Sanchez Prada wrote: > Hi all, > > Following the discussion in the contributors meeting about layering > violations I was thinking about moving all the accessibility stuff inside > WebCore/accessibility into a new WebCore/platform/accessibility directory. >

Re: [webkit-dev] More C++11 in WebKit2!

On Apr 29, 2013, at 10:33 AM, Anders Carlsson wrote: > > On Apr 28, 2013, at 1:00 PM, Geoffrey Garen wrote: > >> Hi Mikhail. >> >>> In continuation of the topic I'd like also to know people's opinion about >>> Pass*Ptr types deprecation: >> >> I don't think this is appropriate until the co

Re: [webkit-dev] On Safari 5.1.8 for Snow Leopard...

This isn't really a proper forum for this question. This list is for development of WebKit, not discussing the contents of specific vendor releases. For more information on this specific question, you can look at Apple's release notes for 5.1.8, or contact Apple Developer Relations. - Maciej

Re: [webkit-dev] mouseenter and mouseleave events

On Apr 22, 2013, at 3:32 PM, Allan Sandfeld Jensen wrote: > On Wednesday 17 April 2013, Maciej Stachowiak wrote: >> >> Seems like a reasonable feature to add. >> > Would you mind also reviewing the patch in question then or help me find a > reviewer with the r

Re: [webkit-dev] Enabling Experimental Features

On Apr 19, 2013, at 3:50 PM, Timothy Hatcher wrote: > > On Apr 19, 2013, at 6:15 PM, Bear Travis wrote: > >> What do folks think about adding a mechanism for users to toggle features >> like this on in WebKit nightlies? I don't have a definite approach yet, but >> wanted to float the idea f

Re: [webkit-dev] Implement ruby-overhang

Is this behavior change likely to affect any existing Web content, or other important content that uses html ruby markup such as books in EPUB format? - Maciej On Apr 17, 2013, at 12:26 AM, Yuki Sekiguchi wrote: > Hi, > > I'd like to add support for ruby-overhang. > The spec for this featu

Re: [webkit-dev] mouseenter and mouseleave events

On Apr 16, 2013, at 5:08 AM, Allan Sandfeld Jensen wrote: > Hi webkit-dev > > I have recently uploaded a new patch to > https://bugs.webkit.org/show_bug.cgi?id=18930 to implement mouseenter and > mouseleave events. > > These events are part of DOM3 > http://www.w3.org/TR/DOM-Level-3-Events/

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

On Apr 12, 2013, at 10:26 PM, Filip Pizlo wrote: > > You have all of the same problems as with threads and locks. The two are > logically equivalent. You can imagine a lock as being a message queue that > always has a token in it when the lock is unlocked, and the token is read out > to "l

Re: [webkit-dev] Layout Tests and the W3C

On Apr 15, 2013, at 5:31 PM, Dirk Pranke wrote: > Hi all, > > Those of you who are subscribed to blink-dev@ will see that I just sent out a > note entitled "Blink, Testing and the W3C", describing stuff I'm working on > to get the W3C tests running regularly as part of the layout tests. The W

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

On Apr 12, 2013, at 2:13 PM, Filip Pizlo wrote: > > On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote: > >> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote: >> >> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls >> wrote: >> >>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote: >>> >>>

[webkit-dev] C++11 (was Re: on coding-style)

On Apr 12, 2013, at 4:09 PM, Karen Shaeffer wrote: > > Of course, I understand that. But there is a huge opportunity cost to webkit. > The c++11 standard also rewrites the entire standard library. I have been > using > g++ 4.7.2 using -stdc++11 in my work with linux. And the code I have tested

<    1   2   3   4   5   6   7   8   9   10   >