Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)
On Fri, Oct 11, 2019 at 9:38 AM Konstantin Tokarev wrote: > > 10.10.2019, 23:10, "Ryosuke Niwa" : > > People often associate the term "WebKit" with Apple's WebKit port in > practice. The risk here is really about people not understanding the nuance > of port specific bugs & set of features. > > However, Safari has its own column in the table, and its logo is very > different. I don't think that addresses my primary concern. It's very important to signal to the rest of the world that a single port of WebKit doesn't represent the entirety of the WebKit project for the purpose of WPT pass rate or any other standards compliance. We already had a discussion about how how Apple should provide JSC binary on Linux despite of the fact Apple does not maintain any port on Linux: https://lists.webkit.org/pipermail/webkit-dev/2017-December/029805.html I don't think we want to add more confusion to the situation by different ports of WebKit using the WebKit logo on wpt.fyi or any other place for that matter. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview
Hi Carlos, Thanks for the tip. After struggling to get the RPM to build cleanly, I just manually edited /usr/share/mime/packages/freedesktop.org.xml to remove those extensions and ran update-mime-database, but it made no difference. Will update the bug. Ryan On Fri, 11 Oct 2019, at 5:29 PM, Carlos Alberto Lopez Perez wrote: > On 11/10/2019 18:07, Ryan Walklin wrote: > > Thanks for letting me know. Is there any workaround not requiring the edits > > to the Web Inspector UI mentioned in > > https://bugs.webkit.org/show_bug.cgi?id=202321#c4 (which I assume would > > necessitate a custom Epiphany build) on Fedora currently? > > Can you try this? > > 1. Download the source package of shared-mime-info (the SRPM and > install it) > 2. Patch it with this patch (by adding the patch to the RPM SPEC file): > https://people.igalia.com/clopez/wkbug/202321/0001-Revert-Assign-.html-to-XHTML-pages.patch > 3. Rebuild the package and install the new version. > 4. Check if it works and please report that on the bug above. > > Thanks > > > Attachments: > * signature.asc ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)
10.10.2019, 23:10, "Ryosuke Niwa" : > People often associate the term "WebKit" with Apple's WebKit port in > practice. The risk here is really about people not understanding the nuance > of port specific bugs & set of features. However, Safari has its own column in the table, and its logo is very different. -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview
On 11/10/2019 18:07, Ryan Walklin wrote: > Thanks for letting me know. Is there any workaround not requiring the edits > to the Web Inspector UI mentioned in > https://bugs.webkit.org/show_bug.cgi?id=202321#c4 (which I assume would > necessitate a custom Epiphany build) on Fedora currently? Can you try this? 1. Download the source package of shared-mime-info (the SRPM and install it) 2. Patch it with this patch (by adding the patch to the RPM SPEC file): https://people.igalia.com/clopez/wkbug/202321/0001-Revert-Assign-.html-to-XHTML-pages.patch 3. Rebuild the package and install the new version. 4. Check if it works and please report that on the bug above. Thanks signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)
> On Oct 10, 2019, at 9:02 AM, Carlos Alberto Lopez Perez > wrote: > > On 09/10/2019 21:53, Maciej Stachowiak wrote: >> In terms of legalities: >> >> The WebKit logo (as well as the term WebKit) is trademarked by Apple, but >> there are acceptable use guidelines in the Terms of Use: >> https://webkit.org/terms-of-use/ . I am not a lawyer and cannot give legal >> advice, but my interpretation is that it’s OK to use the WebKit logo in >> association with WebKitGTK. As far as alterations, I think a WebKit logo >> with a GTK+ logo next to it (or Linux logo, whatever), or badging it in the >> corner, would be more in line with the guidelines than a recolor. i.e. >> putting another logo/mark next to the WebKit logo seems more appropriate >> than directly altering the logo. > > > So, if I understand right... something like this would be more > acceptable? https://people.igalia.com/clopez/webkit_gtk_corner_logo.png > > Personally, i think that is more likely to cause confusion than using a > logo with different colors, check: > > https://people.igalia.com/clopez/wpt_fyi_logo_test.png > vs > https://people.igalia.com/clopez/wpt_fyi_logo_test2.png I see what you mean. The second version is hard to see at that size. > > > But if that is ok for you, then for my part is also fine... in the end > webkitgtk is webkit, right? > > > And if someone doesn't like this, please let me know, we may try to come > with a new logo for webkitgtk (that is not simply changing the colors). > I just want to know how to best proceed in this regard. > > > Regards. > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview
Thanks for letting me know. Is there any workaround not requiring the edits to the Web Inspector UI mentioned in https://bugs.webkit.org/show_bug.cgi?id=202321#c4 (which I assume would necessitate a custom Epiphany build) on Fedora currently? Ryan On Fri, 11 Oct 2019, at 3:21 PM, Michael Catanzaro wrote: > > Hi Ryan, > > This is https://bugs.webkit.org/show_bug.cgi?id=202321 > > Michael > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview
Hi Ryan, This is https://bugs.webkit.org/show_bug.cgi?id=202321 Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview
Hi, I'm not sure if this is a WPE bug or an Epiphany bug, but I'm trying to use the remote debugger with Epiphany to inspect a web app I'm running in WPE on Fedora 31. I'm using WPE 2.26.1 (but same problem with 2.27.1) and the Epiphany flatpak-ed nightly. I'm able to load the inspector page in Epiphany, but when I click the button to open the inspector, I get the following page: This page contains the following errors: error on line 43 at column 8: Opening and ending tag mismatch: link line 0 and head Below is a rendering of the page up to the first error. WI.sharedApp = new WI.AppController; WI.sharedApp.initialize(); Has anyone seen this before or can offer a solution? Thanks, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementing OffscreenCanvas
On 11/10/2019 11:09, Chris Lord wrote: > This sounds good to me, I'll file a bug and write a patch for this. I > assume there are ways of enabling features when tests are run? While a > user (or a developer) using WebKit wouldn't want this feature to be > enabled, I think it should be enabled for (some) test runs as soon as > possible to give us an indication of any issues that exist at the > moment. This can be achieved with a run-time flag that is off by default but enabled for the layout tests. See TestController::resetPreferencesToConsistentValues() in Tools/WebKitTestRunner/TestController.cpp signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementing OffscreenCanvas
On Fri, Oct 11, 2019 at 2:09 AM Chris Lord wrote: > > On 2019-10-10 23:15, Ryosuke Niwa wrote: > > On Thu, Oct 10, 2019 at 2:07 PM Myles C. Maxfield > > wrote: > > > >>> On Oct 10, 2019, at 12:57 PM, Ryosuke Niwa > >>> wrote: > >>> > >>> Hi Chris, > >>> > >>> I'm excited that you're working on OffscreenCanvas because I think > >>> it would be a valuable feature > >> > >> Me too!!! > >> > >>> , and I'm confident we can come up with a strategy to limit its > >>> privacy & security risk as we see fit. > >>> > >>> However, many of your patches seem to ignore the fact most of > >>> WebCore objects aren't thread safe. For example, CSS parser and > >>> the entire CSS object model aren't designed to used in non-main > >>> thread. Regardless of how ready Linux ports might be, we can't > >>> land or enable this feature in WebKit until all thread safety > >>> issues are sorted out. > >>> > >>> Unfortunately, I can't make a time commitment to review & find > >>> every thread safety issue in your patches. Please work with > >>> relevant experts and go over your code changes. > >> > >> I’d be happy to work with you on this. > >> > >>> For example, it's never safe to an object that's RefCounted in > >>> multiple threads because RefCounted isn't thread safe. One would > >>> have to use ThreadSafeRefCounted. It's never safe to use > >>> AtomString from one another in another because AtomString has a > >>> pool of strings per thread. For that matter, it's never safe to > >>> use a single String object from two or more threads because String > >>> itself is RefCounted and isn't thread safe. It's not not okay to > >>> do readonly access to basic container types like Vector, HashMap, > >>> etc... because they don't guarantee atomic update of internal data > >>> structures and doing so can result in UAF. > > To the best of my knowledge, I've taken this into account (it's hard to > see this without applying the whole patch series, as later patches > assume the changes made with respect to thread-safety in the earlier > patches). There are of course bound to be things I've missed - and I'm > also open to taking a different strategy on certain things too, I'm > fairly new to the WebKit codebase (well, I'm assuming having worked on > it around 10 years ago doesn't apply too much anymore :)) and I imagine > I've taken some naive approaches in places that someone more experienced > would be able to correct me on. I think you want Antti's input most here since many of the classes you're touching in CSS is maintained by Antti these days. The thing that worries me most about this feature is the thread safety. Historically, we had many thread safety issues regarding Timer, RefCounted objects, WeakPtr, etc... Chris (Dumez) and I have been addressing some of those issues more systematically (e.g. https://trac.webkit.org/r241499 & https://trac.webkit.org/r248113) because we seem to keep making same mistakes across the codebase. The key here is to really make which objects are used concurrently or in non-main threads obvious to whomever reading the code in the future. I can think of a few ways to do that. For one, we should be adding lots of thread safety assertions. Assertions are better than comments because they're obvious to readers and they warn us whenever they get out of date or we make mistakes. In fact, I discourage adding comments about thread safety; if you find yourself doing that, then it's time to refactor code such that the code is obviously multi-threaded or concurrent by the virtue of the way things are structured or make it not matter because the code is naturally thread safe. Just as an example, one of your patches made CSSValuePool's member functions thread safe but it left the rest of code still access CSSValuePool::singleton() object. This is problematic because singleton objects are usually shared across threads. A better approach is to have each caller explicitly get a specific instance of CSSValuePool from some other object; e.g. CSSParser's member variable. This will make it so that the code that needs to run concurrently would not rely on singleton objects, and whatever new code which gets introduced to CSSValuePool or CSSParser would naturally be thread safe so long as the author follows the same convention. Finally, we can add an assertion in CSSValuePool::singleton() to make sure it's only called in the thread. This way, anyone who makes a mistake of calling this singleton function in CSSParser, or elsewhere which can be used by the offscreen canvas code in worker would hit this assertion. >>> I think the hardest part of this project is validating that > >>> enabling this feature wouldn't introduce dozens of new thread > >>> safety issues and thereby security vulnerabilities. > >> > >> Sounds like this this is a good candidate for a feature flag. > > > > Yeah, in fact, this should really have a compile time flag in addition > > to runtime flag, and it should be default off until we've done enough > >
