Re: [webkit-dev] WPT import status

This is useful information. It should be documented at https://docs.webkit.org/Infrastructure/WPTTests.html even though it is still work in progress. ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] webkit-unassigned

. > > - Alexey > > 15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev < > webkit-dev@lists.webkit.org> написал(а): > > I check it every day. Can I receive the same mails by setting my user > watching to webkit-unassig...@lists.webkit.org? > > On Sat, D

Re: [webkit-dev] webkit-unassigned

I check it every day. Can I receive the same mails by setting my user watching to webkit-unassig...@lists.webkit.org? On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Hello, > > Does anybody make use of the webkit-unassigned mailing list?

Re: [webkit-dev] Site isolation

I created a pull request of the initial support. https://github.com/WebKit/WebKit/pull/12723 BTW, It'd be nice if you have a design document, and a tracking bug. 2023年3月31日(金) 午前5:16 Fujii Hironori : > Windows port is using GPU process for DOM rendering and layer compositing. > I w

Re: [webkit-dev] Removal of trailing whitespace

I checked the clang-format result of WTF. $ find Source/WTF -name '*.h' -o -name '*.cpp' -exec clang-format -i '{}' ';' Although it doesn't comply with the current WebKit style, it looks good enough to me. By adopting clang-format for the project, we can forget most parts of WebKit style

Re: [webkit-dev] Site isolation

Windows port is using GPU process for DOM rendering and layer compositing. I will do the Windows part of the task. On Fri, Mar 31, 2023 at 4:43 AM Alex Christensen via webkit-dev < webkit-dev@lists.webkit.org> wrote: > The SiteIsolation feature is beginning to work in the simplest of cases, >

Re: [webkit-dev] Proposal on retiring JIT on Windows

It sounds reasonable. I don't object to removing Windows JIT support. How about LLInt? LLInt has some Windows specific code. Can I revert the change if the JSC team breaks Windows port even though we have no EWS nor maintainers? On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev <

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

On Tue, Feb 28, 2023 at 6:22 AM Andres Gonzalez wrote: > > "To use `WeakPtr` or `ThreadSafeWeakPtr`, make the class inherit from > `CanMakeWeakPtr` or `CanMakeThreadSafeWeakPtr`, whichever is > appropriate. Note that classes that want to implement both > `ThreadSafeRefCounted` and

Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

On Tue, Jan 31, 2023 at 8:28 AM Ryosuke Niwa via webkit-dev < webkit-dev@lists.webkit.org> wrote: > > I’ve posted > https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Rules > > Very nice. Can I add the following exception for webkit.UncountedLambdaCapturesChecker rule?

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

On Wed, Jan 25, 2023 at 5:54 AM Michael Catanzaro via webkit-dev < webkit-dev@lists.webkit.org> wrote: > > Thinking about this more, I'm not sure this plan works for WeakPtrs? > Say we have: > > WeakPtr f = /* initialized somehow */; > if (Foo* f = f.get()) > { > // do something > } > > Then we

Re: [webkit-dev] GPU Process on all platforms eventually?

On Fri, Nov 11, 2022 at 2:24 PM Alex Christensen via webkit-dev < webkit-dev@lists.webkit.org> wrote: > I remember several years ago there was a configuration to run WebKit2 > without a network process, which was eventually removed. Given the current > work to make the GPU Process on more

Re: [webkit-dev] Nicks in contributors.json

On Tue, Oct 25, 2022 at 4:11 PM Anne van Kesteren via webkit-dev < webkit-dev@lists.webkit.org> wrote: > > We currently do not surface email addresses on the website, but we > could. Would it make sense to surface just the first email address > listed? > We don't use email addresses usually

Re: [webkit-dev] WebKit Documentation

Why not double-down on WebKit Git repository? The closer the document is to the source code, the easier to keep them up-to-date. We can modify both the source code and the document in a single commit through our review process. Do you plan to shutdown https://trac.webkit.org/wiki ?

Re: [webkit-dev] ChangeLog Deprecation Plans

On Tue, Apr 19, 2022 at 6:55 AM Yusuke Suzuki via webkit-dev < webkit-dev@lists.webkit.org> wrote: > I think this is important. We are using commit message / ChangeLog as a > document tied to the change, and we are writing very detailed description > to make the intention / design of the change

Re: [webkit-dev] Miguel Gomez is now WebKit reviewer

Congrats, Miguel  On Mon, Apr 4, 2022 at 5:43 PM Carlos Garcia Campos via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Hi, > > I'm happy to announce that Miguel Gomez is now WebKit reviewer. Miguel > has a lot of experience in WebKitGTK and WPE graphics, so he is the > perfect reviewer

Re: [webkit-dev] OK to flatten WTF's header directory?

On Fri, Feb 4, 2022 at 8:31 AM Darin Adler via webkit-dev < webkit-dev@lists.webkit.org> wrote: > > Those original forwarding headers were not copies of the headers, they > were simply files “in the right place” with include statements in them. I’m > not sure at what point along the way we

Re: [webkit-dev] Using C++20 in WebKit

On Tue, Dec 7, 2021 at 8:07 AM Alex Christensen via webkit-dev < webkit-dev@lists.webkit.org> wrote: > I’m also excited about using coroutines in WebKit. If there is already a > GCC requirement for using a compiler that supports C++20, is there a reason > not to switch from C++17 to C++20 later

Re: [webkit-dev] WPT first test policy proposal

It sounds a good idea. It'd be nice to be documented in the web site for new contributors. https://webkit.org/testing-contributions/ Do we need another WPT-exemption-reason 'non-standards' for WebKit specific features? I think WPT-exemption-reason should be in the test case rather than

Re: [webkit-dev] Replacing PHP with Python in Layout Tests

On Tue, Feb 2, 2021 at 7:14 AM Jonathan Bedard via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Hello Contributors, > > To help reduce the number of dependencies WebKit’s tools have, I would > like to replace our PHP tests (and resources used by tests) with Python 3 > CGI scripts. I’ve

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

On Sun, Oct 18, 2020 at 2:00 AM Sam Weinig wrote: > > What are your thoughts on this? > I'm disappointed. I want to use CMake for all ports. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

According to this Jonathan's bugzilla comment, a new git repository will be reconstructed. https://bugs.webkit.org/show_bug.cgi?id=214957#c12 It'd be nice if commit-qu...@webkit.org is replaced by real authors. ___ webkit-dev mailing list

Re: [webkit-dev] WebKit Transition to Git

On Tue, Oct 6, 2020 at 12:40 AM Jonathan Bedard wrote: > > That's one solution, but even that is somewhat insufficient because we > don’t want to give someone access to every security issue just to give > access to a single one. One of the solutions we’ve discussed is to migrate > bugs component

Re: [webkit-dev] Could use some help from people who care about the WinCairo port

Please disable the precompiled header for Windows DumpRenderTree at the moment. I'll look into it next Monday. WEBKIT_ADD_PRECOMPILED_HEADER("DumpRenderTreePrefix.h" "win/DumpRenderTreePrefix.cpp" DumpRenderTree_SOURCES) On Sun, Sep 13, 2020 at 7:13 AM Darin Adler wrote: > The patch for this

Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

On Fri, Sep 4, 2020 at 2:56 PM Ryosuke Niwa wrote: > On Thu, Sep 3, 2020 at 10:11 PM Fujii Hironori > wrote: > >> >> On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa wrote: >> >>> Consecutive bit fields must use the same type. >>> >> >> Rende

Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa wrote: > Consecutive bit fields must use the same type. > RenderLayer is mixing bool and unsigned in the consecutive bit fields. They should use only uint8_t, right?

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

I'm glad to hear various opinions. Slack still can't beat mailing lists for technical discussions. On Fri, Jul 17, 2020 at 6:37 AM Adrian Perez de Castro wrote: > Also, some packagers used to carry assorted downstream patches for build > issues related to unification build which have not been

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

On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig wrote: > 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

Re: [webkit-dev] Adrian Perez de Castro is now a WebKit reviewer

Congratulations, Adrian  On Mon, Oct 14, 2019 at 11:57 PM Caio Lima wrote: > Congratulations Adrian! > > Em seg, 14 de out de 2019 às 15:17, Carlos Alberto Lopez Perez < > clo...@igalia.com> escreveu: > >> Hi everyone, >> >> I would like to announce that Adrian Perez de Castro (aperezdc on

Re: [webkit-dev] Moving to Python 3

On Sun, Jul 14, 2019 at 7:44 AM Ryosuke Niwa wrote: > > I don’t think anyone is arguing that we’d eventually need to move to > Python3. I’m arguing that it’s not okay to require random WebKit > contributor to know some obscure python insanity to install Python 3, or > have a script that installs

Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

: > Apple is in the process of bringing up VS2019 now. I would be in favor of > moving the minimum to 3.14 so we can safely support VS2019 compiles. > > -Brent > > On Jun 24, 2019, at 8:21 PM, Fujii Hironori > wrote: > > Hi, > > I'm going to bump cmake_minimum_requi

Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

jsc-i368 EWS is still failing. Who is igalia-jsc-i386-ews bot maintainer? On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori wrote: > Hi, > > I'm going to bump cmake_minimum_required version to 3.10 for > shining new features. > > Bug 199181 – [CMake] Bump cmake_minimum_requir

[webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

Hi, I'm going to bump cmake_minimum_required version to 3.10 for shining new features. Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10 https://bugs.webkit.org/show_bug.cgi?id=199181 GTK and WPE's EWS and BuildBot bots maintainers, could you please update your CMake on your

[webkit-dev] Which WTF headers still should be in C++11?

Hi, wtf/CheckedArithmetic.h has been converted from C++14 to C++11. Bug 195187 – Change CheckedArithmetic to not use std::enable_if_t. https://bugs.webkit.org/show_bug.cgi?id=195187 Which WTF headers still should be in C++11? - Fujii ___ webkit-dev

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

On Fri, Dec 21, 2018 at 5:02 AM Konstantin Tokarev wrote: > > > > On Thu, Dec 20, 2018 at 7:42 AM wrote: > >> In that case, I'll point out that C++ Core Guidelines has a rule > "Virtual functions should specify exactly one of virtual, override, or > final". > >> ( >

Re: [webkit-dev] 'final' class specifier and 'final' method specifier

Thank you very much for the feedbacks. On Thu, Dec 20, 2018 at 4:52 AM Konstantin Tokarev wrote: > > 19.12.2018, 12:53, "Fujii Hironori" : > > I'd like to change this because 'final' doesn't necessarily imply > > 'override'. See the following stackoverflow: &

[webkit-dev] 'final' class specifier and 'final' method specifier

Hi WebKit devs, 'final' keyword can be applied to both a class and a method (non-static member function). I don't know correct terminology for them. I call them 'final' class specifier and 'final' method specifier. I'm now going to update WebKit Code Style Guidelines for using 'final' class

Re: [webkit-dev] Watch out for std::optional's move constructor

On Wed, Dec 19, 2018 at 6:41 AM Konstantin Tokarev wrote: > > I agree that "atomic" part of AtomicString is kinda misleading, however > wiki > explains it all > > https://trac.webkit.org/wiki/EfficientStrings#AtomicStringVSString > > BTW, /me personally didn't know what "interned string" is

Re: [webkit-dev] Watch out for std::optional's move constructor

On Tue, Dec 18, 2018 at 10:21 PM Fujii Hironori wrote: > > On Tue, Dec 18, 2018 at 12:25 PM Ryosuke Niwa > wrote: > >> Also, as Geoff has already pointed out, the behavior of STL doesn't >> prevent us from writing our own template library to always have a very well &

Re: [webkit-dev] Watch out for std::optional's move constructor

On Tue, Dec 18, 2018 at 12:25 PM Ryosuke Niwa wrote: > Also, as Geoff has already pointed out, the behavior of STL doesn't > prevent us from writing our own template library to always have a very well > specified & good state after std::move'ed & its value was move-constructed. > Do you mean

Re: [webkit-dev] Watch out for std::optional's move constructor

On Tue, Dec 18, 2018 at 11:16 AM Maciej Stachowiak wrote: > > Among other things, this allows for a “did anything actually get left > here” check after the function that may or may not move a value. Seems like > an upgrade. > > Don't recommend such checks. It is simply use-after-move. The

Re: [webkit-dev] Watch out for std::optional's move constructor

On Mon, Dec 17, 2018 at 4:55 PM Maciej Stachowiak wrote: > > Maybe there is an option I am missing? Out of these, I think (2) is likely > the best, on the whole. > > Reasonable. But, some classes need to be modification for that. For example, WTF::URL is using default move constructor. I think

Re: [webkit-dev] Watch out for std::optional's move constructor

I've changed my mind. It is ensured std::vector move constructor makes moved value empty. > After the move, other is guaranteed to be empty(). https://en.cppreference.com/w/cpp/container/vector/vector Unfortunately, WTF::Vector move constructor just swaps values. I think this swapping is not a

Re: [webkit-dev] Watch out for std::optional's move constructor

I don't like the proposal because it encourages misuse of move. We can use move only for values about to be destroyed. I like Dan's suggestion. We should use std::exchange or std::optional::swap for the cases. Or, what about adding a new method WTF::Optional::release() for the case?

Re: [webkit-dev] Watch out for std::optional's move constructor

On Sat, Dec 15, 2018 at 8:46 AM Chris Dumez wrote: > > > This is the latest one: https://trac.webkit.org/changeset/239228/webkit > This expression WTFMove(*m_pendingWebsitePolicies) doesn't move std::optional, but moves the content of the std::optional, WebsitePoliciesData. I think your

[webkit-dev] Don Olmstead and Ross Kirsling are now WebKit reviewers

, and send them patches to review. Don and Ross, congratulations.  - Fujii Hironori, Sony Interactive Entertainment Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCorePrefix.h vs. config.h

On Wed, Dec 12, 2018 at 7:07 AM Darin Adler wrote: > > On Dec 9, 2018, at 10:34 PM, Fujii Hironori > wrote: > > > > MSVC has /FI option. > > > > /FI (Name Forced Include File) | Microsoft Docs > > > https://docs.microsoft.com/en-us/cpp/build/referenc

Re: [webkit-dev] WebCorePrefix.h vs. config.h

On Sun, Dec 9, 2018 at 8:22 AM Darin Adler wrote: > Best would be to eliminate “config.h”: Change “config.h” into an empty > file first, then remove all “config.h” includes, and then remove the file. > But to do that, we need to make sure every build system for WebKit supports > prefix headers.

Re: [webkit-dev] Lots of spam on Bugzilla

On Wed, Dec 5, 2018 at 6:30 AM Alexey Proskuryakov wrote: > > What I would want to know is what lures spammers to bugzilla. Perhaps we > can find a way to decrease bugs.webkit.org page rank or whatever makes it > a valuable target. > > What about adding nofollow. Mozilla bugzilla is using

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

On Sat, Nov 17, 2018 at 3:45 AM Ryosuke Niwa wrote: > I think the right macro to use here would have HAVE(ACCESSIBILITY). It > never makes sense to compile out accessibility support if you have the > support in a given platform/port. The question is really whether a given > port / platform has

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

On Thu, Nov 15, 2018 at 12:05 PM Timothy Hatcher wrote: > It wasn’t added for Tesla. But they did build with it disabled at the time > I lasted worked on it. It was a frequent pain point to keep the build > working when AX changes happened. > > For the record, HAVE_ACCESSIBILITY has been

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

On Thu, Nov 15, 2018 at 10:29 AM Ryosuke Niwa wrote: > I think it was added for Telsa's private port. Probably not worth > maintaining the flag if the maintenance cost is high but is it? > No, it isn't high. It is no problem to keep the code. CMake defines the similar name macro

Re: [webkit-dev] Rename wtf/unicode/UTF8.h

Thank you for the feedback, Konstantin and Darin. On Thu, Nov 1, 2018 at 1:52 AM Darin Adler wrote: > > With a few seconds thought I am thinking that maybe UTF8Conversion.h or > UTF8Transcoding.h are possible better ideas for new names. Neither is > completely accurate. If we were going to add

Re: [webkit-dev] Rename wtf/unicode/UTF8.h

Oh no. I didn't know that. Thank you for letting me know. Then, how about ? There is which has '-' in the name. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Rename wtf/unicode/UTF8.h

wtf/unicode/UTF8.h is conflicting with ICU header in MSVC builds. I'd like to rename wtf/unicode/UTF8.h to wtf/unicode/WTFUTF8.h. Any suggestion? Here is ICU's #include "unicode/utf8.h" which happens to include wtf/unicode/UTF8.h

Re: [webkit-dev] WinCairo EWS bot broken?

I apologize for the inconvenience. I'm going to look into it in the following bug ticket. https://bugs.webkit.org/show_bug.cgi?id=187725 -- Fujii ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] Fujii Hironori is now a WebKit reviewer

Thank you very much! I'm honored to become a WebKit reviewer. Fujii 2018年7月15日(日) 2:30 Michael Catanzaro : > Hi, > > Fujii Hironori is now a WebKit reviewer. He has expertise in Windows > support, WebKitGTK+, and WebCore bugs. Please congratulate him and send > him pa

Re: [webkit-dev] Meltdown and Spectre attacks

Hi Filip, Thank you for writing the nice article. https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ I have a question. What's the reason why the patch (5) isn't shipped yet? On Sat, Jan 6, 2018 at 4:37 AM, Filip Pizlo wrote: > Here is what else is in

Re: [webkit-dev] Linking against MultiThreadedDLL instead of MultiThreaded on Windows (wincairo)

On Fri, May 19, 2017 at 5:24 PM, Isaac Devine <is...@devinesystems.co.nz> wrote: > On 19 May 2017 at 16:16, Fujii Hironori <fujii.hiron...@gmail.com> wrote: >> > I have a linker warning because it was no longer linked to the > MultiThreadedDLL, and was statically l

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

On Fri, Sep 23, 2016 at 5:14 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > 23.09.2016, 00:59, "Alex Christensen" <achristen...@apple.com>: >> Requiring CMake 3.0 would not cause us a problem. > > Looks like anyone is fine with updating CMake

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

On Wed, Sep 21, 2016 at 12:39 AM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > On Tue, 2016-09-20 at 18:35 +0900, Fujii Hironori wrote: > > WebKitGTK+ intends to continue supporting 2.8.12 until April, when we > drop support for Ubuntu 14.04. So the new features you wa

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

Oops. I replied personally. I repost my and his messages again. On Tue, 20 Sep 2016 19:34:36 +0900, Fujii Hironori wrote: > > On Tue, Sep 20, 2016 at 2:58 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > Supporting 2.8.12 allows building on more older/LTS

[webkit-dev] [CMake] Bumping cmake_minimum_required

I'm interested in bumping cmake_minimum_required for . Which version of CMake is minimum version to be supported? --- hironori.fu...@sony.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org