Re: [webkit-dev] Proposal: bundled/vendored code belongs under ThirdParty/

d despite our best intentions, I trash my build repo for one reason or another more often than I would like). - Sam > On Oct 2, 2024, at 6:58 PM, Yusuke Suzuki wrote: > > The question I have is, what is the benefit from this policy change? > > -Yusuke > >> On Oct 1

Re: [webkit-dev] Proposal: bundled/vendored code belongs under ThirdParty/

I think this makes a lot of sense and we should adopt this into the style guidelines. Two additional steps I am curious if we can take are: 1. Moving all, including source currently in WTF and PAL to Sources/ThirdParty. Having a single place seems more straightforward than multiple. Are there

Re: [webkit-dev] Request for position: Canvas 2D display-p3 support

Hi Christopher, We are in favor of this proposal. - Sam > On Jun 9, 2021, at 6:39 PM, Christopher Cameron via webkit-dev > wrote: > > Hi webkit-dev, > > (and sorry for the duplicate post here, I mangled the headers on the previous > post!) > > This is a request for WebKit's position on dis

Re: [webkit-dev] Request for position: preferCurrentTab

Hi Elad, Are there other existing uses of the term “tab” in other web exposed APIs? It feels a bit wrong to be wrong to be encoding that specific UI treatment into API. - Sam > On Jun 9, 2021, at 4:20 AM, Elad Alon via webkit-dev > wrote: > > This is a request for WebKit's position on addin

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

Hi Jer, I think it sounds like a reasonable rule to allow Swift for bridging purposes only, with the caveat that we should prefer Objective-C/C where it can be used. The one other place that Swift seems reasonable for WebKit is in the definition and refinement of Swift bindings to WebKit’s publ

[webkit-dev] Is anyone building with USE(DIRECT2D)?

Hi WebKit-dev, Is anyone still using attempting to build using USE(DIRECT2D) enabled? Recently, I updated files to “keep” it working, but in some I have seen things that obviously wouldn’t compile and think it is probably unmaintained. So is anyone using it? - Sam __

Re: [webkit-dev] New EWS Non-Unified builder

Hi, I am curious about the current state of our knowledge about the various benefits we are gaining from Unified Source. I think it is important to reevaluate it from time to time to ensure we are still getting the benefits we want (as there are some not so insignificant downsides). I know when

Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

Hey Geoff and Chris, > On Dec 1, 2020, at 9:21 AM, Geoff Garen via webkit-dev > wrote: > > A few thoughts here: > > 1. It’s not just ref counting. > > To make String thread-safe, you also need to address all other data members. > That means all state in m_hashAndFlags, including the 8bit/16

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

> On Oct 20, 2020, at 3:36 PM, Darin Adler wrote: > >> On Oct 20, 2020, at 3:09 PM, Sam Weinig wrote: >> >> For the Platform.h issue, I think we could probably engineer things in the >> short term to have a script phase that produces a Defines.txt that the oth

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

> On Oct 20, 2020, at 2:25 PM, Keith Rollin wrote: > >> On Oct 20, 2020, at 10:51, Andy Estes wrote: >> >>> On Oct 18, 2020, at 11:01, Sam Weinig wrote: >>> >>> One direct benefit of moving away from DerivedSources.make would likely be >>

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

One direct benefit of moving away from DerivedSources.make would likely be (I say likely, as the details of how it works out are far from certain in my mind) removing at least one place that a IDL file needs to be listed as we would not need to explicitly the list the IDL file in DerivedSources.

Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

> On Oct 17, 2020, at 12:34 PM, Fujii Hironori <mailto:fujii.hiron...@gmail.com>> wrote: > > > On Sun, Oct 18, 2020 at 2:00 AM Sam Weinig <mailto:wei...@webkit.org>> wrote: > > What are your thoughts on this? > > I'm disappointed. I want to

[webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

Hi webkit-dev, I’d like to propose, and gauge feedback on, reducing (with the goal of ultimately removing) the use of Makefile based DerivedSources.make. My understanding is that currently only the Xcode based ports still use DerivedSources.make, as all the CMake based ones have moved derived s

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

While I don’t want to take away from what Darin is saying here about correct usage of forward declaration and , I’d like to understand why we have two different compilation models supported in WebKit. Is there a reason both need to be supported? Can we remove one? - Sam > On Jul 14, 2020, at 1

Re: [webkit-dev] C++17 is here. Should we use it?

> On Jun 17, 2019, at 8:45 AM, Guillaume Emont wrote: > > Quoting Sam Weinig (2019-06-17 03:25:15) >> Did we ever land on conclusion here? >> >> I tried to use c++17 structured bindings (see >> https://bugs.webkit.org/show_bug.cgi?id=198905 >> &

Re: [webkit-dev] C++17 is here. Should we use it?

Did we ever land on conclusion here? I tried to use c++17 structured bindings (see https://bugs.webkit.org/show_bug.cgi?id=198905) and it looks like most of the EWS bots are ok with it, but the jsc-mips and jsc-armv7 bots are not into it. Looking at the output, it seems like those bots may st

Re: [webkit-dev] Reminder regarding formatting uint64_t

> On Feb 27, 2019, at 6:46 PM, Michael Catanzaro wrote: > > On Wed, Feb 27, 2019 at 6:05 PM, Keith Rollin wrote: >> The underlying Cocoa os_log facility > > Yeah this is really interesting too. RELEASE_LOG is Cocoa-specific, because > it's only backed by os_log. So when you change debug LOG

Re: [webkit-dev] Reminder regarding formatting uint64_t

> On Feb 27, 2019, at 4:05 PM, Keith Rollin wrote: > >> On Wed, Feb 27, 2019 at 2:36 PM Michael Catanzaro >> wrote: >> Hi, >> >> For the past several years, I've been regularly fixing -Wformat >> warnings that look like this: >> >> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46

Re: [webkit-dev] Encoding and decoding ProcessID

> On Feb 24, 2019, at 11:55 AM, Adrien Destugues > wrote: > > On Sun, Feb 24, 2019 at 10:52:53AM -0800, Sam Weinig wrote: >> Hi Adrien, >> >> Would you mind adding the compiler output when this happens? I’d like to see >> exactly what the error you ar

Re: [webkit-dev] Encoding and decoding ProcessID

Hi Adrien, Would you mind adding the compiler output when this happens? I’d like to see exactly what the error you are seeing is. - Sam > On Feb 24, 2019, at 9:54 AM, Adrien Destugues > wrote: > > Hi there, > > We are finally starting to look into moving the Haiku port to WebKit2. > > We

[webkit-dev] Remove Credential Management code

Hey gang, I’d like to propose removing the Credential Management code from WebCore. Work began on supporting this spec in January of this year, but so far, only IDLs and stubs have been added. In May, there was an effort to update the IDLs and stubs to the latest spec (https://webkit.org/b/17

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

> On Aug 29, 2017, at 6:36 PM, Maciej Stachowiak wrote: > > > >> On Aug 29, 2017, at 5:54 PM, Sam Weinig > <mailto:wei...@apple.com>> wrote: >> >> >> >>> On Aug 29, 2017, at 12:46 PM, Geoffrey Garen >> <mailto:gga...@app

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

> On Aug 29, 2017, at 12:46 PM, Geoffrey Garen wrote: > >> This isn’t the scenario I find myself in most often. A much more common >> scenario is working on a change; touch one or two files, and then compile >> and test/debug. Rinse and repeat. > > We’ve already tested this case. The worst

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

> On Aug 29, 2017, at 11:03 AM, Geoffrey Garen wrote: > >> I worry about adopting unity build because while it makes clean builds >> faster, it also slows down incremental builds. As a developer, I rarely do >> clean builds, I mostly do incremental builds so this would likely make my >> expe

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

> On Aug 1, 2017, at 6:57 AM, Dean Jackson wrote: > > > >> On 24 Jul 2017, at 22:44, Brian Burg wrote: >> >> Hi WebKittens, >> >> In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, >> and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag. >> >>

Re: [webkit-dev] Using "auto -> returnType" breaks prepare-ChangeLog

> On Jul 28, 2017, at 11:13 AM, Maciej Stachowiak wrote: > > > >> On Jul 28, 2017, at 10:58 AM, Sam Weinig > <mailto:wei...@apple.com>> wrote: >> >> >> >>> On Jul 28, 2017, at 10:31 AM, JF Bastien >> <mailto:jfbast...@app

Re: [webkit-dev] Using "auto -> returnType" breaks prepare-ChangeLog

> On Jul 28, 2017, at 10:57 AM, Brady Eidson wrote: > >> >> On Jul 28, 2017, at 10:29 AM, Sam Weinig > <mailto:wei...@apple.com>> wrote: >> >> For some generic programming, this form can be dramatically shorter: >> >> e.g. &

Re: [webkit-dev] Using "auto -> returnType" breaks prepare-ChangeLog

> On Jul 28, 2017, at 10:31 AM, JF Bastien wrote: > > > >> On Jul 28, 2017, at 10:29, Sam Weinig > <mailto:wei...@apple.com>> wrote: >> >> For some generic programming, this form can be dramatically shorter: >> >> e.g. >> >

Re: [webkit-dev] Using "auto -> returnType" breaks prepare-ChangeLog

For some generic programming, this form can be dramatically shorter: e.g. template template ALWAYS_INLINE auto HashMap::inlineAdd(K&& key, V&& value) -> AddResult { return m_impl.template add>(std::forward(key), std::forward(value)); } vs. template template ALWAYS_INLINE typename HashMap::

Re: [webkit-dev] "ReflectOnly" IDL equivalent

> On Jun 10, 2017, at 3:41 PM, Maciej Stachowiak wrote: > > > > On Jun 9, 2017, at 10:08 PM, Chris Dumez <mailto:cdu...@apple.com>> wrote: > >> >>> On Jun 9, 2017, at 11:47 AM, Sam Weinig >> <mailto:wei...@apple.com>> wrote: >

Re: [webkit-dev] "ReflectOnly" IDL equivalent

> On Jun 2, 2017, at 11:32 AM, Ryosuke Niwa wrote: > > On Fri, Jun 2, 2017 at 9:18 AM, Chris Dumez wrote: >> Hi, >> >> No, I do not believe WebKit supports ReflectOnly and this is not standard >> IDL either. >> >> The way to do it in WebKit would be to use a regular DOMString attribute, as >

Re: [webkit-dev] Another WPT bite

> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov wrote: > > >> 12 мая 2017 г., в 14:38, Sam Weinig > <mailto:wei...@apple.com>> написал(а): >> >> I regret piling on here, as I think this thread has diverged from it’s >> original purpose,

Re: [webkit-dev] Another WPT bite

> On May 12, 2017, at 2:10 PM, Simon Fraser wrote: > > >> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov > > wrote: >> >> >>> 12 мая 2017 г., в 11:52, Ben Kelly >> > написал(а): >>> >>> On Fri, May 12, 2017 at 2:26 PM, Rick Byers >>

Re: [webkit-dev] Another WPT bite

> On May 8, 2017, at 9:31 PM, youenn fablet wrote: > > Hi all, > > Discussing with some WebKittens, testharness.js is more and more used in > WebKit. > Is it time to make testharness.js the recommended way of writing LayoutTests? I am in favor of this. If we simplified the question to some f

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa wrote: > > On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers > wrote: > Chrome ships with a built-in extension that exposes the high-level API (which > I think we all agree is a hack). We recently had this discussion >

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

> On Feb 22, 2017, at 5:52 AM, Jacob Greenfield wrote: > > I’m working on adding support to WebKit for FIDO U2F (JS API: > https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html > Architecture overview: > https://fidoalliance.org/specs/fido-u2f-

Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

👍👍 It should probably get a parallel page to https://webkit.org/code-style-guidelines/ and be updated with the same type of right / wrong examples. Our of curiosity, other than for features that simply aren’t available in C++ / Objective-C (or vice-versa), are there places where the inspecto

Re: [webkit-dev] Networking proxy on iOS

> On May 22, 2016, at 3:39 PM, Daniel Olegovich Lazarenko > wrote: > > What if I make a bug report in bugzilla about making a design spec of this > feature. I could then write down implementation details options and summarize > all points we've discussed here. Maybe in a form of a google docu

Re: [webkit-dev] Which bugzilla component should be used for bmalloc?

I agree. I added the bmalloc component. Let me know if there are any problems with it. - Sam > On Feb 23, 2016, at 11:36 AM, saam barati wrote: > > I also came across this when doing a bmalloc patch recently. I think it'd be > useful to have a bmalloc component. > > Saam > >> On Feb 22,

Re: [webkit-dev] Support "registerProtocolHandler" in WebKit2

(Sorry, had this sitting in my drafts). My concern with the registerProtocolHandler() API is that it complicates an already the very complicated area of custom protocols and a good implementation requires configuration UI (to choose which of potentially multiple apps/websites you want a specifi

Re: [webkit-dev] Content-DPR header

> On May 29, 2015, at 2:11 PM, Yoav Weiss wrote: > > On Fri, May 29, 2015 at 8:34 PM, Sam Weinig <mailto:wei...@apple.com>> wrote: > Hi Yoav, > > Can you give a concrete example of when this will be used? I’m having > trouble understanding when an author

Re: [webkit-dev] Content-DPR header

Hi Yoav, Can you give a concrete example of when this will be used? I’m having trouble understanding when an author will want to change an images intrinsic size but not have control of the markup. > On May 29, 2015, at 11:23 AM, Yoav Weiss wrote: > > As a first step towards the Client-Hints

[webkit-dev] Picking a text autosizing implementation

Hi, WebKit currently has two text autosizing implementations, each behind its own ENABLE macro, the IOS_TEXT_AUTOSIZING implementation used on iOS and the TEXT_AUTOSIZING implementation. I would like to bring that number down to one, and compile it everywhere so we can test it on all platforms

[webkit-dev] Removing support for Shared Workers

Hello, I’d like to remove support for Shared Workers. We have not shipped support for Shared Workers in Safari for two releases and have not seen any significant complaints. The code as it currently stands is not a good fit for the WebKit2 architecture, so, if we ever decided Shared Workers

Re: [webkit-dev] Removing webkit prefix from CSS Shapes properties?

Hi Bem, Can you give us an overview of what other browsers have shipped CSS Shapes and how interoperable they are (e.g are they all passing a shared test suite)? -Sam > On Oct 27, 2014, at 11:42 AM, Bem Jones-Bey wrote: > > Hey all, > > Chrome shipped CSS Shapes un-prefixed. The spec has bee

Re: [webkit-dev] Type checking / casting helpers

That also sounds like reasonable behavior for something called cast<>() to me. Sent from my iPhone > On Oct 2, 2014, at 5:01 PM, Benjamin Poulain wrote: > > downcast<> fails if you do a useless cast/upcast. > > Benjamin > >> On 10/2/14, 4:47 PM, Sam Weini

Re: [webkit-dev] Type checking / casting helpers

This all looks wonderful! One question though, why downcast<>(…)? Will we be adding an upcast<>() function? Since the answer is probably no, could we just call this cast<>(…)? - Sam > On Sep 25, 2014, at 11:11 AM, Chris Dumez wrote: > > Hi all, > > I started working on automatically generati

Re: [webkit-dev] Swift in WebKit

On Jul 28, 2014, at 4:38 PM, Geoffrey Garen wrote: >>> (2) The language and implementation are still changing in breaking ways. >> >> Yep, I concede to this. My only question in response is whether it's >> valuable to observe those changes in a project like this or even to use a >> project li

Re: [webkit-dev] Swift in WebKit

Hi David, I think it is a bit too early to start using Swift in WebKit, especially since the language is still evolving. Eventually, I think we should start using it, but I’d like for it to settle a bit before we do. - Sam On Jul 28, 2014, at 12:47 PM, David Farler wrote: > Hello all, > >

[webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

Hello, Is anyone using the LevelDB backend to IndexedDB? - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebKit Contributors Meeting 2014 - UPDATED DATES

Hi all, I’m really sorry abut this, but we have to move the WebKit Contributors Meeting by one day. We previously told you that the meeting will be Monday, April 14th and Tuesday, April 15th but instead it will be Tuesday, April 15th and Wednesday, April 16th. So just to be clear: the new dat

[webkit-dev] Registration is now open for the 2014 WebKit Contributors Meeting!

Hi all, Registration is now open for the 2014 WebKit Contributors Meeting. Sign up at http://www.webkit.org/meeting/! - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebKit Contributors Meeting 2014 - Save the Date

Hi all, Apple will once again be hosting a WebKit Contributors Meeting. This year, it will be held on Apple’s Infinite Loop campus in Cupertino on Monday, April 14th and Tuesday, April 15th. As with the meeting in previous years, this event will have an "unconference"-like format, allowing plen

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

t! Thanks. > > Do you plan to remove ENABLE(SVG_FONTS) as well? Not at this point. -Sam > > > On Tue, Jan 28, 2014 at 4:34 PM, Andreas Kling wrote: > This sounds good to me. > > A WebKit without SVG support is scarcely a WebKit at all. > > On Jan 28, 2014, at 4:13 PM

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

On Jan 28, 2014, at 4:20 PM, Thomas Fletcher wrote: > Not a true statement if you consider out of tree ports. In general, we do not take in consideration ports that don’t contribute back or live in tree. > None of the ports we have done at Crank have used or needed svg support and > as embed

[webkit-dev] Proposal: Remove ENABLE(SVG)

Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I’d like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a “minimal build” working, but I don’t think the clutter of the #ifdefs is w

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

to Bugzilla. > > I do agree that comments about build failures are much less useful. > > - R. Niwa > > > On Wed, Jan 15, 2014 at 7:54 PM, Sam Weinig wrote: > Hi Everyone, > > I am becoming increasingly annoyed by the comments made in bugs.webkit.org > bugs by o

[webkit-dev] Proposal: Stop EWS bot commenting in bugs

Hi Everyone, I am becoming increasingly annoyed by the comments made in bugs.webkit.org bugs by our non-human helpers, the EWS bots. I don’t find the addition of a comment indicating that a patch has failed on a bot, over the existing indication in the bubble, to be worth the noise it creates.

Re: [webkit-dev] Status of the Blackberry port

I’ll take from the silence that there are no parties interested in maintaining the port. I have filed https://webkit.org/b/126715 to track removing it from trunk. Thanks, -Sam On Jan 4, 2014, at 11:21 AM, Sam Weinig wrote: > There hasn’t been a response to this question in many months

Re: [webkit-dev] Status of the Blackberry port

n builds (which makes it really frustrating to > make changes that touch BlackBerry code). > > Looking forward to an update, > - Anders > > On Oct 7, 2013, at 7:04 AM, Eli Fidler wrote: > >> Yes, it's still being maintained by the folks here at BlackBerry. >&

Re: [webkit-dev] Heads-up: ENABLE_GESTURE_EVENTS removal

Sounds good. -Sam On Oct 10, 2013, at 3:18 PM, Anders Carlsson wrote: > Hello, > > I’m planning to remove the ENABLE_GESTURE_EVENTS ifdef and related code. It > was used by Chromium (and perhaps to some extent Qt) as well as WebKit2 for > trackpad events before we switched over to wheel even

[webkit-dev] Status of the Blackberry port

Hello, Can anyone comment on the status of the Blackberry port? Is it still being maintained? -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag

Or better yet, enable it for all ports on ToT. -Sam On Oct 4, 2013, at 11:03 AM, Timothy Hatcher wrote: > Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it? > > I have a legitimate use for -webkit-text-decoration-color that would allow me > to eliminate a hack in the Insp

Re: [webkit-dev] Proposal: Remove DOMFileSystem support

Antonio Gomes noted to me that Ryosuke asked the same question around a month ago and got no objections (https://lists.webkit.org/pipermail/webkit-dev/2013-August/025351.html), so I am going to move forward and remove it. Thanks, -Sam On Sep 29, 2013, at 9:24 PM, Sam Weinig wrote: > Web

Re: [webkit-dev] Type cast by using toFoo()

On Sep 30, 2013, at 3:39 AM, Gyuyoung Kim wrote: > Hello WebKittens, > > I have focused on using toFoo() for SVG and CSS instead of using > static_cast<>. Because I think there are some advantages when we use it. > > - Bad type cast can be detected by using ASSERTION in toFoo(). The toFoo(

[webkit-dev] Proposal: Remove DOMFileSystem support

WebKit, I’d like to remove WebKit’s support for the DOMFileSystem API (which is under the ENABLE(FILE_SYSTEM) #define) due to it being un-maintained and not enabled in any mainline port. DOMFileSystem is not supported by any major browser except Chrome, and I expect WebKit’s future support in

Re: [webkit-dev] Changes in QtWebKit development

Allan, Andreas and Benjamin make good points, care to respond? (Being an active member of this community means responding on this mailing list). -Sam On Sep 14, 2013, at 3:24 AM, Allan Sandfeld Jensen wrote: > On Friday 13 September 2013, Benjamin Poulain wrote: >> >> This is sad. > > Yes

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

I don’t think this belongs in WebKit, as this doesn’t seem like it would ever be appropriate to expose to the Web at large. I recommend trying to find a way to layer this on top of WebKit if it is something you need to support. -Sam On Aug 29, 2013, at 4:19 PM, Brendan Long wrote: > We would

Re: [webkit-dev] Implementing object-fit

Sounds fine to me. -Sam 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 CR, so I’d like to land this unprefixed, and not protected > by ENABLE guards. Does any

[webkit-dev] Proposal: Add support for Promises

Hey WebKittens, I’d like to add support for Promises. Promises are currently specified in the DOM Living Standard (http://dom.spec.whatwg.org/#promises) but will probably be moved to an ECMAScript standard at some point in the future. As such, I plan to implement them in JavaScriptCore. The

[webkit-dev] Proposal: Remove Microdata support

Hello, I’d like to propose removing support for the Microdata JS API (http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html) from WebKit. The specification has not gotten much adoption from either implementors or from site authors. Additionally, its use cases can all be

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

On May 21, 2013, at 10:56 AM, Darin Adler wrote: > On May 21, 2013, at 10:42 AM, Sam Weinig wrote: > >> On May 21, 2013, at 8:15 AM, Darin Adler wrote: >> >>>> Of course, we could always add an exception to the style checker >>> >>> The s

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

On May 21, 2013, at 8:15 AM, Darin Adler wrote: > >> Of course, we could always add an exception to the style checker > > The style checker rule is wrong and should be removed. It’s better to use a > platform abstraction, but a platform #ifdef is also OK. This was something we discussed duri

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

On Apr 13, 2013, at 1:55 AM, Carlos Garcia Campos wrote: > > El vie, 12-04-2013 a las 18:15 -0700, Maciej Stachowiak escribió: >> 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 sta

[webkit-dev] You can now register for the 2013 WebKit Contributors Meeting

Registration is now open for the 2013 WebKit Contributors Meeting. You can register by going to https://www.webkit.org/meeting/. Hope to see you all there! -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/

[webkit-dev] WebKit Contributors Meeting - Save the Date

Hi all, Apple will once again be hosting a WebKit Contributors Meeting. It will be held at the DoubleTree by Hilton Hotel in San Jose on Thursday, May 2nd and Friday, May 3rd. As with the meeting in previous years, this event will have an "unconference"-like format, allowing plenty of time for

Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code

Sounds good to me as well. -Sam On Jan 30, 2013, at 3:54 PM, Nico Weber wrote: > Hi, > > I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, > nobody ever shipped this and nobody intents to. Please speak up if > you'd like that code to stick around. > > Nico > _

Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient

Hi Mario, The motivation of the change was to reduce the chatter between the WebProcess and UIProcess and reduce the amount of knowledge the UIProcess has about the internals of the WebProcess. We will also be removing the UIProcess' notion of the frame tree, for the same reason. Going forwar

Re: [webkit-dev] Constructors for DOM4 Events

Seems fine to me. -Sam On Jan 10, 2013, at 6:36 AM, Kentaro Hara wrote: > At TPAC there was no objection for DOM4 Event constructors (e.g. new > MouseEvent()). > > Now DOM4 Event constructors are on editor's draft: > http://html5labs.interoperabilitybridges.com/dom4events/ > https://dvcs.w3.or

Re: [webkit-dev] Changes to the WebKit2 development process

On Jan 9, 2013, at 8:10 AM, Gustavo Noronha Silva wrote: > On Qua, 2013-01-09 at 12:04 +0200, Thiago Marcos P. Santos wrote: >>> I think the fact that the regular WebKit review process stops at the >>> boundary >>> of WebKit2 should be documented in the WebKit Committers and Reviewer >>> Polic

Re: [webkit-dev] Changes to the WebKit2 development process

I need to edit a WebKit2 file > http://trac.webkit.org/wiki/AddingFeatures#ActivatingafeatureforAutotoolsbasedports > > Does that guideline change? Should I remove the WebKit2 change? > > > On Tue, Jan 8, 2013 at 2:57 PM, Sam Weinig wrote: > Hello webkit-dev, > > We are ma

[webkit-dev] Changes to the WebKit2 development process

Hello webkit-dev, We are making some changes to the development process for WebKit2. These changes were announced to reviewers in advance, and I'd like to share them with you now. WebKit2 has a core set of functionality that is valuable to all ports, and then aspects that are only of limited/s

Re: [webkit-dev] [WK2] WebContext destructor is never triggered on normal exit

for hearing opinions. :) > > - kangil > > From: Sam Weinig [mailto:wei...@apple.com] > Sent: Sunday, August 26, 2012 8:36 AM > To: kangil@samsung.com > Cc: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] [WK2] WebContext destructor is never triggered on &

Re: [webkit-dev] [WK2] WebContext destructor is never triggered on normal exit

I'm not clear on what you mean. A client of WebKit2 release their WKContextRef pointer from atexit() if they wanted to (or in whatever other termination routines they already have), but its not clear to me why the framework should do it for them. We don't do this for any other objects. -Sam

Re: [webkit-dev] Proposal and WIP implementation for refactoring cross thread communication

Function is definitely useful in non-cross thread cases. It is analogous to std::function, and its use cases are very similar. Please don't rename it. -Sam On Aug 15, 2012, at 7:35 PM, Kwonjin Jeong wrote: > I also thought about what you said. But I'm not sure whether WTF::Function > will b

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

On Jun 4, 2012, at 11:07 AM, Adam Barth wrote: > On Mon, Jun 4, 2012 at 10:51 AM, Sam Weinig wrote: > On Jun 3, 2012, at 6:10 PM, Ryosuke Niwa wrote: >> On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth wrote: >> On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa wrote: >> On Sun

Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

On Jun 3, 2012, at 6:10 PM, Ryosuke Niwa wrote: > On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth wrote: > On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa wrote: > On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak wrote: > On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa wrote: >> On Sun, Jun 3, 2012 at 3:5

Re: [webkit-dev] Removing "type" attribute from DOMSelection

Without any data on its usage, I don't support this. -Sam On May 30, 2012, at 9:58 PM, Antaryami Pandia wrote: > Hi , > We plan to remove the "type" attribute from DOM selection. > This attribute is not part of any standard specification and the current > webkit implementation is not consiste

Re: [webkit-dev] webkit2 with v8

Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemen wrote: > On 04/23/2012 11:53 PM, Sam Weinig wrote: >> Hi Balazs, >> >> This is something we don't want at this time. Dealing with V8 in WebCore is &

Re: [webkit-dev] webkit2 with v8

Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are ma

Re: [webkit-dev] CSS3 Selectors3 test suite

On Mar 22, 2012, at 6:41 PM, Ojan Vafai wrote: > I've recently been greening Chromium's expectations for css3/selectors3. ~10% > of these test need interaction (e.g. hovering over a link or selecting text). > Given that this is an imported test suite does it make sense to add the > appropriat

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

Hey Dave, Can you describe the use case for this new property? When would an author use it? -Sam On Mar 22, 2012, at 4:16 PM, David Levin wrote: > Resurrecting a really old thread so continue the conversation now that I'm > hitting this issue :). > > On Mon, Aug 16, 201

[webkit-dev] 2012 WebKit Contributors' meeting

eeting, or about whether this meeting is appropriate for you to attend, you may email me at wei...@apple.com. We hope to see you there! Thanks, Sam Weinig ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote: > I just did a first pass a greening the Chromium Lion bot: > http://trac.webkit.org/changeset/110096. Of these hundreds of tests, ~99% of > them are perfect candidates for being reftests (e.g. they contain one line of > text and a solid box or tw

Re: [webkit-dev] About BrowsingContext and WindowProxy spec

On Mar 7, 2012, at 9:25 PM, Darin Adler wrote: > On Mar 7, 2012, at 9:34 AM, Adam Barth wrote: > >> The WindowProxy is implemented in WebKit using the WindowShell class. > > Idle thought: We might want to consider renaming our WindowShell class > WindowProxy, just to match the HTML specificati

Re: [webkit-dev] Should WebKit require SQLite?

It seems acceptable to me to require SQLite. -Sam On Dec 3, 2011, at 10:47 AM, Ryosuke Niwa wrote: > Hi, > > Recent removal of OFFLINE_WEB_APPLICATIONS flag in > http://trac.webkit.org/changeset/96123 made SQLite a new requirement to port > WebKit. However, there are many operating systems

Re: [webkit-dev] EventConstructors.h

It should long term be generated from the EventInit dictionary IDLs, but it was handy to implement it in a macro based DSL initially. -Sam On Nov 2, 2011, at 11:02 AM, Adam Barth wrote: > This file seems to be growing a list of ever feature in the project: > > Source/WebCore/bindings/generic/

Re: [webkit-dev] Style guide should mention that we don't use anonymous namespace

Another benefit to using the "static" keyword is that you can tell at a glance that the function is internal to the translation unit, while you may not notice the anonymous namespace. -Sam On Oct 19, 2011, at 3:45 PM, Darin Adler wrote: > The guideline is not to disallow anonymous namespaces.

Re: [webkit-dev] Tightening up our include discipline

gt; Adam > On Oct 18, 2011 6:10 PM, "Sam Weinig" wrote: > For the specific case of Event, we do need some sort of poor man's RTTI here > for the sake of the bindings, but we could consider alternatives. Since you > need to identify the subclasses, you need to ei

Re: [webkit-dev] Tightening up our include discipline

For the specific case of Event, we do need some sort of poor man's RTTI here for the sake of the bindings, but we could consider alternatives. Since you need to identify the subclasses, you need to either use many virtual functions, as we do currently for Event, or have some tagging mechanism,

  1   2   3   >