Re: [webkit-dev] Question related to license in WK2 EFL port

[Darin Adler]

There’s some specific policy about this that’s displayed in bugs.webkit.org 
when you attach a patch for review:

> Hello and thank you for contributing a patch. Here is our licensing policy 
> and terms for contributing code to the WebKit project.
> 
>   • If you are sending in a patch to existing WebKit code, you agree by 
> clicking below that your changes are licensed under the existing license 
> terms of the file you are modifying (i.e., BSD license or GNU Lesser General 
> Public License v.2.1, LGPL v. 2.1). Please also add your copyright (name and 
> year) to the relevant files for changes that are more than 10 lines of code.
>   • If you are sending in a new file for inclusion in WebKit (no code 
> copied from another source), the preferred license is BSD, but LGPL 2.1 is an 
> option as well. Please include your copyright (name and year) and license 
> preference (BSD or LGPL 2.1). By clicking below you agree that your file is 
> licensed under either the BSD license or LGPL 2.1, as indicated in your file.
>   • If you aren't the author of the patch, you agree to include the 
> original copyright notices and licensing terms with it, to the extent that 
> they exist. If there wasn't a copyright notice or license, please make a note 
> of it. Generally we can only take in patches that are BSD- or LGPL-licensed 
> in order to maintain license compatibility within the project.

Note that it’s specifically LGPL 2.1. Other versions of LGPL are likely to be 
unacceptable.

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Dirk Schulze]

On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:

> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
>> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>> interfaces.  However, the situation there is a bit different.
>>> Although SVGSVGElement implements SVGLocatable, there aren't any
>>> interfaces with methods that return SVGLocatable, which means we don't
>>> need to implement toJS(SVGLocatable*).
>> 
>> SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
>> behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED 
>> soon.
> 
> Do you anticipate adding properties or functions that return
> interfaces like SVGLocatable?
Here is a Wiki what we plan to do: 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization

It might not reflect all changes that we discussed during the SVG WG meeting 
today.

Greetings,
Dirk

> 
> Adam
> 
> 
>>> He also points out that Node inherits from EventTarget, which already
>>> contains a virtual interfaceName() function similar to that used by
>>> Event.  That pushes us further towards using a common DOMInterface
>>> base class because introducing Region::interfaceName would mean that
>>> Element would see both EventTarget::interfaceName and
>>> Region::interfaceName.
>>> 
>>> Adam
>>> 
>>> 
>>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
 The CSS Regions specification [1] defines a CSSOM interface named
 Region, which can be mixed into interfaces for other objets that can
 be CSS regions.  That means that Region introduces a form of multiple
 inheritance into the DOM.  For example, Element implements Region but
 Node does not implement Region.
 
 There's a patch up for review that implements Region using C++
 multiple inheritance [2]:
 
 - class Element : public ContainerNode {
 + class Element : public ContainerNode, public CSSRegion {
 
 One difficulty in implementing this feature how to determine the
 correct JavaScript wrapper return for a given Region object.
 Specifically, toJS(Region*) needs to return a JavaScript wrapper for
 an Element if the Region pointer actually points to an Element
 instance.
 
 We've faced a similar problem elsewhere in the DOM when implementing
 normal single inheritance.  For example, there are many subclass of
 Event and toJS(Event*) needs to return a wrapper for the appropriate
 subtype.  To solve the same problem, CSSRule has a m_type member
 variable and a bevy of isFoo() functions [3].
 
 A) Should we push back on the folks writing the CSS Regions
 specification to avoid using multiple inheritance?  As far as I know,
 this is the only instance of multiple inheritance in the platform.
 Historically, EventTarget used multiple inheritance, but that's been
 fixed in DOM4 [4].
 
 B) If CSS Regions continues to require multiple inheritance, should we
 build another one-off RTTI replacement to implement toJS(Region*), or
 should we improve our bindings to implement this aspect of WebIDL more
 completely?
 
 One approach to implementing toJS in a systematic way is to introduce
 a base class DOMInterface along these lines:
 
 class DOMInterface {
 public:
   virtual const AtomicString& primaryInterfaceName() = 0;
 }
 
 That returns the name of the primary interface (i.e., as defined by
 WebIDL [5]).  When implementing toJS, we'd then call
 primaryInterfaceName to determine which kind of wrapper to use.
 
 One downside of this approach is that it introduces a near-universal
 base class along the lines of IUnknown [6] or nsISupports [7].  I
 don't think any of us want WebKit to grow an implementation of
 XPCOM...
 
 I welcome any thoughts you have on this topic.
 
 Thanks,
 Adam
 
 [1] http://dev.w3.org/csswg/css3-regions/
 [2] https://bugs.webkit.org/show_bug.cgi?id=91076
 [3] 
 http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
 [4] http://www.w3.org/TR/dom/#node
 [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
 [6] 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
 [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>>> ___
>>> 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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

From:  Adam Barth 
Date:  Wednesday, July 25, 2012 6:05 PM
To:  Sam Weinig 
Cc:  Elliott Sprehn , Alan Stearns
, Kentaro Hara ,
"webkit-dev@lists.webkit.org" 
Subject:  Re: [webkit-dev] Multiple inheritance in the DOM

On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig  wrote:

On Jul 25, 2012, at 5:53 PM, Elliott Sprehn  wrote:

>>>It seems like this should really be a [NoInterfaceObject].
>>>That resolves the issue of multiple inheritance since you
>>>can no longer do instanceof Region, and I'm not sure why
>>>you'd ever want to do that anyway.

>>I agree.

>That doesn't solve the problem.

But it's a good idea. I'll add it to the spec.

Thanks,

Alan

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/25/12 6:12 PM, "Sam Weinig"  wrote:

>
>On Jul 25, 2012, at 5:37 PM, Sam Weinig  wrote:
>
>> 
>> On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
>> 
>>> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
>>> 
 A) Should we push back on the folks writing the CSS Regions
 specification to avoid using multiple inheritance?  As far as I
>>> know,
 this is the only instance of multiple inheritance in the platform.
 Historically, EventTarget used multiple inheritance, but that's
been
 fixed in DOM4 [4].
 
 If it is possible to avoid the multiple inheritance, that would be
best.
>>> 
>>> From the WebIDL side, it's not strictly multiple inheritance. It's
>>>merely
>>> a supplemental interface that more than one object can implement. None
>>>of
>>> the members of the Region interface can clash with any of the members
>>>of
>>> the object that implements it.
>>> 
>>> Right now Elements can become CSS Regions, but in the future other
>>>objects
>>> will be able to become CSS Regions. As far as I know, the correct way
>>>to
>>> specify this kind of relation is with WebIDL supplemental interfaces.
>>>I'd
>>> rather figure out the correct way to add this WebIDL functionality to
>>> WebKit now, than put something else into the spec and WebKit that we'll
>>> have to change later.
>>> 
>>> Thanks,
>>> 
>>> Alan
>> 
>> What other objects do you envision implementing CSSRegion?  With the
>>spec written the way it is now, I see no reason to make anything
>>virtual, or even have a Region class.  Just implement it in Element.  If
>>need to pull things out for code reuse purposes, we can do that when it
>>comes to that, but right now, there doesn't seem to be a need to
>>complicate things.
>> 
>> -Sam
>
>So, what I said isn't quite right, as I understand you actually can get a
>Region object (via getRegions()).  But, the point of not needing to solve
>the issue right now remains true (though thin).

No, you'll never actually get a Region object. What you get is a
sequence whose members will all be Elements or some other object
that implements the Region interface.

>
>That said, adding this type of multiple inheritance to the platform seems
>undesirable, and I think the standards body should work harder to come up
>with a solution that does not require it.
>
>-Sam
>
>


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

Re: [webkit-dev] Multiple inheritance in the DOM

[Hajime Morrita]

If the only problem is to determine the type of JS wrappers, is it possible
to
make wrapSlow() a virtual method of some base class, instead of static
functions?

It need a tweak on the code generator. Also, it might need to avoid name
conflicts
by suffixing like wrapSlowForNode(), wrapSlowForRegion() etc.

This approach would make wrapSlow() a variation of QueryInterface(). But
considering that the functionality is limited and hard to abuse, it might
be better than having DOMInterface.



On Thu, Jul 26, 2012 at 9:53 AM, Alan Stearns  wrote:

> On 7/25/12 5:37 PM, "Sam Weinig"  wrote:
>
> >
> >On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
> >
> >> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
> >>
> >>> A) Should we push back on the folks writing the CSS Regions
> >>> specification to avoid using multiple inheritance?  As far as I
> >> know,
> >>> this is the only instance of multiple inheritance in the platform.
> >>> Historically, EventTarget used multiple inheritance, but that's
> >>>been
> >>> fixed in DOM4 [4].
> >>>
> >>> If it is possible to avoid the multiple inheritance, that would be
> >>>best.
> >>
> >> From the WebIDL side, it's not strictly multiple inheritance. It's
> >>merely
> >> a supplemental interface that more than one object can implement. None
> >>of
> >> the members of the Region interface can clash with any of the members of
> >> the object that implements it.
> >>
> >> Right now Elements can become CSS Regions, but in the future other
> >>objects
> >> will be able to become CSS Regions. As far as I know, the correct way to
> >> specify this kind of relation is with WebIDL supplemental interfaces.
> >>I'd
> >> rather figure out the correct way to add this WebIDL functionality to
> >> WebKit now, than put something else into the spec and WebKit that we'll
> >> have to change later.
> >>
> >> Thanks,
> >>
> >> Alan
> >
> >What other objects do you envision implementing CSSRegion?  With the spec
> >written the way it is now, I see no reason to make anything virtual, or
> >even have a Region class.  Just implement it in Element.  If need to pull
> >things out for code reuse purposes, we can do that when it comes to that,
> >but right now, there doesn't seem to be a need to complicate things.
> >
> >-Sam
> >
>
> I have an upcoming proposal for a CSSPseudoElement object. You can make a
> pseudo-element like ::before or ::after into a CSS Region right now in
> WebKit. All that's lacking is a way to access those pseudo-elements from
> script.
>
> Thanks,
>
> Alan
>
> ___
> 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] Multiple inheritance in the DOM

[Adam Barth]

On Wed, Jul 25, 2012 at 6:00 PM, Sam Weinig  wrote:

>
> On Jul 25, 2012, at 5:53 PM, Elliott Sprehn  wrote:
>
>
> On Wed, Jul 25, 2012 at 5:13 PM, Alan Stearns  wrote:
>
>> ...
>>
>> From the WebIDL side, it's not strictly multiple inheritance. It's merely
>> a supplemental interface that more than one object can implement. None of
>> the members of the Region interface can clash with any of the members of
>> the object that implements it.
>>
>> Right now Elements can become CSS Regions, but in the future other objects
>> will be able to become CSS Regions. As far as I know, the correct way to
>> specify this kind of relation is with WebIDL supplemental interfaces. I'd
>> rather figure out the correct way to add this WebIDL functionality to
>> WebKit now, than put something else into the spec and WebKit that we'll
>> have to change later.
>>
>>
> It seems like this should really be a [NoInterfaceObject]. That resolves
> the issue of multiple inheritance since you can no longer do instanceof
> Region, and I'm not sure why you'd ever want to do that anyway.
>
>
> I agree.
>

That doesn't solve the problem.  The problem arises from determining what
kind of wrapper to create for an WebCore::Region object (e.g., an Element
wrapper or a CSSPseudoElement wrapper).  It's easy for us to create the
proper constellation of prototype objects.

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/25/12 5:37 PM, "Sam Weinig"  wrote:

>
>On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
>
>> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
>> 
>>> A) Should we push back on the folks writing the CSS Regions
>>> specification to avoid using multiple inheritance?  As far as I
>> know,
>>> this is the only instance of multiple inheritance in the platform.
>>> Historically, EventTarget used multiple inheritance, but that's
>>>been
>>> fixed in DOM4 [4].
>>> 
>>> If it is possible to avoid the multiple inheritance, that would be
>>>best.
>> 
>> From the WebIDL side, it's not strictly multiple inheritance. It's
>>merely
>> a supplemental interface that more than one object can implement. None
>>of
>> the members of the Region interface can clash with any of the members of
>> the object that implements it.
>> 
>> Right now Elements can become CSS Regions, but in the future other
>>objects
>> will be able to become CSS Regions. As far as I know, the correct way to
>> specify this kind of relation is with WebIDL supplemental interfaces.
>>I'd
>> rather figure out the correct way to add this WebIDL functionality to
>> WebKit now, than put something else into the spec and WebKit that we'll
>> have to change later.
>> 
>> Thanks,
>> 
>> Alan
>
>What other objects do you envision implementing CSSRegion?  With the spec
>written the way it is now, I see no reason to make anything virtual, or
>even have a Region class.  Just implement it in Element.  If need to pull
>things out for code reuse purposes, we can do that when it comes to that,
>but right now, there doesn't seem to be a need to complicate things.
>
>-Sam
>

I have an upcoming proposal for a CSSPseudoElement object. You can make a
pseudo-element like ::before or ::after into a CSS Region right now in
WebKit. All that's lacking is a way to access those pseudo-elements from
script.

Thanks,

Alan

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Alan Stearns]

On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:

 > A) Should we push back on the folks writing the CSS Regions
 > specification to avoid using multiple inheritance?  As far as I
know,
 > this is the only instance of multiple inheritance in the platform.
 > Historically, EventTarget used multiple inheritance, but that's been
 > fixed in DOM4 [4].
>
>If it is possible to avoid the multiple inheritance, that would be best.

>From the WebIDL side, it's not strictly multiple inheritance. It's merely
a supplemental interface that more than one object can implement. None of
the members of the Region interface can clash with any of the members of
the object that implements it.

Right now Elements can become CSS Regions, but in the future other objects
will be able to become CSS Regions. As far as I know, the correct way to
specify this kind of relation is with WebIDL supplemental interfaces. I'd
rather figure out the correct way to add this WebIDL functionality to
WebKit now, than put something else into the spec and WebKit that we'll
have to change later.

Thanks,

Alan

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Kentaro Hara]

>>> > A) Should we push back on the folks writing the CSS Regions
>>> > specification to avoid using multiple inheritance?  As far as I know,
>>> > this is the only instance of multiple inheritance in the platform.
>>> > Historically, EventTarget used multiple inheritance, but that's been
>>> > fixed in DOM4 [4].

If it is possible to avoid the multiple inheritance, that would be best.

>>> > - class Element : public ContainerNode {
>>> > + class Element : public ContainerNode, public CSSRegion {

Another concern is that if CSSRegion has any virtual method, this will
increase sizeof(Element) by 8 byte in a 64 bit architecture. A virtual
method table pointer is needed for each parent class of multiple
inheritance. (c.f. https://bugs.webkit.org/show_bug.cgi?id=88528)


>>> > B) If CSS Regions continues to require multiple inheritance, should we
>>> > build another one-off RTTI replacement to implement toJS(Region*), or
>>> > should we improve our bindings to implement this aspect of WebIDL more
>>> > completely?

If CSSRegions does require multiple inheritance, I think
DOMInterface::interfaceName() sounds reasonable as Adam pointed out.



On Thu, Jul 26, 2012 at 6:54 AM, Adam Barth  wrote:
> According to WebIDL, every platform object has a "primary" interface,
> as defined by .
> As long as that's the case, DOMInterface::interfaceName() should be
> sufficient to figure out which JavaScript wrapper to use.
>
> Adam
>
>
> On Wed, Jul 25, 2012 at 2:44 PM, Darin Fisher  wrote:
>> At least DOMInterface::interfaceName() is no where near as bad as COM's
>> QueryInterface.
>>
>> Provided we don't end up with any diamond inheritance hierarchies, we
>> shouldn't need
>> something as complicated as QueryInterface.
>>
>> -Darin
>>
>>
>>
>> On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth  wrote:
>>>
>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>> interfaces.  However, the situation there is a bit different.
>>> Although SVGSVGElement implements SVGLocatable, there aren't any
>>> interfaces with methods that return SVGLocatable, which means we don't
>>> need to implement toJS(SVGLocatable*).
>>>
>>> He also points out that Node inherits from EventTarget, which already
>>> contains a virtual interfaceName() function similar to that used by
>>> Event.  That pushes us further towards using a common DOMInterface
>>> base class because introducing Region::interfaceName would mean that
>>> Element would see both EventTarget::interfaceName and
>>> Region::interfaceName.
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>>> > The CSS Regions specification [1] defines a CSSOM interface named
>>> > Region, which can be mixed into interfaces for other objets that can
>>> > be CSS regions.  That means that Region introduces a form of multiple
>>> > inheritance into the DOM.  For example, Element implements Region but
>>> > Node does not implement Region.
>>> >
>>> > There's a patch up for review that implements Region using C++
>>> > multiple inheritance [2]:
>>> >
>>> > - class Element : public ContainerNode {
>>> > + class Element : public ContainerNode, public CSSRegion {
>>> >
>>> > One difficulty in implementing this feature how to determine the
>>> > correct JavaScript wrapper return for a given Region object.
>>> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>>> > an Element if the Region pointer actually points to an Element
>>> > instance.
>>> >
>>> > We've faced a similar problem elsewhere in the DOM when implementing
>>> > normal single inheritance.  For example, there are many subclass of
>>> > Event and toJS(Event*) needs to return a wrapper for the appropriate
>>> > subtype.  To solve the same problem, CSSRule has a m_type member
>>> > variable and a bevy of isFoo() functions [3].
>>> >
>>> > A) Should we push back on the folks writing the CSS Regions
>>> > specification to avoid using multiple inheritance?  As far as I know,
>>> > this is the only instance of multiple inheritance in the platform.
>>> > Historically, EventTarget used multiple inheritance, but that's been
>>> > fixed in DOM4 [4].
>>> >
>>> > B) If CSS Regions continues to require multiple inheritance, should we
>>> > build another one-off RTTI replacement to implement toJS(Region*), or
>>> > should we improve our bindings to implement this aspect of WebIDL more
>>> > completely?
>>> >
>>> > One approach to implementing toJS in a systematic way is to introduce
>>> > a base class DOMInterface along these lines:
>>> >
>>> > class DOMInterface {
>>> > public:
>>> > virtual const AtomicString& primaryInterfaceName() = 0;
>>> > }
>>> >
>>> > That returns the name of the primary interface (i.e., as defined by
>>> > WebIDL [5]).  When implementing toJS, we'd then call
>>> > primaryInterfaceName to determine which kind of wrapper to use.
>>> >
>>> > One downside of this approach is that it introduces a near-universal
>>> > base cla

Re: [webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>> interfaces.  However, the situation there is a bit different.
>> Although SVGSVGElement implements SVGLocatable, there aren't any
>> interfaces with methods that return SVGLocatable, which means we don't
>> need to implement toJS(SVGLocatable*).
>
> SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. 
> Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.

Do you anticipate adding properties or functions that return
interfaces like SVGLocatable?

Adam


>> He also points out that Node inherits from EventTarget, which already
>> contains a virtual interfaceName() function similar to that used by
>> Event.  That pushes us further towards using a common DOMInterface
>> base class because introducing Region::interfaceName would mean that
>> Element would see both EventTarget::interfaceName and
>> Region::interfaceName.
>>
>> Adam
>>
>>
>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>>> The CSS Regions specification [1] defines a CSSOM interface named
>>> Region, which can be mixed into interfaces for other objets that can
>>> be CSS regions.  That means that Region introduces a form of multiple
>>> inheritance into the DOM.  For example, Element implements Region but
>>> Node does not implement Region.
>>>
>>> There's a patch up for review that implements Region using C++
>>> multiple inheritance [2]:
>>>
>>> - class Element : public ContainerNode {
>>> + class Element : public ContainerNode, public CSSRegion {
>>>
>>> One difficulty in implementing this feature how to determine the
>>> correct JavaScript wrapper return for a given Region object.
>>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>>> an Element if the Region pointer actually points to an Element
>>> instance.
>>>
>>> We've faced a similar problem elsewhere in the DOM when implementing
>>> normal single inheritance.  For example, there are many subclass of
>>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>>> subtype.  To solve the same problem, CSSRule has a m_type member
>>> variable and a bevy of isFoo() functions [3].
>>>
>>> A) Should we push back on the folks writing the CSS Regions
>>> specification to avoid using multiple inheritance?  As far as I know,
>>> this is the only instance of multiple inheritance in the platform.
>>> Historically, EventTarget used multiple inheritance, but that's been
>>> fixed in DOM4 [4].
>>>
>>> B) If CSS Regions continues to require multiple inheritance, should we
>>> build another one-off RTTI replacement to implement toJS(Region*), or
>>> should we improve our bindings to implement this aspect of WebIDL more
>>> completely?
>>>
>>> One approach to implementing toJS in a systematic way is to introduce
>>> a base class DOMInterface along these lines:
>>>
>>> class DOMInterface {
>>> public:
>>>virtual const AtomicString& primaryInterfaceName() = 0;
>>> }
>>>
>>> That returns the name of the primary interface (i.e., as defined by
>>> WebIDL [5]).  When implementing toJS, we'd then call
>>> primaryInterfaceName to determine which kind of wrapper to use.
>>>
>>> One downside of this approach is that it introduces a near-universal
>>> base class along the lines of IUnknown [6] or nsISupports [7].  I
>>> don't think any of us want WebKit to grow an implementation of
>>> XPCOM...
>>>
>>> I welcome any thoughts you have on this topic.
>>>
>>> Thanks,
>>> Adam
>>>
>>> [1] http://dev.w3.org/csswg/css3-regions/
>>> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>>> [3] 
>>> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>>> [4] http://www.w3.org/TR/dom/#node
>>> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>>> [6] 
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>>> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>> ___
>> 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] Multiple inheritance in the DOM

[Dirk Schulze]

On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:

> Eric Seidel points out that SVG uses multiple inheritance in its DOM
> interfaces.  However, the situation there is a bit different.
> Although SVGSVGElement implements SVGLocatable, there aren't any
> interfaces with methods that return SVGLocatable, which means we don't
> need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. 
Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.

Greetings,
Dirk

> 
> He also points out that Node inherits from EventTarget, which already
> contains a virtual interfaceName() function similar to that used by
> Event.  That pushes us further towards using a common DOMInterface
> base class because introducing Region::interfaceName would mean that
> Element would see both EventTarget::interfaceName and
> Region::interfaceName.
> 
> Adam
> 
> 
> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>> The CSS Regions specification [1] defines a CSSOM interface named
>> Region, which can be mixed into interfaces for other objets that can
>> be CSS regions.  That means that Region introduces a form of multiple
>> inheritance into the DOM.  For example, Element implements Region but
>> Node does not implement Region.
>> 
>> There's a patch up for review that implements Region using C++
>> multiple inheritance [2]:
>> 
>> - class Element : public ContainerNode {
>> + class Element : public ContainerNode, public CSSRegion {
>> 
>> One difficulty in implementing this feature how to determine the
>> correct JavaScript wrapper return for a given Region object.
>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>> an Element if the Region pointer actually points to an Element
>> instance.
>> 
>> We've faced a similar problem elsewhere in the DOM when implementing
>> normal single inheritance.  For example, there are many subclass of
>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>> subtype.  To solve the same problem, CSSRule has a m_type member
>> variable and a bevy of isFoo() functions [3].
>> 
>> A) Should we push back on the folks writing the CSS Regions
>> specification to avoid using multiple inheritance?  As far as I know,
>> this is the only instance of multiple inheritance in the platform.
>> Historically, EventTarget used multiple inheritance, but that's been
>> fixed in DOM4 [4].
>> 
>> B) If CSS Regions continues to require multiple inheritance, should we
>> build another one-off RTTI replacement to implement toJS(Region*), or
>> should we improve our bindings to implement this aspect of WebIDL more
>> completely?
>> 
>> One approach to implementing toJS in a systematic way is to introduce
>> a base class DOMInterface along these lines:
>> 
>> class DOMInterface {
>> public:
>>virtual const AtomicString& primaryInterfaceName() = 0;
>> }
>> 
>> That returns the name of the primary interface (i.e., as defined by
>> WebIDL [5]).  When implementing toJS, we'd then call
>> primaryInterfaceName to determine which kind of wrapper to use.
>> 
>> One downside of this approach is that it introduces a near-universal
>> base class along the lines of IUnknown [6] or nsISupports [7].  I
>> don't think any of us want WebKit to grow an implementation of
>> XPCOM...
>> 
>> I welcome any thoughts you have on this topic.
>> 
>> Thanks,
>> Adam
>> 
>> [1] http://dev.w3.org/csswg/css3-regions/
>> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>> [3] 
>> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>> [4] http://www.w3.org/TR/dom/#node
>> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>> [6] 
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
> ___
> 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] Multiple inheritance in the DOM

[Adam Barth]

According to WebIDL, every platform object has a "primary" interface,
as defined by .
As long as that's the case, DOMInterface::interfaceName() should be
sufficient to figure out which JavaScript wrapper to use.

Adam


On Wed, Jul 25, 2012 at 2:44 PM, Darin Fisher  wrote:
> At least DOMInterface::interfaceName() is no where near as bad as COM's
> QueryInterface.
>
> Provided we don't end up with any diamond inheritance hierarchies, we
> shouldn't need
> something as complicated as QueryInterface.
>
> -Darin
>
>
>
> On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth  wrote:
>>
>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>> interfaces.  However, the situation there is a bit different.
>> Although SVGSVGElement implements SVGLocatable, there aren't any
>> interfaces with methods that return SVGLocatable, which means we don't
>> need to implement toJS(SVGLocatable*).
>>
>> He also points out that Node inherits from EventTarget, which already
>> contains a virtual interfaceName() function similar to that used by
>> Event.  That pushes us further towards using a common DOMInterface
>> base class because introducing Region::interfaceName would mean that
>> Element would see both EventTarget::interfaceName and
>> Region::interfaceName.
>>
>> Adam
>>
>>
>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>> > The CSS Regions specification [1] defines a CSSOM interface named
>> > Region, which can be mixed into interfaces for other objets that can
>> > be CSS regions.  That means that Region introduces a form of multiple
>> > inheritance into the DOM.  For example, Element implements Region but
>> > Node does not implement Region.
>> >
>> > There's a patch up for review that implements Region using C++
>> > multiple inheritance [2]:
>> >
>> > - class Element : public ContainerNode {
>> > + class Element : public ContainerNode, public CSSRegion {
>> >
>> > One difficulty in implementing this feature how to determine the
>> > correct JavaScript wrapper return for a given Region object.
>> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>> > an Element if the Region pointer actually points to an Element
>> > instance.
>> >
>> > We've faced a similar problem elsewhere in the DOM when implementing
>> > normal single inheritance.  For example, there are many subclass of
>> > Event and toJS(Event*) needs to return a wrapper for the appropriate
>> > subtype.  To solve the same problem, CSSRule has a m_type member
>> > variable and a bevy of isFoo() functions [3].
>> >
>> > A) Should we push back on the folks writing the CSS Regions
>> > specification to avoid using multiple inheritance?  As far as I know,
>> > this is the only instance of multiple inheritance in the platform.
>> > Historically, EventTarget used multiple inheritance, but that's been
>> > fixed in DOM4 [4].
>> >
>> > B) If CSS Regions continues to require multiple inheritance, should we
>> > build another one-off RTTI replacement to implement toJS(Region*), or
>> > should we improve our bindings to implement this aspect of WebIDL more
>> > completely?
>> >
>> > One approach to implementing toJS in a systematic way is to introduce
>> > a base class DOMInterface along these lines:
>> >
>> > class DOMInterface {
>> > public:
>> > virtual const AtomicString& primaryInterfaceName() = 0;
>> > }
>> >
>> > That returns the name of the primary interface (i.e., as defined by
>> > WebIDL [5]).  When implementing toJS, we'd then call
>> > primaryInterfaceName to determine which kind of wrapper to use.
>> >
>> > One downside of this approach is that it introduces a near-universal
>> > base class along the lines of IUnknown [6] or nsISupports [7].  I
>> > don't think any of us want WebKit to grow an implementation of
>> > XPCOM...
>> >
>> > I welcome any thoughts you have on this topic.
>> >
>> > Thanks,
>> > Adam
>> >
>> > [1] http://dev.w3.org/csswg/css3-regions/
>> > [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>> > [3]
>> > http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>> > [4] http://www.w3.org/TR/dom/#node
>> > [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>> > [6]
>> > http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>> > [7]
>> > https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>> ___
>> 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] Multiple inheritance in the DOM

[Darin Fisher]

At least DOMInterface::interfaceName() is no where near as bad as COM's
QueryInterface.

Provided we don't end up with any diamond inheritance hierarchies, we
shouldn't need
something as complicated as QueryInterface.

-Darin



On Wed, Jul 25, 2012 at 2:33 PM, Adam Barth  wrote:

> Eric Seidel points out that SVG uses multiple inheritance in its DOM
> interfaces.  However, the situation there is a bit different.
> Although SVGSVGElement implements SVGLocatable, there aren't any
> interfaces with methods that return SVGLocatable, which means we don't
> need to implement toJS(SVGLocatable*).
>
> He also points out that Node inherits from EventTarget, which already
> contains a virtual interfaceName() function similar to that used by
> Event.  That pushes us further towards using a common DOMInterface
> base class because introducing Region::interfaceName would mean that
> Element would see both EventTarget::interfaceName and
> Region::interfaceName.
>
> Adam
>
>
> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
> > The CSS Regions specification [1] defines a CSSOM interface named
> > Region, which can be mixed into interfaces for other objets that can
> > be CSS regions.  That means that Region introduces a form of multiple
> > inheritance into the DOM.  For example, Element implements Region but
> > Node does not implement Region.
> >
> > There's a patch up for review that implements Region using C++
> > multiple inheritance [2]:
> >
> > - class Element : public ContainerNode {
> > + class Element : public ContainerNode, public CSSRegion {
> >
> > One difficulty in implementing this feature how to determine the
> > correct JavaScript wrapper return for a given Region object.
> > Specifically, toJS(Region*) needs to return a JavaScript wrapper for
> > an Element if the Region pointer actually points to an Element
> > instance.
> >
> > We've faced a similar problem elsewhere in the DOM when implementing
> > normal single inheritance.  For example, there are many subclass of
> > Event and toJS(Event*) needs to return a wrapper for the appropriate
> > subtype.  To solve the same problem, CSSRule has a m_type member
> > variable and a bevy of isFoo() functions [3].
> >
> > A) Should we push back on the folks writing the CSS Regions
> > specification to avoid using multiple inheritance?  As far as I know,
> > this is the only instance of multiple inheritance in the platform.
> > Historically, EventTarget used multiple inheritance, but that's been
> > fixed in DOM4 [4].
> >
> > B) If CSS Regions continues to require multiple inheritance, should we
> > build another one-off RTTI replacement to implement toJS(Region*), or
> > should we improve our bindings to implement this aspect of WebIDL more
> > completely?
> >
> > One approach to implementing toJS in a systematic way is to introduce
> > a base class DOMInterface along these lines:
> >
> > class DOMInterface {
> > public:
> > virtual const AtomicString& primaryInterfaceName() = 0;
> > }
> >
> > That returns the name of the primary interface (i.e., as defined by
> > WebIDL [5]).  When implementing toJS, we'd then call
> > primaryInterfaceName to determine which kind of wrapper to use.
> >
> > One downside of this approach is that it introduces a near-universal
> > base class along the lines of IUnknown [6] or nsISupports [7].  I
> > don't think any of us want WebKit to grow an implementation of
> > XPCOM...
> >
> > I welcome any thoughts you have on this topic.
> >
> > Thanks,
> > Adam
> >
> > [1] http://dev.w3.org/csswg/css3-regions/
> > [2] https://bugs.webkit.org/show_bug.cgi?id=91076
> > [3]
> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
> > [4] http://www.w3.org/TR/dom/#node
> > [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
> > [6]
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
> > [7]
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
> ___
> 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] Multiple inheritance in the DOM

[Adam Barth]

Eric Seidel points out that SVG uses multiple inheritance in its DOM
interfaces.  However, the situation there is a bit different.
Although SVGSVGElement implements SVGLocatable, there aren't any
interfaces with methods that return SVGLocatable, which means we don't
need to implement toJS(SVGLocatable*).

He also points out that Node inherits from EventTarget, which already
contains a virtual interfaceName() function similar to that used by
Event.  That pushes us further towards using a common DOMInterface
base class because introducing Region::interfaceName would mean that
Element would see both EventTarget::interfaceName and
Region::interfaceName.

Adam


On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
> The CSS Regions specification [1] defines a CSSOM interface named
> Region, which can be mixed into interfaces for other objets that can
> be CSS regions.  That means that Region introduces a form of multiple
> inheritance into the DOM.  For example, Element implements Region but
> Node does not implement Region.
>
> There's a patch up for review that implements Region using C++
> multiple inheritance [2]:
>
> - class Element : public ContainerNode {
> + class Element : public ContainerNode, public CSSRegion {
>
> One difficulty in implementing this feature how to determine the
> correct JavaScript wrapper return for a given Region object.
> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
> an Element if the Region pointer actually points to an Element
> instance.
>
> We've faced a similar problem elsewhere in the DOM when implementing
> normal single inheritance.  For example, there are many subclass of
> Event and toJS(Event*) needs to return a wrapper for the appropriate
> subtype.  To solve the same problem, CSSRule has a m_type member
> variable and a bevy of isFoo() functions [3].
>
> A) Should we push back on the folks writing the CSS Regions
> specification to avoid using multiple inheritance?  As far as I know,
> this is the only instance of multiple inheritance in the platform.
> Historically, EventTarget used multiple inheritance, but that's been
> fixed in DOM4 [4].
>
> B) If CSS Regions continues to require multiple inheritance, should we
> build another one-off RTTI replacement to implement toJS(Region*), or
> should we improve our bindings to implement this aspect of WebIDL more
> completely?
>
> One approach to implementing toJS in a systematic way is to introduce
> a base class DOMInterface along these lines:
>
> class DOMInterface {
> public:
> virtual const AtomicString& primaryInterfaceName() = 0;
> }
>
> That returns the name of the primary interface (i.e., as defined by
> WebIDL [5]).  When implementing toJS, we'd then call
> primaryInterfaceName to determine which kind of wrapper to use.
>
> One downside of this approach is that it introduces a near-universal
> base class along the lines of IUnknown [6] or nsISupports [7].  I
> don't think any of us want WebKit to grow an implementation of
> XPCOM...
>
> I welcome any thoughts you have on this topic.
>
> Thanks,
> Adam
>
> [1] http://dev.w3.org/csswg/css3-regions/
> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
> [3] 
> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
> [4] http://www.w3.org/TR/dom/#node
> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
> [6] 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Building on Mountain Lion

[Jacob Goldstein]

On 7/25/12 2:21 PM, "Mark Rowe"  wrote:

>
>On 2012-07-25, at 14:15, Jacob Goldstein  wrote:
>
>> Has any tried to build WebKit on Mountain Lion?
>> 
>> I just attempted with a new install of Mountain Lion and Xcode 4.4 and
>>the build keeps failing while trying to compile
>>AlternativeTextUIController.  If anyone has thoughts as to why this
>>could be, please let me know.
>
>We've obviously been building on Mountain Lion for quite some time. The
>WebKit nightly builds have been building for 10.6 through 10.8 against
>the OS X 10.8 SDK for the last few weeks. What problems are you running
>in to?


Ah, right, thanks for the reminder.  It must be something with my local
configuration - I'll have to take a look.

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

Re: [webkit-dev] Building on Mountain Lion

[Mark Rowe]

On 2012-07-25, at 14:15, Jacob Goldstein  wrote:

> Has any tried to build WebKit on Mountain Lion?  
> 
> I just attempted with a new install of Mountain Lion and Xcode 4.4 and the 
> build keeps failing while trying to compile AlternativeTextUIController.  If 
> anyone has thoughts as to why this could be, please let me know.

We've obviously been building on Mountain Lion for quite some time. The WebKit 
nightly builds have been building for 10.6 through 10.8 against the OS X 10.8 
SDK for the last few weeks. What problems are you running in to?

- Mark

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

[webkit-dev] Building on Mountain Lion

[Jacob Goldstein]

Has any tried to build WebKit on Mountain Lion?

I just attempted with a new install of Mountain Lion and Xcode 4.4 and the 
build keeps failing while trying to compile AlternativeTextUIController.  If 
anyone has thoughts as to why this could be, please let me know.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Multiple inheritance in the DOM

[Adam Barth]

The CSS Regions specification [1] defines a CSSOM interface named
Region, which can be mixed into interfaces for other objets that can
be CSS regions.  That means that Region introduces a form of multiple
inheritance into the DOM.  For example, Element implements Region but
Node does not implement Region.

There's a patch up for review that implements Region using C++
multiple inheritance [2]:

- class Element : public ContainerNode {
+ class Element : public ContainerNode, public CSSRegion {

One difficulty in implementing this feature how to determine the
correct JavaScript wrapper return for a given Region object.
Specifically, toJS(Region*) needs to return a JavaScript wrapper for
an Element if the Region pointer actually points to an Element
instance.

We've faced a similar problem elsewhere in the DOM when implementing
normal single inheritance.  For example, there are many subclass of
Event and toJS(Event*) needs to return a wrapper for the appropriate
subtype.  To solve the same problem, CSSRule has a m_type member
variable and a bevy of isFoo() functions [3].

A) Should we push back on the folks writing the CSS Regions
specification to avoid using multiple inheritance?  As far as I know,
this is the only instance of multiple inheritance in the platform.
Historically, EventTarget used multiple inheritance, but that's been
fixed in DOM4 [4].

B) If CSS Regions continues to require multiple inheritance, should we
build another one-off RTTI replacement to implement toJS(Region*), or
should we improve our bindings to implement this aspect of WebIDL more
completely?

One approach to implementing toJS in a systematic way is to introduce
a base class DOMInterface along these lines:

class DOMInterface {
public:
virtual const AtomicString& primaryInterfaceName() = 0;
}

That returns the name of the primary interface (i.e., as defined by
WebIDL [5]).  When implementing toJS, we'd then call
primaryInterfaceName to determine which kind of wrapper to use.

One downside of this approach is that it introduces a near-universal
base class along the lines of IUnknown [6] or nsISupports [7].  I
don't think any of us want WebKit to grow an implementation of
XPCOM...

I welcome any thoughts you have on this topic.

Thanks,
Adam

[1] http://dev.w3.org/csswg/css3-regions/
[2] https://bugs.webkit.org/show_bug.cgi?id=91076
[3] 
http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
[4] http://www.w3.org/TR/dom/#node
[5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
[6] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
[7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit memory instrumentation

[Ilya Tikhonovsky]

It turns out that clang has good API for plugins and a simple plugin for
checking the instrumentation coverage contains ~200 loc.
Thus the first option looks useless.

Regards,
Tim.


On Wed, Jul 25, 2012 at 11:34 PM, Maciej Stachowiak  wrote:

>
> On Jul 25, 2012, at 2:08 AM, Yury Semikhatsky  wrote:
>
>
>
> On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak  wrote:
>
>>
>> On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky 
>> wrote:
>>
>>
>>
>> On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak wrote:
>>
>>>
>>> On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky 
>>> wrote:
>>>
>>> *
>>>
>>> First option we consider is to define a class with the same set of
>>> fields as the instrumented one, then have a compile time assert that size
>>> of the reference class equals to the size of the instrumented one. See
>>> https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more
>>> details.
>>>
>>> Pros: compile time error whenever size of an instrumented class changes
>>> with the appropriate modifications to the instrumentation function.
>>> Cons: it will require each committer to adjust the reference class and
>>> the instrumentation on any modification that affects size of the
>>> instrumented class. Changes that don't affect size of the class will go
>>> unnoticed.
>>> *
>>>
>>>
>>> What is the advantage of this approach compared to just using the sizeof
>>> operator on the relevant classes?
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>> Summing up sizeof type of each field and parent class and comparing it to
>> sizeof the class would do the same thing except that we would need
>> sometimes to manually handle alignment discrepancies on different platforms.
>>
>>
>> I'm not sure I understand the problem you are trying to solve. Isn't
>> sizeof on the class the correct answer? Why would you need to manually add
>> sizeof for the fields? You need sizes of objects referenced by pointer, but
>> that won't be affected by alignment issues.
>>
> We use sizeof to report *this size, after that we need to go through the
> fields and report referenced objects. The problem is that the set of fields
> may change eventually and break the instrumentation. The compile check
> should help developers not to forget to update the instrumentation and add
> traversal code for the new fields.
>
>
> It seems like the compile-time check would give false positives (if you
> add a non-pointer field) and false negatives (if you change the size of a
> buffer pointed to). The most obvious way to fix it would also be to update
> the size of the reference class and not do anything special about new
> pointers, which would be the wrong thing to do. So based on that, I'm not
> sure it's worth the cost. I think compile-time checks are more effective
> when the failure is more directly related to a developer mistake.
>
> 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] Delaying Applying CSS Effects

[Keyar Hood]

For the SVGResoruceCache route, how would I specify that some element
depends on another element with id x, where x does not exist in the DOM yet?

I have noticed  SVGDocumentExtensions::addPendingResource which sounds like
what I want, but it only excepts SVGStyleElements.

On Tue, Jul 24, 2012 at 7:43 PM, Dirk Schulze  wrote:

>
> In SVG we have SVGResourcesCache which takes care of that.
>
> Greetings,
> Dirk
>
> On Jul 24, 2012, at 3:56 PM, Dean Jackson wrote:
>
> >
> > On 25/07/2012, at 6:09 AM, Keyar Hood  wrote:
> >
> >> I am working on https://bugs.webkit.org/show_bug.cgi?id=90405
> >>
> >> The problem is that when doing SVG filters in CSS using URL references,
> if the target SVG filter is after the element that the filter is to be
> applied to (the filtered element), then the filter will not be applied.
> >>
> >> Looking at the code, a getElementByID() call is made when looking for
> the target SVG filter. However, this does not work when the target SVG
> filter is after the filtered element. I believe this is because the DOM
> element for the target SVG filter does not exist yet.
> >>
> >> I am wondering if there is some way to delay resolving these CSS
> effects until after the DOM has finished loading.
> >
> > Your analysis sounds right. I think we'll have to do exactly that: delay
> calling buildFilterEffectRenderer until the document has loaded.
> >
> > Dean
> >
> >
> > ___
> > 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] WebKit memory instrumentation

[Maciej Stachowiak]

On Jul 25, 2012, at 2:08 AM, Yury Semikhatsky  wrote:

> 
> 
> On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak  wrote:
> 
> On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky  wrote:
> 
>> 
>> 
>> On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak  wrote:
>> 
>> On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky  wrote:
>> 
>>> 
>>> 
>>> First option we consider is to define a class with the same set of fields 
>>> as the instrumented one, then have a compile time assert that size of the 
>>> reference class equals to the size of the instrumented one. See 
>>> https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more 
>>> details.
>>> 
>>> Pros: compile time error whenever size of an instrumented class changes 
>>> with the appropriate modifications to the instrumentation function.
>>> Cons: it will require each committer to adjust the reference class and the 
>>> instrumentation on any modification that affects size of the instrumented 
>>> class. Changes that don't affect size of the class will go unnoticed.
>> 
>> What is the advantage of this approach compared to just using the sizeof 
>> operator on the relevant classes?
>> 
>> Regards,
>> Maciej
>> 
>> 
>> Summing up sizeof type of each field and parent class and comparing it to 
>> sizeof the class would do the same thing except that we would need sometimes 
>> to manually handle alignment discrepancies on different platforms.
> 
> I'm not sure I understand the problem you are trying to solve. Isn't sizeof 
> on the class the correct answer? Why would you need to manually add sizeof 
> for the fields? You need sizes of objects referenced by pointer, but that 
> won't be affected by alignment issues.
> We use sizeof to report *this size, after that we need to go through the 
> fields and report referenced objects. The problem is that the set of fields 
> may change eventually and break the instrumentation. The compile check should 
> help developers not to forget to update the instrumentation and add traversal 
> code for the new fields.

It seems like the compile-time check would give false positives (if you add a 
non-pointer field) and false negatives (if you change the size of a buffer 
pointed to). The most obvious way to fix it would also be to update the size of 
the reference class and not do anything special about new pointers, which would 
be the wrong thing to do. So based on that, I'm not sure it's worth the cost. I 
think compile-time checks are more effective when the failure is more directly 
related to a developer mistake.

Regards,
Maciej

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

[John Yani]

>> 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"?

Probably he meant that Webkit doesn't use STL, exceptions and RTTI.
___
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  wrote:

> 2012/7/19 Brady Eidson :
>> 
>> On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:
>> 
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>> 
>>> 
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>>> wrote:
>>> 
 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
> 
> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
> 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()<<"Hello"<<"World"<<3<<4.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] Easing printf based debugging in WebKit with an helper.

[Yong Li]

2012/7/19 Brady Eidson :
>
> On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:
>
> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
>> >> 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()<<"Hello"<<"World"<<3<<4.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?

> 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
>
___
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?

[Adam Barth]

There is no such thing as "pushing to trunk" for Chromium.  All
development happens on trunk.  That sounds like a regression.  I'll
follow up with the networking folks.

Thanks for checking!

Adam


On Wed, Jul 25, 2012 at 12:57 AM, xuewen  wrote:
> As I tested, the chromium Version 22.0.1217.0 (148296) shows auth dialogs
> for both XHR and sub-resources. Perhaps the changing has not been pushed to
> trunk !?
>
> On 07/25/2012 12:58 AM, Adam Barth wrote:
>
> On Tue, Jul 24, 2012 at 9:28 AM, xuewen.wang
>  wrote:
>
> Do you know why the chromium has not cancel auth dialog for XHR? Is this
> the main reason?
>
> The network stack folks did a round of removing auth dialogs for
> subresources a while back.  I'm not sure why they didn't remove the
> dialog from XHR.  It's possible they ran into compat trouble or that
> it was an oversight.
>
> Adam
>
>
> On 07/24/2012 11:52 PM, Brady Eidson wrote:
>
> On Jul 24, 2012, at 2:58 AM, Adam Barth  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 
> 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] Do we need a "webkitBackground" property for XMLHttpRequest?

[Joe Mason]

> From: webkit-dev-boun...@lists.webkit.org 
> [webkit-dev-boun...@lists.webkit.org] on behalf of Brady Eidson 
> [beid...@apple.com]
> 
> I think there are corporate/financial apps that would break if this was 
> policy.

Any idea which?

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
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Joe Mason]

> From: webkit-dev-boun...@lists.webkit.org 
> [webkit-dev-boun...@lists.webkit.org] on behalf of Adam Barth 
> [aba...@webkit.org]
> 
> The network stack folks did a round of removing auth dialogs for
> subresources a while back.  I'm not sure why they didn't remove the
> dialog from XHR.  It's possible they ran into compat trouble or that
> it was an oversight.

If they're not reading this thread, got a name I can contact directly?  If 
there was compat trouble I'd like to document it.

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
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Question related to license in WK2 EFL port

[Gyuyoung Kim]

Thank you for your kind reply. My curiosities are solved. 
I will discuss which license we will use with my co-workers. 

Cheers,
Gyuyoung.

--- Original Message ---
Sender : Kenneth Rohde Christiansen
Date : 2012-07-25 18:46 (GMT+09:00)
Title : Re: [webkit-dev] Question related to license in WK2 EFL port

Hi,

The license is basically up to the contributor, though there might be
a few advantages using the BSD license.

Using BSD licensed code means that the code can be re-factored in the
future and parts can be moved into WebCore or elsewhere. If you use
LGPL you have to make sure to not reuse the code in any file licensed
as BSD.

Having the code licensed as BSD also means that your employer can
reuse code parts in other internal products. That is also possible if
the code is already under your copyright, but when other people start
contributing to it, it becomes less clear.

Cheers
Kenneth

On Wed, Jul 25, 2012 at 8:36 AM, Dumez, Christophe
wrote:
> Hi,
>
> This kind of decision is not easy to take and cannot necessarily be taken by
> us developers (our employers may favor one particular license).
>
> The WebKit project allows both Apple's new BSD or LGPL as far as I know. So,
> as long as contributors use one of those 2 licenses for WebKit-EFL, I don't
> see any problem with it.
>
> Kr,
>
>
> On Wed, Jul 25, 2012 at 8:50 AM, Gyuyoung Kim 
> wrote:
>>
>> Hello WebKit folks,
>>
>> I'd like to have your opinions on EFL port licensing. Currently it uses
>> both LGPL and BSD, and there's no explicit rule in EFL port so far. So the
>> license was decided by individual contributor when new file was submitted.
>> Nowadays, some EFL contributors are confused which license should be used.
>>
>> I would like to know whether EFL folks can continue to choose which
>> license to use. Or, is there any rule related to license?
>>
>> Gyuyoung
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> --
> Christophe Dumez
> Linux Software Engineer, PhD
> Intel Finland Oy - Open Source Technology Center
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ???
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Question related to license in WK2 EFL port

[Kenneth Rohde Christiansen]

Hi,

The license is basically up to the contributor, though there might be
a few advantages using the BSD license.

Using BSD licensed code means that the code can be re-factored in the
future and parts can be moved into WebCore or elsewhere. If you use
LGPL you have to make sure to not reuse the code in any file licensed
as BSD.

Having the code licensed as BSD also means that your employer can
reuse code parts in other internal products. That is also possible if
the code is already under your copyright, but when other people start
contributing to it, it becomes less clear.

Cheers
Kenneth

On Wed, Jul 25, 2012 at 8:36 AM, Dumez, Christophe
 wrote:
> Hi,
>
> This kind of decision is not easy to take and cannot necessarily be taken by
> us developers (our employers may favor one particular license).
>
> The WebKit project allows both Apple's new BSD or LGPL as far as I know. So,
> as long as contributors use one of those 2 licenses for WebKit-EFL, I don't
> see any problem with it.
>
> Kr,
>
>
> On Wed, Jul 25, 2012 at 8:50 AM, Gyuyoung Kim 
> wrote:
>>
>> Hello WebKit folks,
>>
>> I'd like to have your opinions on EFL port licensing. Currently it uses
>> both LGPL and BSD, and there's no explicit rule in EFL port so far. So the
>> license was decided by individual contributor when new file was submitted.
>> Nowadays, some EFL contributors are confused which license should be used.
>>
>> I would like to know whether EFL folks can continue to choose which
>> license to use. Or, is there any rule related to license?
>>
>> Gyuyoung
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> --
> Christophe Dumez
> Linux Software Engineer, PhD
> Intel Finland Oy - Open Source Technology Center
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit memory instrumentation

[Yury Semikhatsky]

On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak  wrote:

>
> On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky  wrote:
>
>
>
> On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak  wrote:
>
>>
>> On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky  wrote:
>>
>> *
>>
>> First option we consider is to define a class with the same set of fields
>> as the instrumented one, then have a compile time assert that size of the
>> reference class equals to the size of the instrumented one. See
>> https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more
>> details.
>>
>> Pros: compile time error whenever size of an instrumented class changes
>> with the appropriate modifications to the instrumentation function.
>> Cons: it will require each committer to adjust the reference class and
>> the instrumentation on any modification that affects size of the
>> instrumented class. Changes that don't affect size of the class will go
>> unnoticed.
>> *
>>
>>
>> What is the advantage of this approach compared to just using the sizeof
>> operator on the relevant classes?
>>
>> Regards,
>> Maciej
>>
>>
> Summing up sizeof type of each field and parent class and comparing it to
> sizeof the class would do the same thing except that we would need
> sometimes to manually handle alignment discrepancies on different platforms.
>
>
> I'm not sure I understand the problem you are trying to solve. Isn't
> sizeof on the class the correct answer? Why would you need to manually add
> sizeof for the fields? You need sizes of objects referenced by pointer, but
> that won't be affected by alignment issues.
>
We use sizeof to report *this size, after that we need to go through the
fields and report referenced objects. The problem is that the set of fields
may change eventually and break the instrumentation. The compile check
should help developers not to forget to update the instrumentation and add
traversal code for the new fields.

Yury


>
> Regards,
> Maciej
>
>
___
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?

[xuewen]

As I tested, the chromium Version 22.0.1217.0 (148296) shows auth
dialogs for both XHR and sub-resources. Perhaps the changing has not
been pushed to trunk !?

On 07/25/2012 12:58 AM, Adam Barth wrote:
> On Tue, Jul 24, 2012 at 9:28 AM, xuewen.wang
>  wrote:
>> Do you know why the chromium has not cancel auth dialog for XHR? Is this
>> the main reason?
> The network stack folks did a round of removing auth dialogs for
> subresources a while back.  I'm not sure why they didn't remove the
> dialog from XHR.  It's possible they ran into compat trouble or that
> it was an oversight.
>
> Adam
>
>
>> On 07/24/2012 11:52 PM, Brady Eidson wrote:
>>> On Jul 24, 2012, at 2:58 AM, Adam Barth  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  
 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