[webkit-dev] Mixed content checking

[Michael Catanzaro]

Hi,

I'm an intern with Igalia currently working on mixed content blocking in
WebKitGTK+. I see WebCore already has decent support for mixed content
blocking using the settings allow-display-of-insecure-content and
allow-running-of-insecure-content, which were previously used by the
Chromium port.

One problem with these settings is that frames are treated as mixed
passive content rather than mixed active content. For the WebKitGTK+ API
I want frames to be treated as active content, which is what most major
browsers currently do. Is it OK if I change this, so that
allow-running-of-insecure-content and not
allow-display-of-insecure-content will be checked to determine whether
or not to block a frame? These settings seem to be currently unused, so
I don't think this will be an unexpected behavior change for anyone.

I'm also planning to block mixed XMLHttpRequest and WebSocket
connections when allow-running-of-insecure-content is false. 

Thanks,

Michael Catanzaro

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Mixed content checking

[Michael Catanzaro]

Hi Alexey,

On Wed, 2014-07-23 at 22:59 -0700, Alexey Proskuryakov wrote:
> Thank you for the heads up!
> 
> Can you elaborate on why this is desirable? A non-https frame always
> has a different origin, so it can't script the main frame.
> 
> In other words, how is "active content" defined here?

One big reason is that if an insecure frame is loaded on an HTTPS page,
users may believe the page to be secure even though a substantial
portion of that page may not be; browsers generally display a warning
icon when a page display mixed content, but users generally ignore it.
This used to be a big problem, but nowadays no major browser except
Safari allows mixed content frames [1], so it's a low-risk catch-up for
us.

[2] describes a couple other good reasons for blocking these frames
(scroll down to "mixed content frames"). Please note that when [2] was
authored only IE and Firefox were blocking mixed content frames, but
Chrome started doing so some months ago.

> Same question, why? Cross origin XMLHttpRequest is different from
> cross origin scripts in that it takes quite a bit of effort to make it
> work, so it's not the same case of accidentally loading a subresource
> using http instead of https.

Even so, no major browser besides Safari currently allows mixed content
XMLHttpRequests, so I think this is a low-risk restriction. (Again see
[1], but note that Chrome has quite recently begun blocking these as
well.)

Happy Thursday,

Michael

[1]
https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl
[2]
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Mixed content checking

[Michael Catanzaro]

On Tue, 2014-08-05 at 11:03 +0200, Mike West wrote:
> Apologies for digging up an old thread; I didn't see it until now.
> 
> On Thu, Jul 24, 2014 at 7:59 AM, Alexey Proskuryakov 
> wrote:
> > In other words, how is "active content" defined here?
> 
> Note that the WebAppSec WG is working on a mixed content spec that
> drops the "active"/"passive" distinction in favor of "stuff we can
> block without breaking the web"/"images":
> http://w3c.github.io/webappsec/specs/mixedcontent/#categories Feedback
> on that document would be welcome.
> 
> As Michael notes in his response, Chrome is busy tightening its
> implementation to match that spec. Some details on that in
> https://groups.google.com/a/chromium.org/d/msg/security-dev/Uxzvrqb6IeU/wb51F3nV7csJ
> 
> -mike

Thanks Mike, I will definitely read that spec and keep it in mind as an
end goal. Our mixed content blocking will probably not be so
comprehensive at first, but it's good to have a formal goal and also
indicates that I might have been mistaken to expose "block active mixed
content" and "block passive mixed content" as separate settings --
probably "block all mixed content" and "block selected mixed content"
would be more sensible levers for browsers to have.

Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, Jan 28, 2015 at 8:11 PM, Maciej Stachowiak  
wrote:
Yet another possibility is finding a better name than ‘shared’ 
for the singleton pattern function, but I don’t have any better 
ideas. Class::getSingleton() is more explicit but the extra verbosity 
doesn’t seem helpful to me.


I recommend Class::instance(), which is what I've seen used almost 
exclusively outside of WebKit. It's what Scott Meyers used, and it's 
very similar to the Gang of Four's choice of Class::Instance() and the 
Java pattern Class.INSTANCE.


That said, Class::singleton() is very attractive too.

I've never seen Class::shared() used anywhere except WebKit. The first 
time I saw this I had no clue what it was until I looked up the 
implementation.


All of these can get quite annoying to type, especially when the name 
of the class is long. (Sometimes I will keep a reference to the 
instance in a local variable with a shorter name.) But I think they're 
easier to read than free functions, and we should optimize for reading 
code, not writing it. Not a big deal either way.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Running new/modified tests on EWS bots

[Michael Catanzaro]

This seems to me like an obvious step to take. I'd much rather know
about tests that my patch breaks before pushing rather than afterward.

I guess the potential issue would be build power.

Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit browser always minimzed on CentOS 7.1

[Michael Catanzaro]

On Mon, 2015-05-04 at 07:54 -0400, Jerry Geis wrote:
> So I looked closer at my functions...
> 
> void maximize(void) {
> gtk_window_maximize(GTK_WINDOW(window));
> gtk_window_fullscreen(GTK_WINDOW(window));
> gtk_window_set_decorated(GTK_WINDOW(window), FALSE);
> }

Are you sure this problem is related to WebKit? If not, would ask on
gtk-list: https://mail.gnome.org/mailman/listinfo/gtk-list
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] CMake dependency bump?

[Michael Catanzaro]

Hi,

For bug #144747 it would be helpful to require CMake 2.8.12, so that I
can use the SYSTEM argument to target_include_directories. Would this
be a problem for anyone (in particular, the EFL port)? It was released
October 2013 and it's present in Ubuntu 14.04.

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CMake dependency bump?

[Michael Catanzaro]

On Tue, 2015-05-12 at 18:26 -0700, Alex Christensen wrote:
> It would be quite helpful to my CMake on Mac effort (which isn’t 
> complete yet) and the long-term CMaking of WebKit, JavaScriptCore, 
> and in particular JSC’s FTL to keep the CMake requirements the same 
> as LLVM, which are 2.8.8 right now.  I know CMake has cool new 
> features that I would also like to use, but I would oppose such a 
> change right now if there is another way.
> 
> http://llvm.org/docs/CMake.html

OK. I don't understand why keeping the same minimum version as LLVM
matters, but we don't want to cause problems for you. We'll try to find another
solution.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] *.webkit.org network issues

[Michael Catanzaro]

On 05/18/2015 03:30 PM, Osztrogonác Csaba wrote:

Unfortunately I still don't get any bugzilla e-mail, but
I got all webkit-dev mails. (However I am subscribed to
webkit-dev with this mail address, but set the webkit.org
one in bugzilla - which is forwarded to this one.) Does
everything work fine on the Apple side? If yes, I'll
ping my email service provider.
I haven't noticed any network issues, but I've had no mail from Bugzilla 
since Saturday, which seems highly improbable.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] *.webkit.org network issues

[Michael Catanzaro]

On 05/18/2015 03:37 PM, Michael Catanzaro wrote:
I haven't noticed any network issues, but I've had no mail from 
Bugzilla since Saturday, which seems highly improbable. 
I just got all the (backdated) bugmail within the past hour or two, so I 
guess that problem's been resolved.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, 2015-05-20 at 10:31 +0900, Gyuyoung Kim wrote:
> I would like to listen what do you think to support 
> 'registerProtocolHandler' in WebKit2.
> 
> This feature is to execute web content through registered custom 
> protocol.

Hi,

I think this would be useful for GNOME. One of our goals is for the
user to be able to set GMail as the default mail application in System
Settings. If the user visits gmail.com and it attempts to register
itself as a mailto:// handler, I envision the WebKitGTK+ would fire a
signal that would trigger Epiphany to display an info bar to ask the
user for approval. If the user approves the registration, we would go
one step further: we'd create a new web application for GMail and in
the desktop file indicate support for the MIME type x-scheme
-handler/mailto (or if the user already has a GMail web application,
modify the desktop file to add that MIME type). The user would then be
able to set the GMail web app as the default mail application
systemwide.

We would restrict this functionality to HTTPS sites only. I'd greatly
prefer that restriction to be enforced by WebKit rather than
implementing that policy in Epiphany.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Sun, 2015-06-07 at 17:39 -0700, Darin Adler wrote:
> As one next step in the discussion, is there anyone that wants to 
> present a use case for a protocol other than mailto?

irc:// would be useful for those who don't like desktop clients.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] TestWebKitAPI and CMake

[Michael Catanzaro]

On Fri, 2015-08-07 at 16:59 -0700, Alex Christensen wrote:
> I consider each option to have about equal merit, but I think I need 
> input from the GTK and EFL maintainers before proceeding.

I don't have a strong opinion, so long as if you go with (1) it remainspossible 
to run tests individually.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] PSA: you should use WTF::Lock and WTF::Condition instead of WTF::SpinLock, WTF::Mutex, WTF::ThreadCondition, std::mutex, std::condition_variable, or std::condition_variable_any

[Michael Catanzaro]

On Wed, 2015-08-19 at 13:08 -0700, Filip Pizlo wrote:
> TL;DR.  Don’t use WTF::SpinLock, WTF::Mutex, std::mutex,
> WTF::ThreadCondition, std::condition_variable, or
> std::condition_variable_any.  They waste CPU time and they waste
> memory.  Use WTF::Lock and WTF::Condition instead.

Hi, I recommend adding a style-checker rule to enforce this, if you
haven't already.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

Hi,

In WebKit Bugzilla the default assignee for all bugs is Nobody. This is
problematic because it makes it really hard to notice when new bugs are
filed against a particular component. For example, I want to be CCed on
all new bugs in the WebKit Gtk component. If there was a fake default
assignee, say webkit-gtk-ma...@webkit.bugs, then I could just add that
email to the User Watching section under my Email Preferences, and I'd
notice whenever a bug in that component is filed or changes state. This
is what we do in GNOME Bugzilla and it works quite well.

Since we don't have that, what I've been doing is watching Carlos
Garcia, which is a decent approximation since he tends to get CCed on a
lot of bugs. :) But only regular contributors know to CC him, so if the
bug isn't filed by a regular contributor, nobody ever sees it.

If a Bugzilla admin could set up default assignees for the various
components (or at least the WebKit Gtk component, but it would be
useful for all of them), that would be awesome.

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Mon, 2015-09-14 at 09:39 -0700, Alexey Proskuryakov wrote:
> Yet another approach used by the Accessibility component is to have a
> technical account auto-CC'ed, and then anyone interested can follow
> this account. This seems like the most reliable solution to me.

Yeah, I think that would be better, because that way everyone stays
CCed when the assignee changes. (In GNOME Bugzilla, the QA Contact
field serves that purpose, at the expense of cluttering the UI.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Mon, 2015-09-14 at 09:39 -0700, Alexey Proskuryakov wrote:
> Yet another approach used by the Accessibility component is to have a
> technical account auto-CC'ed, and then anyone interested can follow
> this account. This seems like the most reliable solution to me.

If someone with admin rights on Bugzilla could set this up for us, that
would be awesome.

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CMake on Windows

[Michael Catanzaro]

On Mon, 2015-09-28 at 13:28 -0700, Alex Christensen wrote:
> All the Windows buildbots are now using Windows.  We are planning to
> leave all the Visual Studio projects in the tree for a couple weeks,

Thanks Alex! It sounds like you're planning to remove the Visual Studio
projects in a couple weeks, and it's great news that we'll soon be rid
of another build system.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Mon, 2015-09-28 at 14:32 -0700, Darin Adler wrote:
> Yes, I’m sure someone can help. Do you have the accounts for each
> component? Then we can add these to the auto-CC list.

I was thinking it might be possible to just add some fake email
addresses to the auto-CC list, like webkitgtk-ma...@webkit.bugs, that
way we could have one auto-CCed to every component. But if we need to
use real addresses, we will make one @igalia.com email to use for just
the WebKitGTK+ component.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Mon, 2015-09-28 at 15:41 -0700, Lucas Forschler wrote:
> I can add a default CC for the WebKit Gtk component. However, I’m not
> sure if using a fake email would cause any negative side effects.
> (possibly an email bounce message on the mail server every time a bug
> was created?)
> 
> Lucas

Hey Lucas,

Can you please add for our default CC: bugs-nore...@webkitgtk.org

Mails sent to this address will be ignored and won't bounce.

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Fri, 2015-10-09 at 09:15 -0700, Lucas Forschler wrote:
> Hi Michael,
> 
> Attempting to add it resulted in an error. I believe this may have to
> be a valid/registered email address inside bugzilla. 
> Here is the error I received:
> 
> Bugzilla was unable to make any match at all for one or more of the
> names and/or email addresses you entered on the previous page.
> 
> Please go back and try other names or email addresses.
> 
> Default CC List:  
> bugs-nore...@webkitgtk.org did not match anything
> 
> Can you create a bugzilla user with that email, and I’ll try again?
> Thanks,
> Lucas

I will ask our sysadmin to help with this... I'm afraid that Bugzilla
is probably going to want to send a confirmation mail. :)

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Fri, 2015-10-09 at 09:15 -0700, Lucas Forschler wrote:
> Default CC List:  
> bugs-nore...@webkitgtk.org did not match anything
> 
> Can you create a bugzilla user with that email, and I’ll try again?
> Thanks,
> Lucas

Done, could you try again please?

We also experimented a bit with it and found that we can disable all
email for that account without disabling emails to people watching it,
so Bugzilla won't actually be sending any extra mail!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla default assignees

[Michael Catanzaro]

On Fri, 2015-10-09 at 14:04 -0700, Lucas Forschler wrote:
> Changes to the component WebKit Gtk have been saved:
> Default CC list updated to bugs-nore...@webkitgtk.org

Thanks Lucas!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Michael Catanzaro]

On Thu, 2015-12-31 at 19:25 +0300, Konstantin Tokarev wrote:
> Hi Yusuke,
> 
> What is the status of this proposal?
> AFAICS there were no serious objections, quite the opposite, many
> people support your proposal (me too). However, no patches were
> landed yet.

I only wonder why it is called Nix? Is it named for http://nixos.org/?
Or is just supposed to be a generic *nix Unix? Maybe a better name for
the port would simply be "jsc" or "js"...? It's just when I see "Nix" I
don't think "JSC only."

Did you test this with build-jsc? I guess it's fine to make 'build-
webkit --nix' do the right thing, but I bet it'd be more convenient to
just use the build-jsc command.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clipboard API and events

[Michael Catanzaro]

On Tue, 2016-01-05 at 16:48 +0200, Claudio Saavedra wrote:
> Hi,
> 
> It seems to me that this API is missing from WK. Is there a reason
> for
> this other than "nobody has stepped up yet"?
> 
> Claudio

What is the security model regarding the clipboard API? I'm not
enthusiastic about web pages being able to go through my clipboard
without my noticing, for example
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] CC on reviewed bugs

[Michael Catanzaro]

Hi,

I notice that when my only comment on a bug is the comment added using
the WebKit review feature, I do not get CCed on the bug and so do not
notice follow-up responses to my review.

It would be awesome if auto-CC could be implemented. I always want to
be CCed on bugs with patches I have reviewed.

Please be careful to CC yourself manually in the meantime.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CC on reviewed bugs

[Michael Catanzaro]

On Thu, 2016-01-07 at 13:09 -0800, Brian Burg wrote:
> The only reason that normal commenting will CC you is that the [X]
> Add me to CC list is checked by default.
> I agree it would be reasonable to duplicate that behavior when
> commenting via the review tool.
> 
> To do this, you’d have to modify “sub update()” in attachment.cgi,
> and pass in some new parameter.
> I recommend filing a bug so we can deliberate how to implement it.
> 
>   -Brian

OK: https://bugs.webkit.org/show_bug.cgi?id=152854

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Unprefixing hyphens property?

[Michael Catanzaro]

Hi,

Mozilla has unprefixed the CSS hyphens property as of Firefox 43. Is
there any interest in unprefixing it for WebKit?

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Fri, 2016-01-29 at 13:44 +0900, Yusuke SUZUKI wrote:
> Awesome, awesome work!
> Thanks Fil and all the JSC B3 developers!
> 
> After this https://bugs.webkit.org/show_bug.cgi?id=153422 is landed,
> jsc-layout-tests.yaml/js/script-tests/array-enumerators-
> functions.js.layout-ftl-eager-no-cjit
>  is only the test failing in B3 on Linux GTK port! B3 in the other
> platforms looks approaching :D

https://bugs.webkit.org/show_bug.cgi?id=153647 looks pretty serious as
well.

Glad we're getting close though!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sat, 2016-01-30 at 14:13 -0800, Filip Pizło wrote:
> That's so awesome!  I can't wait to see it enabled on Linux!
> 
> The gcc-clang differences suggest that we will need to be extra
> careful now. I'd like to see more Linux testing of JSC. 
> 
> -Filip

Hi,

We have two bots that run the JSC tests with GCC (our major
distributors all use GCC). The JSC tests break regularly, but the
failures are usually cross-platform and so get fixed fairly quickly. If
there are any JSC failures, they show up here:

https://build.webkit.org/dashboard/

Currently all the JSC tests are passing (running FTL with LLVM).

It would be very nice if the EWS were to run GTK tests (without
blocking commit-queue) so that developers can notice failures
immediately. Otherwise, I don't see room for improvement here.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sun, 2016-01-31 at 06:00 +0900, Yusuke SUZUKI wrote:
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and
> https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.
> 
> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
> time
> to enable B3 in Linux x64 :D
> 
> Regards,
> Yusuke Suzuki

Let's turn this on. :)

I thought we could remove all the LLVM goo from the CMake build system,
but I see there is some code to support LLVM for the EFL port on
AArch64. (For the GTK port, FTL is only supported on x86_64).

Do we want to continue to support FTL on AArch64 using LLVM, or do we
want to just turn off FTL on that platform until B3 is ready? It's
currently disabled by default, so I don't see much value in keeping it
around.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> Do we have Linux bots that run Octane, Speedometer, JetStream and
> Kraken in browser?
> 
> We find that this catches a lot of bugs that none of the other tests
> catch. 
> 
> -Filip

I would assume it just executes 'run-jsc-tests'.

I didn't realize Apple was running tests not covered in run-jsc-tests.
It would be good to improve this.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> Do we have Linux bots that run Octane, Speedometer, JetStream and
> Kraken in browser?
> 
> We find that this catches a lot of bugs that none of the other tests
> catch. 
> 
> -Filip

This is the command that the bots run:

/usr/bin/env ruby Tools/Scripts/run-jsc-stress-tests -j
/home/slave/webkitgtk/gtk-linux-64-release-
tests/build/WebKitBuild/Release/bin/jsc -o /home/slave/webkitgtk/gtk-
linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-results 
PerformanceTests/SunSpider/tests/sunspider-1.0
PerformanceTests/JetStream/cdjs/cdjs-tests.yaml
Source/JavaScriptCore/tests/executableAllocationFuzz.yaml
Source/JavaScriptCore/tests/exceptionFuzz.yaml
PerformanceTests/SunSpider/no-architecture-specific-optimizations.yaml
PerformanceTests/SunSpider/tests/v8-v6
Source/JavaScriptCore/tests/mozilla/mozilla-tests.yaml
Source/JavaScriptCore/tests/stress LayoutTests/js/regress/script-tests
PerformanceTests/SunSpider/profiler-test.yaml LayoutTests/jsc-layout-
tests.yaml Source/JavaScriptCore/tests/typeProfiler.yaml
Source/JavaScriptCore/tests/controlFlowProfiler.yaml
Source/JavaScriptCore/tests/es6.yaml
Source/JavaScriptCore/tests/modules.yaml --ftl-jit --

I see SunSpider and JetStream in there, but not the others

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Michael Catanzaro]

Hi,

On Sun, 2016-01-31 at 15:22 -0800, Eric Wing wrote:
> - libICU is a difficult dependency because it is big and it is not
> guaranteed to be on all systems. (Some context, I’m interested in
> deploying binaries, e.g. SteamOS, Android, so I can’t make users
> install it via package management). So static linking is the
> preferred
> method. (It’s discussed in the above doc.) Currently, JavaScriptCore
> needs to additionally link against libicudata because the other
> libraries have a dependency on it. Static linking doesn’t pick up on
> the implicit dependency. I don’t think it hurts anything in the
> dynamic library case.

I don't mind if static linking is an option. (We will keep using
dynamic linking for WebKitGTK+, though, as it's what all our
distributors require.)

> - soname versioning *must* be disabled for Android. I would also like
> an option to shut it off for regular desktop Linux. I am bundling
> JavaScriptCore with my app, so the versioning is mostly a nuisance
> for
> my build system.

Ditto for soname versioning.

> - Can somebody explain libllvmForJSC.so? libJavaScriptCore does not
> link to it. Is it actually used? Is it a dlopen type thing? If so,
> since I’m bundling JSCore with my app, what are the rules for where
> to
> place libllvmForJSC so it can be found/loaded? Is there an C API to
> set the path?

Yes, it's a dlopen-type thing. But it's about to go away because we're
about to remove the LLVM dependency (see the recent topics on B3).

See: https://bugs.webkit.org/show_bug.cgi?id=153478

> - I think libedit was required for libllvmForJSC.so. libedit is not
> included with SteamOS. I built my own static version and had to set
> my
> $LIBRARY_PATH environment to make sure it got picked up. This seems
> like it should have gone through the CMake FInd_Library() mechanism
> so
> I could specify the location directly to the build system.

Yes, this is an annoying bug. If it's only needed for libllvmForJSC,
then hopefully the problem is about to go away. :)

> - Some general feedback on the gcc 4.9.0 requirement to the WebKit
> team as a whole. This is really hard for SteamOS because it only has
> 4.8.1 (and I don't think I can upgrade without introducing new
> dependencies on glibc/libstdc++ that nobody would have on their
> machines.) I consider myself fortunate that things built under its
> provided clang 3.6.

Maybe we should lower this requirement.

If you remove the version checks and build with
-DENABLE_DATABASE_PROCESS=OFF -DENABLE_INDEXED_DATABASE=OFF it will
work. See for an example:

https://build.opensuse.org/package/show/GNOME:Next/webkit2gtk3

Actually, it's possible that database process would work with newer
versions of GCC 4.8, but we haven't tested. 4.8.1 is almost certainly
broken, though.

If you're just building JSC, you can safely remove the version checks
(for now).

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Web inspector images

[Michael Catanzaro]

Hi,

I'd like to address the problem with the license for the web inspector
images. The background on this is that a WebKitGTK+ release was
rejected by the legal department of one of our distributors after it
discovered the file Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf,
which covers the images under
Source/WebInspectorUI/UserInterface/Images. From a cursory glance at
the license, it's clear that not only is this license not open source
compatible (and therefore not compatible with the acceptable content
policies of major WebKitGTK+ distributors), the images are also not
distributable. I don't believe this is consistent with the values of
the WebKit open source project.

In response to this issue, we created similar but freely-licensed
replacement images under
Source/WebInspectorUI/UserInterface/Images/gtk, took down our hosted
tarballs for several previous WebKitGTK+ releases, reissued those
tarballs with the images replaced, and posted a notice to alert some of
our distributors to the issue. This was sufficient for our port, so we
just... stopped at that. But it would be good if other ports did not
have to address this problem individually, especially since there is no
obvious warning when downloading WebKit as to the legal status of this
content.

Since the images are not usable except by Apple, it would be nice to
remove these images from the public repository to reduce the risk of
other ports accidentally including these image files. Therefore, I
propose to simply overwrite the images under Images with the images
under Images/gtk. As part of this, we would need to create a few new
images that do not currently exist under Images/gtk. Also, Apple's
internal build process would need to be modified to include the Apple
images from elsewhere.

If I am remembering correctly, I spoke to Joe Pecoraro about this at
the WebKit Contributors Meeting, and he liked this idea. Would anyone
object to this change?

A couple alternative solutions:

 * Apple could relicense its images. I suspect the set of similar but
freely-licensed gtk images defeats the purpose of using a restrictive
license for the Apple images. This would be the best solution.
Possible?

* We could move the license file up from WebInspectorImages to the
toplevel project directory. This would make it very difficult to
accidentally distribute the Apple images without knowing the license.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

[Michael Catanzaro]

I'm curious what Martin and Alex think about this. It seems fine to me;
the downside is there are more CMake files to maintain, the upside is
the big ones should be slightly smaller, and we can reduce duplication
between PlatformEFL.cmake and PlatformGTK.cmake.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Michael Catanzaro]

On Thu, 2016-03-03 at 09:54 -0800, Ryosuke Niwa wrote:
> I think "virtual" + "override" is more of a historical artifact than
> the preferred style because we used to have OVERRIDE macro before all
> compilers supported C++11.  I think we should just use only
> "override"
> going forward.
> - R. Niwa

I agree, "virtual" in subclasses adds no value, it is simply redundant
with "override"... we should omit it in new files.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Michael Catanzaro]

On Thu, 2016-03-03 at 11:38 -0800, Geoffrey Garen wrote:
> I volunteer for any future needs in the physical restraint department
> -- but in this case, I think (3) sounds like a good idea.

Allowing Darin to perform (3) sounds good to me, what could possibly go
wrong? Some folks will have to rebase patches, but that should not be
difficult

We could also really go the full mile and start using override wherever
possible. I guess a script to make that change could be written by
turning on the GCC -Wsuggest-override warning, and parsing the compiler
output to get line numbers that need fixed

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Michael Catanzaro]

On Fri, 2016-03-04 at 17:54 +0300, Konstantin Tokarev wrote:
> clang-modernize can do that automatically, I have WebCore patch ready
> for upload.

clang. :)

Let's do this?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Michael Catanzaro]

On Fri, 2016-03-04 at 10:32 -0800, Darin Adler wrote:
> Here are three other loose ends I am thinking about:
> 
> - Style guide should say that in a class marked final, virtual
> functions should all be marked final, not override and certainly not
> virtual. Agreed? Can we check that with the script? Apply that rule
> globally like we just did with the other rules with do-webcore-
> rename?

I kinda prefer the other way around, to use "override" for virtual
functions even in final classes, as it's a bit more readable IMO.
(There's absolutely no difference between override and final in this
case, right?) But I think it doesn't really matter.

> - Style guide should encourage programmers to use final instead of
> override whenever possible. I suspect many of the functions that
> currently are tagged override should be final instead. Agreed?

What's your reasoning for this suggestion?

> - Style guide should discourage virtual on destructors where the
> destructor is already virtual due to a base class. This is now more
> consistent with the use of virtual on other member functions, final
> would be on the class, override doesn’t need to be stated. Agreed?

We just need to make the style checker's warning clear to ensure
programmers don't improperly remove the destructor declaration in
response to the style checker's warning. We had a GTK port bug caused
by a missing virtual destructor recently... GCC and Clang have warnings
for this, which I think should be enabled, but apparently were not or
somehow didn't work.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Michael Catanzaro]

On Fri, 2016-03-04 at 14:04 -0800, Darin Adler wrote:
> I’d like to learn more about this. Are the relevant warnings on for
> all the WebKit project’s compilers, ports, and build systems?

See:

https://bugs.webkit.org/show_bug.cgi?id=153695
https://bugs.webkit.org/show_bug.cgi?id=155048

GCC and Clang both have these warnings (under the same names). I don't
know about MSVCC or XCode.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Regarding CVE-2014-1303

[Michael Catanzaro]

On Mon, 2016-03-07 at 08:45 -0800, Darin Adler wrote:
> If you have a specific legitimate reason that you need to know more
> information about this particular bug, then you’ll need to state the
> reason, and given what it says on that webpage, you should send the
> inquiry to secur...@webkit.org rather than to this mailing list.

It's also concerning that you are worried about one particular
vulnerability, when there have been dozens of dozens of vulnerabilities
discovered in WebKit since then.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Use #pragma once instead of header guards

[Michael Catanzaro]

On Wed, 2016-03-09 at 17:27 -0800, Anders Carlsson wrote:
> Hi floks,
> 
> Currently we use 
> 
> #ifndef Header_h
> #define Header_h
> 
> … 
> 
> #endif
> 
> I propose that we instead start using
> 
> #pragma once
> 
> which does the same thing.

I think it's fine for the GTK port in general, but it would be nice to
keep this out of our public headers. That is mostly just GTK-specific
headers, but also the public JavaScriptCore headers JavaScript.h,
JSBase.h, JSContextRef.h, JSObjectRef.h, JSStringRef.h, JSValueRef.h,
and WebKitAvailability.h.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Fonts for WebKit tests on OS X?

[Michael Catanzaro]

On Fri, 2016-03-11 at 13:12 -0800, Myles C. Maxfield wrote:
> 2. Petition for the fonts to be preinstalled on all future releases
> of OS X, and mark the tests as expected to fail on all current
> versions of OS X.

Fred, if these fonts are not preinstalled, is MathML broken for users
in practice? If so, that would be a good argument for installing the
fonts by default.

That's kinda my concern with this Latin Modern Math font we're using
for the GTK port. We're not shipping that in Fedora and I doubt other
distros are either, so if it's needed for MathML to work well, it's
broken for users in practice.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Fonts for WebKit tests on OS X?

[Michael Catanzaro]

On Sat, 2016-03-12 at 10:27 +0100, Frédéric WANG wrote:
>  So it's relatively easy for users to install the fonts.
> Ideally, the Latin Modern package should be a dependency of
> WebKitGTK+,
> which I think I (or Martin Robinson) already asked in the past to
> some
> distro maintainers when we added Latin Modern Math to the test
> environment.

Not sure I agree that WebKit should pull in any particular font
package. I'd prefer to just add some math font that's installed by
default. Other apps will want it too.

> In the case of Fedora, the good news is that STIX is installed by
> default in the normal setup. The bad news is that the current 1.1
> release of STIX has many bugs making it bad for math layout albeit
> not
> as bad as with the obsolete version shipped in OS X. However, I'm
> confident the Fedora package will be updated to version 2 when it is
> released.
> 
> See (*) for more details, which also gives an overview of the
> situation
> in other operating systems. Given the lack of availability of math
> fonts, workarounds have been considered but they add burden for each
> actor:

I considered adding texlive-lm-math to the list of packages installed
by default in Fedora. This takes about two minutes to change, so it's
normally no problem at all.

But it seems to depend on a bunch of perl and texlive packages:

perl-Digest, perl-Digest-MD5, perl-Filter, perl-Text-Unidecode, perl-
Tk, perl-XML-XPath, perl-encoding, perl-open, texlive-base, texlive-
hyphen-base, texlive-kpathsea, texlive-kpathsea-bin, texlive-kpathsea-
lib, texlive-metafont, texlive-metafont-bin, texlive-tetex, texlive-
tetex-bin, texlive-texlive.infra, texlive-texlive.infra-bin

I'm hesitant to add texlive dependencies. Also, I don't see it in Font
Viewer, so I guess it requires the fontconfig change suggested by that
wiki page to work, and that would require coordination with fontconfig
upstream. I suspect there is some good reason that texlive fonts are
not available to applications by default?

Perhaps the easiest solution is to do nothing, and wait for a new STIX
release?

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Fonts for WebKit tests on OS X?

[Michael Catanzaro]

On Sat, 2016-03-12 at 17:50 +0100, Frédéric WANG wrote:
> This depends on what distro / maintainer prefers. In Debian-base
> distro
> the fontconfig changes are automatically done for Latin Modern Math,
> but
> one Arch Linux user told me that their philosophy is rather to always
> do
> the minimal setup and let users decide if they want to configure more
> ;
> so the fontconfig change is unlikely to be done by default...

Well the Fedora maintainers are the upstream maintainers too, so no
point in diverging from fontconfig upstream. If you can get a change
upstream, you can get it into all distros too.

> I guess that's the easiest solution for Fedora...
> 
> However, in general I think the best would probably for distros to
> have
> font packages independent from texlive that will just install the
> fonts
> in more standard system locations and expose them to all apps by
> default...

Yeah, makes sense. I don't plan to work on this, but I'm happy to add
non-texlive font packages to the default install on request, if those
packages exist in Fedora and don't require changes in fontconfig
configuration.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] question about WSA-2016-0002

[Michael Catanzaro]

On Sat, 2016-03-26 at 15:53 -0600, Brian Martin wrote:
> http://webkitgtk.org/security/WSA-2016-0002.html
> 
> Of the six issues, five say to upgrade to 10.2.5 to mitigate, while
> the
> sixth (CVE-2016-1726) says upgrade to 10.2.8. Can you confirm that is
> the case rather than a typo?
> 
> Thank you,
> 
> Brian
> OSF / OSVDB.org

Hi Brian,

That page is correct; CVE-2016-1726 was not fixed until 2.10.8. It
seems strange, but it's not a typo. CVE assignment is handled by Apple
following their schedule for Safari releases and security advisories.
WebKitGTK+ security advisories are based on Safari advisories and so
follow behind on that schedule, but WebKitGTK+ stable releases are not
based on the same branches as Safari and do not follow that schedule.
Many vulnerabilities are already fixed in WebKitGTK+ releases at the
time of a new Safari advisory (as was the case for the other five
issues here), but others are missed and only fixed in WebKitGTK+ after
they're first fixed in Safari (which was the case for CVE-2016-1726).

Hope that helps explain the strangeness.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SPAM on trac.webkit.org

[Michael Catanzaro]

A bunch of spam pages are currently being created on the wiki. I don't
have permission to delete the pages so a wiki admin will have to clean
this up (and ban the user).

The first such page is:

http://trac.webkit.org/wiki/Microsoft%20Office%20Support@%201844.811.60
63%20Phone%20number%20Microsoft%20Office%20tech%20support%20number..
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Improving the flexibility of the cookie manager

[Michael Catanzaro]

On Sun, 2016-04-17 at 08:57 -0400, Drew DeVault wrote:
> 2. Add sufficient signals and APIs to WebKitCookieManager to allow
> the
> UA to effectively manage cookies themselves.
> 
> I'm leaning towards the second option. Would like to hear your
> thoughts.

I would lean towards the second option as well. Once you have a more
specific API proposal, please send it to 

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SPAM on trac.webkit.org

[Michael Catanzaro]

On Sun, 2016-04-17 at 06:44 -0700, Lucas Forschler wrote:
> I believe the spam is coming only from users who are not identified
> as developers (committers). Therefore, I’ve re-enabled WIKI_CREATE
> and WIKI_MODIFY permissions to the trac ‘developer’ group. 
> This will keep the wiki locked down to those with committer access,
> and not be as open as we would prefer. Moving forward, we should
> decide which mechanism we’d like to use to help prevent spam.

Perhaps I was never added to the developer group, as I can't edit the
wiki anymore. Could you look into this Lucas?

Thanks,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

On Mon, 2016-04-18 at 22:36 +0300, Konstantin Tokarev wrote:
> Are there any objections for lowering GCC requirement from 4.9.0 to
> 4.8.4 (only for JavaScriptCore without B3)? I'm going to fix arising
> compilation errors myself.

I've been kinda hoping to do this regardless, since you started
contributing GCC 4.8 buildfixes. GCC 4.8 is still being used by a
prominent distributor that's recently started releasing occasional
WebKit updates. I worked on downstream patches to remove the GCC 4.9
requirement so that their users can get WebKit updates. Since
increasing our GCC requirement past the GCC version included in a
distribution just guarantees users will never receive WebKit security
updates, we need to recognize that we moved too quickly in increasing
our requirement to GCC 4.9. (At the time I thought this was OK, but I
was wrong.) We'll need to be more careful in the future when bumping
our GCC requirement, lest we leave a large segment of users stuck on
ancient versions of WebKit.

It's unfortunate as of course we want to be able to use new language
features, but we need to balance this with the desire to ensure our
updates reach users.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

On Mon, 2016-04-18 at 15:01 -0700, Geoffrey Garen wrote:
> GCC 4.8 is three years old.

Yeah, unfortunately no Linux distros are ever willing to do major
compiler upgrades, even Fedora is only willing to take minor compiler
upgrades, so our willingness to support old compilers is proportional
to the size of our user base eligible for updates. :/

I understand resistance to restoring support for a compiler we
previously decided to drop, so let me tone down my request: I just ask
that when we decide to drop support for a compiler, we consider which
major distros actually shipping our updates still use that compiler, so
we can get a feel for how many users will stop getting WebKit updates
as a consequence. We've just recently gotten to the point where a few
distros are beginning to take our updates, and I'm really hoping to
facilitate this by maintaining support for the compilers these distros
are using as long as possible.

It's really annoying to be stuck catering to older compilers, but I
don't see any good solution to this without throwing users under the
bus. :(

> I don’t think we should put a three year hold on all current and
> future C++ language features.
> 
> Vendors that want to ship security updates to old, stable OS’s should
> maintain a branch that cherry-picks fixes from trunk and applies
> build fixes as necessary, rather than holding back development in
> trunk.

I'm not aware of any distributor that has ever attempted to seriously
backport security fixes; not even enterprise distros like RHEL do this.
Reality is that distros only ship what we release upstream.

> > It's unfortunate as of course we want to be able to use new
> language
> > features, but we need to balance this with the desire to ensure our
> > updates reach users.
> 
> I don’t think that shipping trunk as a security update on very old
> platforms is a viable strategy.

Nobody ships trunk, they ship our stable releases, which branch off of
trunk every six months. We don't have the resources to maintain
compiler support outside of trunk.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

On Mon, 2016-04-18 at 17:26 -0700, Filip Pizlo wrote:
> Yeah.  If we allow GCC 4.8 then I think we should make all of our
> code compile with it.  If that proves too difficult (like if we had
> to get rid of all lambdas), then I think we need to not allow GCC
> 4.8.

Agreed. And don't worry, we would not have to get rid of lambdas...
that would not be a reasonable proposal.

I can confirm that WebKitGTK+ 2.10.7 works fine with GCC 4.8.5 when
patched to remove the error we added to require use of GCC 4.9, and
when using -DENABLE_DATABASE_PROCESS=OFF and -DENABLE_INDEXED_DB=OFF
(undesirable but acceptable IMO). I'm not sure if the database process
disablement is still required with the latest GCC 4.8 release, but it
was crashing at some point in the past.

Now, there are eight months of changes in trunk since that last
confirmed-working version; if we were to lower the supported GCC
version, we would have to investigate to see if it still works with
trunk.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Michael Catanzaro]

Hi,

On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
> I am sympathetic to the principle that we should support the
> compilers that ship on the most popular versions of Linux.

Great. :)

> I’d like to understand if that argument is sufficient to support GCC
> 4.8.
> 
> Can you clarify, is it the case that if I installed the latest stable
> Fedora, I’d get GCC 4.8?

No, all currently-supported versions of Fedora include GCC 5 (only).
Different distros have very different release cycles and policies for
compiler upgrades. Fedora releases roughly every six months, and each
release is supported for roughly 13 months. GCC releases once per year.
The GCC developers coordinate with Fedora release planning to time GCC
releases to coincide with spring Fedora releases; in the winter before
a new GCC release, we rebuilt all of Fedora with the GCC beta so the
GCC developers can collect bug reports. So we will never have issues
with Fedora, as the oldest Fedora will be at most one year behind
upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
I'm making sure all supported Fedoras get updates.)

But Fedora is exceptional in this regard. Other distros are supported
for much longer than 13 months (5 years for Ubuntu LTS and newly also
for Debian, 10 years for enterprise distros) and therefore have much
older compilers. The question is where do we draw the line. We
obviously cannot support a 10 year old distro; those are maintained by
rich corporations, and if they cared about WebKit security, they could
take responsibility for that. We could handle 5 years, but do we really
want to? (It's clear Apple doesn't.) It's really inconvenient to not
have access to newer dependencies or language features for so long. We
might start by saying that we only support the latest release of [list
of major distros that have recently been shipping WebKit updates]. Most
of these distros are currently built using GCC 4.9, though they might
have GCC 5 or GCC 6 packaged as well, but not used by default. The big
one still using GCC 4.8 is openSUSE.

We don't *need* to consider Ubuntu right now, because they rarely ever
take our updates, nor Debian, because they never take our updates. I
think WebKit updates for Debian is all but totally a lost cause, but
I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.

