[webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

2015-07-06 Thread Yusuke SUZUKI
Hi WebKittens,

I've landed the update of the ES6 Promise implementation.
Through this work, I've experimentally added the internal private function,
@enqueueJob(JS function, JS array for arguments).
This is corresponding to the ES6 spec EnqueueJob[1].

This EnqueueJob handler is now tightly integrated with WebCore's microtask
infrastructure. So in JSC framework side, we cannot use this function.
As a result, current JSC framework disables Promise because there's no
event loop abstraction.

So I propose the API configuring euqueueJob handler into JSC VM (That
corresponds to the Realm in ECMA spec).

Like,

void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef,
JSEnqueueJobCallback, void* callbackData);

What do you think about this?

[1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob

Best Regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Support registerProtocolHandler in WebKit2

2015-07-06 Thread 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] JSC framework API proposal: setting a handler for enqueuing tasks

2015-07-06 Thread Geoffrey Garen
I’m suggesting a default runloop for non-web content.

I haven’t read through the details of integrating with the web content 
definition of micro task.

Geoff

 On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 Should JS be defining an event loop abstraction that WebCore then uses? That 
 would be weird, because the required behavior of the even loop in web content 
 is chock full of issues that are not at all related to JavaScript. JSC 
 doesn't even know enough to run microtasks at all the right times (from 
 reading the spec it seems that way, at least) for the Web case. Or are you 
 saying it would have a fallback runloop for non-Web contents?
 
 Regards,
 Maciej
 
 On Jul 6, 2015, at 3:24 PM, Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 
 I think it would be better for JavaScriptCore to handle micro tasks natively.
 
 It’s not so great for each client to need to reinvent the microtask runloop 
 abstraction.
 
 Geoff
 
 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com 
 mailto:utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private function, 
 @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no 
 event loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 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


Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

2015-07-06 Thread Maciej Stachowiak

Should JS be defining an event loop abstraction that WebCore then uses? That 
would be weird, because the required behavior of the even loop in web content 
is chock full of issues that are not at all related to JavaScript. JSC doesn't 
even know enough to run microtasks at all the right times (from reading the 
spec it seems that way, at least) for the Web case. Or are you saying it would 
have a fallback runloop for non-Web contents?

Regards,
Maciej

 On Jul 6, 2015, at 3:24 PM, Geoffrey Garen gga...@apple.com wrote:
 
 I think it would be better for JavaScriptCore to handle micro tasks natively.
 
 It’s not so great for each client to need to reinvent the microtask runloop 
 abstraction.
 
 Geoff
 
 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com 
 mailto:utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private function, 
 @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no event 
 loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] JSC framework API proposal: setting a handler for enqueuing tasks

2015-07-06 Thread Geoffrey Garen
I think it would be better for JavaScriptCore to handle micro tasks natively.

It’s not so great for each client to need to reinvent the microtask runloop 
abstraction.

Geoff

 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private function, 
 @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no event 
 loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 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 registerProtocolHandler in WebKit2

2015-07-06 Thread Gyuyoung Kim
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.

If so, custom protocol handler feature is different with role of
registerProtocolHandler. Thank you for your explanation about it.


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:

For more detailed scenario in addition to Brady's explanation, I consider
below call sequence to use registerProtocolHandler.

 1. Custom scheme is registered by registeredProtocolHandler() in JS
 2. The registered scheme will be filtering in WebCore. (If unsupported
scheme is requested, security error happens.)
 3. Filtered scheme will be passed to application side (of course, which is
web browser or similar things)
 4. The application will register passed custom scheme and a callback to
call the native embedding application to WK2's network
 using custom protocol handler feature, which was implemented in
WebKit2.

Thus, in my humble opinion, registerProtocolHandler will use the custom
protocol instead of complicating it.


Gyuyoung.

On Tue, Jul 7, 2015 at 1:56 AM, Brady Eidson beid...@apple.com wrote:


 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
 wrote:

 On Mon, Jun 8, 2015 at 9:39 AM, Darin Adler 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
 wrote:

 On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro 
 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] maximalOutlineSize inflate all RenderLayers

2015-07-06 Thread Simon Fraser
This is a well-known issue. Ideally outline size would be factored into visual 
overflow, but that’s a bit tricky because outline is weird and crosses between 
RenderObjects.

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


 On Jul 6, 2015, at 9:26 PM, Kim, NamHoon na...@ea.com wrote:
 
 Hi experts,
  
 While hacking composited layer in WebKit, I realized CSS outline style 
 inflate size of all RenderLayers. Since WebKit has default css of 5px outline 
 for focused element, focusing input in the below sample inflate the cyan box. 
 This can reproduced in WK2 OSX port in r186227.
  
 style
 .box {
   position: fixed;
   top: 50px;
   width: 100px;
   height: 30px;
   border-radius: 10%;
   background-color: cyan;
 }
 /style
  
 input type='text'
 div class='box'/div
  
 Through investigation, I found `RenderView::m_maximalOutlineSize` value is 
 set in the RenderElement::setStyle() function. And this cause inflation of 
 layers in RenderLayer::localBoundingBox() function. Since setter of 
 `m_maximalOutlineSize` scheduled rebuild of the whole composited layers, all 
 layers inflated by the value.
  
 Honestly, I don’t know about this value’s purpose. But it seems weird to me 
 that this value does not cleared in the RenderView even after outline style 
 cleared. (i.e. loose focus of the input)
  
 And this behavior makes several problem in our ports, [EAWebKit][1]. Since we 
 uses composited layers backed by DirectX, this makes paint call requests 
 larger size than texture itself in TextureMapperTile::paint() function. This 
 cause rendering of corrupted memory. Steps follow,
  
 a. layer inflated by maximalOutlineSize. Let 100x100 layer increased to 
 110x110.
 b. texture increased in the 
 TextureMapperTiledBackingStore::createOrDestroyTilesIfNeeded() to 110x110.
 c. layer’s texture destroyed then reconstructed by display style change.
 d. while reconstruct of the layer’s texture, this time texture created with 
 the size of 100x100 instead of 110x110.
 e. then painting this texture in TextureMapperTile::paint() request 110x110 
 rect for 100x100 texture.

This sounds like a bug in your port.

 While step d. GraphicsLayerTextureMapper::m_needsDisplayRect intersected with 
 TextureMapperTile::m_rect, makes texture smaller then layer’s size. On the 
 other hand, TextureMapperTile::paint() call in the step e. request whole 
 TextureMapperTile::m_rect for draw request.
  
 To escape this problem, I overridden default style of :focus to `outline: 
 none`. I wonder better solution for this. Is it some bug of WebKit? Is there 
 some proper way to handle this? If inflation of the layers inevitable, it 
 seems reasonable shrunken back after outline style cleared.

Simon


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


[webkit-dev] maximalOutlineSize inflate all RenderLayers

2015-07-06 Thread Kim, NamHoon
Hi experts,

While hacking composited layer in WebKit, I realized CSS outline style inflate 
size of all RenderLayers. Since WebKit has default css of 5px outline for 
focused element, focusing input in the below sample inflate the cyan box. This 
can reproduced in WK2 OSX port in r186227.

style
.box {
  position: fixed;
  top: 50px;
  width: 100px;
  height: 30px;
  border-radius: 10%;
  background-color: cyan;
}
/style

input type='text'
div class='box'/div

Through investigation, I found `RenderView::m_maximalOutlineSize` value is set 
in the RenderElement::setStyle() function. And this cause inflation of layers 
in RenderLayer::localBoundingBox() function. Since setter of 
`m_maximalOutlineSize` scheduled rebuild of the whole composited layers, all 
layers inflated by the value.

Honestly, I don't know about this value's purpose. But it seems weird to me 
that this value does not cleared in the RenderView even after outline style 
cleared. (i.e. loose focus of the input)

And this behavior makes several problem in our ports, [EAWebKit][1]. Since we 
uses composited layers backed by DirectX, this makes paint call requests larger 
size than texture itself in TextureMapperTile::paint() function. This cause 
rendering of corrupted memory. Steps follow,

a. layer inflated by maximalOutlineSize. Let 100x100 layer increased to 110x110.
b. texture increased in the 
TextureMapperTiledBackingStore::createOrDestroyTilesIfNeeded() to 110x110.
c. layer's texture destroyed then reconstructed by display style change.
d. while reconstruct of the layer's texture, this time texture created with the 
size of 100x100 instead of 110x110.
e. then painting this texture in TextureMapperTile::paint() request 110x110 
rect for 100x100 texture.

While step d. GraphicsLayerTextureMapper::m_needsDisplayRect intersected with 
TextureMapperTile::m_rect, makes texture smaller then layer's size. On the 
other hand, TextureMapperTile::paint() call in the step e. request whole 
TextureMapperTile::m_rect for draw request.

To escape this problem, I overridden default style of :focus to `outline: 
none`. I wonder better solution for this. Is it some bug of WebKit? Is there 
some proper way to handle this? If inflation of the layers inevitable, it seems 
reasonable shrunken back after outline style cleared.

Regards,
Namhoon

[1]: http://gpl.ea.com/eawebkit.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev