Re: [webkit-dev] Position on emerging standard: video.requestAnimationFrame()

[Elliott Sprehn]

Would a method that returns a Promise be more in line with what this is
doing?

On Wed, Jan 22, 2020, 1:49 PM Simon Fraser  wrote:

>
> On Jan 21, 2020, at 5:27 PM, Thomas Guilbert  wrote:
>
> The idea was to reuse an API name that developers are already
> familiar with, in a similar context. The name is also being used in
> XRSession (
> https://developer.mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame),
> and in OffscreenCanvas (or technically DedicatedWorkerGlobalScope). The 
> AnimationFrameProvider
> mixin
> 
>  could
> also be updated so HTMLVideoElement can extend it.
>
> Yes, this isn't formally spec'ed out, but it will be. For now, they are
> added to the task queue and run like any other task. So, going off the spec
> you linked, I think this would be "5) Perform oldestTask's step"  and not
> "10) Rendering: [...] 11. Foreach document run animation frame callbacks
> for that Document".
>
>
> I would expect something that's called "requestAnimationFrame" to only
> fire in the "update the rendering" steps; requestAnimationFrame is a
> "before rendering" callback. So firing a callback with the same name at
> other times seems like it will lead to author confusion.
>
> The author's expectation should be that any content/style changes they
> make inside a requestAnimationFrame callback will appear on-screen in the
> same frame as other changes in the same event loop cycle, and that
> requestAnimationFrame won't be called more often than is necessary to
> update the screen at the appropriate frame rate.
>
> Simon
>
>
> On Tue, Jan 21, 2020 at 1:01 PM Simon Fraser 
> wrote:
>
>> On Jan 21, 2020, at 12:37 PM, Thomas Guilbert 
>> wrote:
>>
>> Hello,
>>
>> I'm reaching out to see if webkit would like to weigh in on the following 
>> proposal:https://discourse.wicg.io/t/proposal-video-requestanimationframe/3691
>>
>> The HTMLVideoElement.requestAnimationFrame() API allows web developers to be 
>> notified when a video frame has been presented for composition, and provides 
>> metadata for that frame.
>>
>> If you want to try it out, a prototype is available in Chromium Dev,
>> behind the enable-experimental-web-platform-features flag.
>>
>>
>> This is not official feedback, but I have some issues with the proposal.
>>
>> First, the name is confusing. It sounds like you're requesting a frame
>> from the video, but it's really a "frame available" callback. Why not call
>> it onFrameAvailable()?
>>
>> Second, its interaction with normal requestAnimationFrame() and the HTML
>> event loop needs to be better defined. Where in in the
>> https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model
>>  do
>> these callbacks fire?
>>
>> Simon
>>
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Elliott Sprehn]

On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher  wrote:

> On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr.  wrote:
>
> > On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher 
> wrote:
> >> On Nov 6, 2013, at 4:26 PM, John Mellor  wrote:
> >>> I've suggested before that the attributes could be combined if that's
> >>> considered simpler. My only concern is that most developers aren't
> used to
> >>> putting line breaks in html attributes, so might feel obliged to put
> all the
> >>> alternatives on one line, harming readability. But as long as the
> developer
> >>> documentation encourages line breaks, that could be fine...
> >>
> >> As I replied before, there should only be one attribute — srcset. Given
> that
> >> your micro format extends around parts of the existing micro format of
> >> srcset, it just makes sense to reuse the same attribute. Wishing srcset
> >> didn't exist doesn't make it go away.
> >
> > srcset doesn't significantly "exist" yet. It's in one browser's
> > nightly.  I'd like to resolve this soon, but it doesn't help anything
> > to pretend that it's already a done deal that must be engineered
> > around.
>
> It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.
>
>
Can you please clarify this, I just tested in Safari 6.1 and 7 and I don't
see srcset on HTMLImageElement. What do you mean it's shipped?

document.createElement('img').srcset is undefined.

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

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

[Elliott Sprehn]

On Mon, Nov 4, 2013 at 4:55 PM, Ryosuke Niwa  wrote:

> On Mon, Nov 4, 2013 at 3:12 PM, Elliott Sprehn wrote:
>
>> On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa  wrote:
>>
>>> 99 is a very high upper bound while it would still allow us to implement
>>> the optimization we're thinking of.
>>>
>>> I'm of the opinion that we should use exactly one attribute for this
>>> feature.
>>>
>>
>> Can you explain what this optimization is? It's difficult to figure out
>> how to address your issues without knowing what optimization it prevents.
>>
>
> I'm not sure if I wasn't clear here but I'm saying that having an upper
> bound of 9 or 99 would address the concern of not being able to implement
> the particular optimization we're considering.
>

Yeah; what optimization do you plan to implement though?


>
> Completely separate from that concern, I don't want us to add more than
> one content attribute to address the use cases src-N proposal addresses for
> the API's sake although I wouldn't firmly object to it if there is a broad
> consensus that this is a feature we want in WebKit.
>
> However, I don't think that there is such a consensus amongst the WebKit
> community yet as far as I've been following this thread. As such, I DO NOT
> support implementing this feature in WebKit.
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Elliott Sprehn]

On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa  wrote:

> 99 is a very high upper bound while it would still allow us to implement
> the optimization we're thinking of.
>
> I'm of the opinion that we should use exactly one attribute for this
> feature.
>
>
>
Can you explain what this optimization is? It's difficult to figure out how
to address your issues without knowing what optimization it prevents.

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

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

[Elliott Sprehn]

On Wed, Jun 19, 2013 at 9:46 AM, Andreas Kling  wrote:

> On Jun 19, 2013, at 6:37 PM, Timothy Hatcher  wrote:
>
> What about?
>
> StyleResolver* existingStyleResolver()
> StyleResolver& styleResolver()
>
>
>
This doesn't make sense since calling styleResolver() again won't create a
new one so it's also "existing style resolver".

I rather like the foo() and ensureFoo() methods. foo() is just a plain
getter like any other method, the class may start with:

setFoo(Foo*);
Foo* foo();

later we want to also allow optionally created when needed so we add:

Foo* ensureFoo();

The current naming and methodology makes a lot of sense. fooIfExists()
always bugs me because there's no reason to decorate a getter that is just
a plain getter. Adding an ensureFoo() method shouldn't make me rename the
existing foo() method to fooIfExists().

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

Re: [webkit-dev] What do we do with various Web component features?

[Elliott Sprehn]

