Re: [webkit-dev] maximalOutlineSize inflate all RenderLayers

[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 



> On Jul 6, 2015, at 9:26 PM, Kim, NamHoon  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.
>  
> 
> .box {
>   position: fixed;
>   top: 50px;
>   width: 100px;
>   height: 30px;
>   border-radius: 10%;
>   background-color: cyan;
> }
> 
>  
> 
> 
>  
> 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

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


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





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

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

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

>
> On Jul 1, 2015, at 7:42 PM, Gyuyoung Kim  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  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 
> wrote:
>
>> On Mon, Jun 8, 2015 at 9:39 AM, Darin Adler  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 
>> 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] JSC framework API proposal: setting a handler for enqueuing tasks

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

___
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

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

___
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

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

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

[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

[Brady Eidson]

> On Jul 1, 2015, at 7:42 PM, Gyuyoung Kim  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  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  > wrote:
> On Mon, Jun 8, 2015 at 9:39 AM, Darin Adler  > 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  > wrote:
> On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro  > 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