Re: [webkit-dev] Pthread

[Brady Eidson]

(webkit-dev to BCC)

webkit-dev is a list for the development of WebKit itself.

webkit-help is much more appropriate for conversations about getting your own 
private build up and running.

Thanks,
~Brady

> On Jul 7, 2017, at 5:05 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 07.07.2017, 15:01, "Nagendra K" :
>> Hi All,
>> 
>> When building JavaScriptCore I am not able to link pthread calls.
>> Is there a way we can specify the CMakeLists.txt with option to include 
>> pthread.
>> 
>> I am using Ubuntu machine to build.
> 
> You need to link ${CMAKE_THREAD_LIBS_INIT}, see
> 
> https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformGTK.cmake#L24
> https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformJSCOnly.cmake#L54
> 
>> 
>> Thanks and Regards,
>> Nagendra
>> ,
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

[Brady Eidson]

> On Sep 1, 2017, at 9:46 AM, Maciej Stachowiak  wrote:
>> 
>> Does RefPtr do anything for us today that std::optional doesn’t?
> 
> The obvious things would be: uses less storage space

Grumble. If that’s true (which, thinking about it, of course it is true) this 
is pretty much a nonstarter. So… nevermind.

Thanks,
~Brady


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

[webkit-dev] Get rid of RefPtr, replace with std::optional?

[Brady Eidson]

I recently worked on a patch where - because of the organic refactoring of the 
patch over its development - I ended up with a std::optional instead of a 
RefPtr.

A followup review after it had already landed pointed this out, and it got me 
to thinking:

Does RefPtr do anything for us today that std::optional doesn’t?

I kind of like the idea of replacing RefPtr with std::optional. It makes 
it explicitly clear what object is actually holding the reference, and 
completely removes some of the confusion of “when should I use Ref vs RefPtr?"

Thoughts?

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Service workers

[Brady Eidson]

> On Aug 3, 2017, at 12:14 AM, Yusuke SUZUKI  wrote:
> 
> I've just seen some of initial work about service workers[1,2].
> So, have we started experimenting with implementing service workers?

https://trac.webkit.org/changeset/220220/webkit 


Thanks,
~Brady

> [1]: https://bugs.webkit.org/show_bug.cgi?id=175115 
> 
> [2]: https://bugs.webkit.org/show_bug.cgi?id=175053 
> 
> 
> Best regards,
> Yusuke Suzuki

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

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

[Brady Eidson]

> On Aug 1, 2017, at 11:18 PM, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>> Some others I see:
>>> 
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>> 
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>> 
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>> 
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
> 
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

INDEXED_DATABASE can be built and used without the SQLite dependency; We have 
our own fully supported in-memory backing store for private browsing that could 
be used by any port for mainline browsing as well.
In fact, the in-memory store would be a fine default store for a port that 
doesn't even specify an IDB database directly.

At this point in the web platform and the lifecycle of IndexedDB I think it's 
problematic for any port to pretend it doesn't exist.

I support removing this one, as well.

Thanks,
 Brady

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

Re: [webkit-dev] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

[Brady Eidson]

> On Jul 28, 2017, at 10:29 AM, Sam Weinig <wei...@apple.com> wrote:
> 
> For some generic programming, this form can be dramatically shorter:
> 
> e.g. 
> 
> template KeyTraitsArg, typename MappedTraitsArg>
> template
> ALWAYS_INLINE auto HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
> MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
> {
> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
> HashFunctions>>(std::forward(key), std::forward(value));
> }
> 
> vs.
> 
> template KeyTraitsArg, typename MappedTraitsArg>
> template
> ALWAYS_INLINE typename HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
> MappedTraitsArg>::AddResult HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
> MappedTraitsArg>::inlineAdd(K&& key, V&& value)
> {
> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
> HashFunctions>>(std::forward(key), std::forward(value));
> }

In this example, yes it is notably shorter.

But neither of these definitions are remotely readable without puttin' on your 
thinkin' cap.

> It is also the only format available for lambdas, so people are probably 
> getting used to it.

Lambdas don't have the problem of prepare-ChangeLog completely missing edits to 
a member function

> Not sure it’s worth it to avoid it.

My request was to be aware of this while prepare-ChangeLog was broken for this 
case.
Seems like that's almost fixed. :)

~Brady

> 
> - Sam
> 
>> On Jul 27, 2017, at 11:06 PM, Brady Eidson <beid...@apple.com 
>> <mailto:beid...@apple.com>> wrote:
>> 
>> I just noticed this tonight. When a change is made to one of these 
>> functions, prepare-ChangeLog doesn't log the functions that changed.
>> 
>> I have a question and a request.
>> 
>> Question:
>> 
>> The functions in question where I noticed this:
>> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
>> ExceptionType
>> 
>> Would normally be written as:
>> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
>> ResourceError& error)
>> 
>> Is there some actual value to using this syntax other than… being 
>> syntactically different, and being just a little shorter?
>> 
>> Request:
>> 
>> Until we fix prepare-ChangeLog, and unless there is some great advantage to 
>> this syntax that I'm not aware of… it's hold off on using it more.
>> 
>> Thanks,
>> ~Brady
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

[webkit-dev] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

[Brady Eidson]

I just noticed this tonight. When a change is made to one of these functions, 
prepare-ChangeLog doesn't log the functions that changed.

I have a question and a request.

Question:

The functions in question where I noticed this:
auto WebURLSchemeTask::didComplete(const ResourceError& error) -> ExceptionType

Would normally be written as:
WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
ResourceError& error)

Is there some actual value to using this syntax other than… being syntactically 
different, and being just a little shorter?

Request:

Until we fix prepare-ChangeLog, and unless there is some great advantage to 
this syntax that I'm not aware of… it's hold off on using it more.

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

> On Jun 27, 2017, at 9:36 AM, Carlos Garcia Campos <carlo...@webkit.org> wrote:
> 
> El mar, 27-06-2017 a las 18:19 +0200, Carlos Garcia Campos escribió:
>> El vie, 16-06-2017 a las 09:43 -0700, Brady Eidson escribió:
>> [...]
>>>>> If not, I can get rid of it right now
>>>>> 
>>>>> If so, then I need a GTK maintainer to come up with a plan
>>>>> soon.
>>>> 
>>>> How soon is soon? :-) We are approaching the end of our release
>>>> cycle,
>>>> it would be good for us if we could do any changes related to
>>>> this
>>>> after we branch for 2.18. Of course I can branch earlier if
>>>> needed.
>>>> According to our schedule we should branch the first week of
>>>> August. Is
>>>> that late?
>>> 
>>> That’s much later than the soon I was targeting.
>>> 
>>> Hoping to do this by the end of June.
>> 
>> Ok, I've found time today to work on this. I don't have time to re-
>> implement WebKitFaviconDatabase using a different database model, so
>> I've copied IconDatabase from WebCore to WebKit and used it directly
>> from WebKitFaviconDatabase. I've switched the client implementation
>> to
>> API::IconLoadingClient too. So, I think you can just remove all the
>> WebCore and WebKit2 code after the patch lands.
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=173877
> 
> I forgot to say that copying IconDatabase is just a temporary solution,
> because I don't have time for a proper solution now, so during our next
> release cycle I'll try to either improve or replace it with a new
> implementation that allows to store multiple icons and sizes for the
> same page, etc.

This is great. Thanks!

I’ll review shortly.

~Brady

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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

> On Jun 16, 2017, at 11:11 AM, Maciej Stachowiak  wrote:
>>> This is slightly tangential, but a comment on the model: it doesn't seem 
>>> like there's a way for clients to check what range of icons are available 
>>> and only then choose which to load. Even though Safari may not have needed 
>>> this to move over, if you wanted to do something rigorous like load the 
>>> closest available size to what you need or else a scalable format, there's 
>>> no way to do that without potentially loading icons you don't need. While 
>>> Safari hasn't done this, it might be useful if Safari's various places that 
>>> display icons are ever made more consistent and coherent.
>> 
>> This was discussed when implementing the model for Safari, which was 
>> admittedly done quickly.
>> 
>> While Safari didn't need what you suggest right now, they agreed they might 
>> need it in the future. Since the load decision request has a completion 
>> callback, and since it's a known implementation detail that they will all 
>> come in quick succession, it was accepted that the current model could work 
>> for "choosing the right icon of all choices" in a pinch.
> 
> How are you supposed to do this? Save all the completion handlers 
> indefinitely? I can sort of see how that could work, but if the completion 
> handler is intended to be used at a possibly later time than the 
> shouldLoadIconWithParameters: method, it's kind of weird that it's a callback 
> at all.

It definitely needs to be asynchronous because loading decisions can (often? 
always?) depend on i/o to a database.

Scenario:

1 - WebKit says “There’s a favicon of size 64x64 from URL 
“http://foo.com/favicon.ico ” - Do you want me to 
load it?
2 - Client saves off that decision handler and queries its database to see if 
it wants that icon. (Do I have this one already? Do I have it but in a smaller 
size? Is my icon weeks old and therefore I want a refreshed one?)
3 - After the i/o for the database operation, the client decides it does (or 
does not) want this icon, and calls the completion handler.


>>> I can see that there needs to be some per-icon notification, since  
>>> elements can be added after the fact, and also incremental parsing is a 
>>> thing. So one notification that tells you all icons wouldn't cut it.
>> 
>> Right - The "just one icon" notification was the bare minimum because of 
>> this need.
>> We can definitely add a greater API surface to deliver a bulk "here's all 
>> the icons in the " in addition to the individual icon notification.
>> 
>>> Another minor comment: it seems like this new API returns raw data. It 
>>> seems like the native way to use this would result in running untrusted 
>>> data from the network through image decoders outside the Web Process 
>>> sandbox. Do we have a way to avoid that?
>> 
>> This came up while implementing it for Safari, too. In practice we didn't 
>> decode icons out-of-process before so this model was not a regression. I see 
>> value in offering this, but it's also something conscientious clients can do 
>> on their own with the raw data.
> 
> It's not that easy for an arbitrary macOS app to make their own tightly 
> sandboxed service for this, and probably impossible on iOS. So if we made 
> this interface into public API, there wouldn't be a way for most clients to 
> do the right thing.

There’s a *lot* of questions to answer before we even consider making this API.

Considering nothing related to the icon database has ever been API, there 
wasn’t a compelling reason to answer those questions this time around.

>>> But separating the loading mechanism from the notification, plus adding a 
>>> notification that the  section is done parsing, could allow avoidance 
>>> of unnecessary loads. In addition, there could be other useful future uses 
>>> of a mechanism to properly load a resource as if it was being loaded by the 
>>> page. So it would be nice to decouple this from the notification of 
>>> discovering an icon link.
>> 
>> That's the full-on tangent!
>> 
>> As you know, "load an arbitrary subresource in the context of the page" has 
>> come up plenty of times over the history of the WK API, so it does seem like 
>> there's value here. 
>> Offering that, however, does seem to make the "decode the icon image out of 
>> process" less of a fit with a general purpose API.
> 
> Yeah, we'd either have to provide a generic image decoding service or make a 
> generic loading facility that's capable of vending decoded image data instead 
> of raw data, which both seem a bit inelegant.
> 
>>> Asking these questions because if this is to be the One True Model of icon 
>>> loading going forward, we should try to make sure the design is 
>>> future-proof.
>> 
>> Yes, these are all great questions to ask. 
>> 
>> Everything that's been brought up so far only really touches the API surface 
>> (Do we batch together icon load decision requests? Do we give an 
>> 

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

> On Jun 15, 2017, at 10:54 PM, Carlos Garcia Campos <cgar...@igalia.com> wrote:
> 
> El jue, 15-06-2017 a las 17:11 -0700, Brady Eidson escribió:
>> Hi all,
>> 
>> The IconDatabase in WebCore is the source of crashes, spins, and
>> complexity. Additionally it’s not flexible enough to acknowledge that
>> there’s multiple types of site icons in use on the modern web, nor to
>> adapt to the embedding client’s need for customization.
>> 
>> I recently introduced the “_WKIconLoadingDelegate” model to
>> WebKit2Cocoa.
>> 
>> WebCore gathers all of the candidate icon URLs and asks the embedding
>> app for each one whether or not it wants to load them.
>> If the app says yes, the icon will be loaded as a subresource in the
>> current document and the data will be handed off to the client.
> 
> Do we have any cache here? would we use the disk cache like with any
> other subresource?

As noted, they are loaded as subresources in the current document.
As such, they go through the memory cache and disk cache.

Note: IconDatabase loads actually worked the same way.

>> If not, I can get rid of it right now
>> 
>> If so, then I need a GTK maintainer to come up with a plan soon.
> 
> How soon is soon? :-) We are approaching the end of our release cycle,
> it would be good for us if we could do any changes related to this
> after we branch for 2.18. Of course I can branch earlier if needed.
> According to our schedule we should branch the first week of August. Is
> that late?

That’s much later than the soon I was targeting.

Hoping to do this by the end of June.

>> The icon load delegate mechanism is powerful enough to rebuild an
>> IconDatabase on top of, so if GTK needs to keep this API functional
>> they can do so - maintaining the actual IconDatabase code themselves
>> up in their API layer.
> 
> I have to look at it in detail. If I can use the new mechanism to
> reimplement WebKitFaviconDatabase, I'll definitely do that. But if
> there's no longer a database of favicons, I wouldn't mind to deprecate
> it and provide a new better API. But in any case, I need to keep
> WebKitFaviconDatabase working, whether using new way or moving the
> current IconDatabase to wk2gtk.

The new mechanism definitely provides all of the signaling necessary to 
reimplement the current IconDatabase, but a little plumbing will be involved.

Thanks,
~Brady

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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

> On Jun 15, 2017, at 7:27 PM, Michael Catanzaro  wrote:
> 
> One issue we've noticed is there are many different nonstandard ways that 
> websites use to find icons. [1] details many of these: the Microsoft way, the 
> Apple way, the OpenGraph way... and even then the icons can be put in 
> different places... is this the problem Brady's code is designed to solve?

The WebCore::IconDatabase was extremely limited.

It would look at only the last  or  
(which are standardized in HTML5) and consider it "the one icon" for a page.
If the  specified none, it would consider the default /favicon.ico the 
one icon.
And all it could load/store is that one icon.

The new mechanism already expands upon this by allowing for *each*  icon 
to be considered individually.
It also expands upon this by having built-in support for apple-touch and 
apple-touch-precomposed icons.

There's nothing stopping us from adding support for all of these icon types 
with only small changes to WebCore. Of the list in that blog post some might be 
considered relevant to Apple, others probably not - But LinkIconCollector is a 
tidy self-contained class that can easily have per-platform implementations.

tl;dr - Yes, this is basically the problem the new mechanism solves.

Thanks,
 Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

Slight reordering.

> On Jun 15, 2017, at 5:27 PM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> This is slightly tangential, but a comment on the model: it doesn't seem like 
> there's a way for clients to check what range of icons are available and only 
> then choose which to load. Even though Safari may not have needed this to 
> move over, if you wanted to do something rigorous like load the closest 
> available size to what you need or else a scalable format, there's no way to 
> do that without potentially loading icons you don't need. While Safari hasn't 
> done this, it might be useful if Safari's various places that display icons 
> are ever made more consistent and coherent.

This was discussed when implementing the model for Safari, which was admittedly 
done quickly.

While Safari didn't need what you suggest right now, they agreed they might 
need it in the future. Since the load decision request has a completion 
callback, and since it's a known implementation detail that they will all come 
in quick succession, it was accepted that the current model could work for 
"choosing the right icon of all choices" in a pinch.

> I can see that there needs to be some per-icon notification, since  
> elements can be added after the fact, and also incremental parsing is a 
> thing. So one notification that tells you all icons wouldn't cut it.

Right - The "just one icon" notification was the bare minimum because of this 
need.
We can definitely add a greater API surface to deliver a bulk "here's all the 
icons in the " in addition to the individual icon notification.

> Another minor comment: it seems like this new API returns raw data. It seems 
> like the native way to use this would result in running untrusted data from 
> the network through image decoders outside the Web Process sandbox. Do we 
> have a way to avoid that?

This came up while implementing it for Safari, too. In practice we didn't 
decode icons out-of-process before so this model was not a regression. I see 
value in offering this, but it's also something conscientious clients can do on 
their own with the raw data.

Also...

> But separating the loading mechanism from the notification, plus adding a 
> notification that the  section is done parsing, could allow avoidance 
> of unnecessary loads. In addition, there could be other useful future uses of 
> a mechanism to properly load a resource as if it was being loaded by the 
> page. So it would be nice to decouple this from the notification of 
> discovering an icon link.

That's the full-on tangent!

As you know, "load an arbitrary subresource in the context of the page" has 
come up plenty of times over the history of the WK API, so it does seem like 
there's value here. 
Offering that, however, does seem to make the "decode the icon image out of 
process" less of a fit with a general purpose API.

> Asking these questions because if this is to be the One True Model of icon 
> loading going forward, we should try to make sure the design is future-proof.

Yes, these are all great questions to ask. 

Everything that's been brought up so far only really touches the API surface 
(Do we batch together icon load decision requests? Do we give an out-of-process 
decoded image instead of raw data? Do we offer an API for loading arbitrary 
subresource?)

Speaking with understanding of what's implemented today and what would be 
necessary to make any or all of these changes, I know that the current 
mechanism is a solid base on which these ideas can easily be built.

Thanks,
 Brady

> 
> 
> Regards,
> Maciej
> 
> 
>> On Jun 15, 2017, at 5:11 PM, Brady Eidson <beid...@apple.com> wrote:
>> 
>> Hi all,
>> 
>> The IconDatabase in WebCore is the source of crashes, spins, and complexity. 
>> Additionally it’s not flexible enough to acknowledge that there’s multiple 
>> types of site icons in use on the modern web, nor to adapt to the embedding 
>> client’s need for customization.
>> 
>> I recently introduced the “_WKIconLoadingDelegate” model to WebKit2Cocoa.
>> 
>> WebCore gathers all of the candidate icon URLs and asks the embedding app 
>> for each one whether or not it wants to load them.
>> If the app says yes, the icon will be loaded as a subresource in the current 
>> document and the data will be handed off to the client.
>> 
>> From Apple’s perspective:
>> 
>> The new model is powerful and flexible enough that Safari has adopted it.
>> In WebKit1, the “WebIconDatabase” class was never API and is currently 
>> unused.
>> In WebKit2, the C-API support was never API and is currently unused.
>> 
>> Therefore we intend to remove the current WebCore IconDatabase from the 
>> projec

[webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Brady Eidson]

Hi all,

The IconDatabase in WebCore is the source of crashes, spins, and complexity. 
Additionally it’s not flexible enough to acknowledge that there’s multiple 
types of site icons in use on the modern web, nor to adapt to the embedding 
client’s need for customization.

I recently introduced the “_WKIconLoadingDelegate” model to WebKit2Cocoa.

WebCore gathers all of the candidate icon URLs and asks the embedding app for 
each one whether or not it wants to load them.
If the app says yes, the icon will be loaded as a subresource in the current 
document and the data will be handed off to the client.

From Apple’s perspective:

The new model is powerful and flexible enough that Safari has adopted it.
In WebKit1, the “WebIconDatabase” class was never API and is currently unused.
In WebKit2, the C-API support was never API and is currently unused.

Therefore we intend to remove the current WebCore IconDatabase from the project 
soon.

Starting in on this task, I of course noticed GTK’s API has exposed 
“WebKitFaviconDatabase”

Is that something that’s published API and that is used?
If not, I can get rid of it right now

If so, then I need a GTK maintainer to come up with a plan soon.

The icon load delegate mechanism is powerful enough to rebuild an IconDatabase 
on top of, so if GTK needs to keep this API functional they can do so - 
maintaining the actual IconDatabase code themselves up in their API layer.

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

[Brady Eidson]

> On Jun 13, 2017, at 12:37 PM, Alex Christensen  wrote:
> 
> I’d be opposed to adding a copy constructor to WTF::Function because the 
> non-copyability of WTF::Function is why we made it, and it has prevented many 
> bugs.

Ditto.

The lack of a copy c’tor in WTF::Function turns the compiler into a tool that 
prevents bugs that engineers would’ve otherwise introduced.

Whatever the goal of the refactoring is here, for me it’s an absolute deal 
breaker for us to end up without a  that is move-only.

Thanks,
 Brady

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

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

[Brady Eidson]

> On Jun 13, 2017, at 9:55 AM, Filip Pizlo  wrote:
> 
> Would SharedTask’s sharing be semantically incorrect for users of 
> WTF::Function?  In other words, do you rely on the compiler error that says 
> that there is no copy constructor?


WTF::Function is used in cross-thread dispatching, where arguments captured by 
the lambda are “thread safe copied”, “isolated copied”, etc.

Part of the safety is the lack of a copy constructor, as accidentally making a 
copy on the originating thread can invalidate the setup for thread safety.

So, yes, they must maintain move-only semantics.

> I’m imagining that if WTF::Function was backed by SharedTask that it would 
> not result in any behavior change for existing WTF::Function users.

I see the reverse. Is there any reason SharedTask can’t be backed by a 
WTF::Function?

There’s no harm in adding Ref counting semantics on top the move-only 
WTF::Function if SharedTask is your goal.

Thanks,
 Brady

>  At worst, it would mean that WTF::Function’s backing store has an extra word 
> for the ref count - but if you only move and never copy then this word starts 
> out at 1 and stays there until death, so it’s very cheap.
> 
> -Filip
> 
> 
>> On Jun 13, 2017, at 9:43 AM, Chris Dumez > > wrote:
>> 
>> In most cases in WebCore at least, we don’t actually want to share ownership 
>> of the lambda so we don’t need RefCounting / SharedTask. Because of this, I 
>> don’t think we should merge SharedTask into Function. I think that as it 
>> stands, WTF::Function is a suitable replacement for most uses in WebCore 
>> since we actually very rarely need copying (either it just builds or the 
>> code can be refactored very slightly to avoid the copying).
>> 
>> --
>>  Chris Dumez
>> 
>> 
>> 
>> 
>>> On Jun 13, 2017, at 9:34 AM, Filip Pizlo >> > wrote:
>>> 
>>> We should have a better story here.  Right now the story is too 
>>> complicated.  We have:
>>> 
>>> - ScopedLambda or ScopedLambdaRef if you have a stack-allocated function 
>>> that outlives its user
>>> - SharedTask if you have a heap-allocated function that you want to share 
>>> and ref-count
>>> - WTF::Function if you have a heap-allocated function that you want to 
>>> transfer ownership (move yes, copy no)
>>> - std::function if you have a heap-alloated function that you want to pass 
>>> by copy
>>> 
>>> Only std::function and WTF::Function do the magic that lets you say:
>>> 
>>> std::function f = 
>>> 
>>> Also, std::function has the benefit that it does copying.  None of the 
>>> others do that.
>>> 
>>> ScopedLambda serves a specific purpose: it avoids allocation.  Probably we 
>>> want to keep that one even if we merge the others.
>>> 
>>> IMO SharedTask has the nicest semantics.  I don’t ever want the activation 
>>> of the function to be copied.  In my experience I always want sharing if 
>>> more than one reference to the function exists.  I think that what we 
>>> really want in most places is a WTF::Function that has sharing semantics 
>>> like SharedTask.  That would let us get rid of std::function and SharedTask.
>>> 
>>> In the current status quo, it’s not always correct to convert std::function 
>>> to the others because:
>>> 
>>> - Unlike ScopedLambda and SharedTask, std::function has the magic 
>>> constructor that allows you to just assign a lambda to it.
>>> - Unlike ScopedLambda, std::function is safe if the use is not scoped.
>>> - Unlike WTF::Function, std::function can be copied.
>>> 
>>> -Filip
>>> 
>>> 
 On Jun 13, 2017, at 9:24 AM, Darin Adler > wrote:
 
 I’ve noticed many patches switching us from std::function to WTF::Function 
 recently, to fix problems with copying and thread safety.
 
 Does std::function have any advantages over WTF::Function? Should we ever 
 prefer std::function, or should we use WTF::Function everywhere in WebKit 
 where we would otherwise use std::function?
 
 — Darin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org 
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> 
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Another WPT bite

[Brady Eidson]

> On May 12, 2017, at 7:43 PM, Ryosuke Niwa  wrote:
> 
> On Fri, May 12, 2017 at 7:31 PM, Alexey Proskuryakov  wrote:
>> 
>> When there is a test failure that I need to communicate to others, I say
>> something "please open
>> 
>> in Safari to reproduce". That's very easy to do, and makes it very easy for
>> others to work on the issue.
>> ...
> 
> Note that W3C's web-plaform-tests are hosted on
> http://w3c-test.org/tools/runner/index.html so you can could do the
> same thing.

Note Alexey's URL example points to a specific revision of a specific test.

A frustration that has often come up while I've been working on leading-edge 
features in WebKit is that the w3c-test.org  tests are 
constantly updated and therefore are a moving target.
One cannot use the same test repeatedly over some length of time and expect it 
to remain consistent.

Thanks,
~Brady



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

Re: [webkit-dev] Another WPT bite

[Brady Eidson]

> On May 8, 2017, at 10:44 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> 
> On Mon, May 8, 2017 at 10:17 PM, Brady Eidson <beid...@apple.com> wrote:
> 
>> But now talking about testharness.js directly, I object on the grounds of "a
>> file:// regression test is dirt easy to hack on and work with, whereas
>> anything that requires me to have an httpd running is a PITA"
> 
> I think whether we use file:// or http:// is orthogonal point to using
> testharness.js.  Many of the tests Chris and I have written using
> testharness.js are checked into regular LayoutTests/ directories, and
> they work just fine.

Yes, I misunderstood this in Youenn's original message. Good to know!
> 
>> I just object to making it the "recommended way" of writing tests.
> 
> Would you equally object to making js-test.js / js-test-pre.js the
> recommended way of writing tests?

Yes.

> If not, why?

N/A

> What we're suggesting is to give preferential treatments to
> testharness.js over js-test.js / js-test-pre.js when you were already
> planning to write a test with the latter two scripts.

"It's okay to write your test however you'd like. If you were considering using 
js-test, maybe you should consider using testharness instead."

Is that's what's being proposed?

The WebKit project usually doesn't spend much time worrying about highly 
qualified non-binding suggestions. ;)

Thanks,
 Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Brady Eidson]

> On May 8, 2017, at 10:42 PM, youenn fablet  wrote:
> 
> testharness.js does not need an http server. Some WPT goodies need the WPT 
> server.

I misunderstood since we were also discussing:

>> To continue moving forward, some of us are proposing to serve all tests in 
>> LayoutTests/wpt through the WPT server [1].

I think if somebody is writing a testharness.js test and it does *not* require 
the WPT server, it should be tested as a file URL.

This would imply putting it outside of LayoutTests/wpt though, right?

> I agree different frameworks offer different benefits. There is no reason we 
> should mandate one framework in particular.

Let me make it even more clear what I'm trying to defend. An ad-hoc custom test 
that uses no "framework" but is entirely self contained.

> In case there is no specific needs, it makes sense to me to recommend using 
> testharness.js, at least for those hacking WebCore.

I think it's valuable for engineers to be aware of the "frameworks" like 
testharness.js and js-test, and familiar with the facilities they provide, but 
to not necessarily imply that using any framework is expected.

Thanks,
 Brady___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Brady Eidson]

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

Setting aside the pros or cons of testharness.js itself, I disagree with the 
principle of "1 single way to write all regression tests"

In the past 11 years I've heard from multiple members of the team commenting on 
the benefits of different people writing regression tests in their own styles 
using their own techniques. We're capable of covering more edge cases when we 
don't have enforced uniformity. And I agree wholeheartedly.

But now talking about testharness.js directly, I object on the grounds of "a 
file:// regression test is dirt easy to hack on and work with, whereas anything 
that requires me to have an httpd running is a PITA"

Note: I don't intend for any of this to mean I discourage the use of 
testharness.js tests. I don't. By all means, write them.

I just object to making it the "recommended way" of writing tests.

Thanks,
 Brady

> 
> To continue moving forward, some of us are proposing to serve all tests in 
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies: 
> file-specific headers, templated tests (*.any.js), IDLParser, server-side 
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
> 
> Some rules can guide whether adding tests to LayoutTests/wpt or 
> LayoutTests/imported/w3c/web-platform-tests:
> - WebKit specific tests (crash tests, tests using internals...) in 
> LayoutTests/wpt
> - Spec conformance/interoperability tests in 
> LayoutTests/imported/w3c/web-platform-tests
> 
>y
> 
> [1]: bug 171479 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] PAL Strategy

[Brady Eidson]

> On May 1, 2017, at 12:41 PM, Michael Catanzaro  wrote:
> 
> I thought the original intent for PAL was to replace WebCore/platform, so I 
> assume the criterion would be "stuff currently in WebCore/platform." If not, 
> then I'd question the value of having PAL at all, as we really don't need a 
> separate PAL on top of the platform abstraction library we already have under 
> in Source/WebCore/platform.
> 
> The stuff that moved to WTF was needed in JSC. If we want to keep stuff like 
> UUID from moving to WTF, then we'd need to allow JSC to depend on PAL, rather 
> than vice-versa.

I think everything in WebCore/platform should be moved to PAL.

WTF should only be for things JSC needs, which is nothing inside 
WebCore/platform.

If JSC later needs something that is in PAL, we can move it from PAL to WTF as 
needed.

Thanks,
~Brady

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

Re: [webkit-dev] Proposal: upstream the WPE port

[Brady Eidson]

> On Apr 24, 2017, at 2:31 AM, Carlos Garcia Campos <cgar...@igalia.com> wrote:
> 
> El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:
>>> On Apr 22, 2017, at 6:21 AM, Michael Catanzaro <mcatanzaro@igalia.c
>>> om> wrote:
>>> 
>>> I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
>>> would be much better for us.
>> 
>> I as long as the GTK and WPE ports like this plan (it appears they
>> both are) and are both committed to see it to fruition (it appears
>> they both are), then I fully support this.
>> 
>> I do *not* support adding another client of the C API, even in the
>> interim.
> 
> It would be easier for us to move to the new API after the port is
> upstream, since it will require refactorings in both ports GTK+ and WPE
> . So, we can simply remove from the current patch anything added to the
> C API (except the web view implementation or whatever is needed by WTR)
> and then work on moving to the new API in follow up patches.
> 
> Are you ok with that?

In the coming weeks I am actually likely to be changing and/or removing at 
least a few functions from the C-API.

As long as the WPE upstreaming effort is comfortable with the idea that I might 
be breaking them as they go… That’s fine.

Thanks,
~Brady

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

Re: [webkit-dev] Proposal: upstream the WPE port

[Brady Eidson]

> On Apr 22, 2017, at 6:21 AM, Michael Catanzaro  wrote:
> 
> I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API would be 
> much better for us.

I as long as the GTK and WPE ports like this plan (it appears they both are) 
and are both committed to see it to fruition (it appears they both are), then I 
fully support this.

I do *not* support adding another client of the C API, even in the interim.

Thanks,
~Brady

___
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

[Brady Eidson]

My take-away from this discussion so far is that there is actually very little 
consensus on usage of auto, which means there’s probably very little room for 
actual style guideline rules.

I think there are two very limited rules that are probably not objectionable to 
anybody.

1 - If you are using auto for a raw pointer type, you should use auto*
2 - If you are using auto in a range-based for loop for values that aren’t 
pointers, you should use (const) auto&

If there’s no objections to these rules, I think it’s valuable to have them in 
the style guidelines at the very least.

Thanks,
~Brady


> On Jan 11, 2017, at 10:27 PM, saam barati  wrote:
> 
> 
> 
> On Jan 11, 2017, at 11:15 AM, JF Bastien  > wrote:
> 
>> Would it be helpful to focus on small well-defined cases where auto makes 
>> sense, and progressively grow that list as we see fit?
>> 
>> 
>> e.g. I think this is great:
>> auto ptr = std::make_unique(bar);
>> Proposed rule: if the type is obvious because it's on the line, then auto is 
>> good.
>> Similarly:
>> auto i = static_cast(j);
>> auto foo = make_foo();
>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
> I'm not sure I agree with this style. There are times where the type of an 
> auto variable is obvious-enough, but it's almost never more obvious than 
> actually writing out the types. Writing out types, for my brain at least, 
> almost always makes the code easier to understand. The most obvious place 
> where I prefer auto over explicit types is when something has a lot of 
> template bloat.
> 
> I feel like the places where auto makes the code better are limited, but 
> places where auto makes the code more confusing, or requires me to spend more 
> time figuring it out, are widespread. (Again, this is how my brain reads 
> code.)
> 
> Also, I completely agree with Geoff that I use types to grep around the 
> source code and to figure out what data structures are being used. If we used 
> auto more inside JSC it would hurt my workflow for reading and understanding 
> new code.
> 
> - Saam
> 
>> 
>> 
>> Range-based loops are a bit tricky. IMO containers with "simple" types are 
>> good candidates for either:
>> for (const auto& v : cont) { /* don't change v */ }
>> for auto& v : cont) { /* change v */ }
>> But what's "simple"? I'd say all numeric, pointer, and string types at 
>> least. It gets tricky for more complex types, and I'd often rather have the 
>> type in the loop. Here's more discussion on this 
>> , 
>> including a recommendation to use auto&& on range-based loops! I think this 
>> gets confusing, and I'm not a huge fan of r-value references everywhere.
>> 
>> 
>> Here's another I like, which Yusuke pointed out a while ago (in ES6 Module's 
>> implementation?):
>> struct Foo {
>>   typedef Something Bar;
>>   // ...
>>   Bar doIt();
>> };
>> auto Foo::doIt() -> Bar
>> {
>>   // ...
>> }
>> Why? Because Bar is scoped to Foo! It looks odd the first time, but I think 
>> this is idiomatic "modern" C++.
>> 
>> 
>> I also like creating unnamed types, though I know this isn't everyone's 
>> liking:
>> auto ohMy()
>> {
>>   struct { int a; float b; } result;
>>   // ...
>>   return result;
>> }
>> void yeah()
>> {
>>   auto myMy = ohMy();
>>   dataLogLn(myMy.a, myMy.b);
>> }
>> I initially had that with consumeLoad 
>> ,
>>  which returns a T as well as a ConsumeDependency. I couldn't care less 
>> about the container for T and ConsumeDependency, I just want these two 
>> values.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
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

[Brady Eidson]

> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI  wrote:
> 
> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  > wrote:
> I understand the appeal of “org.webkit” and structured names but personally I 
> would prefer to read names that look like titles and are made up of words 
> with spaces, like these:
> 
> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
> “WebKit: JavaScript DFG Compiler” rather than “org.webkit.jsc.DFGCompiler”.
> 
> Not sure how well that would generalize to all the different names.
> 
> I like the idea of having a smart way of automatically making a shorter name 
> for the platforms that have shorter length limits.
> 
> One interesting idea I've come up with is that,
> 
> 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”

Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder” part is 
ever going to be used?
Is that because Windows could use “org.webkit.”?

Again, back to Darin’s point, I don’t see any particular value in ever seeing 
“org.webkit.”

Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
presumably separated on case-change, is problematic.

e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
different from today.
e.g. “IndexedDBServer”, which is probably what this should be called, would 
expand to “Indexed D B Server"
e.g. “GCController” would expand to “G C Controller”

—

Taking your proposal and running with it, I think we could do this:

1 - Specify the feature name with spaces: “Asynchronous Disassembler”

2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
2a - It could get truncated with ellipses: “AsynchronousDi…" 

3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
Asynchronous Disassemb”
3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”

4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous Disassembler"

Addendum: If we see value in having somethings flagged as “JSC” instead of 
“WebKit”, we just augment the input to include that.
The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
feature could be “WebKit. IndexedDB Server”

Thanks,
~Brady___
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

[Brady Eidson]

> On Jan 5, 2017, at 12:43 AM, Darin Adler  wrote:
> 
> I understand the appeal of “org.webkit” and structured names but personally I 
> would prefer to read names that look like titles and are made up of words 
> with spaces, like these:
> 
> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
> “WebKit: JavaScript DFG Compiler” rather than “org.webkit.jsc.DFGCompiler”.

I strongly agree with this.

That is, I strongly disagree with having to see “org.webkit.FOO” on macOS/iOS.

> Not sure how well that would generalize to all the different names.
> 
> I like the idea of having a smart way of automatically making a shorter name 
> for the platforms that have shorter length limits.

This seems good and possible.

Thanks,
~Brady
___
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

[Brady Eidson]

> On Nov 5, 2016, at 6:18 PM, Michael Catanzaro  wrote:
> 
> 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?

I still don't think this is right.

Safari might want to enable a "disabled by default" feature for a release, or 
it might want to disable an "enabled by default" feature for a release.

We'd do so by changing the default value in the code and then checking that in 
to our branch for that release.

In this same vein, "trunk" is a "branch" for a certain type of release (WebKit 
nightly, STP, etc) where I think there's arguments to be made on a per-feature 
basis that it be either disabled or enabled by default.

Thanks,
~Brady

___
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

[Brady Eidson]

> On Nov 5, 2016, at 3:52 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> 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.

This section was only added 7 months ago in 
https://trac.webkit.org/changeset/199700 and I don't recall seeing the 
discussions that decided this rule.

Are they in webkit-dev archives or a bugzilla somewhere?

>> 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),

On Mac we have this as well in the form of WKPreferences.

_WKExperimentalFeatures is different. The app does not need to know about a 
feature ahead of time. The API automatically enumerates the list of features.

All the app needs to do is call [WKPreferences _experimentalFeatures] to get a 
set of all experimental features.
It can then inspect each feature and turn it on or off as needed.

If you launch Safari Technology Preview, for example,  and go to the "Develop 
-> Experimental Features", you'll see each feature listed.
Behind the scenes, that menu is 100% driven by WebKit and the set of features 
this API enumerates.

If WebKit engineers add a new "experimental feature", it automatically shows up 
in the list of features as exposed by the WKPreferences API, and therefore 
automatically shows up in Safari's menu.

This is very different from WebPreferences and WebKitSettings, which have lots 
and lots of methods, one set of methods per feature, and each method must be 
adopted by new builds of a client.

> Of course I agree it makes sense to have non-experimental settings that can be
> enabled or disabled at runtime.

Again, the word "experimental" here is ill defined and I don't think we're all 
on a common ground with it.

Here's one possible breakdown one can make for the lifecycle of a new 
web-exposed feature under development:

1 - Development just started in WebKit. It's nowhere near working yet. The 
feature has a runtime-enabled flag that is off by default, but is also behind a 
compile-time flag that might be off by default, or off for all but one platform.

2 - The feature works well enough that it's meaningful for WebKit dev to all 
test it and see how it affects stability of the rest of the engine. It might 
also be far enough along that letting cutting-edge web devs play with it would 
give great feedback. The compile-time flag is now on by default for everybody, 
but the runtime enabled flag is still off.

3 - The feature is "complete", and most known bugs with it are squashed. It's 
still "new," though, and hasn't shipped yet in a major stable project. It 
should be on for all of WebKit's targets as well as "development" products from 
vendors.
At this point the runtime-flag should probably be enabled by default. But if a 
vendor doesn't want to be the first to ship, they can disable it by default in 
their product. Or if the vendor wants to provide a switch for their users to 
change at runtime, they use API to do so.

4 - The feature is so well baked and so embedded in the web platform that it no 
longer makes any sense to ship a web engine without it. At this point the 
runtime flag should be removed altogether.

The _WKExperimentalFeatures API provides for both #2 (disabled by default) and 
#3 (enabled by default) features.
If the API was called something like _WKRuntimeEnabledFeatures instead I feel 
like a lot of this discussion would have self resolved. Let's pretend it was 
called that. :)

> It sounds like Cocoa API changes are required to support this?

Cocoa API already exists for this, in the form of _WKExperimentalFeature.

GTK+ could consider adding something like this, as well, to support clients 
that want an API

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

[Brady Eidson]

> On Nov 5, 2016, at 6:13 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> We discovered that several experimental features are currently enabled
> by default:
> 
> https://bugs.webkit.org/show_bug.cgi?id=164367
> ...
> These features are not ready to be default, or they wouldn't be listed as 
> experimental.

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.

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.

I think the API wasn't named properly for how it was destined to be used, as 
there was a clear need for an API that presents many "non-experimental" runtime 
enabled features to the client.
But in reality, many other long standing runtime-enabled features could (and in 
my opinion *should*) be under the same mechanism.

I know some engineers have expressed the opinion that once a runtime feature is 
stable enough to be turned on by default then it should no longer be 
"experimental" and should be removed from the set of experimental features.
But other engineers (myself included) see this set of features as "an 
enumerable list of runtime features that can easily be turned on and off"

Whether or not a feature is on by default, there is significant value in having 
this enumerable list of runtime features.
A feature might be deemed stable enough to enabled by default but it's 
extremely useful for a user to quickly be able to *disable* it at runtime to 
see if it has broken a website, or for a dev to quickly and easily test site 
behavior with it enabled or disabled.

Additionally, it commonly makes sense for a feature to be enabled by default in 
WebKit trunk but then *disabled* by default in a branch.

> 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.

> 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.

As mentioned above, it's not only Safari that wants these on by default.

However, I definitely agree that different ports have different concerns - e.g. 
What Apple might want enabled by default in its port, GTK might not.

> Can we fix the WebKit project defaults please?

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.

Thanks,
~Brady

___
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

[Brady Eidson]

> On Oct 30, 2016, at 8:27 PM, Brady Eidson <beid...@apple.com> wrote:
> 
> I filed https://bugs.webkit.org/show_bug.cgi?id=164213 to track the task of 
> removing.
> I'll continue to monitor this email thread and comments in that bug, but 
> assuming no objections come up I'll remove the code later this week.

Seems like nobody objects to removing this.

The motion carries.

~Brady
___
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

[Brady Eidson]

> On Oct 30, 2016, at 5:14 PM, Brady Eidson <beid...@apple.com> wrote:
> 
> What to other Apple folks think? What do port maintainers who enable the API 
> think?

In only a couple of hours since I started the thread the Linux port maintainers 
have agreed it's okay to remove.
I also received another vote to remove from another Apple contributor.

I filed https://bugs.webkit.org/show_bug.cgi?id=164213 to track the task of 
removing.
I'll continue to monitor this email thread and comments in that bug, but 
assuming no objections come up I'll remove the code later this week.

As always with version control, it can easily be revived if the need comes up.

Thanks,
~Brady 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

There's code in the tree to support the W3C Battery Status API.

A recent study showed the extent of the risk (discussion and link to study 
https://blog.lukaszolejnik.com/battery-status-readout-as-a-privacy-risk/) which 
led to Mozilla first making the API less precise 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1124127) but then eventually 
removing it altogether (https://bugzilla.mozilla.org/show_bug.cgi?id=1313580)

Apple has never enabled this on their ports, one reason being concern for abuse 
in fingerprinting/tracking. 
The study seems to be a strong second opinion backing this concern.
Mozilla's actions demonstrate another vendor not seeing the API being useful 
enough to outweigh the user concern.

As one of the voices for Apple's ports I think the above episode further 
cements our concern in ever enabling the API.

As one of the voices for WebKit as a whole I think above episode suggests we 
should just remove the code from the tree altogether.

What to other Apple folks think? What do port maintainers who enable the API 
think?

Thanks,
~Brady

___
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

[Brady Eidson]

> On Jul 14, 2016, at 11:17 AM, Frédéric WANG  wrote:
> 
> FYI, I just performed that change as part of a general cleanup of MathML
> headers:
> 
> https://trac.webkit.org/changeset/203228
> 
> The code style guidelines still mention the old-style header guards so
> it should probably be updated:
> 
> https://webkit.org/code-style-guidelines/#names-header-guards 
> 

Header guard style should be updated to be "#pragma once"
https://bugs.webkit.org/show_bug.cgi?id=159785 


~Brady

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

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

[Brady Eidson]

> On May 22, 2016, at 6:41 PM, Filip Pizlo  wrote:
> 
> Hi everyone!
> 
> I’d like us to stop using std::chrono and go back to using doubles for time.  
> First I list the things that I think we wanted to get from std::chrono - the 
> reasons why we started switching to it in the first place.  Then I list some 
> disadvantages of std::chrono that we've seen from fixing std::chrono-based 
> code.  Finally I propose some options for how to use doubles for time.
> 
> Why we switched to std::chrono
> 
> A year ago we started using std::chrono for measuring time.  std::chrono has 
> a rich typesystem for expressing many different kinds of time.  For example, 
> you can distinguish between an absolute point in time and a relative time.  
> And you can distinguish between different units, like nanoseconds, 
> milliseconds, etc.
> 
> Before this, we used doubles for time.  std::chrono’s advantages over doubles 
> are:
> 
> Easy to remember what unit is used: We sometimes used doubles for 
> milliseconds and sometimes for seconds.  std::chrono prevents you from 
> getting the two confused.
> 
> Easy to remember what kind of clock is used: We sometimes use the monotonic 
> clock and sometimes the wall clock (aka the real time clock).  Bad things 
> would happen if we passed a time measured using the monotonic clock to 
> functions that expected time measured using the wall clock, and vice-versa.  
> I know that I’ve made this mistake in the past, and it can be painful to 
> debug.
> 
> In short, std::chrono uses compile-time type checking to catch some bugs.
> 
> Disadvantages of using std::chrono
> 
> We’ve seen some problems with std::chrono, and I think that the problems 
> outweigh the advantages.  std::chrono suffers from a heavily templatized API 
> that results in template creep in our own internal APIs.  std::chrono’s 
> default of integers without overflow protection means that math involving 
> std::chrono is inherently more dangerous than math involving double.  This is 
> particularly bad when we use time to speak about timeouts.
> 
> Too many templates: std::chrono uses templates heavily.  It’s overkill for 
> measuring time.  This leads to verbosity and template creep throughout common 
> algorithms that take time as an argument.  For example if we use doubles, a 
> method for sleeping for a second might look like sleepForSeconds(double).  
> This works even if someone wants to sleep for a nanoseconds, since 0.01 
> is easy to represent using a double.  Also, multiplying or dividing a double 
> by a small constant factor (1,000,000,000 is small by double standards) is 
> virtually guaranteed to avoid any loss of precision.  But as soon as such a 
> utility gets std::chronified, it becomes a template.  This is because you 
> cannot have sleepFor(std::chrono::seconds), since that wouldn’t allow you to 
> represent fractions of seconds.  This brings me to my next point.
> 
> Overflow danger: std::chrono is based on integers and its math methods do not 
> support overflow protection.  This has led to serious bugs like 
> https://bugs.webkit.org/show_bug.cgi?id=157924 
> .  This cancels out the 
> “remember what unit is used” benefit cited above.  It’s true that I know what 
> type of time I have, but as soon as I duration_cast it to another unit, I may 
> overflow.  The type system does not help!  This is insane: std::chrono 
> requires you to do more work when writing multi-unit code, so that you 
> satisfy the type checker, but you still have to be just as paranoid around 
> multi-unit scenarios.  Forgetting that you have milliseconds and using it as 
> seconds is trivially fixable.  But if std::chrono flags such an error and you 
> fix it with a duration_cast (as any std::chrono tutorial will tell you to 
> do), you’ve just introduced an unchecked overflow and such unchecked 
> overflows are known to cause bugs that manifest as pages not working 
> correctly.
> 
> I think that doubles are better than std::chrono in multi-unit scenarios.  It 
> may be possible to have std::chrono work with doubles, but this probably 
> implies us writing our own clocks.  std::chrono’s default clocks use 
> integers, not doubles.  It also may be possible to teach std::chrono to do 
> overflow protection, but that would make me so sad since using double means 
> not having to worry about overflow at all.
> 
> The overflow issue is interesting because of its implications for how we do 
> timeouts.  The way to have a method with an optional timeout is to do one of 
> these things:
> 
> - Use 0 to mean no timeout.
> - Have one function for timeout and one for no timeout.
> - Have some form of +Inf or INT_MAX to mean no timeout.  This makes so much 
> mathematical sense.
> 
> WebKit takes the +Inf/INT_MAX approach.  I like this approach the best 
> because it makes the most mathematical sense: not giving a timeout is exactly 
> like asking for a timeout at 

Re: [webkit-dev] Networking proxy on iOS

[Brady Eidson]

> On May 22, 2016, at 3:14 AM, Daniel Olegovich Lazarenko <dani...@opera.com> 
> wrote:
> 
> > It’s not yet clear what the ideal architecture is, which is one of the 
> > reasons why the mentioned issued remains unresolved.
> 
> What are the other reasons?

Perhaps I misrepresented - AFAIK that is the only important reason.

> Are there any reasons that block us from discussing the right architecture?
> I'd like to start working on a patch, but I need directions from you.

I replied to this thread to describe significant issues with the two approaches 
you suggested.

But I am not able to conclude the thread by unilaterally giving directions to a 
lone contributor on how to properly implement this feature.

That’s a much broader conversation than just you and I.

Thanks,
~Brady

> 
> I'd like to come up with some sort of a plan for this as well. Since the 
> desired approach sounds complicated, it would be nice to split it as a series 
> of patches where each patch is committed separately and improves the feature 
> towards the goal.
> 
> On Sun, May 22, 2016 at 6:16 AM, Brady Eidson <beid...@apple.com 
> <mailto:beid...@apple.com>> wrote:
> 
>> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko <dani...@opera.com 
>> <mailto:dani...@opera.com>> wrote:
>> 
>> > We are exploring ways to restore that full functionality - 
>> > https://bugs.webkit.org/show_bug.cgi?id=138169 
>> > <https://bugs.webkit.org/show_bug.cgi?id=138169>
>> 
>> Having custom scheme protocols is important to me too. I didn't know that it 
>> is broken with WKWebView. Do you know what exactly is broken?
> 
> From most developer’s perspective, what is broken is that their NSURLProtocol 
> they can register in their “UI Process” that used to work in WK1 views no 
> longer has any effect in WK2.
> 
>> 
>> I thought that if you call [WKBrowsingContextController 
>> registerSchemeForCustomProtocol:] with your scheme, then it works. When I 
>> checked last (a year ago) it was implemented in a way that the 
>> WebProcess/NetworkingProcess would pass a message to UIProcess, and handle 
>> the network request in the UIProcess. Did it change?
> 
> That did not change.
> 
> But that mechanism was never API, and even as SPI it is formally deprecated.
> 
>> Assuming that registerSchemeForCustomProtocol still works the same way, you 
>> basically state that you dislike the current solution (that does the work in 
>> the UIProcess), and want to have a different architecture.
>> 
>> For custom networking or proxying you have to run the app-provided code. The 
>> basic strategy I proposed was to run it in the app process (i.e. UIProcess). 
>> Since you don't want any networking in UIProcess, it means that the app 
>> needs to spawn a dedicated process to do custom networking. This process 
>> would run app-specific code (including NSURLProtocol-s), and communicate by 
>> IPC with the NetworkingProcess. Is this a kind of architecture you would 
>> like to have?
> 
> It’s not yet clear what the ideal architecture is, which is one of the 
> reasons why the mentioned issued remains unresolved.
> 
> Thanks,
> ~Brady
> 
> 
>> 
>> 
>> On Fri, May 20, 2016 at 5:58 PM, Brady Eidson <beid...@apple.com 
>> <mailto:beid...@apple.com>> wrote:
>> 
>>> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko <dani...@opera.com 
>>> <mailto:dani...@opera.com>> wrote:
>>> 
>>> Thank you for such a fast reply. That is amazing! :)
>>> Back to questions...
>>> 
>>> > Are you primarily focused on a custom networking layer (e.g. your own 
>>> > HTTP implementation?),
>>> > or with custom protocol handling for non-http protocols?
>>> 
>>> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but if 
>>> there are any other widely used protocols that's also interesting. FTP 
>>> support is not interesting for me. Do you have any other specific things in 
>>> mind?
>>> 
>>> If there's a custom proprietary protocol that people handle in the app with 
>>> their own code, for example, acme://acme.com:1234 <http://acme.com:1234/>, 
>>> then proxying this thing is not very interesting to me, because it's very 
>>> easy to proxy my own protocol handled by my own code. There's a case when 
>>> "acme" is provided by some 3rd party, and the app author doesn't have the 
>>> processing code. In such case it might be interesting to proxy it as well, 
>>> but then again, I'm asking for a co

Re: [webkit-dev] Networking proxy on iOS

[Brady Eidson]

> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko <dani...@opera.com> 
> wrote:
> 
> > We are exploring ways to restore that full functionality - 
> > https://bugs.webkit.org/show_bug.cgi?id=138169 
> > <https://bugs.webkit.org/show_bug.cgi?id=138169>
> 
> Having custom scheme protocols is important to me too. I didn't know that it 
> is broken with WKWebView. Do you know what exactly is broken?

From most developer’s perspective, what is broken is that their NSURLProtocol 
they can register in their “UI Process” that used to work in WK1 views no 
longer has any effect in WK2.

> 
> I thought that if you call [WKBrowsingContextController 
> registerSchemeForCustomProtocol:] with your scheme, then it works. When I 
> checked last (a year ago) it was implemented in a way that the 
> WebProcess/NetworkingProcess would pass a message to UIProcess, and handle 
> the network request in the UIProcess. Did it change?

That did not change.

But that mechanism was never API, and even as SPI it is formally deprecated.

> Assuming that registerSchemeForCustomProtocol still works the same way, you 
> basically state that you dislike the current solution (that does the work in 
> the UIProcess), and want to have a different architecture.
> 
> For custom networking or proxying you have to run the app-provided code. The 
> basic strategy I proposed was to run it in the app process (i.e. UIProcess). 
> Since you don't want any networking in UIProcess, it means that the app needs 
> to spawn a dedicated process to do custom networking. This process would run 
> app-specific code (including NSURLProtocol-s), and communicate by IPC with 
> the NetworkingProcess. Is this a kind of architecture you would like to have?

It’s not yet clear what the ideal architecture is, which is one of the reasons 
why the mentioned issued remains unresolved.

Thanks,
~Brady


> 
> 
> On Fri, May 20, 2016 at 5:58 PM, Brady Eidson <beid...@apple.com 
> <mailto:beid...@apple.com>> wrote:
> 
>> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko <dani...@opera.com 
>> <mailto:dani...@opera.com>> wrote:
>> 
>> Thank you for such a fast reply. That is amazing! :)
>> Back to questions...
>> 
>> > Are you primarily focused on a custom networking layer (e.g. your own HTTP 
>> > implementation?),
>> > or with custom protocol handling for non-http protocols?
>> 
>> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but if 
>> there are any other widely used protocols that's also interesting. FTP 
>> support is not interesting for me. Do you have any other specific things in 
>> mind?
>> 
>> If there's a custom proprietary protocol that people handle in the app with 
>> their own code, for example, acme://acme.com:1234 <http://acme.com:1234/>, 
>> then proxying this thing is not very interesting to me, because it's very 
>> easy to proxy my own protocol handled by my own code. There's a case when 
>> "acme" is provided by some 3rd party, and the app author doesn't have the 
>> processing code. In such case it might be interesting to proxy it as well, 
>> but then again, I'm asking for a concrete example of such protocol (in 
>> WebKit context).
> 
> In a WebKit1 app (WebView on Mac, UIWebView on iOS), app authors were able to 
> use NSURLProtocol to override any scheme they wished.
> 
> While some such as yourself might’ve used it to override http from the 
> default handling, *many more* used it to implement custom protocols. e.g. 
> “acme://my-app-specific-url <>”
> 
> We are exploring ways to restore that full functionality - 
> https://bugs.webkit.org/show_bug.cgi?id=138169 
> <https://bugs.webkit.org/show_bug.cgi?id=138169>
> 
>> > You seem to dismiss the Networking process’ crash recovery aspect.
>> > "because in practice we know that most of the crashes happen in the 
>> > WebProcess parts”.
>> > I’m curious what data you’re using to make that claim?
>> 
>> Well, I'm not dismissing it, it's definitely a trade off that an app author 
>> will make by choosing to enable this option.
>> The data comes from our web browser apps. We certainly see networking 
>> faults, but in total it was usually a minor part of all the WebKit crashes. 
>> To not sound subjective, I've looked through our current app version, which 
>> already has enough data to judge, and in the top WebKit crashes there are 
>> none in the network code. Most are crashes in JavaScriptCore, DOM and 
>> graphics subsystems. This is the experience we have over many versions and 
>> years of service. I might be a

Re: [webkit-dev] Networking proxy on iOS

[Brady Eidson]

ting matrices 
and make development in this area (which there has been a lot of lately) more 
difficult.

> > Debugging the multi process architecture of WebKit2 
> > has not gotten any harder in years, active developers have all adapted, 
> > and new developers tend to pick it up pretty quickly. This is not a useful 
> > point.
> 
> I'm sorry that you are rejecting this. Of course you can adapt to that, but 
> it inevitably has a steeper learning curve, and takes longer time. Many app 
> developers come from a single-process background and find multi-process 
> debugging much harder. Often it's a real challenge to understand what's going 
> on. I'm sure that you in your team have multiple stories that show how 
> non-trivial it is, and tricks about dealing with it. Nevertheless, I agree, 
> it's not a decisive point.

AFAIK, we haven’t had a potential contributor to the WebKit Open Source project 
decide to not contribute because of the multi-process architecture.

But, regardless, the MP architecture is primarily how well WebKit works as a 
browser engine for the user, and not about how easy it is for 
single-process-only developers to contribute.

Such developers can still actively contribute to the cross platform code of the 
project (WebCore) in single process mode using MiniBrowser or DumpRenderTree.

Thanks,
~Brady
> 
> 
> 
> On Thu, May 19, 2016 at 6:43 PM, Brady Eidson <beid...@apple.com 
> <mailto:beid...@apple.com>> wrote:
> 
>> On May 19, 2016, at 8:41 AM, Daniel Olegovich Lazarenko <dani...@opera.com 
>> <mailto:dani...@opera.com>> wrote:
>> 
>> I'd like to ask your for advice about implementation of a custom networking 
>> layer
> 
> Are you primarily focused on a custom networking layer (e.g. your own HTTP 
> implementation?), or with custom protocol handling for non-http protocols?
> 
>> ...with WKWebView on iOS.
> 
> WKWebView is an API that ships on both OS X and iOS. When a design aspect of 
> it affects both platforms (such as the networking behavior), we must consider 
> both platforms.
> 
>> Our current solution is based on NSURLProtocol, and the issues we had with 
>> it in 2014 are unresolved:
>> https://bugs.webkit.org/show_bug.cgi?id=137302 
>> <https://bugs.webkit.org/show_bug.cgi?id=137302>
>> https://bugs.webkit.org/show_bug.cgi?id=138131 
>> <https://bugs.webkit.org/show_bug.cgi?id=138131>
>> 
>> It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain 
>> and Alexey Proskuryakov among other reviewers.
> 
> I’m not sure it’s useful for WebKit to spend energy testing and maintaining a 
> mechanism that *only* allows for HTTP-handling replacement and doesn’t also 
> allow for the oft-requested feature of custom protocol handling.
> 
>> Now I'm again looking for a better solution.
>> I'd really like to discuss it with somebody responsible,
> 
> There is no single person responsible; the project works largely on 
> consensus. When dealing with platform specific concerns such as this, it 
> works on consensus of the platform owners.
> 
> That said, I have been the primary caretaker of the Networking process since 
> it’s inception, as well one of the primary caretakers of Mac/iOS networking 
> in general for many years, so I’ll share my thoughts below.
> 
>> There's currently 2 solutions I'm weighting:
>> Pass and use NetworkProcessCreationParameters.httpProxy to 
>> NSURLSessionConfiguration (in NetworkSession and maybe other places). The 
>> httpProxy solution is easy to implement and would look clean design-wise. It 
>> would let us spawn an HTTP proxy on localhost and filter the traffic there. 
>> There might be some complications, because it's not fully transparent to the 
>> client side. For example HTTPS will have issues. All in all this could be a 
>> fine short-term solution.
> While ToT WebKit contains an NSURLSession-based networking implementation for 
> Mac/iOS, it also still contains an NSURLConnection implementation, which is 
> unaffected by NSURLSession considerations.
> 
> That a solution doesn’t work on all supported platforms is not a deal 
> breaker, but it certainly makes it less interesting than one that does.
> 
> HTTPS losing reliability is likely an unacceptable red flag. 
> 
> I’m not sure it’s useful for WebKit to spend energy testing and maintaining a 
> mechanism that *only* allows for HTTP-handling replacement and doesn’t also 
> allow for the oft-requested feature of custom protocol handling.
>> Add a new mode to the NetworkProcess, which would do all networking in 
>> UIProcess (instead of spawning a new process). A mode would be optional and 
>> controlled with s

Re: [webkit-dev] Networking proxy on iOS

[Brady Eidson]

> On May 19, 2016, at 8:41 AM, Daniel Olegovich Lazarenko  
> wrote:
> 
> I'd like to ask your for advice about implementation of a custom networking 
> layer

Are you primarily focused on a custom networking layer (e.g. your own HTTP 
implementation?), or with custom protocol handling for non-http protocols?

> ...with WKWebView on iOS.

WKWebView is an API that ships on both OS X and iOS. When a design aspect of it 
affects both platforms (such as the networking behavior), we must consider both 
platforms.

> Our current solution is based on NSURLProtocol, and the issues we had with it 
> in 2014 are unresolved:
> https://bugs.webkit.org/show_bug.cgi?id=137302 
> 
> https://bugs.webkit.org/show_bug.cgi?id=138131 
> 
> 
> It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain 
> and Alexey Proskuryakov among other reviewers.

I’m not sure it’s useful for WebKit to spend energy testing and maintaining a 
mechanism that *only* allows for HTTP-handling replacement and doesn’t also 
allow for the oft-requested feature of custom protocol handling.

> Now I'm again looking for a better solution.
> I'd really like to discuss it with somebody responsible,

There is no single person responsible; the project works largely on consensus. 
When dealing with platform specific concerns such as this, it works on 
consensus of the platform owners.

That said, I have been the primary caretaker of the Networking process since 
it’s inception, as well one of the primary caretakers of Mac/iOS networking in 
general for many years, so I’ll share my thoughts below.

> There's currently 2 solutions I'm weighting:
> Pass and use NetworkProcessCreationParameters.httpProxy to 
> NSURLSessionConfiguration (in NetworkSession and maybe other places). The 
> httpProxy solution is easy to implement and would look clean design-wise. It 
> would let us spawn an HTTP proxy on localhost and filter the traffic there. 
> There might be some complications, because it's not fully transparent to the 
> client side. For example HTTPS will have issues. All in all this could be a 
> fine short-term solution.
While ToT WebKit contains an NSURLSession-based networking implementation for 
Mac/iOS, it also still contains an NSURLConnection implementation, which is 
unaffected by NSURLSession considerations.

That a solution doesn’t work on all supported platforms is not a deal breaker, 
but it certainly makes it less interesting than one that does.

HTTPS losing reliability is likely an unacceptable red flag. 

I’m not sure it’s useful for WebKit to spend energy testing and maintaining a 
mechanism that *only* allows for HTTP-handling replacement and doesn’t also 
allow for the oft-requested feature of custom protocol handling.
> Add a new mode to the NetworkProcess, which would do all networking in 
> UIProcess (instead of spawning a new process). A mode would be optional and 
> controlled with some configuration setting (or NSUserDefaults).
> The UIProcess solution is harder to implement, and it will affect more code. 
> It is somewhat controversial. One of the reasons of splitting out a 
> NetworkProcess was to have it respawn after crashes. Nevertheless we can take 
> this risk, because in practice we know that most of the crashes happen in the 
> WebProcess parts.

You seem to dismiss the Networking process’ crash recovery aspect. "because in 
practice we know that most of the crashes happen in the WebProcess parts”.  I’m 
curious what data you’re using to make that claim?

>  I don't see any other significant downsides of having the UIProcess handling 
> networking.

The Networking process provides significant benefit unrelated to crash recovery 
that should not be abandoned for convenience sake. e.g. Sandboxing.

Especially when moving the networking to the UI process would also end up 
moving 3rd party code execution into the UI process, this seems like an 
unacceptable regression.

> In addition it can simplify the NetworkProcess debugging.

Debugging the multi process architecture of WebKit2 has not gotten any harder 
in years, active developers have all adapted, and new developers tend to pick 
it up pretty quickly. This is not a useful point.

Thanks,
~Brady

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

[webkit-dev] Coding style proposal - Consistent naming of protector Ref/RefPtrs (https://bugs.webkit.org/show_bug.cgi?id=157591)

[Brady Eidson]

It is a common pattern throughout the project to temporarily protect a 
RefCounted object with a Ref/RefPtr.

e.g.,
RefPtr protectedNode(node);

The naming for these protector variables is all over the map.
e.g.,

RefPtr protect(element);
RefPtr protector(this);
RefPtr self(node);
RefPtr widgetRef(widget);

I’ve seen this come up in patch review a lot, most recently from Darin - 
(https://bugs.webkit.org/show_bug.cgi?id=157448#c16)

In reply (https://bugs.webkit.org/show_bug.cgi?id=157448#c17) I suggested that 
we should formalize a style guideline for this so it’s no longer a gray area.

I filed https://bugs.webkit.org/show_bug.cgi?id=157591 with a description of 
what I think the rule should be, including examples of both good and bad names.

I’ve already attached a patch to implement the check-webkit-style enforcement 
of the rule as well as update https://webkit.org/code-style-guidelines/ 
describing it.

If there are no objections here in the next ~day, assuming I get a review on 
the patch, I’ll be landing the new rule.

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Brady Eidson]

 On Jul 1, 2015, at 7:42 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:
 
 WebKit2 already has a similar feature, which is so-called *custom protocol* 
 enabled by Mac, Gtk and EFL ports. However the custom protocol feature 
 supports to register custom scheme
 through API layer instead of JavaScript. The registerProtocolHandler() is to 
 support to register the custom scheme by means of JavaScript. I don't know 
 yet why we can't support to register it
 from JavaScript.

The custom protocol handler feature of the WebKit2 API is for the embedding 
native application to provide raw data to resource loads directly.

While tangentially related to how registerProtocolHandler would work for some 
uses, there’s numerous differences. 

One key example: Since it was implemented for the native embedding application 
(which is, of course, trusted) none of the normal web security concerns have 
been taken into account.

Also, since they’re for special-use native apps instead of a general web 
browser, none of Sam’s concerns had to be accounted for:

 On Jul 4, 2015, at 10:24 AM, Sam Weinig wei...@apple.com wrote:
 
 My concern with the registerProtocolHandler() API is that it complicates an 
 already the very complicated area of custom protocols and a good 
 implementation requires configuration UI (to choose which of potentially 
 multiple apps/websites you want a specific protocol to go to) that I am not 
 sure users are in the position make.  
 ...
 From an implementation perspective I also have concerns.  How is this should 
 the registration data be managed? Can it fit in the WebSiteData model we are 
 using for other data? Does it account for non-persistent sessions?  And 
 lastly, can we get the code size of supporting a feature like this to be 
 smaller?   

I’m not crafting this reply as an argument against registerProtocolHandler, but 
rather to dispel the notion that exposing WK2 custom protocols” to JS is all 
we need to do to get registerProtocolHandler.

~Brady

 Gyuyoung.
 
 On Tue, Jun 16, 2015 at 10:43 AM, Gyuyoung Kim gyuyoung@webkit.org 
 mailto:gyuyoung@webkit.org wrote:
 On Mon, Jun 8, 2015 at 9:39 AM, Darin Adler da...@apple.com 
 mailto:da...@apple.com wrote:
 Sam, Anders, you haven’t replied to the thread since Maciej made his remarks 
 two weeks ago. He asked what you dislike about the API.
 
 It seems that some people hope to listen why you guys dislike about this API 
 as well as I want.
 
 Gyuyoung.
 
 On Thu, Jun 11, 2015 at 10:06 AM, Gyuyoung Kim gyuyoung@webkit.org 
 mailto:gyuyoung@webkit.org wrote:
 On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro mcatanz...@igalia.com 
 mailto:mcatanz...@igalia.com wrote:
 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.
 
 
 geo: would be useful for people who want to use map application as well.
 
 Gyuyoung.
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Brady Eidson]

 On Apr 23, 2015, at 2:38 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 On Apr 23, 2015, at 1:07 PM, Brady Eidson beid...@apple.com wrote:
 
 
 On Apr 21, 2015, at 3:39 PM, Chris Dumez cdu...@apple.com wrote:
 
 Hi,
 
 I would like to suggest we remove support for 'multipart/x-mixed-replace’ 
 main resources while keeping support for multipart images.
 
 Based on Chrome usage data, this feature is extremely rarely used by Web 
 sites (less than 0.1% of page loads) [1]. This feature adds complexity 
 to the loader and is a source of (security) bugs (e.g. [2] recently), 
 current support also seems buggy.
 
 Current support in Safari / WebKit:
 - Support is not great is WebKit. If you load a Motion JPEG main resource 
 for example, it will keep creating a new ImageDocument and all its DOM tree 
 for every frame (tested on Safari / Mac).
 - It looks like support is broken on Safari on iOS (I tried a Motion JPEG 
 main resource on iOS8, I see the first frame then a blank page that never 
 finishes loading).
 
 Other browsers:
 - Never supported by IE (including IE11) for any resource
 - Chrome already dropped support for this (main resources only) almost 2 
 years ago [3].
 - Firefox 37 still supports this based on local testing.
 
 Again, I am only proposing dropping support for main resources. For e.g., 
 having an IMG element in a page whose src attribute points to a Motion 
 JPEG would still work as intended.
 
 I think it’s fine to drop support for multipart main resources besides MPJEG.
 
 I think loading MJPEG as a main resource and having it be displayed as an 
 ImageDocument is a valuable feature, and I object to dropping support for 
 it. I’m not sure if that’s what you’re proposing, since it’s both a main 
 resource and a multipart image.
 
 I think you might have filed a bug about the new ImageDocument per frame, 
 thought I can’t find it right now. I think fixing that bug is a better 
 solution than dropping that support.
 
 Does this feature have non-negligible actual use in the wild? There are far 
 better ways to do streaming video, so I think we only need to treat this as a 
 legacy feature, and only support it if use warrants it.

I’d wager “sites in the wild” are the fraction of a fraction of a percent 
mentioned above.

I use a web cam at home most evenings whose “view live video” link takes you 
directly to an MJPEG main resource when you’re on a Mac, based on the 
assumption that the default browser on the platform supports it.

Was that a poor design decision on their part? Yes. Can they fix it now? No.

Killing the feature would lead to a confusing experience for such users.

 On Apr 23, 2015, at 1:44 PM, Anders Carlsson ander...@apple.com wrote:
 
 Given that so few browsers support this I think we should get rid of this 
 feature; it would let us simplify the loader code significantly.

I can think of a handful of ways to kill the general “multipart main resource” 
feature - which is allegedly supported in the code but not *really* supported - 
and still maintain the ability to have ImageDocument specifically support this 
one use case.

Thanks,
 Brady

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

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

[Brady Eidson]

 On Apr 21, 2015, at 3:39 PM, Chris Dumez cdu...@apple.com wrote:
 
 Hi,
 
 I would like to suggest we remove support for 'multipart/x-mixed-replace’ 
 main resources while keeping support for multipart images.
 
 Based on Chrome usage data, this feature is extremely rarely used by Web 
 sites (less than 0.1% of page loads) [1]. This feature adds complexity to 
 the loader and is a source of (security) bugs (e.g. [2] recently), current 
 support also seems buggy.
 
 Current support in Safari / WebKit:
 - Support is not great is WebKit. If you load a Motion JPEG main resource for 
 example, it will keep creating a new ImageDocument and all its DOM tree for 
 every frame (tested on Safari / Mac).
 - It looks like support is broken on Safari on iOS (I tried a Motion JPEG 
 main resource on iOS8, I see the first frame then a blank page that never 
 finishes loading).
 
 Other browsers:
 - Never supported by IE (including IE11) for any resource
 - Chrome already dropped support for this (main resources only) almost 2 
 years ago [3].
 - Firefox 37 still supports this based on local testing.
 
 Again, I am only proposing dropping support for main resources. For e.g., 
 having an IMG element in a page whose src attribute points to a Motion JPEG 
 would still work as intended.

I think it’s fine to drop support for multipart main resources besides MPJEG.

I think loading MJPEG as a main resource and having it be displayed as an 
ImageDocument is a valuable feature, and I object to dropping support for it. 
I’m not sure if that’s what you’re proposing, since it’s both a main resource 
and a multipart image.

I think you might have filed a bug about the new ImageDocument per frame, 
thought I can’t find it right now. I think fixing that bug is a better solution 
than dropping that support.

Thanks,
 Brady

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

Re: [webkit-dev] Keep ResourceBuffer?

[Brady Eidson]

 On Oct 23, 2014, at 9:56 AM, Geoffrey Garen gga...@apple.com wrote:
 
 I think Brady explained to me — a year ago? — what ResourceBuffer’s goal was. 
 
 Brady, do you remember?
 

Two goals.

Use #1:

 On Oct 23, 2014, at 10:13 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 Note that ResourceBuffer is virtual and wraps a ShareableResource on WebKit2 
 side. ShareableResource exists to do memory mapped IPC. 

Use #2: There was also plans for a NetworkProcess based memory cache and 
ResourceBuffer was part of those plans.

As Antti also mentioned, the currently factoring is messy and can definitely be 
cleaned up, but it must maintain use case #1.

If we ever get around to implementing #2, we can add what we need at that time.

 Brady

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

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

[Brady Eidson]

Are there any WebKit1’s left besides Apple’s Mac and Windows ports?

If not, we can drop the LevelDB source and start simplifying.

 Brady

On Jul 16, 2014, at 8:59 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:

 Hello Nataraj,
 
 Though there is a meta bug as well as some following bugs, there are no 
 patches yet.
 
 [EFL][META] Enable IndexedDB
 https://bugs.webkit.org/show_bug.cgi?id=87661
 
 Some webkit-efl folks are interested in supporting it though, AFAIK, it is 
 not started yet.
 
 Gyuyoung
 
 On Thursday, July 17, 2014, Nataraj Bukkambudi natarajb...@gmail.com wrote:
 Dear Gyuyoung,
 
 Is there anywork around patch going on to support indexedDB based on sqlite 
 for EFL WK2 port also ?
 
 
 
 On Tue, Apr 29, 2014 at 8:39 AM, Gyuyoung Kim gyuyoung@webkit.org wrote:
 Hi Brady,
 
  Gyuyoung is there a bugzilla for that?
 
 I just file a bug for it.
 
 [EFL][WK1] Support indexedDB based on sqlite directly
 (https://bugs.webkit.org/show_bug.cgi?id=132317)
 
 My co-worker will upload  patches to support indexedDB based on sqlite for 
 EFL WK1.
 
 Gyuyoung.
 
 
 On Mon, Apr 28, 2014 at 11:42 PM, Brady Eidson beid...@apple.com wrote:
 
 On Apr 28, 2014, at 5:40 AM, Steven Coul (scoul) sc...@cisco.com wrote:
 
 Is there an alternative to levelDB without going to webkit2 ?
 
 Not at this time, but apparently EFL is planning to make it work (per 
 Gyuyoung’s email to this thread)
 
 Gyuyoung is there a bugzilla for that?
 
 Thanks,
  Brady
 
 
 Steve Harry Coul
 sc...@cisco.com
 
 
 
 On Apr 28, 2014, at 4:20 AM, ryuan Choi ryuan.c...@webkit.org wrote:
 
 WebKit/Efl dropped level db dependency (and disabled leveldb)
 
 
 2014-04-28 16:44 GMT+09:00 Raphael Kubo da Costa rak...@webkit.org:
 Darin Adler da...@apple.com writes:
 
  On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa rak...@webkit.org 
  wrote:
 
  Sam Weinig wei...@apple.com writes:
 
  Hello,
 
  Is anyone using the LevelDB backend to IndexedDB?
 
  The EFL and GTK+ ports are.
 
  Are you sure?
 
  Since the GTK+ port is now WebKit2-only, then it can’t be using the
  LevelDB back end at this time, because I believe nobody has made it
  work in WebKit2 yet.
 
 Right, so it's only the build system that sets WTF_USE_LEVELDB to 1 and
 builds the LevelDB stuff in ThirdParty.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 
 -- 
 Nataraj,
 Samsung india,
 Bangalore.
 
 
 -- 
 Sent from Gyuyoung Iphone

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

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

[Brady Eidson]

 On Jul 9, 2014, at 12:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wed, Jul 9, 2014 at 12:35 PM, Tim Horton timothy_hor...@apple.com wrote:
 
 On Jul 9, 2014, at 12:10 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 Could we teach webkitbot to do an appropriate notification with a waiting 
 period? Either as part of rollout or add a new command to do it.
 
 It already does. The “waiting period” is defined by when the person who asked 
 for the rollout sets the cq+ bit on the rollout patch.
 
 I don't think creating a rollout patch should be the standard method of 
 notifying the author/reviewer.  We should be informing the author/reviewer 
 ahead of the time.

We already have an automated tool that quickly and easily notifies the 
author/reviewer, and that tool also happens to create the rollout patch.

As Tim points out, the rollout patch is never landed unless a reviewer (usually 
the person who created the rollout patch) sets the cq+ bit on it.

I don’t see what negative effect the mere existence of the rollout patch has, 
or why we should codify into the process that a rollout patch is *not* created 
when notifying the author/reviewer.

Thanks,
~Brady

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

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

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

[Brady Eidson]

 On Jul 9, 2014, at 1:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wed, Jul 9, 2014 at 1:08 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 9, 2014, at 12:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wed, Jul 9, 2014 at 12:35 PM, Tim Horton timothy_hor...@apple.com wrote:
 
 On Jul 9, 2014, at 12:10 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 Could we teach webkitbot to do an appropriate notification with a waiting 
 period? Either as part of rollout or add a new command to do it.
 
 It already does. The “waiting period” is defined by when the person who 
 asked for the rollout sets the cq+ bit on the rollout patch.
 
 I don't think creating a rollout patch should be the standard method of 
 notifying the author/reviewer.  We should be informing the author/reviewer 
 ahead of the time.
 
 We already have an automated tool that quickly and easily notifies the 
 author/reviewer, and that tool also happens to create the rollout patch.
 
 As Tim points out, the rollout patch is never landed unless a reviewer 
 (usually the person who created the rollout patch) sets the cq+ bit on it.
 
 I don’t see what negative effect the mere existence of the rollout patch has, 
 or why we should codify into the process that a rollout patch is *not* 
 created when notifying the author/reviewer.
 
 When the bug for a rollout is created, the original bug is automatically 
 reopened.

Which makes sense when a patch breaks something, whether the resolution is the 
author following up with a fix *or* the rollout committing.’

This is not a reason to avoid creating a rollout patch.

 Also, the bot doesn't provide enough information as to what's breaking 
 because it only takes a single line of description on IRC.

This seems like a complaint you have with the tool that can be fixed.

This is not a reason to avoid creating a rollout patch.

 It's crucial that whoever reverting a patch provide a detailed explanation on 
 what build or test failed and provide a hyper link to build.webkit.org.  
 Otherwise the original author and the reviewer may have no idea what went 
 wrong.

This statement seems at odds with how webkitbot (or an earlier form thereof) 
has been used countless times, since it has been reverting patches with only 
1-line explanations for years without an uproar.

If the premise of this thread is “don’t rely on the tool we already have, and 
instead please manually look up email addresses and/or go to bugzilla to 
manually comment yourself”, then I disagree.

If the premise of this email thread is “please provide a detailed description 
of why a patch is a candidate to be rolled out, including a link to the 
build/test failures”, then I wholeheartedly agree that webkitbot should be 
enhanced to allow and encourage this.

~Brady


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

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

[Brady Eidson]

 On Jul 9, 2014, at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:

 When the bug for a rollout is created, the original bug is automatically 
 reopened.
 
 Which makes sense when a patch breaks something, whether the resolution is 
 the author following up with a fix *or* the rollout committing.’
 
 This is not a reason to avoid creating a rollout patch.
 
 Also, the bot doesn't provide enough information as to what's breaking 
 because it only takes a single line of description on IRC.
 
 This seems like a complaint you have with the tool that can be fixed. This is 
 not a reason to avoid creating a rollout patch.
 
 This is not a complaint about the tool.  In practice, the bot can't figure 
 out why a given patch needs to be rolled out.  It's the responsibility of the 
 person who is rolling out the patch to give necessary details.

Of course the bot can’t know, and of course it’s the rollout’er’s 
responsibility.

I believe the thing that has drawn this thread out was the request to “do this 
work manually before using the tool”

But I find the request to “do this manually instead of using the tool” bizarre 
because:
1 - The tool objectively meets most of the requirements, except for forcing a 
detailed description and URL to the failure.
2 - The tool objectively meets all of the requirements if the person using it 
provides the necessary data to the tool.
3 - You requested that creating the rollout patch should *not* be done, even 
though nobody presented a reason why the mere existence of the rollout patch is 
a problem.
4 - Relying on tools for common processes is a *good* thing.

 It's crucial that whoever reverting a patch provide a detailed explanation 
 on what build or test failed and provide a hyper link to build.webkit.org.  
 Otherwise the original author and the reviewer may have no idea what went 
 wrong.
 This statement seems at odds with how webkitbot (or an earlier form thereof) 
 has been used countless times, since it has been reverting patches with only 
 1-line explanations for years without an uproar.
 
 Not at all.  The point is that the person who requested to rollout a patch 
 should provide the detailed explanation as to why the patch has to be rolled 
 out, or exactly what got broken by the patch.

This can be done by manually looking up email addresses, emailing people, 
logging in to bugzilla, and typing a comment; Like you requested.

Or this can be done by using the tool we already have, but being aware to give 
the full context and a URL to breakage.

 If the premise of this email thread is “please provide a detailed description 
 of why a patch is a candidate to be rolled out, including a link to the 
 build/test failures”, then I wholeheartedly agree that webkitbot should be 
 enhanced to allow and encourage this.
 
 Giving a detailed description has already been a prerequisite to revert a 
 patch.  I don't see why we need to enhance the tool to continue doing what we 
 have always done.


I don’t see the *need* either, because it already supports everything required.

 If you want to enhance the tool to help this process, please go ahead but I'm 
 not singing up to do that work.

I don’t expect you to.  I’m just trying to make it clear that I’m not going to 
start performing a checklist of manual work instead as originally requested; I 
intend to keep using the tool, but being more aware of giving the additional 
context.

 Brady

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

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

[Brady Eidson]

 On Jul 9, 2014, at 4:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
  Again, im not requesting anything new here. The consensus on webkit-dev has 
 been to ping the author/reviewer on IRC or via email and comment in the 
 original bug PRIOR to using webkitbot to start reverting the patch.

I went through the first handful of emails on that thread.  The original 
request that wasn’t meeting a lot of opposition before I stopped digging 
through the thread was:
“Please contact the author/reviewer and give them a reasonable amount of time 
before rolling out their patch.”

I did not reach the message where the consensus was “contact the author and 
reviewer manually, do not use webkitbot”

I believe that using webkitbot:
1 - Comments in a new bugzilla created specifically because there’s an issue
2 - Comments in the original bugzilla notifying of an issue
3 - Emails the author and reviewer by virtue of CC’ing them on the bugzilla(s)
4 - Does *not* roll out the patch.

Assuming my webkitbot command contains a description of the reason this patch 
is suspect, including a URL to the failure, can you further explain why using 
webkitbot is unreasonable?

Maybe that reasoning was reached in the thread you linked to and I didn’t find 
it yet.  I would appreciate it being restated here as the project has 
progressed quite a bit since Dec 2012.

Thanks,
~Brady

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

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

[Brady Eidson]

 On Jul 9, 2014, at 4:45 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wednesday, July 9, 2014, Brady Eidson beid...@apple.com wrote:
 
 On Jul 9, 2014, at 4:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
  Again, im not requesting anything new here. The consensus on webkit-dev has 
 been to ping the author/reviewer on IRC or via email and comment in the 
 original bug PRIOR to using webkitbot to start reverting the patch.
 
 I went through the first handful of emails on that thread.  The original 
 request that wasn’t meeting a lot of opposition before I stopped digging 
 through the thread was:
 “Please contact the author/reviewer and give them a reasonable amount of time 
 before rolling out their patch.”
 
 I did not reach the message where the consensus was “contact the author and 
 reviewer manually, do not use webkitbot”
 
 I believe that using webkitbot:
 1 - Comments in a new bugzilla created specifically because there’s an issue
 2 - Comments in the original bugzilla notifying of an issue
 
 It doesn't. The bot only files a new bug, make it a blocker of the original 
 bug, and then reopen the bug.

I just tried this on IRC with a patch of mine.

webkitbot:
1 - Filed a new bug
2 - Included my rollout reason in the new bug
3 - Reopened the original bug
4 - Commented in the original bug “This is re-opened since this is blocked by 
bug x”
5 - Announced to the reviewer and author on IRC that this is taking place.

 It doesn't copy over any comments made in the new bug for example.

When was this mentioned as a requirement?

The requirement was that the patch author and reviewer get contacted.  They 
definitely are, as they have been pinged on IRC and directly CC’ed on the 
rollout bug.
Additionally, anybody CC’ed on the original bug also gets CC email notifying 
them of the bug they can follow for the rollout if they wish.

What is the purpose of copying comments between these two bugzillas?

 Assuming my webkitbot command contains a description of the reason this patch 
 is suspect, including a URL to the failure, can you further explain why using 
 webkitbot is unreasonable?
 
 I'm not saying that using webkitbot is unreasonable. I'm saying that the 
 person trying to revert a patch should first inform the author/reviewer first 
 BEFORE start reverting the patch.

Right, and since I haven’t cq+’ed the rollout patch at this stage, I have 
contacted the author/reviewer BEFORE reverting the patch.

 Since webkitbot doesn't automatically post the details as to what failures 
 the patch caused, and one line description is almost never adequate (e.g. 
 needs a hyperlink to buildbot page, test failure diff or error log, et c...), 
 I don't see how using webkitbot in its current state could ever be adequate.

“This patch is a candidate for being rolled out because the build-bots have 
conclusively indicated it as breaking the build.  Please take a look within ~3 
hours of this bug being filed or I will cq+ the rollout. The description of the 
build failure and details on why I think this patch broke things can be found 
here:  http://build.webkit.org/details/for/the/breakage”

That can be told to webkitbot today.  Is that not sufficient?  If not, why not?

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

Re: [webkit-dev] Updating HTML Gamepad support

[Brady Eidson]

 On Jun 19, 2014, at 7:29 PM, KwangHyuk Kim hyuki@samsung.com wrote:
 
 Dear Brady Eidson,
  
  - Only EFL and GTK have Gamepad support code
  - The code only supports in-process WebKit1
  - GTK has it disabled
  - EFL has it enabled, but has also committed to dropping WK1 support
  
 AFAIK, WK2-EFL is also supporting Gamepad api for now.

Since there was no Gamepad code in the WK2 directory, I assumed this was not 
the case.

If EFL’s WK2 strategy is “have every web content process probe the same game 
pads independent of each other,” then hopefully the upcoming work to set up a 
proper process model will excite you!

 However, I would like to say that EFL are now interested in your task too. :)

Great!

As far as getting device state from the native gamepad system, I’m sure it will 
be as easy to adapt to the new model as it was to write GamepadsEfL.cpp.

The new API does include notifications for connecting and disconnecting 
gamepads so an EFL maintaining will have to come along and fill in those bits, 
but it should be pretty straightforward.

Thanks,
~Brady


 

  
 BR
  - Kwang
  
 --- Original Message ---
 Sender : Brady Eidsonbeid...@apple.com
 Date : 2014-06-20 06:52 (GMT+09:00)
 Title : [webkit-dev] Updating HTML Gamepad support
  
 Hi all, 
 
 As a pet project I’ve been pecking away at supporting the Gamepad API on Mac. 
  You can follow along in https://bugs.webkit.org/show_bug.cgi?id=134076.
 
 The first glaring thing I noticed is how out of date the current code is.  
 The Gamepad code currently in the tree has gone over 3 years without any real 
 development.
 
 In the meantime the working draft for the Gamepad API [1] is much different 
 than what’s in our tree.  Also at least 1 other engine (Mozilla) has shipped 
 support matching the newer API.
 
 I plan to completely break what’s currently in the tree in a non-backwards 
 compatible way.  Grep’ing the tree I conclude that this is okay because:
 
 - Only EFL and GTK have Gamepad support code
 - The code only supports in-process WebKit1
 - GTK has it disabled
 - EFL has it enabled, but has also committed to dropping WK1 support
 
 If I am wrong and somebody has a compelling reason to keep supporting the 
 version of the API that exists in the tree today, please contact me here or 
 in the bugzilla.  *SOON*.
 
 Thanks!
 ~Brady
 
 [1] - http://www.w3.org/TR/gamepad/
 
  
 201406201129561_XOK0LK7C.gif

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

Re: [webkit-dev] Updating HTML Gamepad support

[Brady Eidson]

Just had this idea:

I think I’ll start with a patch that renames “GAMEPAD” to “GAMEPAD_DEPRECATED”, 
along with some file renames.

That way the new implementation can be landed completely independently of the 
old one, and EFL can choose when to switch over (probably after the new version 
is done).

From this point on, I’ll lay out plans in the bugzilla 
https://bugs.webkit.org/show_bug.cgi?id=134076

Thanks,
~Brady


 On Jun 20, 2014, at 9:57 AM, Brady Eidson beid...@apple.com wrote:
 
 
 On Jun 19, 2014, at 7:29 PM, KwangHyuk Kim hyuki@samsung.com wrote:
 
 Dear Brady Eidson,
  
  - Only EFL and GTK have Gamepad support code
  - The code only supports in-process WebKit1
  - GTK has it disabled
  - EFL has it enabled, but has also committed to dropping WK1 support
  
 AFAIK, WK2-EFL is also supporting Gamepad api for now.
 
 Since there was no Gamepad code in the WK2 directory, I assumed this was not 
 the case.
 
 If EFL’s WK2 strategy is “have every web content process probe the same game 
 pads independent of each other,” then hopefully the upcoming work to set up a 
 proper process model will excite you!
 
 However, I would like to say that EFL are now interested in your task too. :)
 
 Great!
 
 As far as getting device state from the native gamepad system, I’m sure it 
 will be as easy to adapt to the new model as it was to write GamepadsEfL.cpp.
 
 The new API does include notifications for connecting and disconnecting 
 gamepads so an EFL maintaining will have to come along and fill in those 
 bits, but it should be pretty straightforward.
 
 Thanks,
 ~Brady
 
 
 
 
  
 BR
  - Kwang
  
 --- Original Message ---
 Sender : Brady Eidsonbeid...@apple.com
 Date : 2014-06-20 06:52 (GMT+09:00)
 Title : [webkit-dev] Updating HTML Gamepad support
  
 Hi all, 
 
 As a pet project I’ve been pecking away at supporting the Gamepad API on 
 Mac.  You can follow along in https://bugs.webkit.org/show_bug.cgi?id=134076.
 
 The first glaring thing I noticed is how out of date the current code is.  
 The Gamepad code currently in the tree has gone over 3 years without any 
 real development.
 
 In the meantime the working draft for the Gamepad API [1] is much different 
 than what’s in our tree.  Also at least 1 other engine (Mozilla) has shipped 
 support matching the newer API.
 
 I plan to completely break what’s currently in the tree in a non-backwards 
 compatible way.  Grep’ing the tree I conclude that this is okay because:
 
 - Only EFL and GTK have Gamepad support code
 - The code only supports in-process WebKit1
 - GTK has it disabled
 - EFL has it enabled, but has also committed to dropping WK1 support
 
 If I am wrong and somebody has a compelling reason to keep supporting the 
 version of the API that exists in the tree today, please contact me here or 
 in the bugzilla.  *SOON*.
 
 Thanks!
 ~Brady
 
 [1] - http://www.w3.org/TR/gamepad/
 
  
 201406201129561_XOK0LK7C.gif
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] WebKit Remote Web Inspector

[Brady Eidson]

 On Jun 20, 2014, at 6:07 PM, Vienneau, Christopher cvienn...@ea.com wrote:
 
 Searching my code for INSPECTOR_SERVER I only find it in FeatureDefinesNix.h 
 but no source code wrapped by it.  REMOTE_INSPECTOR does not show up at all. 

I wonder what WebKit source you actually have, then!

`grep -r -l INSPECTOR_SERVER” .`
./WebKit/mac/ChangeLog
./WebKit2/ChangeLog-2012-05-22
./WebKit2/ChangeLog-2013-04-24
./WebKit2/ChangeLog-2013-10-13
./WebKit2/config.h
./WebKit2/UIProcess/efl/WebContextEfl.cpp
./WebKit2/UIProcess/gtk/WebContextGtk.cpp
./WebKit2/UIProcess/InspectorServer/efl/WebInspectorServerEfl.cpp
./WebKit2/UIProcess/InspectorServer/gtk/WebInspectorServerGtk.cpp
./WebKit2/UIProcess/InspectorServer/soup/WebSocketServerSoup.cpp
./WebKit2/UIProcess/InspectorServer/WebInspectorServer.cpp
./WebKit2/UIProcess/InspectorServer/WebInspectorServer.h
./WebKit2/UIProcess/InspectorServer/WebSocketServer.cpp
./WebKit2/UIProcess/InspectorServer/WebSocketServer.h
./WebKit2/UIProcess/InspectorServer/WebSocketServerClient.h
./WebKit2/UIProcess/InspectorServer/WebSocketServerConnection.cpp
./WebKit2/UIProcess/InspectorServer/WebSocketServerConnection.h
./WebKit2/UIProcess/WebInspectorProxy.cpp
./WebKit2/UIProcess/WebInspectorProxy.h
./WebKit2/UIProcess/WebInspectorProxy.messages.in
./WebKit2/UIProcess/WebPageProxy.cpp
./WebKit2/WebProcess/WebCoreSupport/WebInspectorClient.cpp
./WebKit2/WebProcess/WebPage/WebInspector.cpp
./WebKit2/WebProcess/WebPage/WebInspector.h
./WebKit2/WebProcess/WebPage/WebInspector.messages.in


`grep -r -l REMOTE_INSPECTOR” .`
./JavaScriptCore/API/JSBase.cpp
./JavaScriptCore/API/JSContextRef.cpp
./JavaScriptCore/API/JSObjectRef.cpp
./JavaScriptCore/API/JSValue.mm
./JavaScriptCore/API/JSValueRef.cpp
./JavaScriptCore/ChangeLog
./JavaScriptCore/ChangeLog-2014-02-20
./JavaScriptCore/Configurations/FeatureDefines.xcconfig
./JavaScriptCore/inspector/remote/RemoteInspector.h
./JavaScriptCore/inspector/remote/RemoteInspector.mm
./JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.cpp
./JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.h
./JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.h
./JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.mm
./JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.h
./JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.mm
./JavaScriptCore/runtime/JSGlobalObject.cpp
./JavaScriptCore/runtime/JSGlobalObject.h
./JavaScriptCore/runtime/JSGlobalObjectDebuggable.cpp
./JavaScriptCore/runtime/JSGlobalObjectDebuggable.h
./WebCore/bindings/js/JSDOMGlobalObject.cpp
./WebCore/ChangeLog
./WebCore/ChangeLog-2014-02-20
./WebCore/Configurations/FeatureDefines.xcconfig
./WebCore/inspector/InspectorController.cpp
./WebCore/inspector/InspectorController.h
./WebCore/loader/FrameLoader.cpp
./WebCore/page/Page.cpp
./WebCore/page/Page.h
./WebCore/page/PageDebuggable.cpp
./WebCore/page/PageDebuggable.h
./WebCore/WebCore.exp.in
./WebKit/cf/ChangeLog
./WebKit/ChangeLog
./WebKit/ios/ChangeLog
./WebKit/mac/ChangeLog
./WebKit/mac/Configurations/FeatureDefines.xcconfig
./WebKit/mac/WebView/WebIndicateLayer.h
./WebKit/mac/WebView/WebIndicateLayer.mm
./WebKit/mac/WebView/WebPreferenceKeysPrivate.h
./WebKit/mac/WebView/WebView.mm
./WebKit/mac/WebView/WebViewData.h
./WebKit/mac/WebView/WebViewData.mm
./WebKit/mac/WebView/WebViewPrivate.h
./WebKit2/ChangeLog
./WebKit2/ChangeLog-2014-02-20
./WebKit2/Configurations/FeatureDefines.xcconfig
./WebKit2/Shared/WebPageCreationParameters.cpp
./WebKit2/Shared/WebPageCreationParameters.h
./WebKit2/UIProcess/API/C/WKPage.cpp
./WebKit2/UIProcess/API/Cocoa/WKWebView.mm
./WebKit2/UIProcess/WebContext.cpp
./WebKit2/UIProcess/WebPageProxy.cpp
./WebKit2/UIProcess/WebPageProxy.h
./WebKit2/WebProcess/WebPage/WebPage.cpp
./WebKit2/WebProcess/WebPage/WebPage.h
./WebKit2/WebProcess/WebPage/WebPage.messages.in
./WebKit2/WebProcess/WebProcess.cpp
./WTF/ChangeLog
./WTF/wtf/FeatureDefines.h

Thanks,
~Brady

 Should I see source using these defines or do I misunderstand?  I’m guessing 
 the port being used here doesn’t have the things you mentioned in it; which 
 is “Cairo”.  I expect the server portion needed to implement isn’t too 
 difficult, and I suppose the other ports could be used as examples.
  
 Chris
  
  
 From: Joseph Pecoraro [mailto:pecor...@apple.com] 
 Sent: Friday, June 20, 2014 5:37 PM
 To: Vienneau, Christopher
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] WebKit Remote Web Inspector
  
 Hello,
  
 Yes, this is possible. There are currently two paths to making Web Inspector 
 work across processes.
  
  
 1. ENABLE(INSPECTOR_SERVER)
  
 Currently enabled by GTK and EFL. The UIProcess process establishes an HTTP 
 Web/WebSocket server. The index page is a listing page which advertises 
 information about each of the different WebViews that can be inspected. For 
 each of these there is a page which fetches the HTML web inspector frontend 
 assets (WebInspectorUI) and then 

[webkit-dev] Updating HTML Gamepad support

[Brady Eidson]

Hi all,

As a pet project I’ve been pecking away at supporting the Gamepad API on Mac.  
You can follow along in https://bugs.webkit.org/show_bug.cgi?id=134076.

The first glaring thing I noticed is how out of date the current code is.  The 
Gamepad code currently in the tree has gone over 3 years without any real 
development.

In the meantime the working draft for the Gamepad API [1] is much different 
than what’s in our tree.  Also at least 1 other engine (Mozilla) has shipped 
support matching the newer API.

I plan to completely break what’s currently in the tree in a non-backwards 
compatible way.  Grep’ing the tree I conclude that this is okay because:

- Only EFL and GTK have Gamepad support code
- The code only supports in-process WebKit1
- GTK has it disabled
- EFL has it enabled, but has also committed to dropping WK1 support

If I am wrong and somebody has a compelling reason to keep supporting the 
version of the API that exists in the tree today, please contact me here or in 
the bugzilla.  *SOON*.

Thanks!
~Brady

[1] - http://www.w3.org/TR/gamepad/

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

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Brady Eidson]

On May 7, 2014, at 5:38 PM, Rik Cabanier caban...@gmail.com wrote:

 
 
 
 On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain benja...@webkit.org wrote:
 On 5/7/14, 4:13 PM, Benjamin Poulain wrote:
 On 5/7/14, 3:52 PM, Filip Pizlo wrote:
 Exactly. Ben, Oliver, and others have made arguments against web
 workers. Rik is not proposing web workers.  We already support them. The
 point is to give API to let developers opt into behaving nicely if they
 are already using web workers.
 
 I have nothing against Web Workers. They are useful to dispatch
 background tasks.
 
 They are basically the Web equivalent dispatch_async() of GCD, which is
 already a very useful tool.
 
 What you are suggesting is useful for making Web Workers the tool to do
 high performance multi-thread computation.
 I don't think Web Workers are a great tool for that job at the moment. I
 would prefer something along TBB, GCD or something like that.
 
 
 For high performance computation, I think a more useful API would be
 something like TBB parallel_for with automatic chunking.
 It is actually had to do faster than that with the number of cores
 unless you know your task very very well.
 
 It would be a little more work for us, but a huge convenience for the
 users of Web Workers.
 
 After chatting with Filip, it seems such a model is unlikely to happen 
 anytime soon for JavaScript.
 
 In the absence of any tasks/kernels model, I am in favor of exposing a good 
 number of thread API. It is definitely better than nothing.
 
 Do we know what this number would be? My guess would be the number of cores 
 for regular systems...

Define “regular” systems:  As Ryosuke mentioned, for systems that run on 
battery power (read: a vast majority of systems), keeping cores asleep to 
preserve battery life is often preferable to the user instead of waking up all 
available hardware and building up heat.

Also, what type of cores?  Physical cores, or logical cores?

 Boris Zbarsky indicated that Firefox figures out how many workers should run 
 concurrently. Maybe we can reuse that algorithm?

I think it’s definitely worth looking in to.

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

Re: [webkit-dev] Moving ChangeLog-date files into their own subdirectory?

[Brady Eidson]

On May 7, 2014, at 7:01 PM, Steven Coul (scoul) sc...@cisco.com wrote:

 Okay, 
 
 But then, information in the change logs is also mirrored in the repo log. 
 For instance, could you not do “git log | grep whatever” ?

WebKit is stored in an svn repository, not a git repository.

SVN stores history on the server and `svn log` requires networking, so 
ChangeLogs are invaluable for contributors who prefer svn.  And some of those 
committers are invaluable to the project.

 If we are not going to keep functional but currently unused code visible, why 
 bother with ancient-history ?

Indeed, we remove dead code with the notion that it can always be resurrected 
from history.

Commit history is how one would determine when/why that code was removed, and I 
believe the project considers ChangeLogs to be the local copy of that commit 
history that everybody has.

~Brady

 On May 7, 2014, at 8:05 PM, Darin Adler da...@apple.com wrote:
 
 
 On May 7, 2014, at 3:51 PM, Steven Coul (scoul) sc...@cisco.com wrote:
 
 Or just remove them?
 
 I grep them all the time. I don’t think removing them would be a good thing.
 
 Many projects use the configuration management system’s own change logging 
 system rather than an explicit text file, but that’s not how we’ve been 
 doing things in WebKit.
 
 — Darin
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Brady Eidson]

On May 7, 2014, at 9:08 PM, Rik Cabanier caban...@gmail.com wrote:

 
 
 
 On Wed, May 7, 2014 at 7:58 PM, Brady Eidson beid...@apple.com wrote:
 
 On May 7, 2014, at 5:38 PM, Rik Cabanier caban...@gmail.com wrote:
 
 
 
 
 On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain benja...@webkit.org wrote:
 On 5/7/14, 4:13 PM, Benjamin Poulain wrote:
 On 5/7/14, 3:52 PM, Filip Pizlo wrote:
 Exactly. Ben, Oliver, and others have made arguments against web
 workers. Rik is not proposing web workers.  We already support them. The
 point is to give API to let developers opt into behaving nicely if they
 are already using web workers.
 
 I have nothing against Web Workers. They are useful to dispatch
 background tasks.
 
 They are basically the Web equivalent dispatch_async() of GCD, which is
 already a very useful tool.
 
 What you are suggesting is useful for making Web Workers the tool to do
 high performance multi-thread computation.
 I don't think Web Workers are a great tool for that job at the moment. I
 would prefer something along TBB, GCD or something like that.
 
 
 For high performance computation, I think a more useful API would be
 something like TBB parallel_for with automatic chunking.
 It is actually had to do faster than that with the number of cores
 unless you know your task very very well.
 
 It would be a little more work for us, but a huge convenience for the
 users of Web Workers.
 
 After chatting with Filip, it seems such a model is unlikely to happen 
 anytime soon for JavaScript.
 
 In the absence of any tasks/kernels model, I am in favor of exposing a good 
 number of thread API. It is definitely better than nothing.
 
 Do we know what this number would be? My guess would be the number of cores 
 for regular systems...
 
 Define “regular” systems:
 
 regular systems are those were all running CPU's are of the same type. 
 There are some exotic systems where some CPU's are much faster than others. 
 I'm unsure what we should return there.
  
  As Ryosuke mentioned, for systems that run on battery power (read: a vast 
 majority of systems), keeping cores asleep to preserve battery life is often 
 preferable to the user instead of waking up all available hardware and 
 building up heat.
 
 Actually, spinning up more cores while on battery power might be more 
 efficient.

 
 I'm having a hard time finding good data, but take this chart for instance: 
 http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5
 Let's say you have a task that would take 1 core 4 seconds. This would mean 4 
 x 2612mw = 10456mw
 Now if you can divide it over 4 cores: display = 854 (AMOLED), cpu core 
 (simplified) = 2612 - 854 = 1758mw - 854 + (4 x 1758mw) = 7886mw
 
 On the desktop world, Intel Turbo boost [1] boosts single thread performance 
 but at the expense of making the CPU run much hotter. Putting an even load 
 will reduce power usage so the ratio of operator/watt will improve
 There's a paper from NVidia that also describes this [2].
 
 Just because you can break up the work, doesn't mean that you do MORE work.

I’m not arguing that more cores over less time can never be more efficient.  
Sure it can be, on certain systems and under certain conditions.

But less cores over more time can also be more efficient in other 
circumstances.  Waking cores can be expensive, both from a battery and time 
perspective.  In fact transitioning through P-states, T-states, and C-states 
all incur a cost.

A lot of this discussion has been focused on “make long running computational 
algorithms better”, meaning the types of threads that last minutes or even 
hours.  Much more common are the many threads that transition in and out of 
existence over short periods of time, where attempting to minimize these 
transitions is important for battery life.

 Maybe we can keep the current patch that returns the number of available 
 CPU's for now. [3]

This conversation has devolved into talking about the cost/benefit analysis of 
using all the cores versus taking it easy on the system, but it has completely 
ignored the fingerprinting problem.

Instead of passive/aggressively commenting on the patch, I’ve now actually 
r-‘ed it until at least that concern is resolved.

~Brady

 
 1: 
 http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-technology.html?wapkw=turbo+boost
 2: page 12 of 
 http://www.nvidia.com/content/PDF/tegra_white_papers/tegra-whitepaper-0911b.pdf
 3: https://bugs.webkit.org/show_bug.cgi?id=132588
 

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

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

[Brady Eidson]

On Apr 28, 2014, at 5:40 AM, Steven Coul (scoul) sc...@cisco.com wrote:

 Is there an alternative to levelDB without going to webkit2 ?

Not at this time, but apparently EFL is planning to make it work (per 
Gyuyoung’s email to this thread)

Gyuyoung is there a bugzilla for that?

Thanks,
 Brady

 
 Steve Harry Coul
 sc...@cisco.com
 
 
 
 On Apr 28, 2014, at 4:20 AM, ryuan Choi ryuan.c...@webkit.org wrote:
 
 WebKit/Efl dropped level db dependency (and disabled leveldb)
 
 
 2014-04-28 16:44 GMT+09:00 Raphael Kubo da Costa rak...@webkit.org:
 Darin Adler da...@apple.com writes:
 
  On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa rak...@webkit.org 
  wrote:
 
  Sam Weinig wei...@apple.com writes:
 
  Hello,
 
  Is anyone using the LevelDB backend to IndexedDB?
 
  The EFL and GTK+ ports are.
 
  Are you sure?
 
  Since the GTK+ port is now WebKit2-only, then it can’t be using the
  LevelDB back end at this time, because I believe nobody has made it
  work in WebKit2 yet.
 
 Right, so it's only the build system that sets WTF_USE_LEVELDB to 1 and
 builds the LevelDB stuff in ThirdParty.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Brady Eidson]

On Nov 7, 2013, at 6:36 PM, Timothy Hatcher timo...@apple.com wrote:

 On Nov 7, 2013, at 5:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 I'm objecting to combining the src-N attributes into a
 single attribute because that produces a *list of lists*, which is a
 significant step further in mental complexity.
 
 We can agree to disagree then. I do not support the use of multiple 
 attributes. It is a grotesque perversion of the HTML language.

For what it’s worth, following this thread has teased me into refreshing my 
understanding of srcset and looking at the SrcN proposal.

I’m with Timothy on this. This multiple-attribute thing is not how anybody 
should understand HTML to work.

Thanks,
~Brady

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

[webkit-dev] Heads up for WebKit2 ports using IndexedDB

[Brady Eidson]

Hey WK2 folks,

https://bugs.webkit.org/show_bug.cgi?id=122675 lays the most basic framework 
for a WK2, multi-process-aware implementation of Indexed DB.

The future of WK2 is multi-process awareness and it makes no sense to continue 
supporting the default WebCore LevelDB implementation on a per-WebProcess 
basis.  So the patch I have attached knowingly breaks such configurations.

If you would like me to add an #ifdef workaround in the meantime, let me know 
in the bug *soon*.  But be forewarned that at some point soon that workaround 
will be removed and your port will have some work to do in adopting the WK2 
configuration.

Thanks,
~Brady


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

[webkit-dev] Anybody living in trunk with INDEXED_DATABASE enabled?

[Brady Eidson]

Hey all,

Is anybody living in trunk with INDEXED_DATABASE enabled?

I’m trying to get a gauge for how disruptive I’ll be able to be while hacking 
on it.

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ChangeLog format

[Brady Eidson]

On Aug 21, 2013, at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Separately, I'd like to know whether people liked the new format and it's 
 worth my time making webkitpy adopt the new format.
 
 I personally didn't like the old format because it made the first line of 
 each change log too long.  I'm also not a big fun of wrapping URLs in angle 
 brackets.  It's also unclear to me what should happen when there are multiple 
 Bugzilla URLs to list.

I think you mean you personally don’t like the *new* format? :)

I don’t like it either.  The line was too long, and I frequently list multiple 
bug urls (a bugzilla and a radar).

I’ve had prepare-ChangeLog give me the new format and I simply ignored it and 
used the old format instead.  I didn’t feel remotely bad about this as there 
has never been 100% standardization on the format, anyways.

 But I hear the new format made git log --oneline much more readable so I can 
 be convinced although I don't intend to use git for WebKit development in the 
 foreseeable future myself.

I use git, and the old format doesn’t bother me.

I almost always care about the entire commit message, or at least the “TLDR;” 
included after the bug descriptions and urls.

~Brady

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

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

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

[Brady Eidson]

+1.

I see no benefit to keeping the code around right now.

~Brady

On Aug 5, 2013, at 1:16 PM, Sam Weinig wei...@apple.com wrote:

 Hello,
 
 I’d like to propose removing support for the Microdata JS API 
 (http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html) 
 from WebKit.  The specification has not gotten much adoption from either 
 implementors or from site authors.  Additionally, its use cases can all be 
 addressed in author scripts, and if we see it becoming popular we can always 
 bring it back.
 
 The Mac port has never enabled the feature, and Blink has recently ripped out 
 their support. 
 
 Thoughts?
 
 -Sam
 
 (I have done the work to rip it out, but it is not up for review yet - 
 https://webkit.org/b/119480)
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Notifying PageClient when page transition has begun

[Brady Eidson]

On Jul 25, 2013, at 9:08 AM, Thiago Lacerda thiago.lace...@openbossa.org 
wrote:

 Hi,
 
 We in the Nix port team (which is going upstream), are facing an issue that 
 we need our WebView to know when the page transition has begun.
 There was callback, in PageClient, that was making a similar job, called 
 didCommitLoadForMainFrame, but it was removed recently.

If by “PageClient” you mean the WKPageLoaderClient in WKPage.h, then 
didCommitLoadForFrame is there.

I don’t even recall there ever being a didCommitLoadForMainFrame, but 
didCommitLoadForFrame combined with a quick call to WKPageGetMainFrame will do 
the exact same thing.

 WebPage does have a callback that tells this (didStartPageTransition), but 
 this is not forwarded to UIProcess, which is kind of weird, since its 
 opposite (didCompletePageTransition) is fired to PageClient when a page has 
 completed its transition.

didStartPageTransition is about starting a provisional load, and 
didCompletePageTransition is *not* about committing a provisional load.  
Additionally, neither of these are actually sent to any API clients;  They are 
internal to WebPage.

If you think didCommitLoadForFrame() for the main frame was what you wanted, 
then both of these are irrelevant anyways.

 I have a patch that does forward the didPageStartTransition to UIProcess and 
 I would like to know what you guys think of that. Does this seems useful to 
 you as well?

Since - at this point in my response - I’m not sure what you want or what 
you’re talking about, I would say no it does not seem useful.

~Brady

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

Re: [webkit-dev] Notifying PageClient when page transition has begun

[Brady Eidson]

On Jul 25, 2013, at 10:10 AM, Thiago Lacerda thiago.lace...@openbossa.org 
wrote:

 Hi Brady
 
 
 On Thu, Jul 25, 2013 at 1:48 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 25, 2013, at 9:08 AM, Thiago Lacerda thiago.lace...@openbossa.org 
 wrote:
 
 Hi,
 
 We in the Nix port team (which is going upstream), are facing an issue that 
 we need our WebView to know when the page transition has begun.
 There was callback, in PageClient, that was making a similar job, called 
 didCommitLoadForMainFrame, but it was removed recently.
 
 If by “PageClient” you mean the WKPageLoaderClient in WKPage.h, then 
 didCommitLoadForFrame is there.
 
 I don’t even recall there ever being a didCommitLoadForMainFrame, but 
 didCommitLoadForFrame combined with a quick call to WKPageGetMainFrame will 
 do the exact same thing.
 
 By PageClient I mean the one in Source/WebKit2/UIProcess/PageClient.h (which 
 WebView inherits from) 

I see.  I misunderstood and thought you were talking about the API layer.

PageClient is largely a platform abstraction and not all platforms inherit a 
WebView from it.  And since it’s a platform abstraction, I can’t tell you how 
your platform should behave with it.

But that’s probably neither here-nor-there…

 WebPage does have a callback that tells this (didStartPageTransition), but 
 this is not forwarded to UIProcess, which is kind of weird, since its 
 opposite (didCompletePageTransition) is fired to PageClient when a page has 
 completed its transition.
 
 didStartPageTransition is about starting a provisional load, and 
 didCompletePageTransition is *not* about committing a provisional load.  
 Additionally, neither of these are actually sent to any API clients;  They 
 are internal to WebPage.
 
 If you think didCommitLoadForFrame() for the main frame was what you wanted, 
 then both of these are irrelevant anyways.
 
 didCompletePageTransition is forwarded to the C API client.
 In WebPage it calls WebPageProxy::pageTransitionViewportReady - 
 WebView(inheriting PageClient)::pageTransitionViewportReady - 
 WebViewClient::didCompletePageTransition


This is not true in general for the WK2 project.  Cross platform WK2 API is in 
terms of the WK* objects and their clients.  What you’re describing here is 
something very platform specific to your platform’s WebView implementation.

Anyways, in your original message, you mentioned that you wanted to know 
didCommitLoadForFrame for the main frame, and you intended to pipe 
didStartPageTransition through to the UIProcess to approximate that.

didStartPageTransition is more about tiled backing stores being set up properly 
and not about loading transitions.  It’s not remotely the same thing as 
didCommitLoadForFrame was called for the main frame.

Thanks,
~Brady___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Roadmap for Qt specific implementation for Network Process

[Brady Eidson]

On Jul 8, 2013, at 22:13, KwangYul Seo k...@webkit.org wrote:

 Hi,
 
 Currently, only the Mac port uses NetworkProcess, so there is no platform 
 specific code for other backends. 
 
 I am working on porting NetworkProcess to soup backend for WebKit GTK and EFL 
 ports. The master bug is https://bugs.webkit.org/show_bug.cgi?id=108832. 
 
 You can see the platform bits you need to add to support NetworkProcess for 
 Qt. Also we can share some infrastructure work such as supporting UNIX domain 
 sockets in NetworkProcess.
 
 Regards,
 Kwang Yul Seo

To clarify further:

Yes, there is currently Mac-specific code in NetworkProcess as Mac was the port 
it was developed on and is currently the only client.  But a vast majority of 
the code is already cross-platform.

The Soup (EFL/GTK) effort is actually a very small amount of code and will be 
easy to get up-and-running *after* the CoreIPC stuff is resolved.

You may want to follow that specific bug and make sure Qt also gets its CoreIPC 
impl out of #ifdef hell.

~Brady

 
 
 On Tue, Jul 9, 2013 at 1:46 PM, Harsh Sarin h.sari...@gmail.com wrote:
 Hi,
 
 I am new to webkit and currently analyzing the Network Process module. 
 However, I am unable to locate any platform specific implementations for the 
 same, except for that of mac platform. Like the Plugin and Web process I was 
 expecting a main file (platform based) from where I could start debugging.  
 Please could you shed some light on when and how you plan to develop a 
 platform specific infrastructure for Network Process, specifically for Qt 
 platform.
 Thanks for your time.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Brady Eidson]

On Jul 1, 2013, at 5:27 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Sun, Jun 30, 2013 at 9:39 PM, Filip Pizlo fpi...@apple.com wrote:
 On Jun 19, 2013, at 9:41 AM, Dan Bernstein m...@apple.com wrote:
 
 
 
  On Jun 19, 2013, at 7:37 PM, Timothy Hatcher timo...@apple.com wrote:
 
  What about?
 
  StyleResolver* existingStyleResolver()
  StyleResolver styleResolver()
 
  I like it.
 
 
  — Timothy Hatcher
 
 
  On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote:
 
  For me optional seems very misleading and generally different prefixes 
  suggests that those objects are not the same.
  Maybe IfExists does not sound nicely but at least it's clear. I would 
  choose to have a pointer version with IfExists and a reference version 
  which is a noun, like:
 
  StyleResolver* styleResolverIfExists()
 
 I like this more. I like that the use of 'if' in the name alerts me to the 
 fact that the function will return something conditionally.
 
 By contrast, existingFoo only makes sense to me if I'm already aware of the 
 idiom. And although I probably will *become* aware of the idiom it will still 
 nonetheless be one of many idioms that I have to be aware of, so I fear that 
 I'll forget why Foo is qualified with existing. That's why I like 
 fooIfExists - its super explicit about what is going on.
 
 I concur.  Maybe
 StyleResolver* styleResolverIfExists()
 StyleResolver styleResolver()
 ?

I concur with this.

For this entire discussion, this is where I was hoping it was headed.

Thanks,
~Brady

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

Re: [webkit-dev] Safari support for Web Speech API

[Brady Eidson]

On May 15, 2013, at 5:09 PM, Randy Brown rbr...@madmobile.com wrote:

 If a forum dedicated to web-kit development is not the proper place to ask a 
 question about whether anyone has heard of a major vendor's support for a 
 ground-breaking new web-kit spec, exactly where should this be asked?

WebKit is an open source project which this list covers.

Safari is a product released by Apple Inc, and questions about it should 
probably be posed to them directly.

As for the correct forum to do that, traditionally people are encouraged to 
file bug reports at developer.apple.com with feature requests.

~Brady

 
 
 From: Dan Bernstein m...@apple.com
 Date: Wednesday, May 15, 2013 7:53 PM
 To: RANDY BROWN rbr...@madmobile.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Safari support for Web Speech API
 
 
 On May 15, 2013, at 4:46 PM, Randy Brown rbr...@madmobile.com wrote:
 
 I'm trying to ascertain if, and when, Apple is planning on supporting the 
 Web Speech API.  This email from Chris that was attached to this post 
 earlier in the year, is the ONLY thing I can find on the web regarding 
 Apple's support of the speech API, which is very surprising to me.  Does 
 anyone have any knowledge of whether or not Apple is planning to support 
 this spec for Safari, specifically on mobile, and if so, when?  Now that 
 this is a W3C spec, and Chrome has added support for it, Apple is seriously 
 missing the boat on this.  As a developer of mobile optimized sites for 
 large retail brands, we see speech to text as a game changer for the mobile 
 web.  Very interested to know if this is even on Apple's radar…and if not, 
 why not?
 
 Thanks for any and all feed back on this topic.
 Randy
 
 First of all, webkit-dev is not an appropriate forum for discussing any 
 vendor’s product plans. In addition to that, Apple doesn’t comment on 
 unannounced products and features.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] FrameLoader::stopAllLoaders and sync XHR

[Brady Eidson]

On Apr 22, 2013, at 8:37 AM, Joe Mason jma...@blackberry.com wrote:

 I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit 
 (which is pretty hard to reproduce, so I don't have a cut-down test case 
 yet). Right now my suspicions are on this behaviour:
 
 a synchronous XMLHttpRequest starts loading (from a script running in the 
 main frame)
 ResourceHandle::platformLoadResourceSynchronously gets called
 On BlackBerry, this is implemented by creating a nested EventLoop and calling 
 loop.cycle()
 While in the nested event loop, BlackBerry::WebPage::stopLoading is called

There's your problem - loadResourceSynchronously is supposed to guarantee that 
- from WebCore's perspective - the main web thread is waiting on the resource 
load.

The nested event loop needs to be configured to *not* call back in to WebCore 
and *only* to service the load.

Note that this expectation re: sync XHR is why single-process, 
Web-thread-is-UI-thread browsers are expected to become completely non 
responsive during the sync XHR.

The proper way to allowing such an app to exit while a sync XHR is outstanding 
would be to cause the sync XHR load to fail at the networking layer *then* exit.

~Brady


 This is implemented by calling m_mainFrame-loader()-stopAllLoaders()
 
 As far as I can see, FrameLoader::stopAllLoaders does NOT stop any 
 XMLHttpRequest started from this frame - it just stops the 
 provisionalDocumentLoader and documentLoader for the frame itself, and 
 recursively does the same for all subframes. Is that correct?
 
 Is there a way to find and stop all synchronous requests associated with a 
 frame? (There should be only one...)
 
 Thanks,
 Joe
 
 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] restricting the number of new windows created in response to a user gesture

[Brady Eidson]

On Apr 12, 2013, at 5:05 AM, Jochen Eisinger joc...@chromium.org wrote:

 Hi,
 
 currently, WebKit allows for an arbitrary number of new windows to be created 
 in response to a single user gesture. This is used for example to create 
 pop-unders.
 
 In order to restrict the number of new windows to one per user gesture, a 
 port needs to invoke UserGestureIndicator::consumeUserGesture() in it's 
 ChromeClient::createWindow method.
 
 In https://bugs.webkit.org/show_bug.cgi?id=114379 I add this for WK2 and for 
 WK1 mac/win.
 
 Are other ports interested in this behavior? If not, I'd just skip the 
 corresponding tests.

I'm not sure it's the right move to force this on any port.  Some ports might 
be interested, for example, in not breaking legitimate intranet tools that use 
multiple pop-ups/unders.

 There are some gotchas: e.g. if your port is using out of process plugins, 
 and the plugin wants to react to a user gesture, you're probably storing 
 whether WebKit is processing a user gesture before calling out to the plugin, 
 and restore a UserGestureIndicator once the plugin replies. To make sure a 
 plugin cannot use this to generate additional user gestures (after the 
 original user gesture was already consumed), you should store the 
 UserGestureIndicator::currentToken() and use that to create the 
 UserGestureIndicator (it's basically a ref-counted integer of how many 
 gestures are left to consume).

Skipping tests is one thing.  It's definitely not okay to break functionality 
in a port like this.

~Brady

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

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

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Brady Eidson]

 On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote:
 The various tokenizers / lexers work various ways to handle LChar versus 
 UChar input streams.  Most of the other tokenizers are templatized on input 
 character type. In the case of HTML, the tokenizer handles a UChar character 
 at a time.  For 8 bit input streams, the zero extension of a LChar to a 
 UChar is zero cost.  There may be additional performance to be gained by 
 doing all other possible handling in 8 bits, but an 8 bit stream can still 
 contain escapes that need a UChar representation as you point out.  Using a 
 character type template approach was deemed to be too unwieldy for the HTML 
 tokenizer.  The HTML tokenizer uses SegmentedString's that can consist of 
 sub strings with either LChar and UChar.  That is where the LChar to UChar 
 zero extension happens for an 8 bit sub string.
 
 My research showed that at the time showed that there were very few UTF-16 
 only resources (5% IIRC), although I expect the number to grow.

On Mar 7, 2013, at 2:16 PM, Adam Barth aba...@webkit.org wrote:
 Yes, I understand how the HTML tokenizer works.  :)

I didn't understand these details, and I really appreciate Michael describing 
them.  I'm also glad others on the mailing list had an opportunity to get 
something out of this.

~Brady

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

Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess

[Brady Eidson]

On Feb 12, 2013, at 12:00 PM, Maciej Stachowiak m...@apple.com wrote:

 
 On Feb 12, 2013, at 8:28 AM, Zeno Albisser z...@webkit.org wrote:
 
 
 On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote:
 
 You also need IPC because the NetworkProcess serves the needs of the web 
 process. Could you describe why a network thread in the UI process fit your 
 needs bettter? Is it to support API's related to networking or does it have 
 other advantages?
 
  
 Yes, that was slightly ambiguous. Let me rephrase that.
 Currently the IPC for the NetworkProcess is setup by 
 ChildProcess::initialize(). Since we would not need to create a whole new 
 process in our case, we would just spin of a thread and create the 
 appropriate IPC connections ourselves.
 That could be an implementation detail of our NetworkThread implementation. 
 For prototyping i even reused the whole ChildProcess code with a few minor 
 changes. But it would feel wrong to have instances of ChildProcess in 
 something that is a thread of the same process.
 
 One of the main advantages of having networking in the UIProcess for our 
 port is, that we could support some features such as Application URL Schemes 
 without going through the WebKit2 API.
 This is a very Qt specific use case, that IMHO does not fit very nicely into 
 the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of 
 qrc files to embed content. And Application URL Schemes was the solution to 
 allow for qrc content in a QQuickWebView. 
 
 Is this just for the qrc URL scheme specifically? If so, why not just teach 
 the NetworkProcess how to handle qrc:? Using a thread instead of a process 
 sounds like overkill just to solve that one problem.

We already support custom schemes on Mac by proxying the loading from the 
networking process to the UI process.

For the Mac this is done in terms of NSURLProtocol.  You could provide your own 
implementation of the port-specific bits of CustomProtocolManager and 
CustomProtocolManagerProxy.

Thanks,
~Brady

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

Re: [webkit-dev] Multiprocess networking in WebKit

[Brady Eidson]

On Dec 4, 2012, at 12:36 PM, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Tuesday 04 December 2012, Adam Barth wrote:
 There's been a somewhat fragmented discussion across webkit-dev and
 various bugs about how we ought to approach multiprocess networking in
 WebKit.  In an attempt to organize my thoughts, I wrote up a short
 design document that compares various approaches:
 
 https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD
 4fQY/edit
 ...
 About the network process, I would just like to suggest not limiting it to 
 one, not even to begin with. There is not much simplicity or efficiency to be 
 gained by keeping all network request in the same process, and extra 
 processes 
 could be used for faster responses and increased security.

I haven't had the chance to read Adam's document yet.

I disagree with your notion that a single Network Process doesn't much 
efficiency to be gained.  In a world with multiple web content processes it is 
important to have a single coordinator for network i/o so the systems 
connection and any given host isn't hammered.

That said, the work we've already done on the WebKit2 Network Process assumes 
support for multiple Network Processes at some stage.  Actually making use of 
them can be rolled in once the fundamentals in place.

~Brady

 
 Regards
 `Allan Sandfeld
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Feature Request: Dynamic Application Cache

[Brady Eidson]

On Nov 18, 2012, at 10:18 AM, sridharn sridhar.ndr...@gmail.com wrote:

 Oops! didn't realize that .. I was planning to make the changes myself to 
 webkit (I'm totally new btw) so that at least I can use it in my environment 
 but wanted to understand the current state and/or how to go about in case 
 there is an acceptable method so that the changes can be pulled into the 
 mainline in case everything works out .. 

This thread has gotten overloaded and is suffering due to lack of clarity.  I 
think you primarily raised two issues.

1 - The current app cache doesn't work with media files.

This is false.  The design of the app cache is that it *does* work with media 
files, and we expect it to work with media files.  If you are running in to 
problems putting media files in the current app cache mechanism, please file a 
bug at bugs.webkit.org specifying precisely what you tried and with which 
configuration.

2 - I wish application cache has dynamic entry support

This is a feature request (completely unrelated to the fact that you want media 
files in the app cache).  As Maciej mentioned in an earlier reply feature 
requests do not belong on WebKit-dev.  The best place to start is probably - 
again - filing a bug at bugs.webkit.org

Note that if you are a brand new contributor to WebKit, taking on the addition 
of an entirely new app cache feature is almost certainly going to be way too 
difficult.

Thanks,
~Brady

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

Re: [webkit-dev] Feature Request: Dynamic Application Cache

[Brady Eidson]

On Nov 17, 2012, at 7:47 AM, sridharn sridhar.ndr...@gmail.com wrote:

 Any updates / plans for this feature ??

What feature?

 I do agree with  Stefan on this ..
 I've been banging my head on how 
 to  cache video files using html 5 storage features and there just doesn't
 seem to be a straightforward way
 (they all are currently intended for small size text / mobile webkit doesn't
 support file system and blah blah) 
 to do that and feel appcache is cleaner way going forward too for media
 files .. 

Where are you seeing this not work?

At least on the Apple port you should be able to stick audio/video in the app 
cache.  There are a handful of bugzillas that show this work being done a long 
time ago.

If it's not working for you, I look forward to reading the bug you file at 
bugs.webkit.org.

 Also, mobile webkit (chrome/safari in ios4) don't seem to appcache mp3 files
 (~5MB) .. Is this a known issue ? 

iOS4 is ancient.  I forget when this first shipped but it should work in iOS6.

 This should hopefully go away once the dynamic mechanism is added I hope .. 

Again, not sure precisely which dynamic mechanism you're talking about since 
you included no context in your email, but I don't see how a dynamic app cache 
mechanism is related to the app cache supporting media, which it does.

~Brady

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

Re: [webkit-dev] PAN(flick) to left operation collapse screen in Webkit(Safari) on window7 tablet

[Brady Eidson]

It sounds like you meant to go to https://bugs.webkit.org/ and file a bug.

Thanks,
~Brady

On Nov 15, 2012, at 1:13 AM, HIDEKI YOSHIDA yoshida-...@necst.nec.co.jp wrote:

 Hi,
 
 PAN(flick) to left operation collapse screen in Webkit(Safari) on window7
 tablet.
 
 Version:Safari 5.1.7(7534.57.2)
 
 Does anyone know this problem and the patch to resolve?
 
 How to reproduce.
 1) Launch Safai on Windows tablet. Set its window's width less than
 960px.
 
 2) Open http://jquerymobile.com/demos/1.1.1/docs/forms/docs-forms.html
 with it.
 
 3) On the right pane, do PAN(flick) to left, then the whole contents in 
 the window move horizontally to left by about 30px to 100px.
 
 This contents itself is not designed to move horizontally.
 The move does not occur on other browsers such as Chrome and IE.
 This problem may not occur depending on window's width size and zoom scale.
 
 After my team analyzed this problem, we figured out that,
 when RenderLayer's m_scrollSize.m_width is greather than m_LayerSize.m_width
 at the beginning of scrollByRecursively in RederLayer.cpp which is called 
 just before PAN processing, this problem occurs.
 
Hideki
 
 ***
  Hideki Yoshida
  Embedded Software Division
  NEC System Technologies, Ltd.
E-MAIL:yoshida-...@necst.nec.co.jp
 ***
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

A bit of background:

A few of us have been working on enhancing WebKit2's support for multiple 
WebProcesses.  As part of this effort I'm working on 
https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to 
WebKit2

One benefit of the NetworkProcess will be to have a single shared process doing 
network i/o on behalf of all attached WebProcesses.

Another benefit we've identified is the ability to have that process also act 
as custodian for a shared memory cache amongst the attached WebProcesses.

While this effort is primarily about WebKit 2, making it possible will 
obviously involve some changes to the WebCore memory cache and resource loading.

I don't plan to shoehorn in changes, but rather to make sensical refactoring 
that cleans up the code for all ports.  Anyone familiar with the CachedResource 
and ResourceLoader mechanisms probably know they're not really up to the 
clarity and quality standards we strive for, and I'm excited about being able 
to focus on them for awhile and make them better for everyone.

I have a few patches lined up locally to do this and have attached the first of 
these to https://bugs.webkit.org/show_bug.cgi?id=98539

Feel free to share concerns here or in the collection of bugzillas that will 
slowly be growing as I make progress.

~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote:

 When we looked at whether we should add a shared memory cache to
 Chromium, we came to the conclusion that there wasn't much benefit to
 having a shared memory cache.  In
 https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that
 you have data showing that a shared memory cache is a win.  Would you
 be willing to share this data with the WebKit community?

It's possible the disparity is because of the process model Chromium was 
focusing on versus the process models we are exploring.

WebKit 2 is also evolving as an API framework that supports other non-browser 
clients which might have different caching needs than Chromium has focused on.

We don't have hard data to share at this time.  A simple experiment one could 
run to see the type of result we're focusing on would be to open a handful of 
articles from various top-tier news sites in different tabs and note just how 
many resources are shared between them.

Thanks,
~Brady

 
 Adam
 
 
 On Mon, Oct 8, 2012 at 10:39 AM, Brady Eidson beid...@apple.com wrote:
 A bit of background:
 
 A few of us have been working on enhancing WebKit2's support for multiple 
 WebProcesses.  As part of this effort I'm working on 
 https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to 
 WebKit2
 
 One benefit of the NetworkProcess will be to have a single shared process 
 doing network i/o on behalf of all attached WebProcesses.
 
 Another benefit we've identified is the ability to have that process also 
 act as custodian for a shared memory cache amongst the attached WebProcesses.
 
 While this effort is primarily about WebKit 2, making it possible will 
 obviously involve some changes to the WebCore memory cache and resource 
 loading.
 
 I don't plan to shoehorn in changes, but rather to make sensical refactoring 
 that cleans up the code for all ports.  Anyone familiar with the 
 CachedResource and ResourceLoader mechanisms probably know they're not 
 really up to the clarity and quality standards we strive for, and I'm 
 excited about being able to focus on them for awhile and make them better 
 for everyone.
 
 I have a few patches lined up locally to do this and have attached the first 
 of these to https://bugs.webkit.org/show_bug.cgi?id=98539
 
 Feel free to share concerns here or in the collection of bugzillas that will 
 slowly be growing as I make progress.
 
 ~Brady
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

On Oct 8, 2012, at 10:52 AM, Jochen Eisinger joc...@chromium.org wrote:

 Hey,
 
 can you share your plan how to prioritize network requests in the network 
 process?
 …
 We currently work around that issue by adding a TargetType to ResourceRequest 
 which is however a layering violation which I'd like to get rid of.

Since the NetworkProcess management will be contained in WebKit 2 it won't be 
an equivalent layering violation for that port.

If that explanation doesn't make sense then I might have misinterpreted your 
concern.

On a slightly different note it seems reasonable to me that a WebCore 
ResourceRequest have target-type/priority-type information attached to it.

I don't know if doing that has come up in the past and different conclusions we 
reached.  I haven't placed a lot of thought into that since it doesn't seem 
directly necessary for this effort.

~Brady

 
 best
 -jochen
 
 On Mon, Oct 8, 2012 at 7:39 PM, Brady Eidson beid...@apple.com wrote:
 A bit of background:
 
 A few of us have been working on enhancing WebKit2's support for multiple 
 WebProcesses.  As part of this effort I'm working on 
 https://bugs.webkit.org/show_bug.cgi?id=98537 - Add a NetworkProcess to 
 WebKit2
 
 One benefit of the NetworkProcess will be to have a single shared process 
 doing network i/o on behalf of all attached WebProcesses.
 
 Another benefit we've identified is the ability to have that process also act 
 as custodian for a shared memory cache amongst the attached WebProcesses.
 
 While this effort is primarily about WebKit 2, making it possible will 
 obviously involve some changes to the WebCore memory cache and resource 
 loading.
 
 I don't plan to shoehorn in changes, but rather to make sensical refactoring 
 that cleans up the code for all ports.  Anyone familiar with the 
 CachedResource and ResourceLoader mechanisms probably know they're not really 
 up to the clarity and quality standards we strive for, and I'm excited about 
 being able to focus on them for awhile and make them better for everyone.
 
 I have a few patches lined up locally to do this and have attached the first 
 of these to https://bugs.webkit.org/show_bug.cgi?id=98539
 
 Feel free to share concerns here or in the collection of bugzillas that will 
 slowly be growing as I make progress.
 
 ~Brady
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 

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

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

On Oct 8, 2012, at 11:24 AM, Adam Barth aba...@webkit.org wrote:

 On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote:
 On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote:
 When we looked at whether we should add a shared memory cache to
 Chromium, we came to the conclusion that there wasn't much benefit to
 having a shared memory cache.  In
 https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that
 you have data showing that a shared memory cache is a win.  Would you
 be willing to share this data with the WebKit community?
 
 It's possible the disparity is because of the process model Chromium was 
 focusing on versus the process models we are exploring.
 
 WebKit 2 is also evolving as an API framework that supports other 
 non-browser clients which might have different caching needs than Chromium 
 has focused on.
 
 We don't have hard data to share at this time.  A simple experiment one 
 could run to see the type of result we're focusing on would be to open a 
 handful of articles from various top-tier news sites in different tabs and 
 note just how many resources are shared between them.
 
 Without data showing that this is a win, adding a shared memory cache
 to WebCore seems like over-engineering and unneeded complexity.  We
 had the same design instincts as you when we looked at this issue in
 Chromium, but we studied the issue (twice actually) and concluded that
 the complexity wasn't worth the meager benefits.

There might be some misunderstanding of the specifics of what I'm working on.

I don't plan to add a shared memory cache to WebCore, or even to add an 
abstraction of shared memory directly to WebCore.

I'm working on refactoring the resource loader/cache to support more 
customization by the embedding port - In this case, WebKit 2.

Traditionally we've supported refactoring WebCore in ways important to an 
embedding port even if that port has substantially different needs than most 
mainstream WebCore clients.

I'm not sure that I see how this case is in a different category.

Thanks,
~Brady

 
 Adam

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

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

On Oct 8, 2012, at 12:17 PM, Adam Barth aba...@webkit.org wrote:

 On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson beid...@apple.com wrote:
 On Oct 8, 2012, at 11:24 AM, Adam Barth aba...@webkit.org wrote:
 On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson beid...@apple.com wrote:
 On Oct 8, 2012, at 10:58 AM, Adam Barth aba...@webkit.org wrote:
 When we looked at whether we should add a shared memory cache to
 Chromium, we came to the conclusion that there wasn't much benefit to
 having a shared memory cache.  In
 https://bugs.webkit.org/show_bug.cgi?id=98541#c4, you mentioned that
 you have data showing that a shared memory cache is a win.  Would you
 be willing to share this data with the WebKit community?
 
 It's possible the disparity is because of the process model Chromium was 
 focusing on versus the process models we are exploring.
 
 WebKit 2 is also evolving as an API framework that supports other 
 non-browser clients which might have different caching needs than Chromium 
 has focused on.
 
 We don't have hard data to share at this time.  A simple experiment one 
 could run to see the type of result we're focusing on would be to open a 
 handful of articles from various top-tier news sites in different tabs and 
 note just how many resources are shared between them.
 
 Without data showing that this is a win, adding a shared memory cache
 to WebCore seems like over-engineering and unneeded complexity.  We
 had the same design instincts as you when we looked at this issue in
 Chromium, but we studied the issue (twice actually) and concluded that
 the complexity wasn't worth the meager benefits.
 
 There might be some misunderstanding of the specifics of what I'm working on.
 
 I don't plan to add a shared memory cache to WebCore, or even to add an 
 abstraction of shared memory directly to WebCore.
 
 I'm working on refactoring the resource loader/cache to support more 
 customization by the embedding port - In this case, WebKit 2.
 
 Traditionally we've supported refactoring WebCore in ways important to an 
 embedding port even if that port has substantially different needs than most 
 mainstream WebCore clients.
 
 I'm not sure that I see how this case is in a different category.
 
 Would there be any design or implementation constraints on WebCore?
 For example, would WebCore need to understand any concurrency or
 performance issues caused by the memory being shared between
 processes?

For now we think the answer is no, or that any parts that do need to be 
concerned to be wholly encapsulated within the support for the client model.

Thanks,
~Brady

 
 Adam

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

Re: [webkit-dev] Settings and Preferences in layout tests

[Brady Eidson]

On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser simon.fra...@apple.com wrote:
 
  First, direct calls on testRunner that just set preferences should be 
 migrated to internals.settings or testRunner.overridePreference calls, I 
 think (I don't know if either is preferred).
 
 I support the idea of unifying the approaches and just use 
 internals.settings. However, the last time I checked, Alexey had some 
 concerns about using internals due to settings may not be properly propagated 
 to WebKit2 layer. Has this concern been addressed?

In general I prefer the overridePreference() calls whenever they exist.

internals.settings are not exposed in any real-world product whereas 
preferences exist in each platform's WebKit-layer API that they expose to their 
embedders in some form.

~Brady

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

Re: [webkit-dev] Settings and Preferences in layout tests

[Brady Eidson]

On Sep 26, 2012, at 2:05 PM, Adam Barth aba...@webkit.org wrote:

 [re-sent from the proper address]
 
 On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth abarth@nowhere wrote:
 
 
 On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson beid...@apple.com wrote:
 
 On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser simon.fra...@apple.com wrote:
 
  First, direct calls on testRunner that just set preferences should be 
 migrated to internals.settings or testRunner.overridePreference calls, I 
 think (I don't know if either is preferred).
 
 I support the idea of unifying the approaches and just use 
 internals.settings. However, the last time I checked, Alexey had some 
 concerns about using internals due to settings may not be properly 
 propagated to WebKit2 layer. Has this concern been addressed?
 
 In general I prefer the overridePreference() calls whenever they exist.
 
 internals.settings are not exposed in any real-world product whereas 
 preferences exist in each platform's WebKit-layer API that they expose to 
 their embedders in some form.
 
 The main downside of overridePreference is that it requires that you expose 
 an API for twiddling the preference on every port.  That can lead to us 
 exposing unneeded APIs (making them harder to remove) and to a bunch of 
 port-specific code in an otherwise port-independent patch.
 
 IMHO, we should prefer InternalSettings unless we need to test the 
 WebKit-layer code.

I suppose we're biased in Mac-land where the mechanism originated, but the 
API is simply a single string based API that only had to be implemented once.

Your comment leads me to understand that at least one other port doesn't have 
simple string based preferences.

Of course to add *any* new internal setting new code must be added specifically 
for that setting...

Of course that code only has to be added once for all platforms…

I would argue it's not a clear cut decision either way.

~Brady


 
 Adam
 
 

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

Re: [webkit-dev] Settings and Preferences in layout tests

[Brady Eidson]

On Sep 26, 2012, at 2:14 PM, Eric Seidel e...@webkit.org wrote:

 TestExpectation files on all ports are full of:
 # unskip these tests when we add obscure-drt-feature-x
 
 http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L107
 http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L209
 http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L247

I believe these will go away with a single implementation of 
overridePreference().

 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L115
 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L948
 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L958

But am not so sure here.

 I would agree with Adam, and the more we can move to window.internals,
 the less technical debt we incur with each new DRT feature.

 
 I would love to see overridePreferences go away (or only be used for
 preferences which need to test the WebKit-side plumbing).

DRT/WKTR are important not only in that they test WebCore but also in that they 
test the WebKit they embed.

This seems like a short sided conclusion based on convenience.

~Brady

 
 as just a few examples. :)  I didn't even look at the less-well-funded ports. 
 :)
 
 On Wed, Sep 26, 2012 at 4:05 PM, Adam Barth aba...@webkit.org wrote:
 [re-sent from the proper address]
 
 On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth abarth@nowhere wrote:
 
 
 
 On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson beid...@apple.com wrote:
 
 
 On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser simon.fra...@apple.com
 wrote:
 
 
 First, direct calls on testRunner that just set preferences should be
 migrated to internals.settings or testRunner.overridePreference calls, I
 think (I don't know if either is preferred).
 
 
 I support the idea of unifying the approaches and just use
 internals.settings. However, the last time I checked, Alexey had some
 concerns about using internals due to settings may not be properly
 propagated to WebKit2 layer. Has this concern been addressed?
 
 
 In general I prefer the overridePreference() calls whenever they exist.
 
 internals.settings are not exposed in any real-world product whereas
 preferences exist in each platform's WebKit-layer API that they expose to
 their embedders in some form.
 
 
 The main downside of overridePreference is that it requires that you
 expose an API for twiddling the preference on every port.  That can lead to
 us exposing unneeded APIs (making them harder to remove) and to a bunch of
 port-specific code in an otherwise port-independent patch.
 
 IMHO, we should prefer InternalSettings unless we need to test the
 WebKit-layer code.
 
 Adam
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 

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

Re: [webkit-dev] Settings and Preferences in layout tests

[Brady Eidson]

On Sep 26, 2012, at 2:46 PM, Tony Chang t...@chromium.org wrote:

 On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson beid...@apple.com wrote:
 On Sep 26, 2012, at 2:05 PM, Adam Barth aba...@webkit.org wrote:
 [re-sent from the proper address]
 
 On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth abarth@nowhere wrote:
 On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson beid...@apple.com wrote:
 On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser simon.fra...@apple.com 
 wrote:
 
  First, direct calls on testRunner that just set preferences should be 
 migrated to internals.settings or testRunner.overridePreference calls, I 
 think (I don't know if either is preferred).
 
 I support the idea of unifying the approaches and just use 
 internals.settings. However, the last time I checked, Alexey had some 
 concerns about using internals due to settings may not be properly 
 propagated to WebKit2 layer. Has this concern been addressed?
 
 In general I prefer the overridePreference() calls whenever they exist.
 
 internals.settings are not exposed in any real-world product whereas 
 preferences exist in each platform's WebKit-layer API that they expose to 
 their embedders in some form.
 
 The main downside of overridePreference is that it requires that you expose 
 an API for twiddling the preference on every port.  That can lead to us 
 exposing unneeded APIs (making them harder to remove) and to a bunch of 
 port-specific code in an otherwise port-independent patch.
 
 IMHO, we should prefer InternalSettings unless we need to test the 
 WebKit-layer code.
 
 I suppose we're biased in Mac-land where the mechanism originated, but the 
 API is simply a single string based API that only had to be implemented 
 once.
 
 Your comment leads me to understand that at least one other port doesn't have 
 simple string based preferences.
 
 Of course to add *any* new internal setting new code must be added 
 specifically for that setting...
 
 Of course that code only has to be added once for all platforms…
 
 I think for all the major ports, they are simple string based preferences.  
 However, adding a new overridePreference call means updating 5 WebKit API 
 interfaces (Mac, Win, Chromium, GTK+, QT),  and updating 5 DRTs and 1 WTR.  
 Compared to updating a single internal.settings implementation, this is a lot 
 of work.

I think you misunderstand what I meant.

The Mac DRT implementation of overridePreference has the following 
implementation:

void TestRunner::overridePreference(JSStringRef key, JSStringRef value)
{
RetainPtrCFStringRef keyCF(AdoptCF, 
JSStringCopyCFString(kCFAllocatorDefault, key));
NSString *keyNS = (NSString *)keyCF.get();

RetainPtrCFStringRef valueCF(AdoptCF, 
JSStringCopyCFString(kCFAllocatorDefault, value));
NSString *valueNS = (NSString *)valueCF.get();

[[WebPreferences standardPreferences] 
_setPreferenceForTestWithValue:valueNS forKey:keyNS];
}

This works for any preference;  Even a new one that has never been twiddled in 
a regression test before.

For example in http://trac.webkit.org/changeset/127956 we added a new test that 
twiddled the WebKitStorageBlockingPolicy preference and we didn't need to 
change any DRT Mac code to accomplish this.

Compared to adding a single implementation to internal.settings, this was *NO* 
additional work.

 In addition to being a lot of work, it increases the size of each WebKit API 
 even if the particular port doesn't want/need to expose the feature.

If a port doesn't want the feature, it can't be tested and needs to be skipped 
anyways, right?

~Brady

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

Re: [webkit-dev] Settings and Preferences in layout tests

[Brady Eidson]

On Sep 26, 2012, at 4:43 PM, Adam Barth aba...@webkit.org wrote:

 Maybe a better solution is auto-generate all this boilerplate code?  If we 
 had a Settings.in file, we could generate all the port-specific code (and 
 maybe even much of Settings.h/cpp) automatically.  Then all of these patches 
 would be one-liners and work correctly on every port.

I would be all for that.  I'm fuzzy on how the WebCore::Settings boiler plate 
would correctly apply to all WebKit ports in general, but I can see how it 
would easily solve our use case.

~Brady

 
 Adam
 
 
 On Wed, Sep 26, 2012 at 4:28 PM, Brady Eidson beid...@apple.com wrote:
 
 On Sep 26, 2012, at 4:15 PM, Simon Fraser simon.fra...@apple.com wrote:
 
 On Sep 26, 2012, at 4:13 PM, Brady Eidson beid...@apple.com wrote:
 
 This works for any preference;  Even a new one that has never been twiddled 
 in a regression test before.
 
 For example in http://trac.webkit.org/changeset/127956 we added a new test 
 that twiddled the WebKitStorageBlockingPolicy preference and we didn't 
 need to change any DRT Mac code to accomplish this.
 
 Compared to adding a single implementation to internal.settings, this was 
 *NO* additional work.
 
 But is there code to undo this pref change for subsequent tests?
 
 I looked into the mechanism that does this.
 
 On Sep 26, 2012, at 1:44 PM, Simon Fraser simon.fra...@apple.com wrote:
 
 I looked at testRunner.overridePreference(), and it doesn't appear to reset 
 the value at the end of the test.
 
 That happens elsewhere, in:
 static void resetDefaultsToConsistentValues()
 
 Indeed, each individual pref is currently managed with unique API calls here, 
 and the example I provided of WebKitStorageBlockingPolicy leaks.
 
 However, the key/value based preference mechanism can easily be augmented 
 within DRT in a general way that will fix this and all future key/value 
 preference usage.  That change would only have to happen once per port 
 (assuming the port supports key/value based prefs)
 
  Brady
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 

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

[webkit-dev] `git svn dcommit` successful, but trac comes up blank?

[Brady Eidson]

I just `git svn dcommit`ed to the repository.  Git tells me it successfully 
created 126160.  Yet http://trac.webkit.org/ and 
http://trac.webkit.org/changeset/126160 disagree.

Does 126160 actually exist?  What piece of the machine is failing us?

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] `git svn dcommit` successful, but trac comes up blank?

[Brady Eidson]

Nevermind, just saw Bill's email from 20 minutes ago.  Answered my question.

Thanks,
~Brady

On Aug 21, 2012, at 9:23 AM, Brady Eidson beid...@apple.com wrote:

 I just `git svn dcommit`ed to the repository.  Git tells me it successfully 
 created 126160.  Yet http://trac.webkit.org/ and 
 http://trac.webkit.org/changeset/126160 disagree.
 
 Does 126160 actually exist?  What piece of the machine is failing us?
 
 Thanks,
 ~Brady
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] [123877] trunk/Tools

[Brady Eidson]

Why did this get sent to webkit-dev instead of webkit-changes?

(Maybe a result of this morning's migration?)

~Brady

On Jul 27, 2012, at 9:22 AM, kbal...@webkit.org wrote:

 Revision
 123877
 Author
 kbal...@webkit.org
 Date
 2012-07-27 09:22:06 -0700 (Fri, 27 Jul 2012)
 Log Message
 
 [NRWT] should have a way to restrict pixel tests for individual directories
 https://bugs.webkit.org/show_bug.cgi?id=91754
 
 Unreviewed attempt to fix the chaos I introduced.
 
 * DumpRenderTree/qt/DumpRenderTreeQt.cpp:
 (WebCore::DumpRenderTree::processLine):
 Modified Paths
 
 trunk/Tools/ChangeLog
 trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp
 Diff
 
 Modified: trunk/Tools/ChangeLog (123876 = 123877)
 
 --- trunk/Tools/ChangeLog 2012-07-27 14:15:24 UTC (rev 123876)
 +++ trunk/Tools/ChangeLog 2012-07-27 16:22:06 UTC (rev 123877)
 @@ -1,3 +1,13 @@
 +2012-07-27  Balazs Kelemen  kbal...@webkit.org
 +
 +[NRWT] should have a way to restrict pixel tests for individual 
 directories
 +https://bugs.webkit.org/show_bug.cgi?id=91754
 +
 +Unreviewed attempt to fix the chaos I introduced.
 +
 +* DumpRenderTree/qt/DumpRenderTreeQt.cpp:
 +(WebCore::DumpRenderTree::processLine):
 +
  2012-07-27  YoungTaeck Song  youngtaeck.s...@samsung.com
  
  [WK2][EFL] Add an ACCELERATED_COMPOSITING implementation for Efl 
 WebKit2
 Modified: trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp (123876 = 
 123877)
 
 --- trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp2012-07-27 
 14:15:24 UTC (rev 123876)
 +++ trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp2012-07-27 
 16:22:06 UTC (rev 123877)
 @@ -696,7 +696,7 @@
  m_expectedHash = QString();
  // single quote marks the pixel dump hash
  int indexOfFirstSeparator = line.indexOf('\'');
 -int indexOfSecondSeparator = line.indexOf('\'', indexOfFirstSeparator);
 +int indexOfSecondSeparator = line.indexOf('\'', indexOfFirstSeparator + 
 1);
  if (indexOfFirstSeparator  -1) {
  int indexOfPixelHash = indexOfFirstSeparator + 1;
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 25, 2012, at 8:25 AM, Yong Li yong.li.web...@gmail.com wrote:

 2012/7/19 Brady Eidson beid...@apple.com:
 
 On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote:
 
 On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote:
 
 
 On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org
 wrote:
 
 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org
 wrote:
 
 Hi,
 
 For those who secretly use printf debugging :). I know the
 recommended way is to use a debugger and it's not the point of this
 discussion.
 
 A lot of us do this, and sometimes it's necessary.  I agree with the
 gripe and support adding something easier.
 
 So I propose wtf() and its stream operator.
 
 Usage :
 
 wtf()HelloWorld34.53322323; will output : Hello World 3
 4.53322
 
 There is no reason to bring in stream operators - that are willfully
 absent from WebCore - just for debugging.
 
 
 But it's really nice for that purpose, and somehow match std::cout
 
 And we quite purposefully don't use std::cout in the project.
 
 Overloading functions works just as well.
 
 I'm not sure to understand what you mean here…
 
 I mean relying on C++'s overloading of functions for the different types
 you'd like to printf debug.
 
 void debug(WebCore::String);
 void debug(WebCore::Frame*);
 void debug(WebCore::Node*);
 
 etc etc etc.
 
 debug(someFrame);
 debug(someNode);
 debug(someString);
 
 Especially that last one would help me from remembering how to type
 printf(%s, someString.utf8().data()) which is all I've ever really
 wanted.
 
 
 Hello fellow printfers!
 
 While I'm just as ashamed of my printf habits as the next guy, I think it'd
 be great if we could move forward with this somehow.
 
 Coming from a background in Qt, the stream operator syntax looks perfectly
 normal to me, perhaps you could expand on why we want to avoid using these
 in WebKit. Is there a technical reason, or is it more of a language purity
 issue?
 
 
 A possible technical reason - that I am 100% theorizing about - is that it
 might bring in more libraries at link time or runtime since it would be the
 absolute first use of stream operators in the project.
 
 That possibility aside, the stronger part of my objection is language
 purity.  WebCore uses C++ as C with classes and I don't think it's worth
 it to confuse new (or existing) contributors about that going forward.
 
 
 Can you elaborate why WebCore uses C++ as  C with classes?
 
 We are using namespace, template, operator overloading, virtual
 functions, multi-inheritance, scope object, and even
 pointer-to-member. We prefer Vector to C array, and prefer
 OwnPtr/RefPtr to C pointer. Where is C stuff?

I mean we use all the things you just said but we do not use C++ streams.

~Brady

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

Re: [webkit-dev] Do we need a webkitBackground property for XMLHttpRequest?

[Brady Eidson]

On Jul 24, 2012, at 2:58 AM, Adam Barth aba...@webkit.org wrote:

 I don't think we should add this property.  Instead we should not ever
 present HTTP auth dialogs for any requests other than the main
 resource for the top-level frame.  Presenting HTTP auth dialogs in
 other contexts is a phishing risk.

I think there are corporate/financial apps that would break if this was policy.

Thanks,
~Brady

 
 Adam
 
 
 On Tue, Jul 24, 2012 at 2:47 AM, xuewen xuewen.w...@torchmobile.com.cn 
 wrote:
 
 When we send XMLHttpRequest  to access search engines or it is sent from
 chrome extensions,  we may do/don't want the browser to show the
 authentication challenge dialog. Should we provide a property to give a
 choice to users such as the webkitBackground?
 
 Please see the bug https://bugs.webkit.org/show_bug.cgi?id=91964
 
 If we totally disable XHR popping up the challenge dialogs, then how can the
 user request the resource using XHR from the sites across origins and
 requiring authentications? Or will this operation be disallowed in the
 future?
 
 One way is to show a form by javascript to ask for the credentials in its
 onReadyStatusChange and resend it by XHR. Is this the reason to totally
 disable the XHR popping up challenge dialogs?
 
 Sean Wang
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 20, 2012, at 7:53 AM, Shezan Baig shezbaig...@gmail.com wrote:

 On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev annu...@yandex.ru wrote:
 
 19.07.2012, 22:20, Filip Pizlo fpi...@apple.com:
 Now consider the stream form:
 thingy  foo   a   bar   someWeirdNonsenseToEnableHex  b   
 baz   c  endl;
 This is 8 procedure calls and three string constants. This code will be 
 somewhere around 8 times fatter. Hence, you will be less likely to want to 
 enable such debug statements in release builds both due to fears concerning 
 unnecessary increases in binary size, and unnecessary increases in compile 
 times.
 
 Well, if all  operators are inline, it will be optimized. You also don't 
 have to add endl, because thingy can add '\n' and flush buffer at the end 
 by default (like qDebug does)
 
 
 
 Also, if START_THINGY and END_THINGY are defined as:
 
 #define START_THINGY  if (enableDebug) { thingy
 #define END_THINGY endl; }
 
 Then a statement like:
 
 START_THINGY  foo   a   bar   someWeirdNonsenseToEnableHex
  b   baz   c  END_THINGY;
 
 will all be wrapped up within an if (enableDebug) condition, which
 we would only turn on when we need the log output, so the cost of the
 streaming/printing can be virtually eliminated even if we decide to
 land the code.

I see in your followup you realized we could further wrap these in #ifndef 
NDEBUG blocks.  That's all good and well until someone takes a block like...

 This also allows us to do more complex things like:
 
 START_THINGY  Selectively printing variables:;
if (isSet(someVar1))
thingy   someVar1 = '  someVar1  ';
if (isSet(someVar2))
thingy   someVar2 = '  someVar2  ';
 
if (someArray.length()) {
thingy   someArray.items = [;
for (int i = 0; i  someArray.length(); ++i) {
thingy  someArray[i]  , ;
}
thingy  ];
}
 thingy  END_THINGY;

…this and tries to add their own internal #ifndef DEBUG blocks within the 
statement.  For this reason we tend to keep the automatically #ifdef NDEBUG 
protected utilities like LOG and ASSERT limited to a single statement.

In general this is voluminous code we'd probably not want landed the same way 
we like dataLog() and LOG() statements to be landed.  But a specific reason we 
wouldn't want it landed is that It's not at all obvious to a casual observer 
that this entire block is meant to be debug only.

 And because I'm in the middle of debugging a particular issue, I don't
 really want to create a new type that wraps up those (potentially
 unrelated) variables, just in order to create an overloaded debug()
 function that does the pretty printing.

I'm not quite sure what your point is here.

- If you mean you don't want to be hassled by added a new template for a super 
long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when the built 
in utility only supports up through k - then that seems somewhat silly as doing 
so would be simple and mechanical.

- If you mean you don't want to be hassled to add a new overload for the type 
you'd like to print, then you'd still have to add a new operator  overload 
for that type if it didn't already exist.

- If you mean you don't think that debug() statements could be broken up in to 
multiple lines, of course they can.

debug(Selectively printing variables:;
   if (isSet(someVar1))
debug(someVar1 = , someVar1);
   if (isSet(someVar2))
debug(someVar1 = , someVar1);
   if (someVector.size())
debug( someVector.items = , someVector);
debug(\n);

Also notice it would be easy to templatize a debug() override to handle the 
pretty-printing of the vector directly, in addition to other POD and non-class 
types.

Even without the vector enhancement, this version is simple easier on my eyes 
as it's not at odds with the entire rest of our code base.

~Brady

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

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote:

 On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org 
 wrote:
 
  On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
 
  On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org 
  wrote:
 
  Hi,
 
  For those who secretly use printf debugging :). I know the
  recommended way is to use a debugger and it's not the point of this
  discussion.
 
  A lot of us do this, and sometimes it's necessary.  I agree with the gripe 
  and support adding something easier.
 
  So I propose wtf() and its stream operator.
 
  Usage :
 
  wtf()HelloWorld34.53322323; will output : Hello World 3 
  4.53322
 
  There is no reason to bring in stream operators - that are willfully 
  absent from WebCore - just for debugging.
 
 
  But it's really nice for that purpose, and somehow match std::cout
 
 And we quite purposefully don't use std::cout in the project.
 
  Overloading functions works just as well.
 
  I'm not sure to understand what you mean here…
 
 I mean relying on C++'s overloading of functions for the different types 
 you'd like to printf debug.
 
 void debug(WebCore::String);
 void debug(WebCore::Frame*);
 void debug(WebCore::Node*);
 
 etc etc etc.
 
 debug(someFrame);
 debug(someNode);
 debug(someString);
 
 Especially that last one would help me from remembering how to type 
 printf(%s, someString.utf8().data()) which is all I've ever really wanted.
 
 Hello fellow printfers!
 
 While I'm just as ashamed of my printf habits as the next guy, I think it'd 
 be great if we could move forward with this somehow.
 
 Coming from a background in Qt, the stream operator syntax looks perfectly 
 normal to me, perhaps you could expand on why we want to avoid using these in 
 WebKit. Is there a technical reason, or is it more of a language purity issue?

A possible technical reason - that I am 100% theorizing about - is that it 
might bring in more libraries at link time or runtime since it would be the 
absolute first use of stream operators in the project.

That possibility aside, the stronger part of my objection is language purity.  
WebCore uses C++ as C with classes and I don't think it's worth it to confuse 
new (or existing) contributors about that going forward.

 Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods 
 as suggested would still be massively useful.

Definitely.

~Brady

 
 -Kling

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com 
wrote:

 On 19.07.2012 19:53, Andreas Kling wrote:
 On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org 
 wrote:
 
  On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
 
  On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org 
  wrote:
 
  Hi,
 
  For those who secretly use printf debugging :). I know the
  recommended way is to use a debugger and it's not the point of this
  discussion.
 
  A lot of us do this, and sometimes it's necessary.  I agree with the 
  gripe and support adding something easier.
 
  So I propose wtf() and its stream operator.
 
  Usage :
 
  wtf()HelloWorld34.53322323; will output : Hello World 3 
  4.53322
 
  There is no reason to bring in stream operators - that are willfully 
  absent from WebCore - just for debugging.
 
 
  But it's really nice for that purpose, and somehow match std::cout
 
 And we quite purposefully don't use std::cout in the project.
 
  Overloading functions works just as well.
 
  I'm not sure to understand what you mean here…
 
 I mean relying on C++'s overloading of functions for the different types 
 you'd like to printf debug.
 
 void debug(WebCore::String);
 void debug(WebCore::Frame*);
 void debug(WebCore::Node*);
 
 etc etc etc.
 
 debug(someFrame);
 debug(someNode);
 debug(someString);
 
 Especially that last one would help me from remembering how to type 
 printf(%s, someString.utf8().data()) which is all I've ever really 
 wanted.
 
 Hello fellow printfers!
 
 While I'm just as ashamed of my printf habits as the next guy, I think it'd 
 be great if we could move forward with this somehow.
 
 Coming from a background in Qt, the stream operator syntax looks perfectly 
 normal to me, perhaps you could expand on why we want to avoid using these 
 in WebKit. Is there a technical reason, or is it more of a language purity 
 issue?
 
 Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) 
 methods as suggested would still be massively useful.
 
 -Kling
 
 
 Hi,
 
 I am probably one of those people who much dislike printf-debugging.
 What is your problem with using a debugger?

The beauty of this discussion is that people who prefer the purity of using 
only the debugger can continue using only the debugger and ignore what 
printf'ers need to do.

That said, to address your question of what is your problem with using a 
debugger, many issues in WebKit are highly timing related, or highly dependent 
on multiple threads or even multiple processes interacting.  

Many crashes I've had the pleasure of working on go away simply by hitting a 
breakpoint, and many misbehaviors correct themselves the same way.

Most of the time the debugger is good enough for me.  Other times the mix of 
the debugger and printf's has been what cracked the case.  Occasionally 
ignoring the debugger completely and viewing an event stream of printfs has 
been the only reasonable way to monitor the complex interactions of what is 
going on.

 FWIW, there is a gdb python API for changing the behavior... so called pretty 
 printers.
 It is not too difficult to write such pretty-printers.

Some of us don't use gdb.  I'm not sure if these work directly in lldb or if 
there is an lldb alternative.  But...

 Maybe providing a set of useful pretty-printers is a better approach than 
 providing a set of debug functions?

Having a set of debug-build-only functions is also useful in the debugger 
without having to turn to the pretty-printers.

I don't see how adding printf helpers for debug builds negatively affects 
debugger purists, but I do see how it helps at least a handful of prolific 
contributors to the project be more productive.

Thanks,
~Brady



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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 19, 2012, at 2:46 PM, Antti Koivisto akoivi...@gmail.com wrote:

 Maciej Stachowiak m...@apple.com kirjoitti 20.7.2012 kello 0.27:
 
 
 In principle, we could also have this support multiple arguments, so you 
 could write:
 
 debug(frame: , someFrame,  node: , someNode,  string, someString);
 
 I think this is the way to go for the easy syntax. A format string version 
 should also be available.

I'm totally on board with this, too.

~Brady

 
 
  antti
 
 
 This would be no more verbose than the  style, but could compile to a 
 single function call at the call site and therefore could be relatively 
 compact. I would find this easier to deal with than a unary function or a 
 printf-style format string. The way you'd do this is by defining template 
 functions which call a unary overloaded function for each argument:
 
 templatetypename A, typename B debug(A a, B b)
 {
   debug(a);
   debug(b);
 }
 
 templatetypename A, typename B, typename C debug(A a, B b, C c)
 {
   debug(a);
   debug(b);
   debug(c);
 }
 
 templatetypename A, typename B, typename C, typename D debug(A a, B b, C 
 c, D d)
 {
   debug(a);
   debug(b);
   debug(c);
   debug(d);
 }
 
 ... and so on up to some reasonable number of arguments.
 
 Regards,
 Maciej
 
 
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 19, 2012, at 3:09 PM, Filip Pizlo fpi...@apple.com wrote:

 On Jul 19, 2012, at 2:58 PM, Balazs Kelemen kbal...@webkit.org wrote:
 
 But neither these compile to a single function call. Or we could define 
 simple inline debug() overrides but we could also do that with the stream 
 operator. And anyway, if the actual calls are not supposed to land than it 
 doesn't matter how compact it is. For me the stream operator is a bit nicer.
 
 This goal of not landing the actual calls is nice in theory, but we quickly 
 found in JSC that it's impractical.  We did this for a while: each time 
 someone needed to debug something, they'd add some printf's, find the bug, 
 delete the printf's, land the change.  Then the next person to debug the code 
 would add in the same printf's, find another bug, delete those printf's 
 again, and land the change.  Rinse and repeat.  This got horrible very 
 quickly.

There's also been an ebb and flow of this with LOG() in WebCore and WebKit 
over the years.  Currently we're in a long ebb...

I used to be a proponent of checking in sensible LOG statements that multiple 
people could benefit from, but the syntax of having only printf() style 
formatters quickly make many potentially useful statements unwieldily.

This new proposal has the potential to clean up old LOG's and more easily 
introduce new ones going forward.

 In summary, I'm not arguing against having a nicer debug API than the current 
 dataLog(); I'm arguing quite the opposite: that we should investigate such an 
 API, and that the API should be robust enough that we land not just the API 
 but also allow for the landing of dump() methods for classes that webkittens 
 find themselves having to frequently add printf-style debugging to.

I wasn't originally considering the outcome of this thread to be a new log() 
pattern that we could actually land in code.  But seeing the form of Maciej's 
proposal has me tacitly excited.

~Brady

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote:

 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
 
 On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org 
 wrote:
 
 Hi,
 
 For those who secretly use printf debugging :). I know the
 recommended way is to use a debugger and it's not the point of this
 discussion.
 
 A lot of us do this, and sometimes it's necessary.  I agree with the gripe 
 and support adding something easier.
 
 So I propose wtf() and its stream operator.
 
 Usage :
 
 wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322
 
 There is no reason to bring in stream operators - that are willfully absent 
 from WebCore - just for debugging.
 
 
 But it's really nice for that purpose, and somehow match std::cout

And we quite purposefully don't use std::cout in the project.

 Overloading functions works just as well.
 
 I'm not sure to understand what you mean here…

I mean relying on C++'s overloading of functions for the different types you'd 
like to printf debug.

void debug(WebCore::String);
void debug(WebCore::Frame*);
void debug(WebCore::Node*);

etc etc etc.

debug(someFrame);
debug(someNode);
debug(someString);

Especially that last one would help me from remembering how to type 
printf(%s, someString.utf8().data()) which is all I've ever really wanted.

~Brady

 
 
 ~Brady
 
 
 
 -- 
 Alexis Menard (darktears)
 Software Engineer
 openBossa @ INdT - Instituto Nokia de Tecnologia

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote:

 Hi,
 
 For those who secretly use printf debugging :). I know the
 recommended way is to use a debugger and it's not the point of this
 discussion.

A lot of us do this, and sometimes it's necessary.  I agree with the gripe and 
support adding something easier.

 So I propose wtf() and its stream operator.
 
 Usage :
 
 wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322

There is no reason to bring in stream operators - that are willfully absent 
from WebCore - just for debugging.

Overloading functions works just as well.

~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Time out issue (30s) of WebKit layout test [Mac OS]

[Brady Eidson]

On Jun 28, 2012, at 11:57 PM, Horky Chen ho...@sina.com wrote:

 Hi,
 
 On Mac OS, if one time-out larger than 30s would be used, --time-out-ms 
 cannot work well.
 
 According to the run-webkit-tests script, custom Time-Out can be assigned for 
 each test case. But, unfortunately, below line in LayoutTestControllerMac.mm 
 blocked the setting if it is larger than 30s (waitUntilDone  notifyDone are 
 used):
 static const CFTimeInterval waitToDumpWatchdogInterval = 30.0;
 
 That is hard code, and no parameter can be accepted to adjust it. There are 
 two time-out settings for one test case, is it possible to use common 
 time-out setting? 
 
 Would you please help to double check about it? 

Historically there has been absolutely no excuse to *expect* a single test take 
longer than 30 seconds.

Such a test needs to be redesigned or broken up in to smaller tests.

Thanks,
~Brady

 
 Best Regards!
 Horky
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] New Feature Flag Proposal: TIME_INPUT_FIELDS

[Brady Eidson]

Are there bugs tracking this work yet?

Thanks,
~Brady

On Jun 26, 2012, at 8:47 PM, Yoshifumi Inoue yo...@google.com wrote:

 Hi WebKit!
 
 I would like to notify adding new feature flag ENABLE_TIME_INPUT_FIELDS.
 
 This flag will enable multiple fields input UI for input type time.
 
 Looking is as same as input type number (including spin button), but each 
 time component, hour, minute, second, millisecond, period(AM/PM), is fixed 
 and handles keyboard input as overwriting rather than inserting, like Mac 
 OSX's DateTime control.
 
 This feature will be enable for desktop version of Chrome (== excluding 
 Android).
 
 This flag also introduce following class and functions:
 * DateTimeFormat class
 * localizedDecimalSeparator()
 * localizedTimeFormat()
 * localizedShortTimeFormat()
 * DateTimeFIeldElement (for shadow DOM)
 * DateTimeEditElement (for shadow DOM)
 
 Thanks!
 -yosi
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] PageCache and modularization (was Re: The Care and Feeding of WebCore Modules)

[Brady Eidson]

On Mar 2, 2012, at 3:10 PM, Adam Barth aba...@webkit.org wrote:

 2012/3/2 Alexey Proskuryakov a...@webkit.org:
 It seems that we have some agreement on what to modularize, but not 
 necessarily agreement on what the modularization should encompass.
 
 For example, I think that https://bugs.webkit.org/show_bug.cgi?id=80193 
 that moves some knowledge of what makes a page uncacheable out of 
 PageCache::canCachePageContainingThisFrame makes the code less hackable, and 
 is likely to become a disadvantage.
 
 I've just started investigating that issue (which is why the patch is
 labeled work-in-progress).  Is there a reason SQLDatabase is special
 cased in PageCache?  Most features interact with the PageCache via
 ActiveDOMObject::canSuspend().  In that bug, I'm investigating why
 SQLDatabase doesn't just use the same general mechanism as other
 features.

There's no great mystery.  SQLDatabase was added before we had the 
ActiveDOMObject mechanism.

Thanks,
~Brady

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

[webkit-dev] Source/ThirdParty/ChangeLog? Really???

[Brady Eidson]

Bad form!  X0,000 announcements have historically always been in 
WebCore/ChangeLog.

A sad and unfortunate break in tradition just to avoid resolving the conflict 
to land.  :(

But seriously WebKit, congrats!

~Brady

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