On Mon, Apr 29, 2013 at 10:30 AM, Anders Carlsson wrote:

>
> ...
>
> +1
>
> From what I’ve heard, the Shadow DOM changes have negatively impacted the
> packability of the DOM code which is unfortunate. I’m all for removing it.
>
>
Could you elaborate on what you mean by the "packability of the DOM code"?

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

Re: [webkit-dev] Test frame size for reftests

[Elliott Sprehn]

On Wed, Apr 24, 2013 at 3:31 PM, Dirk Pranke  wrote:

>
>
>
> On Wed, Apr 24, 2013 at 3:29 PM, Elliott Sprehn wrote:
>
>> On Wed, Apr 24, 2013 at 11:11 AM, Dirk Pranke wrote:
>>
>>>
>>>> ...
>>>>
>>>>
>>> I think this raises two related questions, both of which would be helped
>>> by concrete examples:
>>>
>>> 1) What sort of test are you writing where 800x600 isn't big enough to
>>> test what you need to test?
>>>
>>> 2) What sort of test are you writing where there's needs to be something
>>> on the page not included in the test
>>> *and* will render differently in different browsers?
>>>
>>> I can posit the existence of both sorts of things, but I'm not sure when
>>> they arise in practice?
>>>
>>>
>>>
>> I've seen tests before that have lots of form controls where a bunch were
>> outside the viewport.
>>
>
> Sure, you *can* write such tests. Did you *have to*?
>
>
Certainly not, I just know such tests already exist.

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

Re: [webkit-dev] Test frame size for reftests

[Elliott Sprehn]

On Wed, Apr 24, 2013 at 11:11 AM, Dirk Pranke  wrote:

>
>> ...
>>
>>
> I think this raises two related questions, both of which would be helped
> by concrete examples:
>
> 1) What sort of test are you writing where 800x600 isn't big enough to
> test what you need to test?
>
> 2) What sort of test are you writing where there's needs to be something
> on the page not included in the test
> *and* will render differently in different browsers?
>
> I can posit the existence of both sorts of things, but I'm not sure when
> they arise in practice?
>
>
>
I've seen tests before that have lots of form controls where a bunch were
outside the viewport.

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

Re: [webkit-dev] RenderLayer::isStackingContext() confusion

[Elliott Sprehn]

The function does what it says, it's just not obvious why:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/css/StyleResolver.cpp&sq=package:chromium&type=cs&q=adjustRenderStyle&l=1469

First we set the z-index to be auto for static position elements. Next we
set the z-index to be 0 for elements based on the big set of cases in
adjustRenderStyle, and then you can tell in RenderLayer if you're a
stacking context based on if you have z-index != auto.

I'd add a comment explaining. The alternative is to check that big set of
cases every time someone calls isStackingContext but that might be slower.
Changing the name of the method would make the code more confusing, since
it is checking the right thing just through some complicated process.


On Wed, Apr 3, 2013 at 3:48 PM, Shawn Singh  wrote:

> Background:
>
> According to CSS 2.1 spec, an element becomes a stacking context when:
>   - it is positioned  (relative, absolute, or fixed)
>   - and it has a non-auto z-index
>
> Spec also mentions that there's room for expanding this definition; the
> examples I know about are fixed-position elements and elements with
> transforms.
>
>
> Questions:
>
> The implementation of RenderLayer::isStackingContext() looks fishy.  It
> only checks for a non-auto z-index.  It does not check for the positioning
> style of the layer.  There is no indication that it checks for any more
> recent special cases such as fixed-position or transforms.
>
> Is this function name a misnomer?  should it actually be renamed to
> hasNonAutoZIndex() ?
>
> If the additional criteria is not being checked inside this helper
> function, then where is it?  I see some code in collectLayers that looks
> vaguely similar to checking whether an element is positioned, but what
> about all the other uses of isStackingContext everywhere?
>
> Thanks!
> Shawn
>
> ___
> 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] Disable the automated markup fixes

[Elliott Sprehn]

This is just the behavior of the HTML5 parser not something special about
webkit. Why do you want to turn it off?



On Tue, Apr 2, 2013 at 6:58 PM, Aaron Lewis wrote:

> Hi Ben,
>
> Thanks for reply,
>
> But I checked the source code, the "createMarkup" function is from
> WebCore, so it's not about QtWebkit, right?
>
> Correct me if I'm wrong 
>
> On Wed, Apr 3, 2013 at 9:57 AM, Benjamin Poulain 
> wrote:
> > On Tue, Apr 2, 2013 at 6:53 PM, Aaron Lewis 
> > wrote:
> >>
> >> I'm running a test app with QtWebkit, looks like webkit is attempting
> >> to fix invalid markups automatically,
> >>
> >> For page contents like this,
> >> [...]
> >
> >
> > Wrong mailing list.
> >
> > This is the QtWebKit mailing list:
> > https://lists.webkit.org/mailman/listinfo/webkit-qt
> >
> > Benjamin
>
>
>
> --
> Best Regards,
> Aaron Lewis - PGP: 0xDFE6C29E ( http://keyserver.veridis.com )
> Finger Print: 9482 448F C7C3 896C 1DFE 7DD3 2492 A7D0 DFE6 C29E
> ___
> 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] Ever increasing binary size

[Elliott Sprehn]

I'd be really interesting to see what patches are causing the growth and by
how much. I wonder how much of this is from some of the fancier template
things we have (ex. the 600 template expansions from StyleBuilder)


On Fri, Mar 22, 2013 at 5:22 AM, Eric Seidel  wrote:

> It seems like it should be trivial to set up an EWS bot to track size
> changes.
>
> It would (sadly) need to clobber, as my understanding is that
> incremental builds are not deterministic in their sizes:
> https://code.google.com/p/chromium/issues/detail?id=110002
> (our bug about this for Chromium Try servers).
>
> Thankfully the EWS is very well suited for this task.
>
> On Fri, Mar 22, 2013 at 1:29 AM, Benjamin Poulain 
> wrote:
> > On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa  wrote:
> >>
> >> WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB.
> >> WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB.
> >>
> >> Our binary size increased by 7.2% in just 4 months.
> >
> >
> > I have been tracking this issue for a bit. I can send more detailed view
> of
> > the growth if anyone is interested.
> >
> >>
> >> Is this a problem?  I think it is. It means that we use more RAM when
> >> WebKit is loaded onto memory. It means that it takes longer to load
> WebKit
> >> into RAM. It means that auto-update, etc... various browsers that use
> WebKit
> >> needs to send more data over the network.  6MB costs you a ton if you're
> >> wiring over cellar network.
> >
> >
> > RAM space is not the only problem we have with big binaries. The bigger
> our
> > code gets, the less efficiently we use the fast CPU caches and WebKit
> gets
> > slower over time overall.
> >
> > On embedded, you typically have tiny caches and slower memory. This
> leads to
> > a lot of memory pressure and we had to cut binary size sometimes to get
> the
> > performance back.
> >
> >> What strategies can we use to address this problem?
> >
> >
> > I would like it if EWS could report growth and shrinkage somehow, and
> have a
> > warning in case of abnormal growth.
> >
> > Benjamin
> >
> > ___
> > 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] Best way to disable JavaScript

[Elliott Sprehn]

On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen  wrote:

> ...
> There are problems with mode (2):
>
> * It breaks features that are implemented in JavaScript.
>
> The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
> autofill all run JavaScript. This means that they break when users disable
> JavaScript.
>
>
The web inspector works even with JS disabled in Safari (I filed the very
first bug about this actually back when it crashed :)) and I just tested
and Reader works fine too.

Are there any examples of browser provided UI that actually breaks with JS
disabled? I'm pretty sure those all run in different worlds.

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

Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute

[Elliott Sprehn]

alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does globalAlpha
still work?

It's sad that WebGL picked such a generic name that isn't about all "alpha"
related things.


On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier  wrote:

> The main reason for this feature is to enhance performance of canvas
> operations.
> Are we certain that this will always be the case? For instance, is google
> going to make certain that the cairo and core graphics backends don't slow
> down?
>
> Rik
>
>
> On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones  wrote:
>
>> I think "opaque" vs. "alpha: false" is a matter of opinion. The
>> functionality doesn't change, regardless of what you call it.
>>
>> I agree with Gregg that this really should be implemented to reflect the
>> functionality that WebGL already has. Wether 2D or 3D, there's a lot of
>> common ground between the various canvas contexts and it doesn't make much
>> sense to reinvent the wheel when one context type has already implemented
>> the functionality.
>>
>> --Brandon
>>
>>
>> On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak  wrote:
>>
>>>
>>> An attribute on the canvas element would presumably be equally
>>> applicable to all contexts. Is there a reason that it's better to have
>>> opaqueness specified at context creation time instead of on the canvas?
>>> Also, I think "opaque" is easier to understand than "alpha: false".
>>>
>>>  - Maciej
>>>
>>> On Mar 13, 2013, at 9:57 AM, Gregg Tavares  wrote:
>>>
>>> It would be nice if this was the same as WebGL instead of different.
>>> Especially because 2d canvas and WebGL need to inter-operate in the near
>>> future.
>>>
>>> In WebGL to create a canvas with no alpha (an opaque canvas) you do this
>>>
>>>gl = canvas.getContext("experimental-webgl", { alpha: false });
>>>
>>> Why can't 2D canvas be this
>>>
>>>ctx = canvas.getContext("2d", {alpha: false});
>>>
>>> As for why this is important to be the same see the proposal for Canvas
>>> in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
>>>
>>> In that proposal the "backingstore" of a canvas can be moved to/from a
>>> worker. That solution may or many not be the final solution but it points
>>> out that whatever solution is chosen we need the solution to work for both
>>> canvas 2d and WebGL and as such needs a common way to create backing stores
>>> with no alpha.
>>>
>>>
>>>
>>> On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze 
>>> wrote:
>>>
 This is a very long thread and I did not see any conclusions or
 agreement on this thread. Can you summarize the topic and the status on the
 acceptance level please?

 Greetings,
 Dirk

 On Mar 13, 2013, at 9:15 AM, Stephen White 
 wrote:

 > Hi WebKittens,
 >
 > I'm planning to implement the canvas "opaque" attribute, as proposed
 here:
 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html
 .
 >
 > This is an attribute that causes the allocation of an opaque backing
 store for , allowing optimizations at the time the canvas is
 composited into the page, such as disabling blending and culling obscured
 content.  It is based on the moz-opaque attribute currently shipping in
 Firefox.
 >
 > I'll be placing the feature behind the build-time flag
 ENABLE(OPAQUE_CANVAS).
 >
 > Let me know if you have any comments or concerns.
 >
 > Stephen
 > ___
 > webkit-dev mailing list
 > webkit-dev@lists.webkit.org
 > https://lists.webkit.org/mailman/listinfo/webkit-dev

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

>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
> ___
> 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] Feature Proposal: Implement Stream and StreamReader

[Elliott Sprehn]

Darin Fisher pointed out to me that this is about Stream and StreamReader
per the subject, not StreamBuilder (which is not planned to be implemented
yet).

So sounds good to me! :)


On Tue, Feb 19, 2013 at 1:28 PM, Elliott Sprehn wrote:

> This API seems like it's in an inconsistent state with the other web
> platform features going on right now.
>
> ex. StreamBuilder sounds like BlobBuilder, and we recently killed that for
> a constructor for Blob.
>
> It's a bit concerning that we're going to add this feature, and then
> perhaps change it, and then need to go through the "how long does it take
> to deprecate features" cycle again.
>
> What's the plan for turning this on?
>
>
> On Tue, Feb 19, 2013 at 2:12 AM, Zach Kuznia  wrote:
>
>> Hi webkit-dev!
>>
>> I'm currently working on adding support for Stream and StreamReader to
>> WebKit.
>> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
>>
>> This support will be behind the ENABLE_STREAM feature define.
>>
>> I have a prototype which implements readAsArrayBuffer() from an XHR
>> connection at:
>> https://bugs.webkit.org/show_bug.cgi?id=110194
>>
>> Tests will be added as I change it to a real implementation.
>>
>> Cheers,
>> -Zach
>>
>> ___
>> 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] Feature Proposal: Implement Stream and StreamReader

[Elliott Sprehn]

This API seems like it's in an inconsistent state with the other web
platform features going on right now.

ex. StreamBuilder sounds like BlobBuilder, and we recently killed that for
a constructor for Blob.

It's a bit concerning that we're going to add this feature, and then
perhaps change it, and then need to go through the "how long does it take
to deprecate features" cycle again.

What's the plan for turning this on?


On Tue, Feb 19, 2013 at 2:12 AM, Zach Kuznia  wrote:

> Hi webkit-dev!
>
> I'm currently working on adding support for Stream and StreamReader to
> WebKit.
> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
>
> This support will be behind the ENABLE_STREAM feature define.
>
> I have a prototype which implements readAsArrayBuffer() from an XHR
> connection at:
> https://bugs.webkit.org/show_bug.cgi?id=110194
>
> Tests will be added as I change it to a real implementation.
>
> Cheers,
> -Zach
>
> ___
> 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] WebKit2/Mac and C++11

[Elliott Sprehn]

Thanks for the advance warning! :)

- E


On Wed, Jan 30, 2013 at 3:17 PM, Anders Carlsson  wrote:

> Hello!
>
> This is just a friendly heads-up that the Mac specific parts of WebKit2
> will soon start requiring C++11 features (move semantics and variadic
> templates being the two most important).
>
> Any recent version of Xcode (4.2 or later) should support this, and we're
> already building all of WebKit2 as C++11 on Mac anyway.
>
> - Anders
> ___
> 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] Can we remove Notification.show()?

[Elliott Sprehn]

This seems like a badly designed API, constructors shouldn't have side
effects and not having show() means after calling close() the notification
object is useless which is silly.


On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson  wrote:

> So, we've recently landed some fixes to address permissions handling for
> Notification.show(): http://trac.webkit.org/changeset/140927
>
> Turns out, the notifications specification does not have a show() API (the
> notification is automatically shown from the constructor --
> http://notifications.spec.whatwg.org/#api). Does anyone have any
> objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS
> flag to bring us under compliance with the spec?
>
> Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs, not
> only do they get support for the old webkitNotifications API, but also some
> of the old API (like show() and cancel()) is exposed on the new
> Notifications objects, because we share the same interface for
> webkitNotifications and Notifications. Do we care (will this make it harder
> to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start
> using those APIs on the new Notifications objects)?
>
> -atw
>
> ___
> 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
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Elliott Sprehn]

On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze  wrote:

> ...
> The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
> are implemented by a lot of other interfaces as well. Supplemental is just
> supposed to be set once per interface. That is why Supplemental doesn't
> work for SVG. The alternative would be to implement the attributes and
> operations of SVGFitToViewBox and SVGZoomAndPan into every class that
> implements them. This would be a lot of code copies. And these are not the
> only interfaces that would need to be merged.
>

That's an issue of being DRY though, which we can certainly solve in
WebKit. I don't think Adam has an issue with extending webkit IDL to help
with that, or at least I'd hope not.

We could probably use multiple inheritance in C++ and copy/paste the idl
defs, or add some new IDL feature for it.

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

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Elliott Sprehn]

On Fri, Jan 25, 2013 at 8:09 PM, Dirk Schulze  wrote:

>
> On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak  wrote:
>
> >
> > On Jan 25, 2013, at 4:13 PM, Adam Barth  wrote:
> >
> >> On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze 
> wrote:
> >>> On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:
>  On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze 
> wrote:
> > This is a followup to the multiple inheritance discussion.
> >
> > Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2
> do not have multiple inheritances of interfaces that are exposed to
> bindings. But SVG2 still uses the "implements" statement for
> "[NoInterfaceObject]" interfaces [2]. This should at least address your
> initial concern not to inherit from different interfaces exposed to
> bindings.
> >
> > However, during a discussion on IRC I got the impression that we do
> not plan to support the "implements" statement because it can do "weird"
> things. If this is right, I would like to understand why this is the case?
> 
>  We don't intend to support all the possible things that you can do
>  with "implements."  With "implements", you can define arbitrarily
>  complicated relationships between interfaces, including some that can
>  be implemented only with a QueryInterface-like mechanism.  We're not
>  going to implement QueryInterface, so we're not going to implement any
>  specifications that require it.
> >>>
> >>> This sounds that you consider having "implements" in our WebIDL
> interpreter, or at least would not block adding this per se. This was my
> concern in the first place, since this is already in use in a lot of
> specifications (just with [NoInterfaceObject] as far as I saw).
> >>
> >> WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
> >> compiler.  If you spec something that requires a QueryInterface-like
> >> mechanism in the implementation, we will not implement it regardless
> >> of what language you write the specification in.  It's a conscious
> >> design decision not to implement a COM-like (or XPCOM-like) system.
> >
> > Setting aside the more general question, does the SVG2 set of interfaces
> effectively require a QueryInterface-like mechanism? What limitations, if
> any, on the use of "implements" would a spec have to follow to dodge this
> bullet? SVG2 is still evolving, so I suspect it could adjust its use of
> "implements" if it's an issue for us.
>
> SVG2 does not require any inter process communication. The QueryInterface
> was an example of Adam what we should not implement. SVG2 uses WebIDL's
> "implements" statement for [NoInterfaceObject] interfaces, as the HTML
> specification is doing it. But SVG uses multiple "implements" statements
> per interface:
>
> interface SVGViewSpec
>  {
>   readonly attribute SVGTransformList transform;
>   readonly attribute SVGElement viewTarget;
>   readonly attribute DOMString viewBoxString;
>   readonly attribute DOMString preserveAspectRatioString;
>   readonly attribute DOMString transformString;
>   readonly attribute DOMString viewTargetString;
> };
> SVGViewSpec implements SVGFitToViewBox;
> SVGViewSpec implements SVGZoomAndPan;
>
> SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.
>
> I hope that I am not mistaken and that this is not what you mean with
> QueryInterface.
>
>
Since they're NoInterfaceObjects we can just merge the idl into the file in
WebKit or use Supplemental in WebkitIDL. You've written it with multiple
implements to be DRY in the WebIDL, that's not a problem for WebKit.

See: HTMLInputElementFileSystem.

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

Re: [webkit-dev] Do any ports still disable SVG?

[Elliott Sprehn]

Perhaps the time to remove ENABLE_SVG is in several years once many pages
depend on it and disabling it results in a busted browser...


On Fri, Jan 25, 2013 at 2:55 PM, Arunprasad Rajkumar  wrote:

> Eric, Most of the resource constraint environments(embedded systems) still
> disables the SVG. If the define is removed code size of WebKit will be
> increased by atleast 3 to 4M.
>
>
> On 26 January 2013 01:01,  wrote:
>
>> This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393
>>
>> Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
>> defines (and potentially unifying SVG and HTML style resolve more
>> closely)?
>>
>> --
> *Arunprasad Rajkumar*
> http://in.linkedin.com/in/ararunprasad
>
> ___
> 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] Proposal to remove list-item special counter

[Elliott Sprehn]

On Wed, Aug 15, 2012 at 3:50 PM, Darin Adler  wrote:

> On Aug 15, 2012, at 2:29 PM, Elliott Sprehn  wrote:
>
> > WebKit is the only browser that implements the magic counter named
> "list-item" and we have no tests for it.
>
> Seems like we really ought to add some tests for it.
>
> > It's not useful since we don't support the ::marker pseudo element
>
> Maybe it can’t be used for its best and most obvious uses without
> ::marker, but it still work and can be used for some things. Here’s an
> example of it doing some good:
>
>  #list-count:before { counter-increment: list-item -1; content:
> counter(list-item); } 
> 
>  A
>  B
>  C
> 
> The list above has  items in it.
>
> I’m still OK with removing it if there is an argument that the current
> implementation does more harm than good.
>

I've scoured the web and can't find any reference to anyone using it,
mention of it's usage on any pages and no other browser supports it. In
terms of harm, it adds implementation complexity, especially when I want to
rewrite counters to be much simpler and faster.

I'd like to go ahead with the removal and then we can bring this back if
developers show interest. Does that sound reasonable?

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

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

[Elliott Sprehn]

On Fri, Dec 21, 2012 at 6:09 AM, Antti Koivisto  wrote:

> On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. wrote:
>
>> No, it's just a refactoring on the CSS side, so we don't have to
>> repeat a bunch of stuff every time we have an at-rule that contains
>> other rules.  It just makes the WebIDL easier and less error-prone.
>>
>
> It seems bit strange to add a web-exposed type if it is just a spec
> writing helper. Each new type has non-zero cost (code size of generated
> bindings etc).
>
> Internally it obviously makes sense to share code, I'm just wondering why
> we would want to expose this via API.
>
>
It means you can add methods to the prototype across all the types, and you
can override methods across the types per the way they're described in IDL.
It also provides instanceof for type checking in JS.

If we're not going to expose it and be spec compliant then perhaps we
should take that up with the spec as an objection and see if they're
willing to use a NoInterfaceObject instead.

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

Re: [webkit-dev] Behaviour of CapsLock in WebKit/Mac

[Elliott Sprehn]

This same bug exists in Gecko
https://bugzilla.mozilla.org/show_bug.cgi?id=712535

It appears Cocoa just doesn't notify of this:
http://stackoverflow.com/questions/12536356/how-to-detect-key-up-or-key-release-for-the-capslock-key-in-os-x

so we'd probably need to interact directly with the HID manager... and then
hope it's not at that level too :)


On Wed, Dec 12, 2012 at 10:43 AM, Wez  wrote:

> Thanks Mark!
>
> If this is intentional behaviour of Mac OS X then ideally WebKit should
> work around it, but I wonder how much existing content that would break?
>
>
> On 11 December 2012 21:32, Mark Rowe  wrote:
>
>>
>> On 2012-12-11, at 21:24, Wez  wrote:
>>
>> > Hi all,
>> >
>> > There's a bug reported against Chromium (crbug.com/144757) for the
>> CapsLock key generating only a keydown when first pressed and released, and
>> a keyup when next pressed and released, i.e. the keydown & keyup events
>> correspond with the caps lock-state being toggled, rather than with the key
>> itself being pressed or released.
>> >
>> > The same issue reproduces against Safari on Mac.  Is this a by-design
>> behaviour of WebKit?
>>
>> It’s a known issue ().
>>
>> - Mark
>>
>>
>
> ___
> 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] Behaviour of CapsLock in WebKit/Mac

[Elliott Sprehn]

Does this reproduce on every platform? If it's a OS X issue then it should
work on Windows or Linux I'd hope.

- E


On Tue, Dec 11, 2012 at 9:32 PM, Mark Rowe  wrote:

>
> On 2012-12-11, at 21:24, Wez  wrote:
>
> > Hi all,
> >
> > There's a bug reported against Chromium (crbug.com/144757) for the
> CapsLock key generating only a keydown when first pressed and released, and
> a keyup when next pressed and released, i.e. the keydown & keyup events
> correspond with the caps lock-state being toggled, rather than with the key
> itself being pressed or released.
> >
> > The same issue reproduces against Safari on Mac.  Is this a by-design
> behaviour of WebKit?
>
> It’s a known issue ().
>
> - Mark
>
> ___
> 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] Rolling out a patch requires a justification beyond a test failure in downstream projects

[Elliott Sprehn]

Do you have an example of when this has occurred? It's good to have
examples if we want to prevent this in the future.


On Tue, Dec 11, 2012 at 1:44 PM, Ryosuke Niwa  wrote:

> Hi,
>
> I've encountered a couple of incidences where people roll out patches
> saying that test X is failing on some downstream project Y without giving
> any details as to how those tests are failing and why that's a real WebKit
> regression we should care about.
>
> First off, I don't think we should be rolling out patches based solely on
> a downstream test unless there is a clear evidence that the failure is a
> real regression in WebKit that affects more than just the said downstream
> project. You may talk to the author and he or she might be nice enough to
> agree to roll out the patch, but I don't think we should be rolling out
> patches right away regardless.
>
> Second, if there is a clear WebKit regression, then you should communicate
> the following information at minimum:
>
>1. The exact location of the test that failed - URL, etc...
>2. The nature of the failure - assertion failure, feature it's
>testing, etc...
>3. The output (before and) after the failure started happening.
>4. Instructions to run the tests locally
>
> Without this, the author is left with no clue whatsoever
> to diagnose and/or fix the problem.
>
> - R. Niwa
>
>
> ___
> 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] Prefix naming scheme for DOM-exposed functions

[Elliott Sprehn]

This seems like it would introduce bugs and make maintaining the DOM harder
since we'd need to duplicate logic. Right now we have appendChild() and
parserAppendChild(), and using parserAppendChild() for anything not in the
parser introduces web observable bugs and changes in behavior. We also only
have tests for the web exposed methods, unless you're suggesting we add C++
unit tests too? :)

Can you give an example of what you want to change in the non web exposed
appendChild() ?


On Fri, Dec 7, 2012 at 9:27 AM, Darin Adler  wrote:

> Hi folks.
>
> Many of the APIs designed for use in the DOM are not efficient for use
> inside WebKit, or have designs that are better for JavaScript than for C++.
> Antti Koivisto and I have been discussing how to best communicate this to
> WebKit contributors so they don’t end up using inefficient idioms just
> because they are familiar with them from use in JavaScript code on
> websites. So far, our best idea for this is to add a prefix to function
> names that indicate they are functions for use by the bindings machinery.
> Thus, a function like appendChild would get a new name:
>
> void bindingsAppendChild(Node*, ExceptionCode&);
>
> The internal function that’s used to add a child node would be designed
> for the best clarity, ease of use, and efficiency within WebKit
> implementation code, even when that does not match up with the DOM
> standard. And could be refactored over time as WebKit design changes
> without affecting the bindings.
>
> - It’s not clear what the best prefix is. I don’t like the prefix “dom”,
> since it’s a lowercased acronym and an overloaded not all that precise
> term. The prefix “bindings” is sort of silly because these functions are
> not themselves “bindings”, rather they are the non-language-specific
> functions designed to be bound to each language. However, I do like the
> idea of a brief non-acronym word. So, still looking for a great prefix.
>
> - When appropriate, these exposed functions can be short inline functions
> that turn around and call internal functions.
>
> - These functions aren’t needed at all to implement reflected content
> attributes. Hooray!
>
> - So far my best idea on how to stage this is to new inlines without
> cutting the bindings over to them. Then cut the bindings generation script
> over, then remove and refactor the various unneeded underlying functions.
> Other ways to stage this would be add an attribute so we can can switch a
> class or a function at a time over to the new naming scheme, but base
> classes could make that process challenging and needlessly complex.
>
> - We don’t want to use ExceptionCode& arguments much in internal
> functions. They lead both to confusing code and to inefficiency, and I
> think we can do much better without them. But they are still probably a
> good efficient way to indicate the need for an exception to the JavaScript
> binding. We’d eliminate ASSERT_NO_EXCEPTION as part of this.
>
> - This will be particularly helpful for future optimizations, such as one
> we are contemplating that will make currently-heavily-used functions such
> as firstChild more expensive, and currently-lightly-used functions such as
> firstElementChild cheaper. We need a way to rename such things and find
> internal callers and prevent people from accidentally undoing that effort
> as they do additional WebKit work.
>
> -- Darin
> ___
> 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] RenderArena: Teaching an old dog new tricks

[Elliott Sprehn]

On Thu, Nov 15, 2012 at 3:22 AM, Chris Evans  wrote:

>
>> ...
>>
>
> My read on the Arena is that it's fragmentation resistant (i.e. it will
> not repurpose a larger free chunk to satisfy a smaller allocation.)
> However, memory usage at any given time is defined by peak usage since it
> cannot release pages back to the system without ruining its security
> guarantee. Interestingly, it can't be super bad: we already bite this
> bullet for RenderArena as used by RenderObjects. The RenderArena lifetime
> is the same as the document / DOM and I was surprised to recently be told
> that we don't throw away the RenderArena on a full layout.
>
>
My understanding is that the render tree is rather small compared to the
DOM in terms of memory usage on most pages so not releasing it may not be
so bad, but never releasing the memory used from DOM nodes seems like it'd
be bad for large web apps.

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

Re: [webkit-dev] RenderArena: Teaching an old dog new tricks

[Elliott Sprehn]

On Thu, Nov 15, 2012 at 1:29 AM, Ryosuke Niwa  wrote:

> ...
> In other words, why are you interested in using the proposed allocation
> mechanism for only DOM nodes/objects instead of everything in
> WebCore/WebKit?
>
>
This was my concern as well. It would seem you'd need many different
arenas, and that would only make it really annoying to get use after frees
since they have to be in the same arena, not impossible.

The major danger is really ArrayBuffer (and I suppose String) which lets
you allocate an object of a specific size and aligned the same as the freed
object. You can then create thousands of them until you get one on top of
the freed location and fill in the buffer with the malicious vtable and ptr.

How hard would it be to allocate the void* buffer and the String UChar*
with an arena?

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

Re: [webkit-dev] RenderArena: Teaching an old dog new tricks

[Elliott Sprehn]

I was present for one of the discussions about the exploit and how an arena
like allocator could have helped at Google. One proposed solution was to
allocate all the JS typed buffers in an arena.

Is there a reason we can't just do that? It's much less intrusive to
allocate ArrayBuffer in an arena than to allocate all DOM objects in one.

- E


On Wed, Nov 14, 2012 at 11:16 PM, Maciej Stachowiak  wrote:

>
> Following up on a bugzilla discussion:
>
> > It is indeed significant that only a small number of classes are
> allocated within RenderArena. For example, when there's a RenderObject
> which has been freed but is still in use, it's not possible for the
> attacker to allocate (e.g.) a raw ArrayBuffer contents on top of the freed
> slot. So the attacker cannot place arbitrary bytes on top of where the
> vtable pointer is expected to be. We've made sure that the first
> sizeof(void*) bytes either point to a valid vtable pointer, or are a
> poisoned freelist pointer, or are an invalid pointer in the case that one
> of the (few) non-virtual classes is overlaid.
> >
> > It's essentially about limiting the attacker's possibilities when the
> inevitable rendering use-after-frees occur. There are some other non vtable
> related possibilities that get limited too.
>
> Interesting! How much value would be derived from allocating all classes
> with a virtual method in a separate heap from classes with no vtable and
> raw data buffers? And how much is specifically due to a more limited range
> of classes that may be present in the RenderArena? If classes with vtables
> getting overwritten by arbitrary data are the top fear, then there is
> probably a more modest solution than RenderArena. It could still cause
> additional memory fragmentation, but probably less so than RenderArenas.
>
> 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] Adding Web Animations to WebCore

[Elliott Sprehn]

I'd also like to object to this as the API is very complicated and doesn't
seem incremental or like it fits with existing platform features.

Also the naming of things is inconsistent and messy. Why are half the
interfaces and properties  abbreviated and half of them not?

This doesn't feel baked enough.

- E
 On Nov 8, 2012 4:45 PM, "Dean Jackson"  wrote:

>
> On Nov 8, 2012, at 4:11 PM, Douglas Stockwell 
> wrote:
>
> I wanted to let you know that work has begun on implementing Web
> Animations in WebKit. New code for this effort will be landed behind the
> ENABLE_WEB_ANIM feature define and a runtime setting. We expect to be
> turning this define on for Chromium buildbots so there will be build and
> test coverage as the new functionality is added.
>
> The current Editor’s Draft for Web Animations is available at:
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html
>
> The implementation will be tracked by a meta bug:
> https://bugs.webkit.org/show_bug.cgi?id=101660
>
>
> As well as Maciej's concerns, I'd like to add that we already have three
> non-interoperable animation technologies in WebKit (SMIL, CSS and rAF). I
> think we need to clean this up before adding any more complexity.
>
> I do very much support the idea of an animation API though.
>
> 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] Making more use of ScriptWrappable

[Elliott Sprehn]

On Thu, Nov 1, 2012 at 2:09 PM, Kentaro Hara  wrote:
> ...
>
> Thanks to the recent efforts of Adam Barth, V8 bindings are going to
> remove the need to enumerate all wrappers, and thus the HashMap does
> not need to store all wrappers. On the other hand, what about JSC
> bindings?
>

JSC has a map per world, and the main world wrappers are stored in the
ScriptWrappable, not in the map. Only Node's are ScriptWrappable it
seems.

http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSDOMBinding.h&l=137

http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSNodeCustom.h&l=42

I'm not sure why setInlineCachedWrapper takes a Node* specifically, it
should just take a ScriptWrappable* so Adam's change works for JSC
too.

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

Re: [webkit-dev] moving focus when clicking on scrollbars

[Elliott Sprehn]

On Thu, Nov 1, 2012 at 4:42 AM, Maciej Stachowiak  wrote:
> ...
> Is our current behavior the same as the "every browser engine, except Gecko" 
> behavior described above?

Yes.

- Native *never* moves focus, even if the control is focusable (ex.
the wireless networks list in OS X Preferences.app)

- Trident, WebKit and Presto blur the activeElement when clicking a
scrollbar even if the element with the scrollbar is not focusable.
This results in the body being focused.

- Gecko *only* blurs the activeElement if the element with the
scrollbar is focusable (ex. overflow div + tabindex). That is, Gecko
will only blurs if the focus can be transfered to the scrollbar owner.

>
> I like the idea of being more like native control behavior.

I agree. I'll update the patch to match Gecko's mostly native, but web
friendly behavior.

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

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

[Elliott Sprehn]

On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa  wrote:
> ...
>
> I agree this is a good change but it appears that we should add more
> cache/loader tests before changing DRT's behavior given that there are
> active contributors who rely on the current DRT behaviors to detect
> regressions.
>

Can we add a flag to control this behavior? Then Antti could run the
tests without cache clearing when modifying things possibly related to
the cache code. We could even run a separate cr-linux bot like we do
for debug builds.

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

Re: [webkit-dev] On returning mutable pointers from const methods

[Elliott Sprehn]

This requires weird contortions in the DOM and Render tree and removes
nice guarantees.

For example Node.h has:

TreeScope* treeScope() const;
Document* document() const;
Node* childNode(unsigned index) const;

Returning a const Document* or Node* from childNode makes the DOM
API's suddenly less useful, and marking them as non-const is
confusing. These methods shouldn't be making mutations and the
compiler should enforce that (or at least try to), and the const is also good
documentation.

On Thu, Oct 25, 2012 at 1:02 PM, Peter Kasting  wrote:
> On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling  wrote:
>>
>> So, I propose that we allow only these two signature formats for raw
>> pointers:
>>
>> - const Foo* foo() const;
>> - Foo* foo();
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding high resolution platform timestamp to DOM events

[Elliott Sprehn]

This doesn't appear to be in any standard yet. You should probably send
something to public-webapps or the whatwg list and make sure others are
onboard for the idea before exposing it to the web.

On Wed, Oct 24, 2012 at 6:17 PM, Robert Flack  wrote:

> Hi webkit-dev,
>
> I would like to add platform timestamps to DOM events as the systemTime
> property. I have a patch implementing the feature:
> https://bugs.webkit.org/show_bug.cgi?id=94987. This will let us know the
> time at which the system received an event to be able to accurately handle
> it, whereas the timestamp property gives the time the DOM event was created
> in an inaccurate milliseconds since 1970 form. This has been discussed on
> www-dom (http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html)
> and www-perf (
> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html)
> and use cases for this have been discussed (
> http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0092.html).
>
> The platform timestamp comes in as a monotonic timestamp. Since the DOM
> Event spec requires that timeStamp() be a 1970-epoch based timestamp it is
> not sufficient for a high resolution precise time delta on event delivery.
> Instead, we add a systemTime property which uses the Performance API spec (
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html)
> for high res timestamps (time since document load timestamp to avoid user
> fingerprinting) and provide the platform's high resolution timestamp to
> ECMAScript.
>
> Let me know if you have any suggestions. I look forward to everyone's
> feedback, cheers!
> - Rob
>
> ___
> 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] Improving DOM Exception console messages.

[Elliott Sprehn]

Even so what we have right now can be improved without exposing sensitive
information. For instance HIERARCHY_REQUEST_ERR or SYNTAX_ERR is really
useless, it would be much nicer to have the tag name and what was really
wrong.

As a current example, if you create a MutationObserver with the wrong
dictionary arguments you get a useless error message.

o = new WebKitMutationObserver(function() {})
o.observe(node, {});
// SYNTAX_ERR: wtf is really wrong?

I don't think we need to wait for interop here, we can just give you
sensible error messages.

On Mon, Oct 1, 2012 at 6:21 PM, Ryosuke Niwa  wrote:

> To make my position clear, I support improving the error messages on
> Inspector. I'm just worried about exposing that to the Web because this
> area is already terribly under-spec'ed.
>
>
> On Mon, Oct 1, 2012 at 5:48 PM, Ryosuke Niwa  wrote:
>
>> On Mon, Oct 1, 2012 at 5:18 PM, Ojan Vafai  wrote:
>>
>>> This isn't spec'ed anywhere. I agree it would be ideal to get a spec for
>>> this, but I don't think we need to block on that in this instance.
>>
>>
>> I would like to see us posting this on public-webapps or www-dom. I've
>> seen js code that tried to parse exception messages to get more information
>> about the failure.
>>
>>
>>> This is an area where browsers are completely incompatible already. I
>>> don't see much benefit from blocking on creating a specification to make
>>> this situation better for web developers. It's actually not that big of a
>>> deal if the error messages from different browsers are different.
>>
>>
>> If Web developers wanted to know the details of failures on their
>> websites as opposed to on Inspector, wouldn't it better to add some sort of
>> API that could interoperate on all browsers?
>>
>> - Ryosuke
>>
>>
>
> ___
> 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] WKCreateCTLineWithUniCharProvider

[Elliott Sprehn]

WKCreateCTLineWithUniCharProvider is in the WebKitSystemInterface so its
source is not available outside Apple.

On Wed, Sep 26, 2012 at 2:34 AM, Glenn Adams  wrote:

> Where can I find the source for WKCreateCTLineWithUniCharProvider? I'm
> working on a bug [1] in which I will need to at least understand and
> perhaps modify its behavior.
>
> Basically, to fix this bug, I need to pass character context from adjacent
> text runs (or adjacent inline text nodes) that will be used to affect the
> shaping substitutions but not otherwise participate in width or drawing
> behavior.
>
> Or is this functionality only exposed to Apple staffers? [If so, then I
> will instead approach doing a trial fix on one of the platforms that uses
> harfbuzz.]
>
> Regards,
> Glenn
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=6148
>
>
>
> ___
> 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] New Feature: Canvas Path object

[Elliott Sprehn]

On Mon, Sep 24, 2012 at 3:56 PM, Eric Seidel  wrote:

> My understanding is that a name collision would only affect the
> ability of existing software to use the new Path.  It would not break
> existing software.  window.Path would just be aliased by the page, no?
>
>
Nope, if someone had  previously and accessed it as just
"Path", we'll break their page because now Path is this canvas object, not
the HTMLInputElement.

Intuitively I feel like using the ID of "Path" can't be that uncommon, and
accessing ids like this was fairly common in a number of apps and code
generators I've worked on...

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

Re: [webkit-dev] New Feature: Canvas Path object

[Elliott Sprehn]

On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze  wrote:

> Hi WebKit,
>
> I would like to ask if there are objections to implement the canvas Path
> object.
>
>
Do we have metrics on how often people already have things named Path? All
other canvas objects have a prefix like CanvasGradient and CanvasPattern,
this thing seems inconsistent and more likely to break existing pages.

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

[webkit-dev] Breaking cycles in mutation observers in JSC

[Elliott Sprehn]

I'm trying to fix the memory leaks in MutationObservers (
http://www.w3.org/TR/dom/#mutation-observers),
https://bugs.webkit.org/show_bug.cgi?id=93661

This is easy in V8 where I've put a hidden property on the MutationObserver
wrapper, and the V8MutationCallback object accesses this hidden property.
The MutationObserver is then an ActiveDOMObject which keeps the wrapper
alive as long as the observer has DOM nodes it's listening on, even if it's
unreachable from JS.

In the JSC side I'm not sure how to handle the cycle problem. Do I need to
use a JSC::Weak in JSMutationCallback and then use visitChildren on the
JSMutationObserver to call
addOpaqueRoot(thisObject->impl()->callback->jsValue) ?

In general if someone could explain visitChildren and
isReachableFromOpaqueRoots and when I want slotVistor.append or
addOpaqueRoot etc. it would be very helpful.

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

Re: [webkit-dev] PSA: removing CSS3_FLEXBOX define

[Elliott Sprehn]

On Sat, Aug 18, 2012 at 2:42 AM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> Nice, congratulations on getting this far! A lot of web developers are
> going to find flexbox extremely useful, and we should also not forget
> that it is even supported by IE10 (though prefixed with -ms-) now, so
> it will be good that people can also use it on WebKit based browsers
> soon.


Note that IE10's implementation is very different than the new spec.

http://msdn.microsoft.com/en-us/library/ie/hh673531(v=vs.85).aspx
http://dev.w3.org/csswg/css3-flexbox/

Even more bizarre they link to the deprecated flexbox spec:
http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/ but don't actually
implement it. :/

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

[webkit-dev] Proposal to remove list-item special counter

[Elliott Sprehn]

WebKit is the only browser that implements the magic counter named
"list-item" and we have no tests for it. This is from the CSS3 Lists module
(http://dev.w3.org/csswg/css3-lists/). This special counter was added back
in the initial implementation of CSS counters 6 years ago.

ex.

 li:before { content: "(" counter(list-item) ")"; } 


 
 

It's not useful since we don't support the ::marker psuedo element, nor
does any other browser. The above example outputs (2) since the implied
counter increment is on the list marker which we don't actually support. I
can't find references to this thing in Google outside the spec itself
either.

Can I remove this feature?

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

Re: [webkit-dev] New runtime setting: css3TextDecoration

[Elliott Sprehn]

I don't think editing code breaking when the page uses -webkit prefixed
properties should block launching a feature. The point of the vendor prefix
is to assert the instability of the feature.

This wouldn't be a regression, it's just a missing feature.

On Tue, Aug 14, 2012 at 3:22 PM, Ryosuke Niwa  wrote:

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

Re: [webkit-dev] Add support for CSS3 text-decoration* properties

[Elliott Sprehn]

On Tue, Jul 31, 2012 at 7:35 PM, Bruno Abinader wrote:

> Hi all :)
>
> As suggested by Ojan, I am writing a mail to you about my intention to
> implement all updated and missing text-decoration* properties from
> CSS3 spec (currently in development), named below:
>
> -webkit-text-decoration ( https://bugs.webkit.org/show_bug.cgi?id=92000 )
> CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration
> Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration
> Status: Proposed patch / pending review
>

It seems weird to have a prefixed version of text-decoration instead of
just making text-decoration allow the new prefixed keywords.

What's the reason for having a whole new prefixed property?

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

[Elliott Sprehn]

On Thu, Jul 26, 2012 at 3:45 PM, Alexandru Chiculita wrote:

> ...
> If CSSPseudoElement would be designed to derive from the same base class
> as Element and share most of their style/layout properties, then 99% of the
> time people will just do region.element.style.top = '100px'; and no query
> interface would be needed.
>
>
I brought this up in #webkit yesterday, but Adam Barth made a good point
that making CSSPseudoElement an Element means you could appendChild it
anywhere, or even append children to it which doesn't make sense.

You could make detaching a CSSPseudoElement or appending a child to it an
error (which is easy since that's centralized in WebKit), but it's a little
weird in the spec.

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

[webkit-dev] Feature Announcement: CSS3 intrinsic width keywords (min-content etc.)

[Elliott Sprehn]

I'm currently implementing the CSS3 writing mode spec intrinsic width
keywords:
http://dev.w3.org/csswg/css3-writing-modes/#intrinsic-sizing

Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=38919

Currently I'm only adding support for width to match the behavior of Gecko.
I'll move on to height once the spec is clarified on behavior. In
discussions with Tab Atkins it looks like we can make height:
fill-available provide sensible 100% height behavior to simplify page
layout for authors which will be really nice.

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