Also, different distros have different policies on using alternative
compilers. E.g. in Fedora we are usually required to always use
Fedora's GCC, and only one version is available at a time... but if a
package *really* has no chance of being built with GCC, we're allowed
to use Fedora's Clang instead. I'm not sure what the policies are for
Debian and Ubuntu, but they always have available a newer GCC than is
used for building packages, and until recently were using Clang to
build Chromium, so alternative compilers must be permitted at least in
exceptional cases. I was trying to convince the openSUSE folks to use
Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
enthusiastic. (But consider that all these distros will have older
versions of Clang as well.)

Now, whether openSUSE is important enough on its own to justify holding
back or lowering our GCC requirement... maybe not. But anyway, since we
have significant contributors like Konstantin stuck with GCC 4.8, and
since this doesn't require giving up on any significant language
features, I think it's OK. If it's only a little work to support that
compiler (on the level we already have in trunk), I think it's a good
idea.

But there is another problem here. openSUSE seems to have no intention
of upgrading to a newer GCC anytime soon, because they have started to
inherit core packages like GCC from the SUSE enterprise distro. So I
might need to negotiate with them if it would be possible to build
WebKit with clang after all.

> Can you clarify what you mean by “backport”?  I’m trying to get a
> picture of how your releases work.  For example, are you saying that
> RHEL wouldn’t take a security update that you backported, or that
> they won’t invest energy into backporting it themselves?

We don't try to convince distros to take individual security fixes as
patches, because there are way too many for that to be practical. We
want them to take our tarball updates.

In that mail I was saying that RHEL won't invest energy into
backporting things themselves downstream; consider that we have about
100 security fixes per year, backporting from trunk needs to be handled
upstream so this can be shared among distros, rather than separately by
each distro that wants to provide WebKit updates. Our upstream
WebKitGTK+ releases work like this: every February and August, we
branch off of trunk; this forms a new stable branch, which gets
released in March/September. We then cherry-pick fixes to that branch
and make releases off of it for the next seven months or so. Our goal
is to convince distros to take these releases, because it's the only

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

[Michael Catanzaro]

On Mon, 2016-05-23 at 07:27 -0700, Filip Pizło wrote:
> You guys are making a convincing case for
> Seconds/WallTime/MonotonicTime!
> 
> -Filip

I will add: the convention "double means seconds" is very much not
obvious. It's OK when we're careful to consistently use "seconds" in
function and variable names, but in practice, that's not always or even
usually the case in WebKit code.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] REQUEST_ANIMATION_FRAME on all ports?

[Michael Catanzaro]

On Wed, 2016-06-08 at 13:59 -0700, Dean Jackson wrote:
> Do the EFL and GTK ports always enable this feature?

Yes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Are there any plans to upgrade SVN server on svn.webkit.org?

[Michael Catanzaro]

On Mon, 2016-06-20 at 13:29 +0900, Yusuke SUZUKI wrote:
> Great work, thanks.
> 
> I've just noticed that the ToT git revision in git://
> git.webkit.org/WebKit.git is r202198 while ToT SVN revision is
> r202223.

Indeed, this is broken. A workaround is to run 'git svn fetch' instead
of 'git pull'.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SIGSEGV possibly (?) due to libwebkitgtk (backtrace included)

[Michael Catanzaro]

On Mon, 2016-07-04 at 00:53 -0700, Saam Barati wrote:
> Presumably this is an older version of JSC, so whatever bug you're
> seeing might be fixed in ToT.

Possibly. We don't support this very old version of WebKitGTK+ anymore
and gnome-web-photo is a long dead project, so I doubt anyone will be
taking a look into this, sorry.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone here interested in improving rebaseline-server?

[Michael Catanzaro]

On Thu, 2016-07-14 at 18:03 +0300, Konstantin Tokarev wrote:
> Is anybody here using rebaseline-server as well, or everyone is using
> garden-o-matic?

Hm, I didn't know about these tools; is there documentation for them?

I've always rebased tests manually

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Michael Catanzaro]

On Mon, 2016-08-29 at 10:16 +0200, Carlos Garcia Campos wrote:
> We basically have a Exception member
> in WebKitDOMObject base class that is reset for every method call,
> and
> set in case of exception. Then we add
> webkit_dom_object_get_exception()
> to query if there were a exception. That's not the GLib way, but DOM
> bindings is a special API anyway.

It would be a major usability regression for developers. :(
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Michael Catanzaro]

On Mon, 2016-08-29 at 14:45 +0200, Carlos Garcia Campos wrote:
> I agree this is not ideal for a GObject API, but I really don't see
> how
> this is a major problem, to be honest.

The problem is that you would either have to check for errors on every
function call, including the 95% of function calls that cannot throw
errors, or just ignore all errors.

I guess if most API users ignore errors, it's not such a big deal.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Michael Catanzaro]

I'm OK with freezing the bindings. I'm disappointed in that these are a
killer feature for us and they'll never get improved now, but
generating them seems to be causing too many problems that we cannot
easily solve.

On Tue, 2016-08-30 at 08:54 +0200, Carlos Garcia Campos wrote:
> haha, no, of course I'm not, but I'm not Ok with the WebKit2 rules
> either and I just live with that :-) Anyway, I think freezing the
> GObject API is harmless and it's better for everybody.

The difference is that the GObject bindings are a seriously difficult
issue for Apple that materially slows down their development (or at
least appears to me to do so). It's impressive how much extra effort
Apple devs (hi Chris) have spent trying to keep our bindings building
(thanks!), but I don't think it's reasonable to expect them to do so.
As much as we appreciate it, really nobody should be spending an
afternoon uploading speculative patches to try to please our bindings
generator. Anyway, if we freeze the API, this becomes a moot point.

WebKit2 is totally different. When WebKit2 breaks (which has
fortunately become much rarer nowadays than it used to be) it's usually
something very very easy to fix -- a function gains an extra parameter
or a pointer becomes a reference or something -- and it just feels
borderline spiteful to not spend five minutes with 'git grep' to avoid
breaking us. It's not as if WebKit2 is somehow less important to us
than WebCore

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebKit2 build breakage

[Michael Catanzaro]

> The difference is that the GObject bindings are a seriously difficult
> issue for Apple that materially slows down their development (or at
> least appears to me to do so). It's impressive how much extra effort
> Apple devs (hi Chris) have spent trying to keep our bindings building
> (thanks!), but I don't think it's reasonable to expect them to do so.
> As much as we appreciate it, really nobody should be spending an
> afternoon uploading speculative patches to try to please our bindings
> generator. Anyway, if we freeze the API, this becomes a moot point.

Hopefully this will be much less of an issue now that we no longer
generate the GObject bindings.
 
> WebKit2 is totally different. When WebKit2 breaks (which has
> fortunately become much rarer nowadays than it used to be) it's
> usually
> something very very easy to fix -- a function gains an extra
> parameter
> or a pointer becomes a reference or something -- and it just feels
> borderline spiteful to not spend five minutes with 'git grep' to
> avoid
> breaking us. It's not as if WebKit2 is somehow less important to us
> than WebCore

This was an issue again today. [1] To be candid about this, we all know
there's just a couple developers who routinely and intentionally break
other WebKit ports. This is not appropriate behavior in a free software
project. Please stop.

(I'm grateful that the vast majority of developers at Apple try to
avoid doing this.)

I'd like to formally propose we allow rolling out commits that
introduce build breaks in WebKit2, just like we do everywhere else in
the WebKit project. WebKit2 is an integral component of all modern
WebKit ports. It's not special, and it doesn't make sense to allow this
nonsense anymore. You can take a few minutes to update other users of
the API you're changing. Or if something is tricky (clearly not the
case here), you can wait for other developers to handle it for you.
It's not like we're inaccessible.

Michael

[1] http://trac.webkit.org/changeset/205327
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Michael Catanzaro]

On Mon, 2016-09-05 at 10:23 -0700, Filip Pizlo wrote:
> The use of "take" for these methods grinds my gears, for the same
> reason you were distracted: "take" describes the desires of the
> caller, but that doesn't work for me because I read
> "fred.makeCoffee()" as "makeCoffee()" being an imperative verb phrase
> and "fred" as being the subject that will make me the coffee.  So,
> "HashMap::take" means to me that the HashMap is taking something from
> me, rather than releasing something to me.
> 
> I wonder if there is anyone who is surprised more by release than by
> take, and who would find it strange to say
> ExceptionOr::releaseReturnValue.

I'm more used to seeing "release" used with smart pointers and "take"
used with data structures, but I like your argument that the semantics
of "take" are backwards. "Release" is clear in either case.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Michael Catanzaro]

On Tue, 2016-09-06 at 11:12 -0700, Filip Pizlo wrote:
> FWIW, I still like release() better than move().  a = move(b) is a
> command to the system to move b to a.  So, value =
> collection.move(key) feels like a command to the collection to move
> key to value, which is clearly not what is going on.

I agree that move() would be quite confusing; I think we should avoid
this option.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

Hi,

The GTK+ port currently has an interesting web process crash on exit:

pure virtual method called
terminate called without an active exception

I found the easiest way to debug it was to rebuild with a terminate
handler set:

    std::set_terminate([] {
CRASH();
});

Even if such issues are very rare, I think it makes sense to set this
up always, since a simple backtrace is a lot better than nothing in
such cases. Are there any objections to always setting this terminate
handler? For my debugging today, I put it in
WebKit::ChildProcess::initialize, which seems like a decent place, but
maybe not the best place. Are there any other suggestions for where to
put this code? I presume this would be desired for all ports, but we
could certainly do it somewhere platform-specific if that's not the
case.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

On Fri, 2016-09-09 at 10:47 -0700, Anders Carlsson wrote:
> On macOS and iOS, we already get this by setting
> NSApplicationCrashOnExceptions in our initialize function.
> 
> - Anders

OK, so we'd have to do it in ChildProcess::platformInitialize to not
disturb you then.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

On Fri, 2016-09-09 at 11:03 -0700, JF Bastien wrote:
>    - The state of the stack when std::terminate is called is
> implementation
>    defined (it could be unwound, unwound partially, or not unwound at
> all).

Hi, I think it's very unlikely to ever be unwound because we compile
with -fno-exceptions?

>    - std::terminate can be called from atexit or at_quick_exit which
> means
>    that global state can be partially broken.

In fact, that's exactly what's occurring in the crash that prompted me
to look into this.

>    - CRASH sometimes behaves in a manner which will cause signals to
> be
>    generated, and installSignalHandlersForFatalErrors registers
> signal
>    handlers (which sometimes calls dumpBacktraceSignalHandler which
> then calls
>    exit, leading us back to atexit).

Hm, installSignalHandlersForFatalErrors is only called
from WTFInstallReportBacktraceOnCrashHook, which is not called from
anywhere on any port, so this can't happen.

Anyone know why we have these unused functions? Are they there to be
used in modified debug builds, or should they be removed?

> The chance for undefined behavior, weirdly circular call graphs,
> exploitable behavior, or all three, seems pretty high here and very
> dependent on configuration at compile-time.

Maybe it makes sense to do this only in debug builds? I agree that
playing with undefined behavior doesn't seem wise, but in practice it
worked very well to get a backtrace for a bug that would otherwise be
difficult to debug.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Tue, 2016-09-20 at 18:35 +0900, Fujii Hironori wrote:
> I'm interested in bumping cmake_minimum_required for
> .
> Which version of CMake is minimum version to be supported?

Hi,

WebKitGTK+ intends to continue supporting 2.8.12 until April, when we
drop support for Ubuntu 14.04. So the new features you want to use
should be used conditionally on the CMake version being high enough,
without bumping the minimum requirement.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Tue, 2016-09-20 at 17:57 +0200, Carlos Garcia Campos wrote:
> So, is our deps policy about build-time only dependencies too? I
> don't
> think it should be.

The problem, as you're well aware, is that once our build dependencies
exceed what's available in a particular distro, that distro will just
say "well I guess we can't do any WebKit updates anymore" and then
users get no more security updates ever. So I would very much like to
count build dependencies towards this policy. Even if it's technically
possible to build packages with custom versions of build dependencies,
I've never seen any distro do it and it's not a fight we're going to
win. Ubuntu just did a major WebKit update, which is great; let's not
imperil future updates.

If we don't want our dependency policy to apply to build dependencies,
we'd need to edit [1].

Michael

[1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, 2016-09-21 at 18:09 +0900, Fujii Hironori wrote:
> Ubuntu 14.04 has GCC 4.8 and build fails with a following error
> message.

Hm that's a good point. Looks like that ship has already sailed. No, we
don't want to support GCC 4.8. Our dependency policy is only a month
old, and we just didn't notice this yet. :)

In that case, we're fine with requiring CMake 3.0 (the version in
Debian Jessie), but I think Apple is using a lower versions than that
so we need to hear from them. Alex?

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove Battery Status API code

[Michael Catanzaro]

On Sun, 2016-10-30 at 17:14 -0700, Brady Eidson wrote:
> What to other Apple folks think? What do port maintainers who enable
> the API think?

Hi,

The GTK+ implementation has been broken for years [1] so we're
definitely not going to miss it!

Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=129040#c4
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GPU rendering possibility

[Michael Catanzaro]

On Fri, 2016-11-04 at 08:23 +0100, Carlos Garcia Campos wrote:
> What I can say as the GTK+ port maintainer is that we are very
> interested in this. We are actually looking for a cairo replacement,
> because unfortunately cairo is nowadays pretty much unmaintained. So,
> if FastUIDraw can be used by the GTK+ port to replace cairo, and the
> performance improvement is so impressive we would definitely switch.

Yes, to be clear, Carlos is representing the WebKitGTK+ development
team here. Since WebKitGTK+ is the currently primary WebKit port used
by Linux distros [1], that means this work would have the potential to
be widely-deployed on Linux desktops worldwide. Maybe that will help
you in your quest for funding. Of course, we can't say whether we would
actually switch to this implementation before the code actually exists,
but we're definitely interested.

Other ports may not be as interested, as different WebKit ports have
very different graphics architectures. For instance, the Apple ports of
course don't run on Linux at all. But if you can demonstrate a
significant performance improvement in WebKitGTK+, then other ports
might take more notice.

I should mention, though, that we require support for hardware that
only supports OpenGL ES 2.0. If FastUIDraw can't handle this, then we
would need to keep a fallback codepath that uses Cairo, which would be
unfortunate.

Michael

[1] Sorry Konstantin ;)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Experimental features enabled at runtime

[Michael Catanzaro]

Hi,

We discovered that several experimental features are currently enabled
by default:

https://bugs.webkit.org/show_bug.cgi?id=164367

It looks like the change was made to avoid needing to enable the
features manually in Safari Tech Preview, but of course this is bad for
all the non-Safari WebKit ports which surely do not want experimental
features enabled by default.

Can we fix the WebKit project defaults please? These features are not
ready to be default, or they wouldn't be listed as experimental. They
should be enabled by Safari if they're desired there.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Experimental features enabled at runtime

[Michael Catanzaro]

Hi Brady!

On Sat, 2016-11-05 at 11:04 -0700, Brady Eidson wrote:
> This has come up in Apple, where some people assume that the fact
> they're called "Experimental" features means they are still under
> heavy development or in some way unstable or potentially harmful.
> 
> I don't believe that is actually the case.

Surely if the feature is stable, then it should be moved to the non-
experimental section of WebPreferencesDefinitions.h. Stable features
shouldn't be touched
by FOR_EACH_WEBKIT_EXPERIMENTAL_FEATURE_PREFERENCE.

> Ignoring the name for a moment, the _WKExperimentalFeature API really
> does precisely two things:
> 1 - Exposes an enumerable set of runtime-enablable features.
> 2 - Exposes an API to turn each of them on or off.
> 
> That's it.
> 
> For a long time we've had "runtime enabled features" in the project
> with no way to expose them as an enumerable set to the API client.
> The API was named "Experimental" feature, I think, because at first
> only "under heavy development" features that were not ready to be
> enabled at runtime adopted the mechanism.

This is surprising to me! We've had API for this in WebKitGTK+ for a
long time (WebKitSettings.h), and there's extensive cross-platform
infrastructure to support it (WebPreferencesDefinitions.h). Of course I
agree it makes sense to have non-experimental settings that can be
enabled or disabled at runtime. It sounds like Cocoa API changes are
required to support this?

> > They should be enabled by Safari if they're desired there.
> 
> The ones that have been deemed fit to be "enabled by default" for
> testing should be on by default for testing in places other than
> Safari, such as MiniBrowser and 3rd party WebKit apps.

Good point.

> I strongly object to reverting all _WKExperimentalFeatures to "off by
> default"
> 
> I strong support adding port-specific defaults.
> 
> As a different conversation, I also support renaming the API to
> something that doesn't impart the baggage of an "under development"
> or "unstable" feature.

Well we already have GTK+-specific defaults for runtime settings in
WebKitSettings.cpp, but only for the subset of the settings that are
exposed in our API. We can't use it for all settings, though, because
we don't want every setting to become API forever, and we don't want
non-GTK+ developers to have to remember to add GTK+ API for every new
runtime feature.

I'm not actually sure that we do need port-specific defaults for
runtime settings. I think that in general, we really want to use the
same defaults as Apple. You know better than we what the settings do
and how stable they are. The exception would be when settings need
platform-specific implementation, but in that case I'd expect the
options would have to be guarded by build flags, and we already have
port-specific defaults for build flags.

But we surely don't want anything labeled experimental to be enabled by
default for end users. I really doubt you would want such features
enabled in stable versions of Safari either, right?

Maybe what we really need is one set of defaults that are appropriate
for development (our bots, ENABLE(DEVELOPER_MODE), Safari Tech Preview,
etc.) and a different set of defaults that are appropriate for stable
releases and end users. We already have this for build options
(FeatureList.pm for developer settings where we enable experimental
stuff, WebKitFeatures.cmake for end-user settings where we do not) but
we have no analog of this for runtime options. So one possibility would
be to have two lists of default values of experimental features: one
used in ENABLE(DEVELOPER_MODE) which turns on all the new fun stuff,
and one for !ENABLE(DEVELOPER_MODE) which is more conservative.
Probably that would work for all ports without requiring port-specific
defaults? (If not, I guess we'll just have to add port-specific
defaults after all, but hopefully we don't need to!)

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Experimental features enabled at runtime

[Michael Catanzaro]

On Sat, 2016-11-05 at 16:03 -0700, Ryosuke Niwa wrote:
> Maybe what we really need is one set of defaults that are appropriate
> > for development (our bots, ENABLE(DEVELOPER_MODE), Safari Tech
> Preview,
> > etc.) and a different set of defaults that are appropriate for
> stable
> > releases and end users.
> 
> 
> That makes sense.  Ideally,
> FOR_EACH_WEBKIT_EXPERIMENTAL_FEATURE_PREFERENCE
> is only used for features that need to be enabled in those "beta" or
> "developer" versions of each port's browser.

Yeah, it could be as simple as all those experimental features are
enabled by default in the ENABLE(DEVELOPER_MODE) case, and they're all
disabled otherwise. Though then there's no way to have features
runtime-enabled features that are too unstable even for Tech Preview.

All CMake ports support ENABLE(DEVELOPER_MODE); is that defined
anywhere with the XCode build?

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Bugzilla clock

[Michael Catanzaro]

I notice that the clock on Bugzilla is about four minutes fast. I guess
it's not using NTP?

This is not anywhere near as important as not being able to commit.
It's just very slightly annoying. But I did want to report it
somewhere!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bugzilla clock

[Michael Catanzaro]

On Mon, 2016-11-14 at 15:13 -0800, Lucas Forschler wrote:
> This is really strange… When I compare the date on bugs.webkit.org to
> my local time, bugzilla is actually 2 minutes behind. 
> I don’t see any NTP errors when syncing.
> Adding Ling to see if he has any ideas, or bandwidth to investigate.

FWIW Bugzilla is still a couple minutes fast for me as well. It's a
relatively recent problem (started within the past few weeks).

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Web inspector images

[Michael Catanzaro]

On Tue, 2016-02-09 at 11:44 -0800, Timothy Hatcher wrote:
> Hi Michael,
> 
> I am looking into our options for the license of the images. Stay
> tuned.
> 
> — Timothy Hatcher

Hi Timothy,

Any update on this?

We should really remove these images from OpenSource if Apple does not
want to relicense them.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

[Michael Catanzaro]

On Fri, 2016-12-23 at 05:42 +, Yusuke SUZUKI wrote:
> Personally I like the name "SetForScope" since the name "scope"
> states that this value change is tied to C++ scope.

Me too. The name is pretty clear. The first time I saw TemporaryChange
I had to look at the implementation to see what it did.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] fullscreen-webkit.c

[Michael Catanzaro]

On Thu, 2016-12-29 at 14:26 -0500, Jerry Geis wrote:
> Hi All,
> 
> I took fullscreen-webkit.c and added some functionality.

Hi,

So my first question would be: where is this file? We can't help you
much if we don't know what you're doing. :)

> I now updated to CentOS 7.3 and the program still works - BUT - after
> the the first message (which does go full screen and no scroll bar)
> for some reason it activates the right scroll bar on a page that has
> no scroll. Just a simple message.
> 
> Is there a reason for that ? 
> Any thoughts?
> 
> Jerry
> 
> These are the files on the CentOS CD for CentOS 7.2 and CentOS 7.3
> for webkit.

This version of WebKit is extremely old and insecure; you won't be able
to get any support for it upstream, sorry. If you can reproduce with
the latest stable version, currently 2.14.2, then you could file a bug
report for the scrollbar appearing unnecessarily.

I did a quick check of the CentOS sources [1] and it looks like the
only change between 7.2 and 7.3 was a German translation update, so no
guesses as to what could have caused the change in behavior. I had
thought modern WebKit was coming to CentOS, because Red Hat was working
on another GNOME rebase and it's needed for that, but looks like that
didn't happen for 7.3.

Michael

[1] https://git.centos.org/summary/?r=rpms/webkitgtk3
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Michael Catanzaro]

On Thu, 2017-01-05 at 17:48 +0900, Yusuke SUZUKI wrote:
> 1. specifying "org.webkit.ImageDecoder"
> 2. In Linux, we just use "ImageDecoder" part.
> 3. In macOS port, we automatically convert it to "WebKit: Image
> Decoder"

This sounds like a good path forward that works for all platforms.

It's a shame that low platform limits have made this unnecessarily
complicated. Traditionally, Linux folks shame older UNIXes for having
such low limits; it's interesting to be on the other end of this
now

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Sun, 2017-01-08 at 18:59 +0100, z...@falconsigh.net wrote:
> For the record, GCC 5 has complete C++14 support. The current
> requirement is 4.9, so the bump would be minimal.
> https://gcc.gnu.org/projects/cxx-status.html#cxx14

We would need to redefine our dependencies policy:

https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

We just recently crafted that policy. I kinda like it because it
provides a clear formula for deciding whether a compiler is too new to
be required or not. It means we would support GCC 4.9 until roughly
next spring/summer, one year from the next Debian release. We could
either (a) drop Debian from the policy, which I support doing anyway
because it does not take our security updates, or we could (b) define
the policy in terms of runtime dependencies, rather than build
dependencies (which I think Carlos Garcia wanted to do anyway). Either
way makes it more likely that distributions will get cut off and choose
to not provide WebKit security updates. I would prefer not to do (b),
because in practice distributions will just not take our updates if
they can't use their default compiler.

Keep in mind that for a distro to upgrade from GCC 4.9 -> 5.0 is weeks
of effort unless you build GCC with the flag that turns on the old C++
ABI, but you have to switch to the new ABI eventually, so might as well
do it at the same time. I have to support WebKit for a distribution
that has been delaying the upgrade for this reason. GCC upgrades are
expensive and not fun. Even turning off the ABI switch, upgrading GCC
means lots of obscure C++ build failures in packages you're not
familiar with.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
> Another idea is: (c) Drop the "one year after the release"
> requirement.
> Which means that we could update to minimum GCC version to 5.3 (the
> one
> in last Ubuntu LTS) when Debian 9 is released (which hopefully is
> expected to happen around the middle of 2017).
> 
> A date that I guess will be near enough to when VS2017 is released.
> 
> This will mean that instead of supporting up to 3-year old
> dependencies
> we will only support up to 2-year old ones.
> I'm not particular enthusiast about this, but I'm ready to understand
> that supporting 3-year old dependencies is not realistic on a project
> like WebKit.

I think it is totally realistic to support 3-year old dependencies.
There's absolutely no reason we cannot do it if we want to. The latest
compiler features are nice-to-haves, not requirements.

But I agree that this would be a good solution if we want to bump the
GCC requirement sooner. As you pointed out, it would allow us to do
that this summer rather than next summer.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
> I strongly oppose to do (a). Also, it is false that Debian doesn't
> take
> our updates. They take our updates in the backports repository for
> stable.

Nobody uses that. Users expect to receive security updates in the
security repository.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Mon, 2017-01-09 at 16:56 +0100, Carlos Alberto Lopez Perez wrote:
> Can you please explain how you reach that conclusion?
> Do you have any data to back up such claim?

No, I don't have data, but it seems extremely naive to assume that any
significant subset of users use backports. It is not enabled by
default, and we know users almost never change defaults. Reasonable
users assume they are receiving security updates by default.

This seems to have diverged from the topic at hand, though. I agree
your proposal to remove the +1 year requirement is better than both of
mine, so if we decide to bump the compiler requirement that's the one
we should choose.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] some problems and wishes

[Michael Catanzaro]

On Tue, 2017-01-10 at 22:42 +0300, Oleg Milovidov wrote:
> Dear Sirs!
> I built WebKit2Gtk release 14.2 under Linux Mint 18 gcc compiler on
> 13/11/2016. 
> It works stable! 
> I use the product for embed web C++ application (Gtk-3).
> I noticed some problems and I have some wishes with the product.
> 1. Size of downloading resource.
> It is important for user to know the size of downloading resource. I
> know that servers sometimes do not send this information. But
> sometimes other browsers and curl can receive the size of resource,
> when WebKit2Gtk returns 0. I use curl in this case internally.
> I wrote embed WebBrowser under MS Windows. IE WebBrowser Control
> always knows the size of resource. Sometimes initially IE WebBrowser
> Control returns 0, but when downloading starts, the IDownloadManager
> always know total size of resource.

I don't know about this.

> 2. Scroll bars rendering often is strange. Scroll bars change own
> images. Some old parts of page under transparent scroll bars are on
> them. Scroll bars need to be invalidated?

That shouldn't happen. Are you using the default GTK+ theme (Adwaita)?
If not, does your GTK+ theme support overlay scrollbars?

> 3. Segmentation error when I was trying to read:
> bool value =
> webkit_settings_get_allow_universal_access_from_file_urls(settings);

That shouldn't happen either. Did you pass in a valid WebKitSettings
object obtained from webkit_web_view_get_settings()?

> 4. Compilation of an extension was problem. I defined symbol
> __WEBKIT2_H_INSIDE__. After that I can compile an extension with
> WebView and manually included ,
>  and others.

You cannot use UI process headers from the web extension because the
web extension runs in the web process, not the UI process. There's
nothing good you could do with those headers. ;)

> 5. I was trying to use model:
> WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES.
> But second web page in the next notebook page do not start
> downloading. So I was unsuccessful with the model.

I don't know about this either. It should work. :(

> 6. User agent string. Well known in Russia mass media
> site http://www.rbc.ru/ detected my browser as very old and there
> were serious problem with rendering the site. When I change UAS to
> "Mozilla/5.0 (X11; Linux) AppleWebKit/602.1 (KHTML, like Gecko)
> Chrome/54.0.2840.59 Safari/8" problem disappeared.
> But Google maps begun inform me with new UAS that «It is simplified
> mode. Your browser do not support full version of Google maps». I
> consider that Google maps rendering with Google Chrome is better that
> with WebKit2Gtk. So Google maps is a good test from my point of view.

Please file a bug report, and respond to this mail with a link to the
bug so that I see it. I will add it to our user agent quirks list.

> 7. Font size for Web Inspector is too small for me. Some editable
> style config for Inspector, including zoom control 
> will be good.

Don't know about this either.

Hope I helped a little,

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Michael Catanzaro]

Perhaps we need to be especially careful about replacing Refs and
RefPtrs with auto. It was mentioned that using typedefs to hide pointer
types is often the source of serious bugs. A similar rule could apply
to using auto with smart pointers.

On Wed, 2017-01-11 at 09:43 -0800, Darin Adler wrote:
> > On Jan 11, 2017, at 9:41 AM, Alexey Proskuryakov 
> > wrote:
> > 
> > In a way, these are read-time assertions.
> 
> Exactly. A type name is a read-time assertion of the specific type
> that a variable has and “auto” is a read-time assertion that the type
> of the variable is the same as the type of the expression on the
> right.
> 
> — Darin

That is a useful observation. Consider this simple scenario:

int i = returnsSomeIntType();
auto i = returnsSomeIntType();

Sometimes you want a variable that is the same type as the expression
on the right, and you are worried about possible bugs if the type of
the expression on the right changes. In my experience, this is the
typical case. Then auto is probably most appropriate. For instance, if
the function returns an int but in the future is changed to return an
int64_t, then you will be very happy that you chose to use auto, as it
avoids a truncation bug that would have been extremely difficult to
discover through code inspection. We face exactly this problem, for
example, in bug #165790, where the goal is to change the type of a
function from unsigned to size_t, but the function is named "length" so
it's virtually impossible to grep for call sites to update. (On the
other hand, you really always have to check call sites in such a
situation, because we have not always used auto.)

But sometimes the type of the expression on the right is not so
important. For instance, I reviewed a patch recently where I discovered
a very subtle integer underflow bug. It was not caused by auto, so it's
not a perfect example, but in this case it was important to ensure
that, regardless of the type returned from the function, it needed to
be assigned to a variable of type int64_t to avoid underflow later on.
In this case, auto was an inferior option, as the only way to safely
use auto would have been this:

auto i = static_cast(returnsSomeIntType());

which is surely inferior to just not using auto:

int64_t i = returnsSomeIntType();

Michael

P.S.

Not very related: the underflow in question was of the form

int64 result = a - b()

where a was a size_t, and b() returned a size_t, and we wanted to
receive a negative result if b() was greater than a. This is such an
easy mistake to make and very difficult to spot. :/ It's worth a little
paranoia to consider that an attacker might try to intentionally insert
such a vulnerability.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Tue, 2017-01-10 at 21:28 -0800, Darin Adler wrote:
> Given that WTF chose , what is the reasoning for PAL
> choosing the all capital ?

I kinda prefer  myself, in order to parallel WTF. On the one
hand, it almost doesn't matter, but on the other it's one more rule to
have to memorize which includes must be lowercase and which must be
uppercase.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

Really happy to see progress on this!

On Tue, 2017-01-10 at 21:24 -0800, Myles C. Maxfield wrote:
> First of all, this isn’t a new project; instead, it’s a new target
> inside the WebCore project. The target creates a static library which
> gets linked into WebCore, which means that the enforcement mechanism
> can’t be done by the linker. Instead, the layering will be enforced
> by a Python script, triggered as an extra build step, which checks
> the symbol names inside the .a file as well as #include directives in
> source code.

My preference remains to put PAL inside the toplevel Source/ directory
and make it a proper dependency of WebCore, because it seems far
superior to have the linker enforce layering. (A secondary concern is
that it will be nicer to say PAL::Foo rather than WebCore::PAL::Foo
when using PAL from the WebKit and WebKit2 layers.)

I appreciate that the decision to make it a target rather than a
dependency was driven by a desire to simplify the build system, and I
also appreciate that CMake and XCode are both complex beasts. But I
don't think this is the right approach. Consider that there is very
little material advantage to WebCore/PAL over the existing
WebCore/platform: we already have Tools/Scripts/check-for-platform-
layering-violations to check for platform layering violations, so the
only real advantage to adding PAL would be that PAL doesn't currently
have any such layering violations and so the layering enforcement
script could be run by the style checker. If that were the only goal,
then it would be simpler to keep WebCore/platform and just fix the
layering violations than to slowly move everything to a new directory.
I'd much rather let the linker handle layering enforcement; then there
is real value to splitting out PAL.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, 2017-01-11 at 23:30 +, Olmstead, Don wrote:
> I had thought of PAL as a library that is internal to WebCore that
> provides a clear porting layer. I would not expect anyone outside of
> WebCore to be linking to it.

So honestly, I don't think this is very realistic. Lots of stuff
currently under WebCore/platform needs to be used by WebKit and
WebKit2. ResourceHandle, for example. Or TextChecker. These are just
the very first two that come to mind. So if we want PAL to be
completely internal to WebCore, then we're not going to be able to get
rid of WebCore/platform, and then we'll have two different platform
abstraction libraries. That does not seem desirable. Moreover, the
criterion to determine whether a class should go in PAL or platform
would then be whether the stuff needs to be accessed from WebKit layers
or not. That doesn't seem useful.

So I think we should drop that goal. (Still really excited for PAL, of
course.)

On Wed, 2017-01-11 at 23:30 +, Olmstead, Don wrote:
> Whatever the consensus is we’re looking forward to working on getting
> the PAL layer up and running. We’re working on rebooting our port so
> we’re in a good position to help build it out and do any refactoring
> to help create a clear layering. Having a clear porting layer,
> especially one with tests, is something we’re hoping will be
> beneficial to all the ports.

This is exciting to hear too!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Fri, 2017-01-13 at 11:39 -0200, Gustavo Sverzut Barbieri wrote:
> On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen
>  wrote:
> > If PAL were a shared library in a CMake build, then it wouldn’t
> > build successfully if there were layering violations.  I think we
> > should do something like that to enforce good design, even if the
> > Mac Xcode projects treat it as a static library or even just a part
> > of WebCore.

Why does it matter if it's static or shared? Surely if PAL is build
before WebCore, and it's missing symbols at link time (because those
symbols actually exist in WebCore) and not linked to WebCore, then PAL
will fail to link regardless of whether it is a shared library or 
static library? Am I just downright wrong to assume this, or does it
work differently on Mac...?

(This is the biggest problem I see with the current plan. Regardless of
where the directory goes and what the namespacing looks like, I really
want to use the linker and not a python script to enforce layering.)

> Actually for development it would make lives much easier to keep it
> as shared library, reducing compile time and help to segment the
> symbols in a different space (linkers, gdb)
> 
> what if it becomes shared by default on Debug builds, static by
> default in Release? 

For GTK+, I'd really like it to be always a static lib as that's what
we need to ship and I wouldn't want to support multiple configurations.
Debug fission has solved our troubles with link time and gdb slowness.
But here it's possible for different ports to do different things. E.g.
some ports support building WebCore as a shared library, which is not
supported by GTK+.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Bugzilla spammer

[Michael Catanzaro]

Hi,

We appear to have a Bugzilla spammer [1]. The user posts a link to an
unrelated website (I guess trying to improve SEO) and gave herself away
by asking a nonsensical question about the bug (a request for detailed
instructions on how to solve the bug when the bug was "add a comment").

In GNOME Bugzilla we have been getting spammers with some regularity;
the admins there lock or delete the accounts and remove all their
posts, and remind them that Bugzilla comments don't contribute to their
SEO. We might want to follow the same approach to discourage more such
comments if this becomes a bigger problem for us in the future. GNOME
also has a dumb keyword filter [2] that's fairly effective at stopping
specific spammers if any particular spammer is persistent enough to be
annoying.

Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=162618#c4
[2] 
https://git.gnome.org/browse/bugzilla-gnome-org-customizations/tree/extensions/GNOME/Extension.pm?id=ed10237c723252eed886eb5a20467c932624be6d#n315
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
> Static (At least for the Xcode projects. I imagine the cmake-based
> projects could do whatever they want here).

For GTK+ we really want static as well, we do not want a new shared
library. So no difference here.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Settings and Testing (Settings, RuntimeEnabledFeatures, WebPreferences)

[Michael Catanzaro]

Thanks for this writeup.

I encourage you to move this knowledge to a wiki page on trac, so we
don't lose it here in the list archives.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ReadMe.md on Github

[Michael Catanzaro]

On Tue, 2017-02-21 at 22:53 -0800, Ryosuke Niwa wrote:
> I feel like GTK+ port's instruction can be consolidated enough to fit
> there but we might want to write some script that someone can run to
> do everything you need like Tools/Scripts/configure-xcode-for-ios-
> development for iOS first.

Currently there are just two scripts (install-dependencies and update-
webkitgtk-libs), and they are sufficiently-different that they should
not be consolidated.

That said, a pointer from the README to somewhere else is fine for us. 
Certainly that's the way to go if the goal is to reduce the size of the
README. I would go as far to remove the Mac/iOS build and run
instructions and just point to the website for all ports. The more
content we duplicate in the README, the more content we have that will
get out of sync with the website.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, 2017-02-22 at 08:52 -0500, Jacob Greenfield wrote:
> The (USB) protocol itself works by sending USB HID reports (packets)
> to the key and getting USB HID reports back. There is a reference
> implementation by one of the members of the specification group -
> libu2f-host (by Yubico); however, it is licensed under GPL and
> LGPLv2.1.

Hi,

According to the documentation:

"The library and command-ine tool is licensed under the LGPLv2+
license. Some other files are licensed under the GPLv3+ license."

Sounds like a perfectly acceptable dependency for WebKit. The only
trick is that if you need to import the source code under
Source/ThirdParty (hopefully not), then you'd need to remove all the
GPLv3+ files from the repository.

> - What to do about other platforms - no implementation, use libu2f-
> host for them, or use libu2f-host everywhere

Ideally we would use the same code on all platforms unless there is a
strong reason not to do so, to reduce the amount of platform-specific
bugs. I'm not sure if there exists such a situation here, so using
libu2f-host on all platforms seems to make the most sense. Possible
examples of strong reasons to diverge:

 * If removing the GPLv3+ files would be somehow problematic. GTK+ port
doesn't care so long as none of the GPL files are used by the library
itself. Apple is much stricter; I guess they might not allow the files
to be imported into internal build systems. That could create a
maintenance headache.
 * If the extra dependencies are problematic for some platform. You'd
be hard-pressed to find a Linux system without libusb, and hidapi and
libu2f-host both look unproblematic. But adding your implementation
directly to WebKit might be easier for Mac ports.

> - UI for key access permission - malicious sites could (eventually)
> lock up a key, as well as possibly identifying a user; the
> specification suggests displaying an info bar for user to allow
> access - but, I’m not familiar with the process of designing/adding
> browser chromes

Sounds like WebKit should request a policy decision from the client on
whether to allow a website to use the U2F API? Then making that
decision in a secure manner is the responsibility of the client to
figure out. In Epiphany we display info bars the first time a
particular security origin requests a permission, and remember the
user's choice in the future.

> - What process should communicate with the token - the protocol is
> robust and designed for many simultaneous accesses and appropriate
> isolation of them, so this can (should?) be per-page; IOKit needs a
> CFRunLoop to schedule the report receive callback on: should this be
> on the main runloop or on another thread just for U2F?

I don't know which process, but you should use the main runloop. Let's
avoid creating a new always-running thread for a feature that will
rarely be used.

> - Presumably, this should be gated behind a macro; does a suitable
> one exist, or add a new one?

You'll have to add a new one, ENABLE_U2F. It's better not to gate
features when possible, but in this case one will be required due to
the new dependencies as we want to allow distributions that do not have
the new dependencies to continue to build without them (with reduced
feature set) for the next few years.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Catanzaro]

On Wed, 2017-02-22 at 12:20 -0500, Jacob Greenfield wrote:
> Michael,
> 
> Thanks for the info. After looking into things a bit more - let me
> know if this does not make sense - it looks like it may be better to
> reimplement for WebKit.

OK, your explanation sounds reasonable to me.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

[Michael Catanzaro]

On Wed, 2017-02-22 at 11:58 -0800, Geoffrey Garen wrote:
> (2) Change RELEASE_ASSERT to do the normal debug ASSERT thing in
> Debug builds. (There’s not much need to preserve register state in
> debug builds.)

This seems like a more desirable approach.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Port For Android

[Michael Catanzaro]

On Tue, 2017-03-07 at 18:35 -0500, Patrick Wright wrote:
> Is there a webkit port for Android that is readily available?  

No, sorry. This is actually the first time I've heard any interest in
WebKit for Android.

> That comes with the minibrowser option that normal GTK webkit has.  I
> want the mini browser for android but don't want to use angle if
> possible.  

For better or for worse, all WebKit ports require ANGLE.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev