Re: [webkit-dev] A catalog of iOS-specific changes related to the WebThread

[Darin Fisher]

Thanks for the heads up!
-Darin


On Sun, Feb 10, 2013 at 1:53 PM, Maciej Stachowiak  wrote:

>
> Here is a list all iOS-specific changes in WebCore and below that are due
> to the iOS WebKit threading model, from an exhaustive review of diffs to
> the downstream source. I'm not sure anyone needs this to make a decision
> any more, but it may be helpful to people to know what's coming as we
> merge, and to provide input about specific items if they care to.
>
>
> Key:
> - Probably has to be upstreamed for the WebThread to work in the open
> source tree
> = Probably has to be upstreamed, but only affects files specific to the
> iOS port and/or the Mac port
> + Can likely be removed before upstreaming
> % Can probably be removed sooner than other differences (these things are
> needed for a non-WebKit use on the system which is likely to go away)
> ? I'm not sure what status this is
>
>
> In WTF:
> - Changing WTF::MainThread to recognize either the web thread of the main
> thread
> - Changes to ThreadRestrictionVerifier to deal with web thread vs main
> thread
> - Changing the assert in StringStatics.cpp to assert the true main thread,
> not isMainThread() (probably not strictly necessary)
> - Change the StackBounds consistency check to adapt to main thread vs Web
> thread (this is a class used by JSC for conservative stack scanning)
> - Sharing of the JSC identifier table (but no locking for that)
> % Locking and sharing for AtomicString (possibly removable; was added to
> avoid a crash on exit)
>
> In JSC, one change total:
> - A trick to avoid creating the GC timer on the wrong thread
>
> In WebCore:
> - In JSDOMWindowBase.cpp, arrange for JSC to handle the Web thread
> correctly
> - A change to get ThreadGlobalData to be the same on the web thread and
> the main thread
> - ScriptDebugServer.cpp, drop and reacquire the web thread lock around a
> nested run loop in ScriptDebugServer
> - The Web thread messages the main thread about some events via
> WKContentObservation
> = The actual implementation of the Web Thread and associated locking and
> messaging mechanisms
> = Not initializing threading in SharedBufferMac.mm +initialize (to avoid
> initializing on the wrong thread)
> = Not initializing threading in WebScriptObject.mm +initialize (to avoid
> initializing on the wrong thread)
> = The iOS implementation of SharedTimer operates on the WebThread run loop
> and messages the WebThread
> = Taking the Web thread lock in an iOS-specific accessibility
> implementation file
> = Locking around the ObjC DOM wrapper cache
> = Schedule CFNetwork callbacks on the Web thread runloop rather than the
> main runloop
> = The iOS tile cache implementation uses locking and messaging between the
> web thread and main thread much like the tile cache in the open source tree
> does it between the main thread and the scrolling thread
> = CALayer implementations sometimes grab the global lock and/or message to
> the WebThread from the main thread (affects WebLayer, PlatformCALayer, and
> a special layer that exists for text tracks)
> = An iBooks-specific workaround to target the main thread in
> LayerFlushSchedulerMac
> = Some messaging from the web thread to the main thread due to the weird
> way HTML5 video is implemented on iOS, in CA-specific files
> = WebCoreMotionManager (a new file that does not exist upstream) uses
> WebThread primitives
> + Some places that check isMainThread() || pthread_main_np(), which I
> expect will not be needed with the isMainThread() change and will likely be
> fixed before upstreaming; we're changing isMainThread() specifically to
> avoid sprinkling these diffs all over WebCore
> + In several places, avoid asserting m_thread == currentThread() (these
> diffs can probably be eliminated as by introducing an isCurrentThread()
> function)
> + An iOS-specific extra ASSERT in ThreadTimers.cpp (probably not needed)
> + Apparently obsolete includes of "WebCoreThread.h" in some files (e.g.
> TextBreakIteratorICU.cpp)
> + Apparently obsolete code to include "WebCoreThreadMessage.h" in some
> generated bindings (seems unused)
> + Apparently obsolete code to include "WebCoreThreadMessage.h" in some
> files (e.g. DOMHTML.mm)
> + An iOS-specific DiskImageCache in WebCore/loader uses threading in a
> non-portable way - it directly uses libdispatch and messages the WebThread.
> We can likely either remove it or rewrite it to do its threading in a more
> portable way.
> % A mutex in FontCache.cpp around access to the font cache (needed for a
> non-WebKit use of WebCore that's likely to be phased out a fair bit sooner
> than the Web thread)
> ? Make ScriptController::initializeThreading a no-op (no idea why this is
> needed)
> ? Make HTMLParserScheduler yield if it is at a yield candidate point and
> the main thread is waiting on the web thread lock (this was done long ago
> for responsiveness, but we need to retest)
> ? A mutex to guard creation and pausing of the database thread (I don't
> understand why th

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Darin Fisher]

On Fri, Feb 8, 2013 at 2:05 PM, Maciej Stachowiak  wrote:

>
> On Feb 8, 2013, at 1:41 PM, Adam Barth  wrote:
>
> > Context: https://bugs.webkit.org/show_bug.cgi?id=109071
> >
> > Adam Barth said:
> >> It's not clear to me that running WebCore on multiple interlocked
> threads is a good idea.  That
> >> seems like a pretty major change to WebCore's architecture.  Is that
> something that's up for
> >> discussion?
> >
> > Darin Adler said:
> >> I agree that it’s not something I’d do if I was starting a project now.
> >>
> >> In the iOS context, it’s fantastic for discussion as a possibly
> multi-year major architecture
> >> change, but if we take a hard line on this, then we won’t have the iOS
> port in the tree for
> >> years, and I think it would be good if we do. iOS WebKit has worked
> this way for the entire
> >> history of iPhone, so it’s not a change that can be made easily.
> >
> > Darin Adler also said:
> >> I think where you and I may differ is on whether a good solution to the
> problem would be
> >> valuable to the WebKit project. Is there some way I convince you of the
> value of fitting
> >> an important existing port of WebKit into our tree in as clean as
> possible a way?
> >
> > I don't really know how to respond to this thread.  I feel like I'm
> > being offered the following choice:
> >
> > 1) Give up the ability to have technical input to how WebCore works
> > and simply accept all the design choices made in the iOS fork, whether
> > they be good choices or bad.
> >
> > 2) Keep the iOS port in an Apple-internal fork for a number of years.
> >
> > I feel like I'm being asked to make this choice in the context of a
> > growing trend of unilateral action by Apple in this project.  Given
> > that trend, I don't see how I can choose option (1).
> >
> > As much as I would like the iOS port merged into trunk, I'm not
> > willing to give up having a technical say in the project.  Therefore,
> > reluctantly, I'm forced to choose option (2).
>
> If we'd taken an equally hard line when Google wanted to merge the
> Chromium port to trunk, with a number of design choices in place that we
> didn't agree with but which were hard to change, it probably still wouldn't
> be in the tree to this day. I don't think that would have been a good thing
> for the WebKit project.
>

I think this is a bit different.

For the Chromium port, we started out with the assumption that we couldn't
easily change much about the architecture of WebCore.  Instead, we tried to
make Chromium match the set of constraints imposed on WebCore by WebKit,
CFNetwork, CoreGraphics and more recently CoreAnimation.

This led to things like hiding the details of the out-of-process network
stack behind ResourceHandle.  We did so because we assumed that it would
make our port less of a burden to others.



>
> I am curious how others feel about the value of merging the iOS port back
> to trunk as soon as possible, vs. the need to fix all of the past design
> decisions in this port that may be disputed.
>

I think it is valuable to upstream the iOS port.  I'm sad that it has not
happened sooner.  Many times, the architecture of the iOS port has been
used as justification by Apple engineers for why WebCore should work a
certain way.  It is often not obvious from the open source code that such
constraints exist.  Having the code in the open would seem to help with
such issues.

I would recommend minimizing the re-architecture of WebCore as you are in
the early stages of upstreaming.  It seems like you already have a working
port that you could simply upstream.  You could then work with others in
the community to introduce new concepts to WebCore with the full disclosure
of code as an aide to the process.  Another option might be to open source
the entire thing as a branch somewhere.

After the initial upstreaming or sharing of code is complete, you could
then catalog all of the warts.  The fact that isMainThread returns true
when called on more than one thread would be one such wart.  I can imagine
a meta bug tracking all of these warts.  This would make it a lot easier
for others to understand the overall change in direction needed for WebKit
to properly support the iOS port.

Hope this helps!
-Darin



>
> Regards,
> Maciej
>
>
> ___
> 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] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Darin Fisher]

On Sat, Feb 2, 2013 at 4:16 PM, James Robinson  wrote:

>
>
> On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen  wrote:
>
>> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>>
>>>
>>> It would be nice if, in the shared library build of chromium, webcore
>>> and perhaps the modules and platform were separate DLLs.
>>>
>>>
>> The shared library build is kind of a developer build, right? In this
>> case I believe you can solve this by setting the default visibility to
>> public at compiler/linker level, no need for exports.
>>
>
> That doesn't work on windows.
>
>
Right.

Yes, the shared library build of Chromium is a developer-only build mode.
 It is helpful to split the project up into separate DLLs to reduce build
times and to help enforce correct dependencies between modules.

-Darin



> - James
>
>
>>
>> -kbalazs
>>
>> __**_
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/**mailman/listinfo/webkit-dev<https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> 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] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Darin Fisher]

It would be nice if, in the shared library build of chromium, webcore and
perhaps the modules and platform were separate DLLs.
On Jan 31, 2013 4:15 PM, "Eric Seidel"  wrote:

> I believe that it's a design mistake for WebCore to need to know
> anything about it's embedder, more than that there is a defined set of
> platform APIs and callbacks which it talks to (which should be the
> exact same for every embedder).
>
> (The export dependency dates back to the WebCore/WebKit separation,
> which in my recollection was done largely to be able to isolate LGPL
> code from the non-LGPL Mac WebKit layer.)
>
> But I believe it is a mistake that WebCore changes need to care about
> the possibility that different ports may export functions differently,
> or even worse, that different ports may need a different set of
> functions exported.
>
> I don't recommend using a more complicated export macro, but rather
> finding ways that WebCore doesn't need to care about diverging sets of
> exports.
>
> I believe most ports (with the exception of AppleWin/AppleMac) do not
> build WebCore as a separate dynamic library from WebKit, which makes
> exports a non-concern in the static case.
>
> In my perfect future world, WebCore would be split into many static
> libraries, and core-code -> WebKit exports would be a non-issue.  And
> of course, no embedder of core-code would ever expose core types, so
> no exports would ever need to be marked.
>
>
> On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov 
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke  написал(а):
> >
> >>> I don't have concrete examples, and I don't know how big an effect on
> performance increasing the number of exports would have. It's something to
> keep an eye on, not a reason to avoid trying.
> >>
> >> I'm not parsing your reply properly -- avoid trying what? A common
> >> EXPORT macro that is set as appropriate by each port?
> >
> > Yes, you are parsing it correctly :)
> >
> > - WBR, Alexey Proskuryakov
> >
> >
> > ___
> > 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] Stream API

[Darin Fisher]

Has anyone reviewed the Stream API proposal from Microsoft?

Here's the spec:
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

I see only a little mention of it on webapps-public:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1494.html

(I haven't looked over the proceedings from TPAC.)

Thoughts on this API?

My take:  It seems useful to have a variant of Blob that supports data of
unknown length.  It seems a bit unfortunate to have StreamReader and
FileReader, which are so similar.  StreamBuilder seems like it may be
unnecessary given that it does not support appending Streams.  It seems
like providing a way to get a Stream from a Blob would be sufficient, or if
we could just pass Blobs to any API that takes a Stream, then we wouldn't
need StreamBuilder.  That is, Blobs should really just be Streams of known
length.

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

Re: [webkit-dev] Unprefixing requestAnimationFrame

[Darin Fisher]

I agree with what Adam wrote in
https://bugs.webkit.org/show_bug.cgi?id=99116#c5.  Even if a lot of sites
will magically failover to the unprefixed API, we can't know for sure that
this change won't break sites.  We need to give them a chance to update.
 (I don't know if one Chrome release cycle will be enough.)

Why not be conservative here?

-Darin


On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen wrote:

> I've posted a patch to remove the "webkit" prefix from
> requestAnimationFrame. [1] The question is whether or not to continue to
> support the prefixed version. I propose dropping it for the following
> reasons:
>
> 1. We're changing the callback semantics to match the spec. [2]
>
> 2. IE10 is shipping with this unprefixed. [3]
>
> 3. Toolkits already use the unprefixed version. [4]
>
> 4. The advice on the internet recommends everyone use the polyfill
> technique. [5]
>
> I'm curious what everyone else thinks.
>
> James
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=99116
> [2] https://bugs.webkit.org/show_bug.cgi?id=66683
> [3] http://caniuse.com/#feat=requestanimationframe
> [4] https://gist.github.com/1579671
> [5]
> https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame
>
> ___
> 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] Removing webkitSlice (was Re: Existing metrics for deprecated features)

[Darin Fisher]

On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth  wrote:

> On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth  wrote:
> > Another metric we have is for Blob.webkitSlice:
> >
> > Ratio of Blob.webkitSlice calls to Blob.slice: 14.87%
> > Ratio of Blob.webkitSlice calls to Document creation: 0.0053%
> >
> > It's difficult to know how to interpret this data because we don't
> > actually correlate calls to webkitSlice with Documents or Pages.
> > Instead, we just count the total number of calls across all Documents.
> >  This gives us an upper bound on how many Documents (or Pages) would
> > be affected by deleting Blob.webkitSlice, but doesn't measure that
> > information as accurately as the data we have for mutation events.
>
> Based on this data, I've posted a patch for removing Blob.webkitSlice
> in favor of Blob.slice:
>
> https://bugs.webkit.org/show_bug.cgi?id=96715
>
> Adam


So, worst case 53 out of a million pages calls webkitSlice.  But, it is
easy to imagine that that upper bound is crazy high, and more likely a
couple pages simply call webkitSlice a lot.  Also, given that there are so
many more calls to Blob.slice() one could imagine that sites that call
webkitSlice probably have fallback to Blob.slice().  Is this the hypothesis?

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

Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?

[Darin Fisher]

Thanks for collecting and sharing this data.  It'll be interesting to see
how this evolves over time.
-Darin

On Sun, Aug 12, 2012 at 7:43 PM, Kinuko Yasuda  wrote:

> As a quick follow-up, in Chrome 21 the usage histogram tells ~80% of slice
> call is still using webkitSlice (no wonder as unprefixed slice was rolled
> out just half a month ago).  Since we started showing a deprecation message
> I hope the number changes over time.
>
>   slice usage: 22.61%
> webkitSlice usage: 77.39%
>
>
>
> On Mon, Jun 11, 2012 at 3:55 PM, Kinuko Yasuda wrote:
>
>> On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher  wrote:
>>
>>> Happy to see us support unprefixed too.  With other vendors on board, it
>>> seems like a straightforward addition to the platform.
>>>
>>> I'm not sure if you are proposing to also remove the prefixed form.  I'm
>>> not sure what it would take to remove the prefixed version.  We'd need some
>>> way to know when it is safe to remove it.  We could surely instrument the
>>> code to measure its use relative to the unprefixed form once it is widely
>>> deployed.
>>>
>>
>> We've been shipping the prefixed version for a year now (in Chrome 11-19
>> and in Safari 5), so I propose keeping the prefixed version too for now,
>> but to start showing a deprecation message to encourage migration.
>>
>> -Darin
>>>
>>>
>>> On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda wrote:
>>>
>>>> Hi WebKit folks,
>>>>
>>>> We've been vendor-prefixing Blob.slice() since we changed the semantics
>>>> of slice() to make it alike Array.slice, i.e. from "start, length" to
>>>> "start, end" semantics in r83873 [1].  The non-prefixed version had only
>>>> been shipped in Chrome and must have helped apps migrate into the new
>>>> semantics.
>>>> However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2],
>>>> Opera said they are going to unprefix it with the new semantics [3] and IE
>>>> compatibility test has a set of Blob.slice tests which require unprefixed
>>>> slice [4].
>>>>
>>>> Maybe it's becoming a good time to unprefix slice() again?
>>>> https://bugs.webkit.org/show_bug.cgi?id=78111
>>>>
>>>> [1] http://trac.webkit.org/changeset/83873
>>>> [2]
>>>> https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations
>>>> [3] https://bugs.webkit.org/show_bug.cgi?id=78111
>>>> [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi
>>>>
>>>> Kinuko
>>>>
>>>>
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Darin Fisher]

https://developer.mozilla.org/en/XmlHttpRequest#Non-standard_propertiessays
that elevated privileges are required to access mozBackgroundRequest.
 That suggests that it is only there for use by Firefox and Firefox
extensions.

At the very least, it seems like in Chromium, if we cannot suppress auth
prompts generated from XHR in all cases, we could / should at least
suppress them for XHR requests made by extensions.

Regards,
-Darin


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] 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] Updates on Chromium's content_shell

[Darin Fisher]

On Mon, Jul 16, 2012 at 2:57 AM, Jochen Eisinger wrote:

>
>
>
> On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher  wrote:
>
>>
>>
>> On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth  wrote:
>>
>>> Yeah, EventSender is likely a good place to start.  Here are some more
>>> details about what I had in mind:
>>>
>>> 1) We'll need to create a new target that builds a TestRunner.a (or
>>> LayoutTestController.a, whatever name is currently in fashion).  This
>>> target is allowed to depend on WTF, WebKit (via the WebKit API), and
>>> probably webkit_support.
>>>
>>> 2) This target will contain LayoutTestController.cpp, EventSender.cpp,
>>> and all the other code that's needed to support the objects we inject when
>>> running LayoutTests.
>>>
>>> 3) To move code into this target, we'll need to abstract any
>>> dependencies on the rest of DumpRenderTree into a delegate interface.  For
>>> example, EventSender has a #include "TestShell.h", which we'll need to
>>> remove.  Today, EventSender gets the WebView is by asking m_shell for it.
>>>  Instead, it will need to ask the delegate.
>>>
>>> One of the trickier things in this project will be WebViewHost.
>>>  TestRunner.a will need some object like that to subclass a bunch of WebKit
>>> API clients, but the design might need to change a bit.  I haven't studied
>>> it carefully yet.
>>>
>>
>> TestRunner.a could just provide the WebViewClient and WebFrameClient
>> implementations.  The delegate you mention could just be a createWebView
>> function.
>>
>> When Jochen and I discussed this topic before, I suggested just adding
>> CreateWebView to webkit_support, but as a delegate function seems even
>> better.  We'd probably like to minimize dependencies on webkit_support
>> since that is Chromium specific.
>>
>
> I think these are two separate issues: one is reusing the bindings for the
> test objects. This is what creating a TestRunner library would achieve. The
> other is to create the webkit objects without too egregious layering
> violations. This is a yet to solve problem :)
>
>
Agreed.



>
>
>>
>> -Darin
>>
>>
>>
>>
>>>
>>> Once this is done, but DumpRenderTree and ContentShell can link
>>> in TestRunner.a and implement the delegate.  Hopefully the bulk of the
>>> interactions will be between TestRunner.a and the WebKit API so that the
>>> delegate will mostly be able providing the WebView and getting out of the
>>> way.
>>>
>>> Adam
>>>
>>>
>>> On Fri, Jul 13, 2012 at 1:56 PM, Jochen Eisinger wrote:
>>>
>>>> What about keeping the discussion here, so others that might want to
>>>> join the effort later can read it up?
>>>>
>>>> In general, I agree with your proposal. I guess starting with something
>>>> small like EventSender might be a good first step.
>>>>
>>>> best
>>>> -jochen
>>>>
>>>>
>>>> On Fri, Jul 13, 2012 at 10:20 PM, Adam Barth  wrote:
>>>>
>>>>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger 
>>>>> wrote:
>>>>>
>>>>>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa wrote:
>>>>>>
>>>>>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger <
>>>>>>> joc...@chromium.org> wrote:
>>>>>>>
>>>>>>>> I wanted to share some updates about content_shell (a
>>>>>>>> multi-processed version of chromium's test shell): meanwhile, it is
>>>>>>>> possible to generate pixel results.
>>>>>>>>
>>>>>>>> Out of 31431 tests that are executed on chromium-linux, 6234 did
>>>>>>>> not match the expected results using content_shell, all others passed
>>>>>>>> (80.17%)!
>>>>>>>>
>>>>>>>
>>>>>>> This is a great news! Thanks a lot for working on this effort. Let
>>>>>>> us know if you needed a help in implementing testRunner methods.
>>>>>>>
>>>>>>
>>>>>> At this point, there are two things I could use help with: in
>>>>>> general, moving methods to window.internals (and addressing the current
>>>>>> shortcomings of that approach) helps a lot, a

Re: [webkit-dev] Updates on Chromium's content_shell

[Darin Fisher]

On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth  wrote:

> Yeah, EventSender is likely a good place to start.  Here are some more
> details about what I had in mind:
>
> 1) We'll need to create a new target that builds a TestRunner.a (or
> LayoutTestController.a, whatever name is currently in fashion).  This
> target is allowed to depend on WTF, WebKit (via the WebKit API), and
> probably webkit_support.
>
> 2) This target will contain LayoutTestController.cpp, EventSender.cpp, and
> all the other code that's needed to support the objects we inject when
> running LayoutTests.
>
> 3) To move code into this target, we'll need to abstract any dependencies
> on the rest of DumpRenderTree into a delegate interface.  For example,
> EventSender has a #include "TestShell.h", which we'll need to remove.
>  Today, EventSender gets the WebView is by asking m_shell for it.  Instead,
> it will need to ask the delegate.
>
> One of the trickier things in this project will be WebViewHost.
>  TestRunner.a will need some object like that to subclass a bunch of WebKit
> API clients, but the design might need to change a bit.  I haven't studied
> it carefully yet.
>

TestRunner.a could just provide the WebViewClient and WebFrameClient
implementations.  The delegate you mention could just be a createWebView
function.

When Jochen and I discussed this topic before, I suggested just adding
CreateWebView to webkit_support, but as a delegate function seems even
better.  We'd probably like to minimize dependencies on webkit_support
since that is Chromium specific.

-Darin




>
> Once this is done, but DumpRenderTree and ContentShell can link
> in TestRunner.a and implement the delegate.  Hopefully the bulk of the
> interactions will be between TestRunner.a and the WebKit API so that the
> delegate will mostly be able providing the WebView and getting out of the
> way.
>
> Adam
>
>
> On Fri, Jul 13, 2012 at 1:56 PM, Jochen Eisinger wrote:
>
>> What about keeping the discussion here, so others that might want to join
>> the effort later can read it up?
>>
>> In general, I agree with your proposal. I guess starting with something
>> small like EventSender might be a good first step.
>>
>> best
>> -jochen
>>
>>
>> On Fri, Jul 13, 2012 at 10:20 PM, Adam Barth  wrote:
>>
>>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger wrote:
>>>
 On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa  wrote:

> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger 
> wrote:
>
>> I wanted to share some updates about content_shell (a multi-processed
>> version of chromium's test shell): meanwhile, it is possible to generate
>> pixel results.
>>
>> Out of 31431 tests that are executed on chromium-linux, 6234 did not
>> match the expected results using content_shell, all others passed 
>> (80.17%)!
>>
>
> This is a great news! Thanks a lot for working on this effort. Let us
> know if you needed a help in implementing testRunner methods.
>

 At this point, there are two things I could use help with: in general,
 moving methods to window.internals (and addressing the current shortcomings
 of that approach) helps a lot, as I can just instantiate this object in
 content_shell.

 The other thing is to work towards making layoutTestController (of
 chromium's DRT) a library.

 Adam mentioned a while ago that he'd be interested with helping with
 the latter as well

>>>
>>> Yes.  The idea is to implement LayoutTestController in terms of the
>>> WebKit API and a (hopefully simple) delegate.
>>>  Currently LayoutTestController knows too much about DumpRenderTree.  That
>>> will let us share the implementation of LayoutTestController and avoid
>>> having to maintain yet another copy.
>>>
>>> Upstreaming the chromium-android port is at the top of my priority list,
>>> but I should be able to help out with this work as well.  Should we talk
>>> off-list about how to approach this work?
>>>
>>> Adam
>>>
>>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Web APIs and class name collisions

[Darin Fisher]

On Fri, Jul 13, 2012 at 10:59 AM, Eric Seidel  wrote:

> 
>
> Just like we don't call the class DOMDocument, there is no need to add
> the CSS prefix where there aren't collisions (IMO).
>
> I do think we should drop the "WebKit" prefix from all classes, and
> use InterfaceName= the .idl to map from "InternalName" to
> "WebKitExternalName".
>
>
^^^ yes, please :-)

/me crawls back into his hole.



> http://trac.webkit.org/wiki/WebKitIDL#InterfaceName
>
> 
>
> On Fri, Jul 13, 2012 at 7:17 AM, Andrei Bucur  wrote:
> > CSSRegion is it then! I'll also make a patch to rename WebKitNamedFlow
> > into CSSNamedFlow.
> >
> > Thx!
> > Andrei.
> >
> > On 7/12/12 10:37 PM, "Alexis Menard" 
> wrote:
> >
> >>So far in the css/ directory we tried to renamed slowly classes so that :
> >>
> >>CSS* prefixed classes are the implementation of CSSOM
> >>"whatevername" is for internal classes. For example we renamed
> >>CSSStyleApplyProperty class to StyleBuilder because it's internal.
> >>
> >>Hope that helps.
> >>
> >>On Thu, Jul 12, 2012 at 2:52 PM, Simon Fraser 
> >>wrote:
> >>> I'd prefer we keep "Region" for the low-level graphics primitive Region
> >>> (just like Path), and use something prefixed for the higher-level
> layout
> >>> concept.
> >>>
> >>> Simon
> >>>
> >>> On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote:
> >>>
> >>> On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa 
> wrote:
> 
>  I'd vote for CSSRegion or CSSOMRegion for the class you're adding but
> I'll
>  also suggest we rename the existing Region class now that the term
> "region"
>  has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion?
> >>>
> >>> IntRegion? It seems closer to an IntRect than a LayoutRect.
> 
>  - Ryosuke
> 
>  On Jul 12, 2012 10:13 AM, "Eric Seidel"  wrote:
> >
> > I would go with CSSRegion, and stick it in the css/ folder.  Much of
> > the CSS folder is our implementation of the CSS Object Model (CSSOM).
> > At some point it might make sense to pull all the classes which
> > implement the CSSOM out of css/ into a new cssom/ similar to dom/,
> but
> > that's a later discussion.
> >
> > -eric
> >
> > On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur 
> >wrote:
> > > From my knowledge the "CSS" prefix is reserved for the CSS engine
> > > classes in
> > > WebKit. Prefixing the Region class with "CSS" could prove
> confusing.
> > >
> > > Regards,
> > > Andrei.
> > >
> > > From: Alan Stearns 
> > > Date: Thursday, July 12, 2012 7:39 PM
> > > To: Adam Barth , Andrei Bucur  >
> > >
> > > Cc: "webkit-dev@lists.webkit.org" 
> > > Subject: Re: [webkit-dev] Web APIs and class name collisions
> > >
> > > The spec itself consistently and deliberately calls them "CSS
> >Regions,"
> > > so a
> > > CSS prefix could be appropriate.
> > >
> > > Thanks,
> > >
> > > Alan
> > >
> > >
> > > From: Adam Barth 
> > > To: Andrei Bucur 
> > > Cc: "webkit-dev@lists.webkit.org" 
> > > Subject: Re: [webkit-dev] Web APIs and class name collisions
> > >
> > > One common thing we do is prefix "DOM" to DOM-level concepts.  For
> > > example,
> > > DOMWindow and DOMFileSystem.  I'm not sure if we have an
> established
> > > convention for CSS-level concepts.
> > >
> > > Adam
> > >
> > >
> > > On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur 
> >wrote:
> > >>
> > >> Hello Webkittens!
> > >>
> > >> While implementing the Region interface (
> > >> http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've
> > >> noticed
> > >> that the name "Region" is already taken by a class in
> > >> platform/graphics. I'd
> > >> like to know what's the best approach in these kind of situations:
> > >>
> > >> Rename the existing WebCore class to something else and use the
> >name
> > >> "Region" for the Web API so there's parity between the
> >implementation
> > >> and
> > >> the spec
> > >> Somehow prefix the Web API implementation class name?
> > >>
> > >> As the Web APIs expand I suppose this situation may occur again in
> >the
> > >> future and I suppose there should be a rule describing what's the
> >best
> > >> approach to take.
> > >>
> > >> Thanks!
> > >> Andrei.
> > >>
> > >> ___
> > >> 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
> > ht

Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?

[Darin Fisher]

Happy to see us support unprefixed too.  With other vendors on board, it
seems like a straightforward addition to the platform.

I'm not sure if you are proposing to also remove the prefixed form.  I'm
not sure what it would take to remove the prefixed version.  We'd need some
way to know when it is safe to remove it.  We could surely instrument the
code to measure its use relative to the unprefixed form once it is widely
deployed.

-Darin


On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda  wrote:

> Hi WebKit folks,
>
> We've been vendor-prefixing Blob.slice() since we changed the semantics of
> slice() to make it alike Array.slice, i.e. from "start, length" to "start,
> end" semantics in r83873 [1].  The non-prefixed version had only been
> shipped in Chrome and must have helped apps migrate into the new semantics.
> However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera
> said they are going to unprefix it with the new semantics [3] and IE
> compatibility test has a set of Blob.slice tests which require unprefixed
> slice [4].
>
> Maybe it's becoming a good time to unprefix slice() again?
> https://bugs.webkit.org/show_bug.cgi?id=78111
>
> [1] http://trac.webkit.org/changeset/83873
> [2]
> https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations
> [3] https://bugs.webkit.org/show_bug.cgi?id=78111
> [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi
>
> Kinuko
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

[Darin Fisher]

On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote:

>
>
> On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa  wrote:
>
>> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger wrote:
>>
>>> I've implemented initial support for running layout tests using
>>> chromium's content_shell instead of test_shell as the current DRT
>>> implementation does. It's still a very experimental, but might already be
>>> interesting for some of you to try.
>>>
>>
>> This is great! Thanks a lot on working this.
>>
>> 1. Make sure your WebKit is at least at r119852 (see
>>> http://trac.webkit.org/wiki/Chromium for prerequisites)
>>> 2. Apply the attachment from
>>> https://bugs.webkit.org/show_bug.cgi?id=87045
>>> 3. In Source/WebKit/chromium run gclient sync
>>> 4. build webkit as usual
>>>
>>> E.g. for a debug build on Linux, this should give you
>>> out/Debug/content_shell
>>>
>>> You can now run layout tests like this:
>>>
>>> new-run-webkit-tests --chromium --debug --driver-name=content_shell
>>> --additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/*
>>>
>>> You'll notice that not all tests are passing yet, mainly because not all
>>> (or actually, almost none of the) layoutTestController features are
>>> implemented yet.
>>>
>>
>>  Where is layoutTestController implemented? We definitely need to move
>> the implementation of layoutTestController, eventSender, etc... into WebKit
>> repository because we often rename functions, etc... in WebKit. It's
>> unacceptable to require having to modify Chromium code in order to do this
>> refactoring in the future.
>>
>
> It's currently here:
> http://code.google.com/searchframe#OAMlx_jo-ck/src/content/shell/layout_test_controller.js&exact_package=chromium
>
> Per my other thread about sharing IDLs between DumpRenderTree and
>> WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
>> instead of adding yet another binding code.
>>
>> Another missing feature is producing pixel results. However, I'm
>>> currently concentrating on text results, as I think the biggest benefit is
>>> the ability to run storage tests on the real storage implementation.
>>>
>>
>> That sounds great to me but we definitely need to support pixel results
>> eventually. I'm more than happy to help you on that but that requires the
>> codebase to be moved into WebKit repository.
>>
>
> Here's the basic problem: content_shell depends on content, so moving this
> on the webkit repository would mean that webkit depended on content.
>
> Another solution would be to formalize the test shell API our current
> layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and
> add a method to chromium's webkit support library that returns a webview
> that supports all the hooks required. The webview could then either be
> implemented by test_shell or by content_shell
>
>
^^^ This second solution seems like it will work well.  It will enable the
guts of layoutTestController to remain in the WebKit repository.  This is
just a variation of exactly what we do today.  You only need to move
creation of WebView to Chromium so that we can eliminate WebViewHost.cpp
(and other "simple" application shell bits).

-Darin



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

Re: [webkit-dev] Adding archive.org-based page loading time performance tests

[Darin Fisher]

On Sun, Apr 29, 2012 at 3:44 PM, Ryosuke Niwa  wrote:

> On Fri, Apr 27, 2012 at 1:49 AM, Nat Duca  wrote:
>
>> I'm concerned at how well this would work graphics performance tests.
>>
>> Consider:
>> http://web.archive.org/web/20110111083848/http://techcrunch.com/
>>
>> http://web.archive.org/web/20110222032916/http://www.nytimes.com/
>>
>>
>> http://web.archive.org/web/20110429194113/http://www.thewildernessdowntown.com/
>>
>> What do we do for the cases where archive.org is getting bad/incomplete
>> ... erm, archives?
>>
> There's no fix to it. If archive.org doesn't work, then we need to pull
> data directly from the website. We can do that. The infrastructure I'm
> developing is agnostic of whether we use archive.org or not. However,
> pulling data directly from websites will make the test suite behave
> differently depending on when you run the test so the test suite can't be
> open that way.
>
>
Does it matter if the page contents are bad/incomplete?  It seems like all
that matters is that they are consistent from pull-to-pull and somewhat
representative of pages we'd care to optimize.  Is the concern that those
URLs are missing too much content to be useful?

Note: The page cyclers used by Chromium all have data sets that are
bad/incomplete.  This was intentional.  For example, if a subresource was
not available for whatever reason, then the request to fetch it was
neutered (e.g., all "http" substrings were replaced with "httpdisabled").

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

Re: [webkit-dev] (no subject)

[Darin Fisher]

On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa  wrote:

> On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak  wrote:
>
>>
>> On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa  wrote:
>>
>> On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak wrote:
>>
>>> On Apr 29, 2012, at 11:01 AM, Adam Barth  wrote:
>>>
>>> I read , but I'm
>>> still unsure how to proceed with removing webkitPostMessage and
>>> aligning postMessage with the spec.  No one responded to my earlier
>>> message, so I'm inclined to just post a patch.
>>>
>>> Comparing your post to the recommended steps on that page (the page
>>> says the same steps should be applied to removing only the prefixed version
>>> of a feature):
>>>
>>> It looks like you did this:
>>>
>>>- Any deprecation should be sent to webkit-dev for discussion.
>>>
>>> It doesn't look like you did any of these yet:
>>>
>>>- Any deprecation requires some data as to why the feature can be
>>>deprecated. The goal of the data is to show that the feature is not 
>>> widely
>>>used and is not popular. The following would qualify:
>>>   - usage statistics in the wild (either by instrumenting the
>>>   browser or any other means).
>>>   - some discussions on the standard mailing lists underlining that
>>>   the standards' bodies don't think there is enough traction to get the
>>>   feature standardized.
>>>   - some proof that there is others way to achieve the same result
>>>   that are better.
>>>
>>> It appears to me that the the unprefixed version will be a better
>> alternative in this case since the websites can just use the same API on
>> all spec-compliant browsers if ArrayBuffer is supported in the unprefixed
>> version.
>>
>> Is there evidence that authors are either not using the prefixed version
>> or are highly willing to migrate? I ask because another part of the policy
>> says:
>>
>> "The burden on the overall project needs to be evaluated as it should be
>> the primary driver for dropping any feature. Small features that require
>> very little maintenance may not qualify under this rule and their
>> deprecation would need to be argued extensively."
>>
>> This implies to me that the burden of proof is higher for
>> lower-maintenance-cost features (which I imagine applies to a prefixed
>> method that also exists in unprefixed form).
>>
>>  I'm not necessarily saying that lots of evidence is required in this
>> case. But we can use this instance as a test case to adjust the policy.
>>
>
> I'm actually curious as to how the session participants reached
> this consensus (probably on a separate thread). It seems like the bar
> shouldn't too high for removing prefixed APIs when they are unprefixed
> equivalents because I'm certain web developers want to use the ones that
> work on all browsers instead of just on WebKit.
>
>
The discussion went like this:

It is good to remove vendor prefixed features in favor of their
standardized, unprefixed forms.

However, the process for removing a vendor prefixed feature is the same as
the process for removing any feature.  In both cases, we care about the
impact to users of WebKit-based products.  The vendor prefix just provides
motivation for wanting to remove a feature.  It doesn't necessarily make it
any easier to remove a feature.

Just as we announce feature addition on webkit-dev, I think it is a good
idea to announce feature removal on webkit-dev.

-- If we have data to indicate that a feature is nearly unused, then
removing the feature straight-away seems good.  We can learn quickly if we
made a mistake.

-- If we have data to indicate that a feature is somewhat used, then we can
still deprecate it, but we probably need to take our time, complain in the
JS console about deprecated API usage for some time, and then remove the
feature from trunk and see who complains.

-- If we have data to indicate that a feature is highly used, then perhaps
we are stuck with the feature.  We may have some hard discussions here if
someone is truly motivated to remove such a feature.

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

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Darin Fisher]

On Mon, Apr 16, 2012 at 3:34 PM, Maciej Stachowiak  wrote:

>
> On Apr 16, 2012, at 1:44 PM, Darin Fisher wrote:
>
> On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt  wrote:
>
>>
>> On Apr 16, 2012, at 1:00 PM, Darin Fisher  wrote:
>>
>> On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak wrote:
>>
>>>
>>> On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
>>>
>>> Could this be an opportunity to design an asynchronous API for fetching
>>> the pixel buffer?  It seems like many implementations are GPU backed now,
>>> and fetching the pixel buffer is an expensive (blocking) operation.  Had
>>> you considered making such a change?
>>>
>>>
>>> Adding async support was suggested on the whatwg thread about this. I
>>> think async support is useful, but should not be tied to high DPI support.
>>> In particular, we shouldn't, in my opinion, require authors to rewrite
>>> their existing sync code to an async model just to properly support higher
>>> resolutions.
>>>
>>> In addition, the whatwg thread revealed that there are many hidden
>>> complexities in the design of get/putImageData, in particular designing how
>>> they work in the face of sychronous drawing operations to the same canvas.
>>> The HiDPI problem is much more straightforward and does not need to be
>>> gated on resolving the async design issues.
>>>
>>>
>> I think you are giving up a good opportunity.  The barriers to an async
>> API are more readily overcome when there are extra benefits to developers.
>>  HiDPI could be a great way to attract developers to a better API.
>>
>> I've addressed those other concerns on the WhatWG thread.
>>
>>
>> No, gating HiDPI on rewriting your code into a more complex, and
>> generally slower model seems like a great way to encourage developers to
>> ignore high dpi.
>>
>> --Oliver
>>
>>
> I'm not sure why developers would choose to ignore HiDPI.  It seems like
> it helps their apps/pages look better!
>
> You really feel like you need to "kowtow" to developers to get them to
> adopt HiDPI?
>
>
> Different developers will have different priorities. HD image data and
> async readback both have potential benefits in image quality and
> nonblocking responsiveness respectively. Here is an example of an
> application using getImageData which would clearly benefit from HD, but
> it's not obvious that async would be useful:
>
> http://mudcu.be/sketchpad/
>
> Here is another where HD helps but benefits of async are unclear, since it
> does a pixel read-write-modify cycle:
>
> http://nerget.com/pressure/pressure.html
>
> Tying HD to async may hurt the adoption of both by requiring developers to
> take two different code change hits when they only care about one. In
> particular, the async change is likely to be more invasive to code
> structure.  If developers are discouraged, they may end up using neither.
> Thus, in my opinion, these two enhancements to ImageData should stand and
> fall on their own merits.
>
>
Hi Maciej,

I was thinking that an asynchronous version of getImageData could be used
to fetch either the HD or non-HD backing.

At any rate, it seems like my motivation is clear.  Blocking getImageData
is a performance penalty for implementations that use deferred rendering.
 If not a penalty for the caller, then surely a penalty for other pages
that may share the same thread.  Making such an API return even larger
amounts of memory seems like it only increases the penalty.

I understand your desire to separate these concerns.  I'm just worried that
we are missing an opportunity to guide developers to a better place.

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

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Darin Fisher]

On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt  wrote:

>
> On Apr 16, 2012, at 1:00 PM, Darin Fisher  wrote:
>
> On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak  wrote:
>
>>
>> On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
>>
>> Could this be an opportunity to design an asynchronous API for fetching
>> the pixel buffer?  It seems like many implementations are GPU backed now,
>> and fetching the pixel buffer is an expensive (blocking) operation.  Had
>> you considered making such a change?
>>
>>
>> Adding async support was suggested on the whatwg thread about this. I
>> think async support is useful, but should not be tied to high DPI support.
>> In particular, we shouldn't, in my opinion, require authors to rewrite
>> their existing sync code to an async model just to properly support higher
>> resolutions.
>>
>> In addition, the whatwg thread revealed that there are many hidden
>> complexities in the design of get/putImageData, in particular designing how
>> they work in the face of sychronous drawing operations to the same canvas.
>> The HiDPI problem is much more straightforward and does not need to be
>> gated on resolving the async design issues.
>>
>>
> I think you are giving up a good opportunity.  The barriers to an async
> API are more readily overcome when there are extra benefits to developers.
>  HiDPI could be a great way to attract developers to a better API.
>
> I've addressed those other concerns on the WhatWG thread.
>
>
> No, gating HiDPI on rewriting your code into a more complex, and generally
> slower model seems like a great way to encourage developers to ignore high
> dpi.
>
> --Oliver
>
>
I'm not sure why developers would choose to ignore HiDPI.  It seems like it
helps their apps/pages look better!

You really feel like you need to "kowtow" to developers to get them to
adopt HiDPI?

-Darin



>
> -Darin
>
>
>
>>
>> Regards,
>> -Darin
>>
>>
>>
>> On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein  wrote:
>>
>>> [This is actually an enhancement announcement to an existing feature]
>>>
>>> Over at <
>>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html>,
>>> Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to
>>> allow authors to take full advantage of high-resolution backing stores,
>>> when available (whereas the existing API hides the fact that the backing
>>> store resolution is not CSS pixel resolution, for compatibility with
>>> existing content). The enhancements include a backingStorePixelRatio
>>> attribute and {get,put}ImageDataHD functions on CanvasRenderingContext2D.
>>>
>>> Through <https://bugs.webkit.org/show_bug.cgi?id=83619> and <
>>> https://bugs.webkit.org/show_bug.cgi?id=83836>, I am making these
>>> enhancements, with the names prefixed with “webkit”.
>>>
>>> There is no build-time option to disable these enhancements. Ports that
>>> don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version
>>> of the additional API. Ports that opt into high-DPI canvas need to enhance
>>> their ImageBuffer implementation to fully support the resolutionScale and
>>> CoordinateSystem parameters.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Darin Fisher]

On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak  wrote:

>
> On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
>
> Could this be an opportunity to design an asynchronous API for fetching
> the pixel buffer?  It seems like many implementations are GPU backed now,
> and fetching the pixel buffer is an expensive (blocking) operation.  Had
> you considered making such a change?
>
>
> Adding async support was suggested on the whatwg thread about this. I
> think async support is useful, but should not be tied to high DPI support.
> In particular, we shouldn't, in my opinion, require authors to rewrite
> their existing sync code to an async model just to properly support higher
> resolutions.
>
> In addition, the whatwg thread revealed that there are many hidden
> complexities in the design of get/putImageData, in particular designing how
> they work in the face of sychronous drawing operations to the same canvas.
> The HiDPI problem is much more straightforward and does not need to be
> gated on resolving the async design issues.
>
>
I think you are giving up a good opportunity.  The barriers to an async API
are more readily overcome when there are extra benefits to developers.
 HiDPI could be a great way to attract developers to a better API.

I've addressed those other concerns on the WhatWG thread.

-Darin



>
> Regards,
> -Darin
>
>
>
> On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein  wrote:
>
>> [This is actually an enhancement announcement to an existing feature]
>>
>> Over at <
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html>,
>> Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to
>> allow authors to take full advantage of high-resolution backing stores,
>> when available (whereas the existing API hides the fact that the backing
>> store resolution is not CSS pixel resolution, for compatibility with
>> existing content). The enhancements include a backingStorePixelRatio
>> attribute and {get,put}ImageDataHD functions on CanvasRenderingContext2D.
>>
>> Through <https://bugs.webkit.org/show_bug.cgi?id=83619> and <
>> https://bugs.webkit.org/show_bug.cgi?id=83836>, I am making these
>> enhancements, with the names prefixed with “webkit”.
>>
>> There is no build-time option to disable these enhancements. Ports that
>> don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version
>> of the additional API. Ports that opt into high-DPI canvas need to enhance
>> their ImageBuffer implementation to fully support the resolutionScale and
>> CoordinateSystem parameters.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Darin Fisher]

Could this be an opportunity to design an asynchronous API for fetching the
pixel buffer?  It seems like many implementations are GPU backed now, and
fetching the pixel buffer is an expensive (blocking) operation.  Had you
considered making such a change?

Regards,
-Darin



On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein  wrote:

> [This is actually an enhancement announcement to an existing feature]
>
> Over at <
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html>,
> Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to
> allow authors to take full advantage of high-resolution backing stores,
> when available (whereas the existing API hides the fact that the backing
> store resolution is not CSS pixel resolution, for compatibility with
> existing content). The enhancements include a backingStorePixelRatio
> attribute and {get,put}ImageDataHD functions on CanvasRenderingContext2D.
>
> Through  and <
> https://bugs.webkit.org/show_bug.cgi?id=83836>, I am making these
> enhancements, with the names prefixed with “webkit”.
>
> There is no build-time option to disable these enhancements. Ports that
> don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version
> of the additional API. Ports that opt into high-DPI canvas need to enhance
> their ImageBuffer implementation to fully support the resolutionScale and
> CoordinateSystem parameters.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] feature proposal: restricting window.blur/focus

[Darin Fisher]

On Wed, Apr 4, 2012 at 11:17 AM, Jochen Eisinger wrote:

>
>
> On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher  wrote:
>
>> On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger wrote:
>>
>>>
>>> On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher  wrote:
>>>
>>>> Matching Firefox behavior likely means that we won't have to worry
>>>> about breaking sites.  We may have to worry about breaking Chrome
>>>> Extensions or other browser-specific content.
>>>>
>>>>
>>> We could add a method to ChromeClient that would enable an embedder to
>>> override the restriction under certain circumstances
>>>
>>
>> Or, perhaps something like UserGestureIndicator.  I'm not sure which is
>> better.
>>
>
> Not sure I understand?
>
> Are you suggesting to allowing focusing/blurring in response to a user
> action? I think that's undesirable, as the site that wants to pop-under a
> window probably "stole" a click to be able to run window.open already.
>
>

No, no... sorry for being unclear.  I meant that you could have a global
state variable (allow focusing / blurring) that gets controlled by a scoped
helper class.  This is an alternative to having a ChromeClient callback.

-Darin



> -jochen
>
>
>> -Darin
>>
>>
>>>
>>> -jochen
>>>
>>>
>>>
>>>> -Darin
>>>>
>>>>
>>>>
>>>> On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> Firefox restricts the use of window.blur() and window.focus() (by
>>>>> default). window.blur() is just doing nothing, and window.focus() only
>>>>> works if the caller is running in the same window.
>>>>>
>>>>> Should we implement similar rules for WebKit? The purpose of this is
>>>>> to make pop-unders more difficult to achieve.
>>>>>
>>>>> I think this can be implemented in such a way the the chrome
>>>>> implementation which is doing the actual focusing/bluring anyway has 
>>>>> enough
>>>>> information to let each port control what they want to do.
>>>>>
>>>>> wdyt?
>>>>>
>>>>> -jochen
>>>>>
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>>
>>>>>
>>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] feature proposal: restricting window.blur/focus

[Darin Fisher]

On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger wrote:

>
> On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher  wrote:
>
>> Matching Firefox behavior likely means that we won't have to worry about
>> breaking sites.  We may have to worry about breaking Chrome Extensions or
>> other browser-specific content.
>>
>>
> We could add a method to ChromeClient that would enable an embedder to
> override the restriction under certain circumstances
>

Or, perhaps something like UserGestureIndicator.  I'm not sure which is
better.
-Darin


>
> -jochen
>
>
>
>> -Darin
>>
>>
>>
>> On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger wrote:
>>
>>> Hey,
>>>
>>> Firefox restricts the use of window.blur() and window.focus() (by
>>> default). window.blur() is just doing nothing, and window.focus() only
>>> works if the caller is running in the same window.
>>>
>>> Should we implement similar rules for WebKit? The purpose of this is to
>>> make pop-unders more difficult to achieve.
>>>
>>> I think this can be implemented in such a way the the chrome
>>> implementation which is doing the actual focusing/bluring anyway has enough
>>> information to let each port control what they want to do.
>>>
>>> wdyt?
>>>
>>> -jochen
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] feature proposal: restricting window.blur/focus

[Darin Fisher]

Matching Firefox behavior likely means that we won't have to worry about
breaking sites.  We may have to worry about breaking Chrome Extensions or
other browser-specific content.

-Darin



On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger  wrote:

> Hey,
>
> Firefox restricts the use of window.blur() and window.focus() (by
> default). window.blur() is just doing nothing, and window.focus() only
> works if the caller is running in the same window.
>
> Should we implement similar rules for WebKit? The purpose of this is to
> make pop-unders more difficult to achieve.
>
> I think this can be implemented in such a way the the chrome
> implementation which is doing the actual focusing/bluring anyway has enough
> information to let each port control what they want to do.
>
> wdyt?
>
> -jochen
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Darin Fisher]

[Oops, I meant to reply on list.]

I think it is a risky practice for WebKit to have half-baked "webkit"
prefixed
features enabled by default on trunk.  It puts the burden on all WebKit
ports
to know which features are half-baked, whereas individual authors of new
features would know best how stable their features are.

Once a port ships a feature, however baked the feature may be, if it becomes
popular (to some degree), we risk having to support it.  I don't think web
developers necessarily understand that they should regard "webkit" prefixed
features as buyer-beware given that there are so many "webkit" prefixed
features that we all tell developers to use.  How can developers tell the
difference between the stable ones and unstable ones?

It seems safest to ENABLE-guard all half-baked features on trunk, vendor
prefixed or otherwise.  The only reason to vendor prefix is if there is not
a
stable well established spec with multi-vendor support.  In the case of
, which seems quite well specified as part of HTML5,
perhaps there is no need to vendor prefix at all?  Just hide behind a guard
until it is ready?

-Darin


On Fri, Mar 30, 2012 at 6:34 PM, Eric Seidel  wrote:

> We certainly could add an ENABLE.  My impression is that we have many
> half-baked -webkit- features, and that use there-of is buyer-beware
> anyway?
>
> My expectation is that this may be a rather short implementation
> effort.  Ideally I'd be able to finish it next week.  Maybe we should
> revisit this question next Friday?
>
> (It's also probably better to discuss this on webkit-dev, but I didn't
> know if you had intended this email as private.)
>
> -eric
>
> On Fri, Mar 30, 2012 at 4:59 PM, Darin Fisher  wrote:
> >
> >
> > On Fri, Mar 30, 2012 at 4:01 PM, Eric Seidel  wrote:
> >>
> >> Per http://www.webkit.org/coding/adding-features.html
> >>
> >>
> >> I'm working on adding  support to WebKit.
> >> http://www.whatwg.org/specs/web-apps/current-work/#dom-iframe-seamless
> >>
> >> Folks interested can follow along at home:
> >> https://bugs.webkit.org/show_bug.cgi?id=45950
> >>
> >> It's currently accessible only via  /
> >> iframe.webkitseamless, but once the implementation is complete it will
> >> move to its spec name "seamless".  I have no plans to add a feature
> >> define, as it should be on for all ports.
> >
> >
> > Wouldn't it be better to hide the feature from shipping products until
> it is
> > complete?
> >
> > I realize this complicates testing, but it seems problematic to ship an
> > incomplete
> > feature that websites might end up depending on.  Once we ship a vendor
> > prefixed
> > API, if folks start depending on it, we need to keep supporting it.  It
> > seems safer to
> > hide the feature until we can ship it unprefixed in this case since the
> > feature is already
> > well known and specified in a standard.
> >
> > -Darin
> >
> >>
> >>
> >> Let me know if I can answer any questions!
> >>
> >> -eric
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

[Darin Fisher]

Hrm, if the test expectations are customized already for different ports of
WebKit, then why not support replacing a PNG file with a HTML file that is
intended to generate exactly the same result?  How does this impair our
ability to update the tests?

(I realize that our current reftest system may not work like this.  I'm not
familiar with the details of how it works in fact, but it seems like it
could be as simple as having an expected result that is a HTML file instead
of a PNG file.)

-Darin


On Wed, Mar 7, 2012 at 4:10 PM, Maciej Stachowiak  wrote:

>
> I'd prefer we not modify imported test suites. That will just make it more
> confusing to update. Perhaps future CSS test suites will be changed to a
> reftest model.
>
> Regards,
> Maciej
>
> On Mar 7, 2012, at 1:41 PM, Ojan Vafai wrote:
>
> I just did a first pass a greening the Chromium Lion bot:
> http://trac.webkit.org/changeset/110096. Of these hundreds of tests,
>  ~99% of them are perfect candidates for being reftests (e.g. they contain
> one line of text and a solid box or two under the text), but most of them
> are in the CSS imported test suites.
>
> Is it kosher to convert them to reftests or should we leave pixel tests
> from imported test suites alone?
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The Care and Feeding of WebCore Modules

[Darin Fisher]

On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov  wrote:

>
> Having read the wiki page, I'm even more unhappy with the approach that
> has been taken than I used to be. In fact, it is harmful even to the goals
> of the refactoring.
>
> If a single #ifdefed line in DOMWindow.idl is a burden for development,
> what about adding several new files to each and every build system, and
> maintaining these multiple files into perpetuity? That's much more work for
> everyone - port maintainers, core developers, and feature developers. The
> likelihood of repeated breakage is higher with the need to maintain a more
> complicated build system.
>
> Sticking to the concrete example, these lines in WorkerContext.idl are not
> really something a WebSocket engineer maintains. It's more important for a
> person working on JS bindings and/or on threading, and the need to hunt
> down these across many files makes hacking more difficult. How can one even
> find an answer to the very practical question of which properties are
> available on WorkerContext if these are split across multiple files?
>

Is this something the build system could help address?  Perhaps a
by-product of the build is or could be a single file that contains
everything that will be exposed on WorkerContext / DOMWindow?

I know studying a generated file is never as nice as studying a source
file, but perhaps there is a compromise of this sort that could work?

I guess I'm just a big fan of modularization.  It seems helpful to separate
logical units and minimize large "cross roads" files.

-Darin




>
> #if defined(ENABLE_WEB_SOCKETS) && ENABLE_WEB_SOCKETS
>attribute [JSCustomGetter,V8EnabledAtRuntime] WebSocketConstructor
> WebSocket; // Usable with the new operator
> #endif
>
> The goal is to make hacking easier. Moving files to separate directories
> should be done as long as that helps to advance the goal, but not beyond
> that, even if we now have an entertaining tool in the form of supplemental
> interfaces that lets you go far beyond reasonable.
>
> - WBR, Alexey Proskuryakov
>
>
> 28.02.2012, в 0:29, Adam Barth написал(а):
>
> > I wrote up a short wiki page explaining how the modules system works
> > and how to use it when building new features:
> >
> > https://trac.webkit.org/wiki/Modules
> >
> > We've been making good progress refactoring some existing features to
> > use the system.  This refactoring both improves the hackability of
> > WebCore by simplifying the core objects (e.g.,
> > Page/DOMWindow/Document/Navigator) and paves the cowpaths for new code
> > to avoid bloating these objects.
> >
> > In Bug 79663, Alexey asked why we were moving the WebSocket
> > declaration out of WorkerContext.idl and into Modules/websockets.
> > Viewed in isolation, I can understand why that change looks somewhat
> > mysterious.  Hopefully the wiki page above provides some more context
> > for the change.  In particular, WebSockets fits neatly into the
> > modules pattern.  We've already removed almost all mentions of
> > WebSockets from WebCore proper.  Besides one item in
> > WebCore::Settings, WorkerContext.idl is the last file in WebCore
> > proper to mention WebSockets.
> >
> > Adam
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The Care and Feeding of WebCore Modules

[Darin Fisher]

The main issue isn't that the settings are large and unwieldy.  I thought
the point of the modularization effort was to enable partitioning of
features.  That means eliminating files that enumerate each feature.  That
said, we might still have classes that need to mention all features, so to
address that you might auto-gen such classes.

-Darin


On Tue, Feb 28, 2012 at 10:47 AM, Simon Fraser wrote:

> "Let's auto generate it" doesn't logically follow from "it's getting large
> and unwieldy" to me.
>
> It seems that a better approach would be to figure out how to simplify
> Settings (do we still need them all?), and if we do, perhaps to break it up
> somehow.
>
> Simon
>
> On Feb 28, 2012, at 10:27 AM, Darin Fisher wrote:
>
> Good idea!
> -Darin
>
> On Tue, Feb 28, 2012 at 8:46 AM, Adam Barth  wrote:
>
>> We haven't done anything about Settings yet, but Setting is also kind
>> of growing out of control.  My initial read is that we should try to
>> autogenerate Settings (and maybe some/all of the Settings-related
>> boilerplate in the WebKit layer) from an "in" file.
>>
>> Adam
>>
>>
>> On Tue, Feb 28, 2012 at 7:40 AM, Darin Fisher  wrote:
>> > Nice.  Is there a plan for modularizing Settings?
>> >
>> > On Feb 28, 2012 12:30 AM, "Adam Barth"  wrote:
>> >>
>> >> I wrote up a short wiki page explaining how the modules system works
>> >> and how to use it when building new features:
>> >>
>> >> https://trac.webkit.org/wiki/Modules
>> >>
>> >> We've been making good progress refactoring some existing features to
>> >> use the system.  This refactoring both improves the hackability of
>> >> WebCore by simplifying the core objects (e.g.,
>> >> Page/DOMWindow/Document/Navigator) and paves the cowpaths for new code
>> >> to avoid bloating these objects.
>> >>
>> >> In Bug 79663, Alexey asked why we were moving the WebSocket
>> >> declaration out of WorkerContext.idl and into Modules/websockets.
>> >> Viewed in isolation, I can understand why that change looks somewhat
>> >> mysterious.  Hopefully the wiki page above provides some more context
>> >> for the change.  In particular, WebSockets fits neatly into the
>> >> modules pattern.  We've already removed almost all mentions of
>> >> WebSockets from WebCore proper.  Besides one item in
>> >> WebCore::Settings, WorkerContext.idl is the last file in WebCore
>> >> proper to mention WebSockets.
>> >>
>> >> Adam
>> >> ___
>> >> webkit-dev mailing list
>> >> webkit-dev@lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The Care and Feeding of WebCore Modules

[Darin Fisher]

Good idea!
-Darin

On Tue, Feb 28, 2012 at 8:46 AM, Adam Barth  wrote:

> We haven't done anything about Settings yet, but Setting is also kind
> of growing out of control.  My initial read is that we should try to
> autogenerate Settings (and maybe some/all of the Settings-related
> boilerplate in the WebKit layer) from an "in" file.
>
> Adam
>
>
> On Tue, Feb 28, 2012 at 7:40 AM, Darin Fisher  wrote:
> > Nice.  Is there a plan for modularizing Settings?
> >
> > On Feb 28, 2012 12:30 AM, "Adam Barth"  wrote:
> >>
> >> I wrote up a short wiki page explaining how the modules system works
> >> and how to use it when building new features:
> >>
> >> https://trac.webkit.org/wiki/Modules
> >>
> >> We've been making good progress refactoring some existing features to
> >> use the system.  This refactoring both improves the hackability of
> >> WebCore by simplifying the core objects (e.g.,
> >> Page/DOMWindow/Document/Navigator) and paves the cowpaths for new code
> >> to avoid bloating these objects.
> >>
> >> In Bug 79663, Alexey asked why we were moving the WebSocket
> >> declaration out of WorkerContext.idl and into Modules/websockets.
> >> Viewed in isolation, I can understand why that change looks somewhat
> >> mysterious.  Hopefully the wiki page above provides some more context
> >> for the change.  In particular, WebSockets fits neatly into the
> >> modules pattern.  We've already removed almost all mentions of
> >> WebSockets from WebCore proper.  Besides one item in
> >> WebCore::Settings, WorkerContext.idl is the last file in WebCore
> >> proper to mention WebSockets.
> >>
> >> Adam
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The Care and Feeding of WebCore Modules

[Darin Fisher]

Nice.  Is there a plan for modularizing Settings?
On Feb 28, 2012 12:30 AM, "Adam Barth"  wrote:

> I wrote up a short wiki page explaining how the modules system works
> and how to use it when building new features:
>
> https://trac.webkit.org/wiki/Modules
>
> We've been making good progress refactoring some existing features to
> use the system.  This refactoring both improves the hackability of
> WebCore by simplifying the core objects (e.g.,
> Page/DOMWindow/Document/Navigator) and paves the cowpaths for new code
> to avoid bloating these objects.
>
> In Bug 79663, Alexey asked why we were moving the WebSocket
> declaration out of WorkerContext.idl and into Modules/websockets.
> Viewed in isolation, I can understand why that change looks somewhat
> mysterious.  Hopefully the wiki page above provides some more context
> for the change.  In particular, WebSockets fits neatly into the
> modules pattern.  We've already removed almost all mentions of
> WebSockets from WebCore proper.  Besides one item in
> WebCore::Settings, WorkerContext.idl is the last file in WebCore
> proper to mention WebSockets.
>
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing obsolete File attributes

[Darin Fisher]

On Fri, Feb 24, 2012 at 1:47 PM, Jochen Eisinger wrote:

>
>
> On Fri, Feb 24, 2012 at 10:38 PM, Eric Seidel  wrote:
>
>> My 2¢:
>>
>> - I'm glad to see these properties go.
>> - I think Darin is correct to be concerned about a potential
>> web-compat risk.  (But, I suspect grepping extensions for ".fileSize"
>> and ".fileName" might actually turn up useful data.  Assuming that's
>> easy to do?)
>> - I agree with ap that warnings are mostly useless.  Firefox has a
>> zillion such warnings, and most page authors seem to ignore them.
>>
>
> Is it really useless, or does it help to decrease the number of new pages
> using the feature? At the very least, it would make it seem more fair if
> the feature is eventually removed to give some warning.
>

Exactly!  For a point of reference, the bug to remove these properties
caught the attention of a developer at Google just yesterday.  He was
really worried that we were taking away the ability to get the "name" and
"size" from a File.  He just wasn't aware of the fact that the same data
was still available, but just under a different name on the Blob interface.
 He was writing new code.  I'm certain a warning in the console would have
been helpful in this case.



>
>> - I agree with Jian Li, that if/when we add warnings (or any other
>> form of deprecation) notating such in the IDL and autogenerating is a
>> Good Idea™.
>>
>
> I agree that this would be useful.
>
>
Great idea!

-Darin



> -jochen
>
>
>>
>> How much work is it to collect "how many unique pages grab these"
>> numbers from nightlies?  Have we done such in the past? (Do we have
>> other studies to compare against?)  It feels a bit odd for WebKit to
>> depend on Chromium to collect such numbers, but Chromium does seem
>> well suited to the task.
>>
>> -eric
>>
>> On Fri, Feb 24, 2012 at 1:30 PM, Alexey Proskuryakov 
>> wrote:
>> >
>> > 24.02.2012, в 12:20, Darin Fisher написал(а):
>> >
>> > Perhaps a concrete good first step is to log a console warning when
>> they are
>> > used?  "Warning, blahBlah is a deprecated attribute.  Use fluxCapacitor
>> > instead."
>> >
>> >
>> > I'm not much in favor of such warnings - from all I heard (second or
>> third
>> > hand, without hard data), they are not effective. FWIW, this is what I'd
>> > expect - developers don't check console logs for sites they've
>> delivered and
>> > were paid for long ago.
>> >
>> > I should point out that replacement standard attributes have been
>> > implemented in WebKit for a long time.
>> >
>> > - WBR, Alexey Proskuryakov
>> >
>> >
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing obsolete File attributes

[Darin Fisher]

On Fri, Feb 24, 2012 at 12:13 PM, Maciej Stachowiak  wrote:

>
> On Feb 24, 2012, at 12:06 PM, Darin Fisher wrote:
>
>
>
> On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak  wrote:
>
>>
>> On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote:
>>
>> As I mentioned in the bug, it is encouraging news that Mozilla has
>> already removed these attributes (for a couple releases now).  I would like
>> to see them go away too.
>>
>> There's unfortunately, the real possibility that there may be some
>> existing webkit-specific or chrome-specific (extensions) content out there
>> that is expecting these properties to exist.  I think we need to be a bit
>> cautious since we've included these properties in webkit for such a long
>> time (since 2008!).  Here's the revision that added them:
>> http://trac.webkit.org/changeset/34702
>>
>>
>> Is there a good way to quantify and/or mitigate this risk?
>>
>
> Well, we could certainly instrument a Chrome nightly build to measure
> accesses made on these attributes, and see what that turns up.  I haven't
> thought about it enough to decide what a good metric would be.  You
> probably want to know the percentage of unique pages that depend on these
> features.  It is probably easier to measure percentage of navigations that
> resulted in a document that depended on these features.  That would
> over-estimate usage if a page that needs these features is navigated to
> frequently.
>
> I'm concerned that it may be tricky to grep the repository of Chrome
> extensions (or Google's index of the web) since "fileName" and "fileSize"
> are likely to be very common terms.
>
>
> Though you did not say so explicitly, it sounded to me like your suggested
> approach to this issue was "let's remove these eventually, but maybe not
> right now". That sounds like a reasonable approach.
>
> But then we'll need to figure out if it's actually too costly to remove
> them right now, and if so, figure out how to get to the point that we feel
> comfortable removing them. I don't really have a specific kind of idea of
> what data would tell us these things.  Your suggestions above seem ok.
>
> Regards,
> Maciej
>
>
>

Perhaps a concrete good first step is to log a console warning when they
are used?  "Warning, blahBlah is a deprecated attribute.  Use fluxCapacitor
instead."

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

Re: [webkit-dev] Removing obsolete File attributes

[Darin Fisher]

On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak  wrote:

>
> On Feb 24, 2012, at 11:52 AM, Darin Fisher wrote:
>
> As I mentioned in the bug, it is encouraging news that Mozilla has already
> removed these attributes (for a couple releases now).  I would like to see
> them go away too.
>
> There's unfortunately, the real possibility that there may be some
> existing webkit-specific or chrome-specific (extensions) content out there
> that is expecting these properties to exist.  I think we need to be a bit
> cautious since we've included these properties in webkit for such a long
> time (since 2008!).  Here's the revision that added them:
> http://trac.webkit.org/changeset/34702
>
>
> Is there a good way to quantify and/or mitigate this risk?
>

Well, we could certainly instrument a Chrome nightly build to measure
accesses made on these attributes, and see what that turns up.  I haven't
thought about it enough to decide what a good metric would be.  You
probably want to know the percentage of unique pages that depend on these
features.  It is probably easier to measure percentage of navigations that
resulted in a document that depended on these features.  That would
over-estimate usage if a page that needs these features is navigated to
frequently.

I'm concerned that it may be tricky to grep the repository of Chrome
extensions (or Google's index of the web) since "fileName" and "fileSize"
are likely to be very common terms.

-Darin



>
> Regards,
> Maciej
>
>
> -Darin
>
>
>
> On Fri, Feb 24, 2012 at 9:36 AM, Alexey Proskuryakov wrote:
>
>>
>> I'd like to remove old File object properties that are superseded in
>> current spec versions, and have been already removed from Firefox: <
>> https://bugs.webkit.org/show_bug.cgi?id=79383>.
>>
>> Would any ports want to keep these under a feature flag, or to have some
>> time to investigate possible consequences of the removal for port specific
>> content?
>>
>> - WBR, Alexey Proskuryakov
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing obsolete File attributes

[Darin Fisher]

As I mentioned in the bug, it is encouraging news that Mozilla has already
removed these attributes (for a couple releases now).  I would like to see
them go away too.

There's unfortunately, the real possibility that there may be some existing
webkit-specific or chrome-specific (extensions) content out there that is
expecting these properties to exist.  I think we need to be a bit cautious
since we've included these properties in webkit for such a long time (since
2008!).  Here's the revision that added them:
http://trac.webkit.org/changeset/34702

-Darin



On Fri, Feb 24, 2012 at 9:36 AM, Alexey Proskuryakov  wrote:

>
> I'd like to remove old File object properties that are superseded in
> current spec versions, and have been already removed from Firefox: <
> https://bugs.webkit.org/show_bug.cgi?id=79383>.
>
> Would any ports want to keep these under a feature flag, or to have some
> time to investigate possible consequences of the removal for port specific
> content?
>
> - WBR, Alexey Proskuryakov
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DOM Rendering synchronization with javascript

[Darin Fisher]

webkitRequestAnimationFrame may be helpful to you.

Regards,
-Darin



On Fri, Feb 17, 2012 at 11:00 AM, Ian Johnson  wrote:

> Hi all,
>
> I'm looking for the ability to synchronize my javascript calls with DOM
> rendering. I want to do calculations based on the rendered size of an SVG
> text element and I've run into cases where the font change will take longer
> than the execution time of my layout calculation code so I end up with bad
> results. Are there some sort of events that can be listened to? I'm fairly
> certain
>
> I've tried searching around and haven't found anything, could this be
> proposed as a feature?
>
> Something llke a barrier() or dom_fence() would be great. I think as more
> people start to heavily manipulate the DOM especially for SVG this type of
> thing will become a larger issue.
>
> I'm happy to help any way I can, but I'm new to the browser world, any
> pointers would be welcome :)
>
> Thank you
>
> --
> Ian Johnson
> http://enja.org
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changing the implementation of KURL

[Darin Fisher]

On Sat, Jan 28, 2012 at 6:01 PM, Adam Barth  wrote:

> On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain 
> wrote:
> > On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson 
> wrote:
> >> So to clarify, I think we need to keep the current architecture.
> >> Obviously WebKit needs a URL class that uses its String class, so
> >> WTFURL would probably be a wrapper around some core library for WebKit
> >> to use. Chromium would rewrite our GURL class to use the same core
> >> library and keep std::strings (we don't want all our browser-level
> >> code to have to convert std::string -> WTF::String just like today we
> >> don't want to do the inverse in WebKit).
> >
> > I don't really get this point. With WTF linked statically, no matter
> > how "largish" WTF, it will not cost much to use.
> >
> > You say you don't want to convert std::string->WTF::String and
> > WTF::String at the browser level, but aren't you doing that a lot more
> > with the current code?
> >
> > Parsing valid URL can probably be done without WTF.
> > URL canonicalization is frequent in WebKit and I would think using
> > String directly is a good idea. Same for modifying a URL.
>
> GURL abstracts the underlying storage so that the canonicalized URL is
> written directly into the proper type.  As far as I can tell, there
> isn't much advantage to WTFURL committing to a particular string type.
>
> > Chromium is the only ports that use the same URL Class in the whole
> > stack. And it seems you do not want any dependencies on WTF. Maybe an
> > alternative is to change this and convert KURL->GoogleURL on platform
> > boundaries like the other ports?
>
> My guess is you won't be able to convince fishd to use different URL
> libraries at different layers in Chromium.  There's a long history of
> that causing security vulnerabilities, both in Firefox and in Safari.
>
>
Right.  In Firefox, the problem was that the cookie code used some
hand-rolled
string parsing code instead of reusing the URL parsing code.  That resulted
in
a subtle bug that could be exploited to steal cookies.  In Safari's case, I
believe
it was caused by differences between CFNetwork and KURL.

If CFNetwork exposed an API to its URL parser, then it would be super wise
for
any port of WebKit using CFNetwork to reuse the same URL parser.

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

Re: [webkit-dev] Changing the implementation of KURL

[Darin Fisher]

The other concern I have is about the stability of the API to the URL
"guts" that GURL living in the chromium repository would depend on.  Anyone
changing the URL guts would need to be careful not to break that contract.
This seems like it might be annoying for those who do not work on chromium.
On Jan 28, 2012 5:43 PM, "Brett Wilson"  wrote:

> On Sat, Jan 28, 2012 at 5:28 PM, Joe Mason  wrote:
> >> -Original Message-
> >> From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
> >> boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak
> >> Sent: Saturday, January 28, 2012 7:08 PM
> >> To: Brett Wilson
> >> Cc: Benjamin Poulain; WebKit Development
> >> Subject: Re: [webkit-dev] Changing the implementation of KURL
> >>
> >> Let's take some specific examples. Would using WTF::Vector inside the
> >> implementation (not necessarily at the API boundary, just internally)
> >> be acceptable? Or would it be required to use C arrays or std::vector?
> >> Would using WTF's ASSERT family of macros be acceptable, or should some
> >> other form of asserts be used? The are examples I can think of where
> >> "dependencies" could simply be added in the course of trying to get the
> >> code to be in WebKit style.
> >
> > Another big potential dependency would be use of Platform.h and the
> ENABLE/USE/etc system of macros - I could easily see a new feature
> including special processing for a new URL scheme, similar to the way file:
> url's have slightly different parsing rules than http: urls.  In this case
> we'd want to wrap the special handling in ENABLE(feature).  (Arguably the
> url class should be flexible enough that you don't have to hardcode special
> handling for a scheme, though.)
>
> I don't see that as being much of an issue. Google Safe Browsing can
> always write their own Platform.h that does what they need.
>
> Brett
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changing the implementation of KURL

[Darin Fisher]

On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth  wrote:

> On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak  wrote:
> > That said, this plan was based on the premise that Chromium folks were
> > willing to cooperate with the unforking effort, and would be happy to
> use a
> > WebKit-integrated URL library based on GoogleURL. If that is no longer
> the
> > case, then certainly we should not proceed on a false premise.
>
> I've been talking a bit with Benjamin about this topic off-list.  I'm
> hopeful that with some careful attention to dependencies and
> interfaces, Chromium will be able to use WTFURL in place of GoogleURL.
>
> Adam
>


I still think it is a bit backwards for Chromium's network stack to depend
on WebKit,
but I remain open minded about this.  I'm curious how it will work out.

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

Re: [webkit-dev] Changing the implementation of KURL

[Darin Fisher]

On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain wrote:

> On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher  wrote:
> > Instead of doing all of this work, have you considered just treating
> > GoogleURL in much the same way as WebKit treats ANGLE?  You could perhaps
> > just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit
> as a
> > whole could switch to a consistent KURL implementation.
>
> WTFURL is a copy of GoogleURL adapted to WebKit so I hope "it is not
> gonna be too much work" (tm). :)
>
> As I understand, it was decided 2 years ago not to add GoogleURL into
> Source/ThirdParty to avoid pulling some dependencies and to have this
> important piece part of the WebKit project (I was not at that
> particular session).
>

Source/ThirdParty didn't exist until Aug 2010, when ANGLE was imported.
 Before
ThirdParty, there wasn't much of a convention of adding wholesale
third-party libraries
to WebKit.

There certainly was a decision made at the earlier WebKit summit to
copy GoogleURL
into WebKit, and massage it there as a path toward having only one KURL
implementation.

My point was just that the work remaining to complete that effort isn't
negligible.

Also, we seem to be successfully sharing ANGLE as-is, and that is also a
very critical
piece of software (impacting web browser security), so why not the same
approach
for the GoogleURL library?  I guess, I'm explicitly re-opening the
conversation on this
topic because it seems like the WTFURL approach will be a fair bit of work
:-)



>
>
> Also, be mindful that if your goal is to avoid having two implementions of
> > KURL, then part of accomplishing that goal is also switching Chromium
> over
> > to WTFURL.  I'm guessing that is probably not in your plans.  Do you
> know if
> > someone is motivated to make that happen?  (Chromium consumes GoogleURL
> > directly, albeit mostly through the GURL front-end, which might be
> portable
> > to WTFURL.)
>
> I assumed Adam Barth could help since he bootstrapped the whole WTFURL
> project.
>

I don't know... I wouldn't rule it out!


> If there is no interest from Chromium to get rid of the split, I would
> rather keep improving the current KURL than completely switch the
> implementation.
>
>
I'm personally supportive of their being only one KURL implementation.  I
think most
people are.  I just think you get there immediately by using GoogleURL
directly.

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

Re: [webkit-dev] Changing the implementation of KURL

[Darin Fisher]

On Thu, Jan 26, 2012 at 6:11 PM, Benjamin Poulain wrote:

> Hello,
>
> I would like to give another shot at the URL implementation Adam
> started some times ago.
>
> There are a few problems with the current KURL:
> -there are two implementations: WebKit and Google URL
> -some stuff are just plain incorrect :)
> -the WebKit implementation has some bugs which makes it differs from
> GoogleURL (and in some cases, the other engines)
>
> So I would like to:
> 1) put back WTF URL in trunk
> 2) add an implementation of KURL based on ParsedURL with a new USE(WTFURL)
> 3) fix the tests until we match at least the current KURL
> 4) fix the performance gap, if any
> 5) kill the current KURL, remove the flag USE(WTFURL)
> 6) fix the remaining tests
>
> If that fails. We can get rid of USE(WTFURL), and resume fixing the
> bug for current's KURL.
>
> Any comments? Suggestions?
>
>
Instead of doing all of this work, have you considered just treating
GoogleURL in much the same way as WebKit treats ANGLE?  You could perhaps
just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as
a whole could switch to a consistent KURL implementation.

This alternative seems like a very small amount of work and yields almost
all of the benefits of creating WTFURL.  The only downside would seem to be
the extra overhead associated with making changes to GoogleURL.  Has that
sort of cost been an issue with ANGLE?  Do you anticipate wanting to make a
lot of significant code changes, or would you primarily just be concerned
about the ease of bug fixing?

Also, be mindful that if your goal is to avoid having two implementions of
KURL, then part of accomplishing that goal is also switching Chromium over
to WTFURL.  I'm guessing that is probably not in your plans.  Do you know
if someone is motivated to make that happen?  (Chromium consumes GoogleURL
directly, albeit mostly through the GURL front-end, which might be portable
to WTFURL.)

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

Re: [webkit-dev] Making empty vectors smaller; eliminate String::adopt(Vector)?

[Darin Fisher]

Worst case, if you needed to keep String::adopt(Vector), it seems like you
could
use a bit in StringImpl::m_hashAndFlags to record the fact that the buffer
requires
special "free" handling.

-Darin


On Wed, Dec 7, 2011 at 10:24 AM, Adam Barth  wrote:

> We originally used String::adopt(Vector) in the parser because we
> thought it would be faster, but studying profiles and experimenting
> with benchmarks revealed that (at least for those use cases) it was
> actually slower than just memcpying the data into the String.  I
> haven't looked at the other uses of String::adopt(Vector) in the
> codebase, but they might also run faster using memcpy.
>
> I think it's probably fine to remove String::adopt(Vector).
>
> Adam
>
>
> On Wed, Dec 7, 2011 at 10:10 AM, Darin Adler  wrote:
> > For vectors with no inline capacity, we can store the capacity inside
> the Vector’s buffer. That way, the Vector itself will be one size_t smaller
> when empty. In fact, with a bit of performance risk, we can do the same
> thing with the vector’s size, making an empty Vector just a single pointer.
> But doing this also means that the allocated buffer won’t have the vector
> elements at the start of the memory block. The only thing I could find that
> this would interfere with would be the String::adopt(Vector) function. My
> question is whether with the latest wonderful StringBuilder technology we
> could eliminate String::adopt(Vector). Can we get rid of that entirely from
> WebKit?
> >
> > -- Darin
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Gamepad API [Was: New feature flag proposal: Joystick API]

[Darin Fisher]

Hi all,

Alexey appears to strongly dislike the name of this API specification (
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so
that he is blocking development of the API behind a flag.

As a reminder, this API is being developed through the WebEvents WG jointly
with other browser vendors, including Mozilla.  Folks working on this appear
to be content with the Gamepad name, precisely because the spec is limited
to dealing with input devices that are represented in terms of buttons and
axes.  Gamepad seems like a fairly canonical name for such a device, even
though devices by other names can be represented by similar data.

Does anyone else feel strongly enough that the name of the API is so bad
that it should therefore not be allowed onto WebKit trunk behind a flag?

Personally, I feel like the name is quite malleable at this point in time,
and I really like coming up with the best possible name for things.
 However, I don't see why we need to have the perfect name before we
continue development of this feature behind a flag.

As we were developing Blob and File support, we made several name changes
along the way.  It is not always so obvious how to name things from the
start.

See this bug for reference:
https://bugs.webkit.org/show_bug.cgi?id=69451

Thoughts?
-Darin


On Thu, Oct 6, 2011 at 2:07 PM, Alexey Proskuryakov  wrote:

>
> 06.10.2011, в 13:49, Scott Graham написал(а):
>
> The first revision of the spec (from the Scope section) is intended to
> handle:
>
> ... support for devices common to current gaming systems including
> gamepads, directional pads, joysticks, wheels, pedals, accelerometers.
>
>
> Why does the spec title and abstract talk about gamepads (joysticks)
> only? Perhaps it's my mistake that I didn't read the scope section, but with
> title and abstract being so specific, that seemed unnecessary.
>
> Skipping scope section, I went right to IDL. Why is the interface called
> Gamepad if it's not only about gamepads?
>
> - WBR, Alexey Proskuryakov
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore

[Darin Fisher]

I agree that this seems like something to #ifdef.  Out of curiosity, did you
just stumble upon this, or did you actually notice a measurable performance
regression from this?

-Darin


On Thu, Oct 6, 2011 at 10:07 AM, Dan Bernstein  wrote:

>
> On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
>
>   Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 => 96819)
>
> --- trunk/Source/WebCore/dom/ScriptElement.h  2011-10-06 16:37:35 UTC (rev 
> 96818)
> +++ trunk/Source/WebCore/dom/ScriptElement.h  2011-10-06 16:40:47 UTC (rev 
> 96819)@@ -113,6 +113,14 @@   ZeroedInStopLoadRequest,   
> ZeroedInNotifyFinished, } m_cachedScriptState;+
> +// We grab a backtrace when we zero m_cachedScript, so that at later 
> crashes
> +// we'll have a debuggable stack.
> +enum {
> +MaxBacktraceSize = 32
> +};
> +int m_backtraceSize;
> +void* m_backtrace[MaxBacktraceSize]; };
>
>
> This appears to increase the size of each ScriptElement instance by 256
> bytes. I don’t know how bad a performance hit this is in real-world use, but
> it is most certainly not something all vendors would like to include in
> their releases. The way this change was made, however, it is almost
> inevitable that a vendor would end up unknowingly shipping this performance
> regression. This change was made on trunk, it is unconditionally compiled
> in, and there is nothing obvious tracking undoing this change.
>
> I think this is the wrong way to incorporate diagnostic code into WebKit.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New feature flag proposal: Joystick API

[Darin Fisher]

This proposal has matured somewhat, so an update is in order.

FYI:
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html
http://www.w3.org/2010/webevents/charter/2011/Overview.html

We are working behind the ENABLE(GAMEPAD) flag at the moment.  Mozilla is
also building a prototype of this API.

We are doing development on the trunk (disabled by default) so that we can
more easily solicit game developers for feedback using our existing Chrome
distribution channels.  This feature should have a very light touch on
existing cross platform code.

We encourage folks to share feedback on the API design to
webevents-pub...@w3.org.

Regards,
-Darin


On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser wrote:

> I think it's too early to implement this. We should wait until it's a W3C
> draft at least.
>
> window.addEventListener("MozJoyConnected"..), really?
>
> Simon
>
> On Aug 24, 2011, at 8:36 AM, Scott Graham wrote:
>
> > Hi,
> >
> > I wanted to let everyone know that I propose to add a new feature
> > flag, JOYSTICK. http://webkit.org/b/66859
> >
> > This flag will enable an API and events for accessing joysticks and
> > related devices. There's a prototype effort happening in Mozilla also
> > (https://wiki.mozilla.org/JoystickAPI), and the design is intended to
> > be similar.
> >
> > As it will not necessarily make sense for all ports, nor be
> > implemented immediately in all ports, a feature flag seems
> > appropriate.
> >
> > Please let me know if you have any concerns or comments.
> >
> > Thanks
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] pthreads and other threading primitives

[Darin Fisher]

On Mon, Sep 26, 2011 at 10:47 AM, Alexey Proskuryakov  wrote:

>
> In the wake of Geoff's work to simplify threading ifdefs, and Adam's review
> of supported ports, I'm curious what people think about maintaining many
> platform branches in our WTF and JavaScriptCore threading code.
>
> Right now, it feels rather non-systemic, with some code built upon
> pthreads, Qt or Gtk libraries, and some calling into Win32 API directly.
> Some specific examples:
> - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads;
> - FastMalloc works with pthreads or Win32 API;
> - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API;
> - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely
> custom. Chromium doesn't even use supposedly cross-platform parts in
> MainThread.cpp.
>

This was done to avoid the queue that callOnMainThread creates.  It causes
both subtle bugs and performance problems for Chromium.  Our native
MessageLoop can implement MainThread.h directly and without those issues, so
it makes sense for us to just use our port's primitives.

However, I realize this approach was not free of trouble.  Recently, someone
added cancelCallOnMainThread, which cannot be implemented easily on top of
the Chromium MessageLoop.  Fortunately, that method is not called by any
code that the Chromium port compiles, but unfortunately, it is a bit of a
ticking-timebomb.  Someone will invariably try to use it and then be
frustrated that Chromium doesn't support it.  I think that it is a poor API
because it requires searching the work queue, so I would prefer to remove
cancelCallOnMainThread or redesign it so it can be implemented efficiently.

-Darin


>
> Supporting multiple implementation has a high cost, both in the work
> directly applied to that, and in having subtle behavior differences.
> Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I
> see that most lines are last touched by people who are not directly
> affiliated with these ports.
>
> I remember that performance was given as the primary reason to not use
> pthreads everywhere. What pthreads functionality in particular needs to be
> reimplemented in WTF for performance? And are there big reasons to use
> anything except for POSIX and Win32 APIs for us? Do we want to require that
> platforms support pthreads, so that code that isn't performance critical
> could have just one implementation?
>
> - WBR, Alexey Proskuryakov
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] new APIs for strokes with dash in Canvas

[Darin Fisher]

Do you know if anyone is working to add this to the spec for Canvas?  It
seems like it may not take much to get it added, given that FF already has
an implementation.

-Darin

On Thu, Sep 22, 2011 at 7:31 PM, Young Han Lee  wrote:

> Hi all,
>
> I have a patch to add webkitLineDash and webkitLineDashOffset APIs on
> CanvasRenderingContext2D on https://bugs.webkit.org/show_bug.cgi?id=63933
>
> The purpose of these APIs is to support for strokes with dash in Canvas.
>
> Although the API is not specified in the HTML Canvas specification yet, I
> believe it would be great to support the API. As Dirk said in the above bug,
> Mozilla already implemented the APIs named mozDash and mozDashOffset[1], and
> there seems to be many needs for the API. Some people even implemented their
> own javascript functions to draw strokes with dash in Canvas[2,3].
>
> As GraphicsContext already have an interface for strokes with dash,
> setLineDash, all we have to do is exposing it to the JS level. So the syntax
> and meaning of the new APIs is the same with the arguments of the
> setLineDash. webkitLineDash is an array of float, and webkitLineDashOffset
> is a float.
>
> I uploaded a patch for JSC first. After the patch is landed, I will make a
> follow-up patch for V8.
>
> Any thought?
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=662038
> [2]
> http://davidowens.wordpress.com/2010/09/07/html-5-canvas-and-dashed-lines/
> [3]
> http://stackoverflow.com/questions/7352769/dashed-curves-on-html5-canvas-bezier
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Mouse Lock API

[Darin Fisher]

On Thu, Sep 22, 2011 at 2:38 PM, Alexey Proskuryakov  wrote:

>
> 22.09.2011, в 14:25, Darin Fisher написал(а):
>
> Our next step is to extend this to non-fullscreen, so I think it would be
> counter-productive to preclude non-fullscreen at this time.
>
>
> I think that adding an API for non-fullscreen mouse lock would be a
> detriment to the Web platform. So gating fullscreen API on it seems pretty
> controversial.
>
> - WBR, Alexey Proskuryakov
>
>
Would you mind raising your concerns with the working group?  I believe
there is a fair bit of interest in providing mouse lock in the
non-fullscreen case too.  I can imagine it may require some additional UI.

It makes sense to me to design the mouse lock API with the idea that it
could work in either fullscreen or non-fullscreen mode.  Then it just
becomes a question of policy and UI as to whether it runs in neither, one or
both.

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

Re: [webkit-dev] Mouse Lock API

[Darin Fisher]

On Thu, Sep 22, 2011 at 2:23 PM, Alexey Proskuryakov  wrote:

>
> 21.09.2011, в 12:52, Darin Fisher написал(а):
>
> True, although there are still questions about how the user experience will
> work for non-fullscreen.  I think we only feel confident that we have a
> decent fullscreen solution at this point, and the plan was to restrict the
> initial implementation to fullscreen mode for that reason.
>
>
> Would it make sense to simplify the API too? Parts of it seem unnecessary
> if mouse lock only works in full screen - all additions to MouseEvent in
> particular can likely be dropped. Security considerations are also
> substantially different.
>
> It might be more productive to treat fullscreen mouse lock as a complete
> API, with only a potential for being some day extended to support windowed
> mode.
>
> - WBR, Alexey Proskuryakov
>
>

Our next step is to extend this to non-fullscreen, so I think it would be
counter-productive to preclude non-fullscreen at this time.

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

Re: [webkit-dev] Mouse Lock API

[Darin Fisher]

On Wed, Sep 21, 2011 at 12:46 PM, Peter Kasting wrote:

> On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov wrote:
>
>> Anyway, I'm not sure if we already agreed that mouse lock is only
>> desirable in full screen. I think that the spec has the goal of enabling it
>> in browser windows.
>>
>
> Indeed, this is explicitly a use case we want to allow.  It's reasonable to
> want to play many mouse-lock-requiring games (Quake, Starcraft, etc.) in
> non-fullscreen mode, e.g. so one can still keep some other critical display
> open elsewhere on the screen.
>
> PK
>

True, although there are still questions about how the user experience will
work for non-fullscreen.  I think we only feel confident that we have a
decent fullscreen solution at this point, and the plan was to restrict the
initial implementation to fullscreen mode for that reason.

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

Re: [webkit-dev] Mouse Lock API

[Darin Fisher]

On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov  wrote:

>
> 21.09.2011, в 11:21, James Robinson написал(а):
>
> >> one can always move the mouse pointer to top of screen to get back their
>> menu bar.
>> > Is that a Mac thing?
>>
>> Yes, this is how fullscreen applications regularly work on OS X.
>>
>
> This is not true for several Flash-based fullscreen video players that I've
> used on my mac.  The interaction there is that upon entering fullscreen
> Flash displays an overlay indicating that hitting ESC will exit fullscreen
> mode and the video player displays its controls near the bottom of the
> screen.  After these fade away, the video controls appear only when moving
> the mouse pointer to the bottom ~1/3rd of the screen.  Moving the mouse
> pointer to the top of the screen does nothing.  Hitting ESC or clicking on
> the appropriate button in the video player's controls exits fullscreen mode.
>  This seems entirely reasonable to me, the keyboard control is provided by
> Flash itself to prevent bad SWFs from taking control of my computer and the
> SWF itself provides the additional controls that make sense for its domain.
>
>
> You are describing how Flash exits full screen, and the fact that it
> apparently always has mouse lock in full screen (so you cannot get to
> browser menu bar by moving mouse pointer up). It's a different behavior from
> what this API provides.
>
> Besides being a security measure for a subtly different feature, Flash
> behavior is quite annoying, and not very efficient - see e.g. <
> http://www.bunnyhero.org/2008/05/10/scaring-people-with-fullscreen/>.
>
> To demonstrate the difference with Flash, there is no mouse lock in Safari
> fullscreen, so you can move the mouse pointer up to get the menu bar.
>
> Anyway, I'm not sure if we already agreed that mouse lock is only desirable
> in full screen. I think that the spec has the goal of enabling it in browser
> windows.
>
> 21.09.2011, в 11:22, Darin Fisher написал(а):
>
> basing APIs largely on how Windows used to work up to version 7 may not be
>> future proof.
>>
>
> Yes, but >90% of internet users are not familiar with Metro.  They are
> familiar with Windows as it exists today (XP thru 7).
>
>
> More than 90% is an understatement :)
>
> Is your implication that Microsoft will be forced to make future Windows UI
> behave the same as Windows 7 does? Otherwise, it's not clear to me how a
> reference to old behavior is relevant to being future proof.
>


My point was that emulating the behavior that most users are familiar with
will likely create a predictable user experience.  Most users are familiar
with hitting ESC to exit fullscreen, so it seems sensible to piggyback on
that.

By the way, wouldn't it be better to debate this API in the WebEvents WG?

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

Re: [webkit-dev] Mouse Lock API

[Darin Fisher]

On Wed, Sep 21, 2011 at 11:11 AM, Alexey Proskuryakov  wrote:

>
> 21.09.2011, в 10:56, Eric Uhrhane написал(а):
>
> >> one can always move the mouse pointer to top of screen to get back their
> menu bar.
> > Is that a Mac thing?
>
> Yes, this is how fullscreen applications regularly work on OS X.
>
> >  Mousing around in a fullscreen flash app on
> > Linux or Windows 7 certainly doesn't pop up a menu bar when I hit the
> > top.  And the way out is always to hit ESC [although there's often a
> > button as well, depending on the application], so I'm not sure what
> > the problem with fullscreen mouse lock would be.
>
> I do not have recent knowledge of Linux, but my understanding is that
> Windows UI is undergoing a major redesign with Metro, so basing APIs largely
> on how Windows used to work up to version 7 may not be future proof.
>
>
Yes, but >90% of internet users are not familiar with Metro.  They are
familiar with Windows as it exists today (XP thru 7).

-Darin




> - WBR, Alexey Proskuryakov
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ENABLE flag cleanup strawman proposal

[Darin Fisher]

On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth  wrote:

> I've updated the spreadsheet of all ENABLE flags to match TOT (as of
> this afternoon):
>
>
> https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Ync&authkey=CJCDiooK&hl=en_US#gid=0
>
> I've gone through the list and marked some of them that we might want
> to change, listed below.  I expect this list to be somewhat
> controversial.  Please consider it as a starting point for discussion.
>
> This proposal introduces a new kinds of flag: DEBUG.  A DEBUG flag is
> only that we expect will only be used by developers locally to debug
> WebKit.  For example, ENABLE(DEBUG_MATH_LAYOUT) and
> ENABLE(SAMPLING_COUNTERS) are only used to debug locally, not to ship
> to end users.  The main benefit of labeling these flags as DEBUG-only,
> for example as DEBUG(MATH_LAYOUT), is that contributors don't need to
> worry as much about breaking them.  (Of course, we still shouldn't try
> to break them capriciously.)
>
> I'd like to emphasize again that this list is just a starting point
> for discussion.  I look forward to your feedback.
>
> Thanks,
> Adam
>
>
> == Rename ==
>
> ENABLE(DATABASE) => ENABLE(SQL_DATABASE)
> ENABLE(LEVELDB) => USE(LEVELDB)
> ENABLE(ON_FIRST_TEXTAREA_FOCUS_SELECT_ALL) => Should be an editing behavior
> ENABLE(OPENTYPE_SANITIZER) => USE(OPENTYPE_SANITIZER)
> ENABLE(SYMBIAN_DIALOG_PROVIDERS) => USE(SYMBIAN_DIALOG_PROVIDERS)
> ENABLE(TILED_BACKING_STORE) => USE(TILED_BACKING_STORE)
>
>
> == Always Disable (Delete Code) ==
>
> ENABLE(APPLICATION_CACHE_DYNAMIC_ENTRIES)
> ENABLE(FTPDIR)
> ENABLE(ICONDATABASE) ???
> ENABLE(WBXML)
> ENABLE(WCSS)
> ENABLE(XHTMLMP)
>
>
> == Always Enable ==
>
> ENABLE(DETAILS) ???
> ENABLE(DOM_STORAGE)
> ENABLE(EVENTSOURCE)
> ENABLE(INSPECTOR) ???
> ENABLE(METER_TAG)
> ENABLE(OFFLINE_WEB_APPLICATIONS)
> ENABLE(PROGRESS_TAG)
> ENABLE(SVG_ANIMATION) => Gated on ENABLE(SVG)
> ENABLE(SVG_AS_IMAGE) => Gated on ENABLE(SVG)
> ENABLE(SVG_DOM_OBJC_BINDINGS) => Gated on ENABLE(SVG)
> ENABLE(SVG_FONTS) => Gated on ENABLE(SVG)
> ENABLE(WEB_TIMING) ??? (I think Maciej has concerns about this
> feature, so maybe keep configurable.)
> ENABLE(WTF_MULTIPLE_THREADS) <-- ggaren is already making this happen,
> right?
> ENABLE(XHR_RESPONSE_BLOB) => Gated by ENABLE(BLOB)
>

^^^ I think this one probably needs to remain since we haven't implemented
the backend for XHR.responseType == "Blob" yet, but other (core) Blob
related APIs are implemented.

What about ENABLE(REQUEST_ANIMATION_FRAME)?

-Darin




> ENABLE(XPATH)
> ENABLE(XSLT)
>
>
> == Mark as for Debugging ==
>
> ENABLE(CODEBLOCK_SAMPLING) => DEBUG(CODEBLOCK_SAMPLING)
> ENABLE(DEBUG_MATH_LAYOUT) => DEBUG(MATH_LAYOUT)
> ENABLE(DEBUG_WITH_BREAKPOINT) => DEBUG(WITH_BREAKPOINT)
> ENABLE(FAST_MALLOC_MATCH_VALIDATION) => DEBUG(FAST_MALLOC_MATCH_VALIDATION)
> ENABLE(GC_VALIDATION) => DEBUG(GC_VALIDATION)
> ENABLE(OPCODE_SAMPLING) => DEBUG(OPCODE_SAMPLING)
> ENABLE(OPCODE_STATS) => DEBUG(OPCODE_STATS)
> ENABLE(REGEXP_TRACING) => DEBUG(REGEXP_TRACING)
> ENABLE(SAMPLING_COUNTERS) => DEBUG(SAMPLING_COUNTERS)
> ENABLE(SAMPLING_FLAGS) => DEBUG(SAMPLING_FLAGS)
> ENABLE(SAMPLING_THREAD) => DEBUG(SAMPLING_THREAD)
> ENABLE(WTF_MALLOC_VALIDATION) => DEBUG(WTF_MALLOC_VALIDATION)
> ENABLE(YARR_JIT_DEBUG) => DEBUG(YARR_JIT)
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Timing updates for SVG SMIL animations

[Darin Fisher]

Perhaps related to this thread, shouldn't we be basing SVG animations off of
the same animation scheduler that drives requestAnimationFrame and soon CSS
animations (https://bugs.webkit.org/show_bug.cgi?id=64591)?  It seems less
than ideal to use a Timer.

-Darin


On Wed, Jul 27, 2011 at 11:14 AM, Scott Graham  wrote:

> Hi,
>
> When the Timer is fired for SMILTimeContainer to update animations, the
> elapsed time is calculated based on the client's currentTime().
>
> That elapsed time is passed into updateAnimations and is used most of the
> way "down".
>
> In some cases during the update though, SMILTimeContainer::elapsed() is
> re-called (e.g. in SVGSMILElement::beginListChanged, endListChanged,
> createInstanceTimesFromSyncbase).
>
> This seems somewhat incorrect because it means that various parts of the
> animation will be updated with (slightly) different elapsed times than
> others. It also makes it impractical to use a debugger to step the code.
>
> Does anyone disagree that all updates should use the same elapsed time
> during the update? Or, in other words, is there any reason to re-get the
> current wallclock time during the update?
>
> Thanks,
> Scott
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] New feature:

[Darin Fisher]

Hello WebKit!

I just wanted to inform the list that we are working to develop a new
feature that will enable web pages to force a navigation to act like it was
served with a "Content-Disposition: attachment" response header.

We want to solve several use cases:

1-  Support for initiating downloads from off-line applications.  Make it
possible to download a data, blob, or filesystem URL, and present the user
with a suggested filename for the download.

2-  Support for initiating downloads when you do not have easy control over
response headers.  For example, it may be a pain to configure a C-D header
server side.

3-  Related to #2, sometimes you want to have dynamic control over whether a
URL is served with a C-D header or not.  This typically involves adding a
query parameter to the URL (?download=true), but this means that you are
bloating web caches.

This feature is being discussed here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032431.html

As you can see this is something that has been discussed before.  There's
been a lot of prior interest in solving the use case.  Originally, we
thought a simple rel="attachment" would suffice, but it turns out that an
earlier proposal for  seems to be gaining the most
traction.  (Unlike rel="attachment", @download gives the developer control
over the filename.)  At any rate, Mozilla seems to like the proposal (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032490.html),
and this feature is on track to be added to the HTML spec.

There are some open security concerns as this enables foo.com to force
resources from bar.com to be downloaded.  This issue is being discussed.

If you have input into the design of this feature, please follow-up with the
whatwg thread.  I just wanted to make sure that folks on webkit-dev were
aware of this work.

The WebKit bug is here:
https://bugs.webkit.org/show_bug.cgi?id=64580

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

Re: [webkit-dev] [New DOM property] selectionDirection on HTMLInputElement and HTMLTextAreaElement

[Darin Fisher]

On Fri, Jul 15, 2011 at 2:08 PM, Ryosuke Niwa  wrote:

> On Fri, Jul 15, 2011 at 2:01 PM, Darin Fisher  wrote:
>
>> I should have also asked:  do you have the support of other browser
>> vendors for this feature?  Or, is it possible that when they set out to
>> solve this problem that they might end up doing it differently?  Are you
>> sure we shouldn't vendor prefix this method if we are going to be the only
>> implementer?
>
>
> I can't think of any other way this property can be implemented. So no, I
> don't think there's a chance for other vendors to implement this API
> differently.  If anything, they may never implement "none" because
> directionless selection is Mac-ism but the spec covers that case as well.
>
> - Ryosuke
>
>

OK... we've been burned in the recent past, so just wanted to make sure.
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [New DOM property] selectionDirection on HTMLInputElement and HTMLTextAreaElement

[Darin Fisher]

I should have also asked:  do you have the support of other browser vendors
for this feature?  Or, is it possible that when they set out to solve this
problem that they might end up doing it differently?  Are you sure we
shouldn't vendor prefix this method if we are going to be the only
implementer?

-Darin


On Fri, Jul 15, 2011 at 11:26 AM, Ryosuke Niwa  wrote:

> No, as far as I know.
>
> - Ryosuke
>
> On Fri, Jul 15, 2011 at 11:04 AM, Darin Fisher  wrote:
>
>> Are any other browsers implementing it?
>> On Jul 14, 2011 5:47 PM, "Ryosuke Niwa"  wrote:
>> > Hi all,
>> >
>> > I have a patch to add selectionDirection property on HTMLInputElement
>> and
>> > HTMLTextAreaElement on https://bugs.webkit.org/show_bug.cgi?id=60403.
>> >
>> > The purpose of this property is to let websites control base and extent
>> of
>> > selection. The property has been added to the HTML5 spec section
>> > 4.10.20<
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection
>> >,
>>
>> > and an extensive discussion about this
>> > feature<
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029814.html
>> >
>>
>> > has
>> > been done on whatwg. Given the discussion took place on whatwg and how
>> > simple this API is, I consider it to be a stable API.
>> >
>> > Best,
>> > Ryosuke Niwa
>> > Software Engineer
>> > Google Inc.
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [New DOM property] selectionDirection on HTMLInputElement and HTMLTextAreaElement

[Darin Fisher]

Are any other browsers implementing it?
On Jul 14, 2011 5:47 PM, "Ryosuke Niwa"  wrote:
> Hi all,
>
> I have a patch to add selectionDirection property on HTMLInputElement and
> HTMLTextAreaElement on https://bugs.webkit.org/show_bug.cgi?id=60403.
>
> The purpose of this property is to let websites control base and extent of
> selection. The property has been added to the HTML5 spec section
> 4.10.20<
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection
>,
> and an extensive discussion about this
> feature<
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029814.html
>
> has
> been done on whatwg. Given the discussion took place on whatwg and how
> simple this API is, I consider it to be a stable API.
>
> Best,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Slow idioms with WTF::String

[Darin Fisher]

On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler  wrote:

> Hi folks.
>
> The key to fast use of WTF::String is to avoid creating temporary
> WTF::StringImpl objects or temporary copies of string data.
>
> With the latest enhancements to WTF::String, here are the preferred fast
> ways to build a new string:
>
>- A single expression with the + operator and arguments of type
> WTF::String, char, UChar, const char*, const UChar*, Vector, and
> WTF::AtomicString.
>- A call to the WTF::makeString function.
>- An expression that uses a single function on the string, or uses the +
> operator exactly once, or the += operator with the types it supports
> directly.
>- WTF::StringBuilder, in cases where the logic to compute the pieces of
> the string has complex branching logic or requires a loop.
>
> Here are acceptable, but not preferred ways to build a new string:
>
>- Building up a Vector followed by WTF::String::adopt. I believe
> StringBuilder is always better, so we should probably retire this idiom.
>
> Inefficient ways to build a new string include any uses of more than one of
> the following:
>
>- WTF::String::append.
>- The += operator.
>
> There are other operations that modify the WTF::String; none of those are
> efficient if the string in question is then modified further.
>
>- WTF::String::insert.
>- WTF::String::replace.
>
> In addition, there are quite a few operations that return a WTF::String,
> and none of those are efficient if the string in question is then modified
> further.
>
>- WTF::String::number.
>- WTF::String::substring.
>- WTF::String::left.
>- WTF::String::right.
>- WTF::String::lower.
>- WTF::String::upper.
>- WTF::String::stripWhiteSpace.
>- WTF::String::simplifyWhiteSpace.
>- WTF::String::removeCharacters.
>- WTF::String::foldCase.
>- WTF::String::format.
>- WTF::String::fromUTF8.
>
> One reason I bring this up is that if we wanted to make combinations of
> these more efficient, we might be able to use techniques similar to those
> used in StringOperators.h to make it so the entire result string is built at
> one time, eliminating unnecessary copies of the string characters and
> intermediate StringImpl objects on the heap.
>
> It would be interesting to find out how often the inefficient idioms are
> used. Until recently, there was no significantly better alternative to the
> inefficient idioms, so it’s highly likely we have them in multiple places.
>
> A quick grep showed me inefficient uses of += in
> XMLDocumentParser::handleError and XPath::FunTranslate::evaluate,
> parseRFC822HeaderFields, InspectorStyleSheet::addRule, drawElementTitle in
> DOMNodeHighlighter.cpp, WebKitCSSTransformValue::cssText,
> CSSSelector::selectorText, CSSPrimitiveValue::cssText,
> CSSBorderImageValue::cssText, and CSSParser::createKeyframeRule.
>
> I would not be surprised if at least some of these will show up immediately
> with the right kind of performance test. The CSS parsing and serialization
> functions seem almost certain to be measurably slow.
>
> I’m looking for two related things:
>
>1) A clean way to find and root out uses of the inefficient idioms that
> we can work on together as a team.
>
> 2) Some ways to further refine WTF::String so it’s harder to “use it
> wrong”. I don’t have any immediate steps in mind, but one possibility would
> be to remove functions that are usually part of poorly-performing idioms,
> pushing WebKit programmers subtly in the direction of operations that don’t
> build intermediate strings.
>
>-- Darin
>
>

This thread resonates very deeply with me (idioms that make it hard to write
slow code == pure goodness), but I suspect we really ought to build
performance tests to help support these improvements.  It is easy to put a
lot of energy into optimizing code that provides no measurable benefit :-/

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

Re: [webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?

[Darin Fisher]

Vendor prefixing has proven to be vital to allowing one vendor to experiment
with an idea before it has broad support for implementation by other
vendors.  It also means that we don't need to have coordination between
vendors about release schedules for new APIs.  Related to that, it also
means that we don't dig ourselves a hole by introducing APIs we might later
regret, which helps avoid web platform fragmentation.  We get the
opportunity, via renaming, to greatly alter the behavior of an API and
converge on standards.

Despite the blog post you quote, RAF is actually a great example of vendor
prefixing working well.  The original version of mozRAF doesn't work like
the current one [
http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html].
 Note, how it didn't take any arguments, but instead signaled the user via a
MozPaintEvent!  When we built webkitRAF, we decided that a function argument
was better.  Mozilla agreed and then changed their implementation.  Note, I
believe they had never shipped the first version to a stable channel, so it
was easy for them to make the change.

Sometimes, you can think you are confident enough and have enough agreement
on an API to go ahead with a non-vendor prefixed implementation.  We did
that with Blob.slice.  The spec was written by Arun from Mozilla, and there
was a lot of review and debate about the API.  Mozilla even had an
implementation, but they had not shipped it yet.  We figured it was unlikely
to require vendor prefixing.  Well, it turns out that on the eve of Firefox
4, someone realized that it should change to be more like Array.slice.
 Unfortunately, we had already shipped the old Blob.slice.  Our remedy in
this case was pretty awful.  See
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0222.html.
 Safari hadn't yet shipped Blob.slice, so only Chrome was impacted by the
change.  Brendan made a pretty convincing argument that one vendor shipping
non-prefixed shouldn't shackle others into implementing the same API [
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0201.html].

The FileSystem API is another interesting case.  Opera has had a FS API
forever, but it is totally different than the one that we implemented.  The
one we implemented for WebKit has not yet been implemented by other vendors,
and we haven't really received much feedback.  One can imagine that once
others begin to implement that they will have interesting feedback that
might lead us to wish the API were different.  Hence, it makes a lot of
sense for the FileSystem API to be vendor prefixed.  We get the chance for
the non-prefixed version to be materially different.

Back to the blog you quoted, I think it is very unfortunate that Microsoft
(or any browser vendor) would advocate that people write code using
untestable codepaths involving hypothetical unprefixed API.  I hope the
folks responsible for this one see this thread and fix the issue.  Or, maybe
someone knows how to get in touch with the right people at Microsoft?

-Darin


On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth  wrote:

> The IE blog has had a couple posts recently about new JavaScript APIs
> that are vendor prefixed:
>
>
> http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx
>
> http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx
>
> Here's one of their code examples:
>
> 8<
> // Future-proof: when feature is fully standardized
> if (window.requestAnimationFrame) window.requestAnimationFrame(draw);
> // IE implementation
> else if (window.msRequestAnimationFrame)
> window.msRequestAnimationFrame(draw);
> // Firefox implementation
> else if (window.mozRequestAnimationFrame)
> window.mozRequestAnimationFrame(draw);
> // Chrome implementation
> else if (window.webkitRequestAnimationFrame)
> window.webkitRequestAnimationFrame(draw);
> // Other browsers that do not yet support feature
> else setTimeout(draw, PERIOD);
> >8
>
> There are a couple things to notice:
>
> 1) The requestAnimationFrame API has a vendor prefix in all of these
> implementations, making this code ugly.
> 2) The vendor prefix isn't buying us anything because this code
> assumes that the final, non-prefixed version of the API will work the
> same way that the vendor prefixed version works!
>
> If web developers are going to assume that future, non-prefixed
> versions of the APIs work the same way as current prefixed versions of
> the APIs anyway, we shouldn't bother with prefixed versions because
> we're already locked in to the current behavior, even without the
> prefix.
>
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://li

Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?

[Darin Fisher]

On Fri, Jul 1, 2011 at 3:37 PM, Dirk Pranke  wrote:

> On Fri, Jul 1, 2011 at 3:24 PM, Darin Fisher  wrote:
> > On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler  wrote:
> >>
> >> On Jul 1, 2011, at 2:54 PM, Dirk Pranke wrote:
> >>
> >> > Does that apply to -expected.txt files in the base directories, or
> just
> >> > platform-specific exceptions?
> >>
> >> Base directories.
> >>
> >> Expected files contain output reflecting the behavior of WebKit at the
> >> time the test was checked in. The expected result when we re-run a test.
> >> Many expected files contain text that says “FAIL” in them. The fact that
> >> these expected results are not successes, but rather expected failures
> does
> >> not seem to me to be a subtle point, but one of the basic things about
> how
> >> these tests are set up.
> >
> > Right, it helps us keep track of where we are, so that we don't regress,
> and
> > only make forward progress.
> >
> >>
> >> > I wonder how it is that I've been working (admittedly, mostly on
> >> > tooling) in WebKit for more that two years and this is the first I'm
> hearing
> >> > about this.
> >>
> >> I’m guessing it’s because you have been working on Chrome.
> >>
> >> The Chrome project came up with a different system for testing layered
> on
> >> top of the original layout test machinery based on different concepts. I
> >> don’t think anyone ever discussed that system with me; I was the one who
> >> created the original layout test system, to help Dave Hyatt originally,
> and
> >> then later the rest of the team started using it.
> >
> > The granular annotations (more than just SKIP) in test_expectations.txt
> was
> > something we introduced back when Chrome was failing a large percentage
> of
> > layout tests, and we needed a system to help us triage the failures.  It
> was
> > useful to distinguish tests that crash from tests that generate bad
> results,
> > for example.  We then focused on the crashing tests first.
> > In addition, we wanted to understand how divergent we were from the
> standard
> > WebKit port, and we wanted to know if we were failing to match text
> results
> > or just image results.  This allowed us to measure our degree of
> > incompatibility with standard WebKit.  We basically used this mechanism
> to
> > classify differences that mattered and differences that didn't matter.
> > I think that if we had just checked in a bunch of port-specific "failure"
> > expectations as -expected files, then we would have had a hard time
> > distinguishing failures we needed to fix for compat reasons from failures
> > that were expected (e.g., because we have different looking form
> controls).
> > I'm not sure if we are at a point now where this mechanism isn't useful,
> but
> > I kind of suspect that it will always be useful.  Afterall, it is not
> > uncommon for a code change to result in different rendering behavior
> between
> > the ports.  I think it is valuable to have a measure of divergence
> between
> > the various WebKit ports.  We want to minimize such divergence from a web
> > compat point of view, of course.  Maybe the count of SKIPPED tests is
> > enough?  But, then we suffer from not running the tests at all.  At least
> by
> > annotating expected IMAGE failures, we get to know that the TEXT output
> is
> > the same and that we don't expect a CRASH.
>
> There's at least two reasons for divergence .. one is that the port is
> actually doing the wrong thing, and the other is that the port is
> doing the "right" thing but the output is different anyway (e.g., a
> control is rendered differently). We cannot easily separate the two if
> we have only a single convention (platform-specific -expected files),
> but SKIPPING tests seems wrong for either category.
>
> It seems like -failing gives you the control you would want, no?
> Obviously, it wouldn't help the thousands of -expected files that are
> "wrong" but at least it could keep things from getting worse.
>
> I will note that reftests might solve some issues but not all of them
> (since obviously code could render both pages "wrong").
>
> -- Dirk
>
>
I'm not sure.  It makes me a bit uneasy adding even more heft to the
LayoutTests directory.

-Darin




> > I suspect this isn't the best solution to the problem though.
> > -Darin
> >
> >
> >>
> >> > Are th

Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?

[Darin Fisher]

On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler  wrote:

> On Jul 1, 2011, at 2:54 PM, Dirk Pranke wrote:
>
> > Does that apply to -expected.txt files in the base directories, or just
> platform-specific exceptions?
>
> Base directories.
>
> Expected files contain output reflecting the behavior of WebKit at the time
> the test was checked in. The expected result when we re-run a test. Many
> expected files contain text that says “FAIL” in them. The fact that these
> expected results are not successes, but rather expected failures does not
> seem to me to be a subtle point, but one of the basic things about how these
> tests are set up.
>

Right, it helps us keep track of where we are, so that we don't regress, and
only make forward progress.



>
> > I wonder how it is that I've been working (admittedly, mostly on tooling)
> in WebKit for more that two years and this is the first I'm hearing about
> this.
>
> I’m guessing it’s because you have been working on Chrome.
>
> The Chrome project came up with a different system for testing layered on
> top of the original layout test machinery based on different concepts. I
> don’t think anyone ever discussed that system with me; I was the one who
> created the original layout test system, to help Dave Hyatt originally, and
> then later the rest of the team started using it.
>

The granular annotations (more than just SKIP) in test_expectations.txt was
something we introduced back when Chrome was failing a large percentage of
layout tests, and we needed a system to help us triage the failures.  It was
useful to distinguish tests that crash from tests that generate bad results,
for example.  We then focused on the crashing tests first.

In addition, we wanted to understand how divergent we were from the standard
WebKit port, and we wanted to know if we were failing to match text results
or just image results.  This allowed us to measure our degree of
incompatibility with standard WebKit.  We basically used this mechanism to
classify differences that mattered and differences that didn't matter.

I think that if we had just checked in a bunch of port-specific "failure"
expectations as -expected files, then we would have had a hard time
distinguishing failures we needed to fix for compat reasons from failures
that were expected (e.g., because we have different looking form controls).

I'm not sure if we are at a point now where this mechanism isn't useful, but
I kind of suspect that it will always be useful.  Afterall, it is not
uncommon for a code change to result in different rendering behavior between
the ports.  I think it is valuable to have a measure of divergence between
the various WebKit ports.  We want to minimize such divergence from a web
compat point of view, of course.  Maybe the count of SKIPPED tests is
enough?  But, then we suffer from not running the tests at all.  At least by
annotating expected IMAGE failures, we get to know that the TEXT output is
the same and that we don't expect a CRASH.

I suspect this isn't the best solution to the problem though.

-Darin




>
> > Are there reasons we [are] doing things this way[?]
>
> Sure. The idea of the layout test framework is to check if the code is
> still behaving as it did when the test was created and last run; we want to
> detect any changes in behavior that are not expected. When there are
> expected changes in behavior, we change the contents of the expected results
> files.
>
> It seems possibly helpful to augment the test system with editorial
> comments about which tests show bugs that we’d want to fix. But I wouldn’t
> want to stop running all regression tests where the output reflects the
> effects of a bug or missing feature.
>
>-- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Darin Fisher]

On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov  wrote:

>
> 26.06.2011, в 19:37, Sreeram Ramachandran написал(а):
>
> >> I'm not sure if historically browsers were often taking the liberty of
> crippling widely used features in this way. We didn't kill marquee, for
> instance. For another example, I know that a lot of users dislike animated
> GIFs, and yet we haven't removed support for those.
> >
> > Yet, we killed the blink tag and block popups. I don't think there's a
> > clear consistency here. Some things we deem to have crossed the line,
> > some we don't. In this case, Ian Hickson has suggested that blocking
> > alerts might be worth codifying into the standard
> > (https://bugs.webkit.org/show_bug.cgi?id=56397#c15).
>
> These examples are both somewhat different from blocking alerts as
> proposed:
> - Killing blink hardly removed any semantic meaning from pages.
> - Killing pop-ups did, so browsers have super accessible preferences and/or
> notifications for that. Note how Safari has the preference right in
> application menu.
>
> Perhaps the pop-up preference should be extended (and renamed) to cover the
> proposed behavior?
>
> - WBR, Alexey Proskuryakov
>
>

I don't understand the comparison you are making.  Popups are/were way more
common
than alerts generated from unload.  Way, way more common.

You mentioned marquee earlier.  That was only added by the Gecko engineers
because
their arms were twisted by management.  So sad.  There are plenty of other
IE'isms that
we did not implement, despite suffering web compat problems.

I'm pretty surprised that you are so concerned about this change.  It seems
like we have
learned that alerts in unload handlers are not very common.  Yes, they are
more common
than expected, but upon closer inspection the usage is poor (trying
to prevent users from
leaving a site).

For multi-process browsers, we see a big benefit to be had by disallowing
these dialogs.
It would potentially allow us to hide tabs immediately when the user closes
them.  We
would no longer need to keep the tab visible while we wait for the unload
handler to run.
Keep in mind that in a multi-process browser, the tab being closed could be
bound to a
process that is entirely swapped out.  Paging it in to run unload handlers
could be very
costly.  Alternative solutions, like bringing the hidden tab back into view
when it pops up
an alert, are not satisfactory either.  That leads to ripping the user's
focus away from what
they want to do next.  That's not good UI.

I think we can make this behavior a Setting, and then certainly each
embedder of WebKit
can decide how prominently to surface this option.  For Chrome, we'll
probably either make
it be a command line flag, or we would just leave out the option entirely.

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

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Darin Fisher]

On Sun, Jun 26, 2011 at 1:53 PM, Sreeram Ramachandran
wrote:

> On Sun, Jun 26, 2011 at 13:40, Ryosuke Niwa  wrote:
> > On Sun, Jun 26, 2011 at 1:37 PM, Ryosuke Niwa  wrote:
> >>
> >> On Sun, Jun 26, 2011 at 1:34 PM, Sreeram Ramachandran
> >>  wrote:
> >>>
> >>> A confirm() can't actually do the first option ("Don't leave"). I
> >>> believe there's nothing a page can do to prevent the navigation once
> >>> it is in unload. The only way it can prevent it is by installing a
> >>> beforeunload and returning a string.
> >>
> >> Right.  So a web page can first ask whether a user wants to save states
> or
> >> not.  Then ask whether a user really wants to leave a page or not using
> >> beforeunload.
> >
> > To further clarify, it doesn't even have to use beforeunload.  The
> important
> > thing is that if we disallow confirm in beforeunload, unload, etc... then
> > web apps will have no way of asking a user if he/she wants to save
> states.
>
> The problem is that if we disallow alerts, but not confirm/prompt,
> webpages will just gravitate to using confirm() to annoy the user. As
> I said, the only uses of confirm() I actually saw were of this type
> already. Those who wanted to save state are already doing it without
> asking the user for explicit confirmation.
>
> If the argument is purely that somebody _might_ want to use it, since
> confirm/prompt functionality can't be exactly duplicated in another
> way, then I submit the case of showModalDialog(). Certainly you can do
> things with showModalDIalog() (such as popping up a form with the
> state, allowing the user to edit and submit) that can't be done with
> alert/confirm/prompt. However, we already disallow these, since by
> default, popup blocking kills these. I don't see anybody championing
> the need of developers to be able to use showModalDialog, because we
> recognize that they are extremely annoying, especially when you are
> trying to leave a page.


Thanks for gathering that data.

It sounds to me like the next step is to push out a version of Chrome to the
dev channel that
disallows alert, confirm, prompt during unload and beforeunload.  Then,
let's see if we get any
bugs filed against Chrome by users who feel that this change impairs their
usage of a web site.

I suspect the only bug reports we might see would come from web developers,
who miss this
ability to nag users.

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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

I think there are web app developers that would do things differently if
they
knew their user was running on battery power.  An app might scale back its
CPU usage, or run a timer at a lower frequency.  Crazy idea: Maybe an
advertising network could be "nice" and not show animated ads to such
users? ;-)

-Darin


On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel  wrote:

> My 2¢:
>
> I'm confused by who the client of this API would be.
>
> It seems that "web sites" don't really need to know my battery state.
> But "web applications" that are on mobile phone (like WebOS, or
> Apple's original vision for iPhone apps) would want battery state
> information, but would want *more* information than this spec provides
> (imagine trying to write any power-management application like the
> zillion examples available for Apple's Dashboard, or iPhone).
>
> I'm also not sure that I want all web sites knowing this information.
> I wonder what fingerprinting vectors this API would expose (if any?).
> Certainly websites could know if their visitors are laptop users or
> not (but I suspect they can already figure that out from screen size
> and UA strings).
>
> It's also possible that I'm just spreading FUD here, and that smarter
> people than I have already hashed this all out on the spec list...
>
> -eric
>
> On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher  wrote:
> >
> >
> > On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu 
> wrote:
> >>
> >> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher 
> wrote:
> >> >
> >> >
> >> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >> >  wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >> >
> >> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> >> >  wrote:
> >> >> >
> >> >> > On 15.6.2011, at 21.29, ext Darin Fisher wrote:
> >> >> >
> >> >> > > There should probably be a way to poll the current state.  Much
> as
> >> >> > > you
> >> >> > > can poll the document.readyState and respond to progress events,
> it
> >> >> > > would
> >> >> > > seem to make sense to have a way to poll the battery state as
> well
> >> >> > > as
> >> >> > > respond to battery state change events.
> >> >> >
> >> >> > The current design is quite similar to that of the Device
> Orientation
> >> >> > Event. We discussed the polling option but settled on the current
> >> >> > design.
> >> >> > Let me know if you'd like me to dig into archives for some pointers
> >> >> > on that
> >> >> > design decision.
> >> >> >
> >> >> > I'd be curious to read them.  Off-hand it seems like device
> >> >> > orientation
> >> >> > suffers from the same problem.  You wouldn't want the application
> to
> >> >> > do too
> >> >> > much work that would be discarded once it finds out that the
> >> >> > orientation is
> >> >> > X instead of Y.
> >> >>
> >> >> I think the design guidelines introduced in the following Mozilla
> >> >> position
> >> >> paper are still valid. In this context, specifically:
> >> >>
> >> >> [[
> >> >>
> >> >> Device APIs should be asynchronous; in particular, user agents should
> >> >> not
> >> >> have to block on return values of Device API function calls, and
> Device
> >> >> APIs
> >> >> should be driven by callbacks.
> >> >>
> >> >>  http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous
> >> >>
> >> >> ]]
> >> >
> >> > The proposal wasn't to make blocking APIs that query any devices.
> >> >  Instead,
> >> > you would be able to get synchronous access to the last known value
> for
> >> > a
> >> > device property ("last known battery state", "last known device
> >> > orientation", etc.).  In particular, you would get access to the last
> >> > known
> >> > value prior to your page being loaded.
> >> > Synchronous access to this va

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu  wrote:

> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher  wrote:
> >
> >
> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >  wrote:
> >>
> >> Hi,
> >>
> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >
> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> >  wrote:
> >> >
> >> > On 15.6.2011, at 21.29, ext Darin Fisher wrote:
> >> >
> >> > > There should probably be a way to poll the current state.  Much as
> you
> >> > > can poll the document.readyState and respond to progress events, it
> would
> >> > > seem to make sense to have a way to poll the battery state as well
> as
> >> > > respond to battery state change events.
> >> >
> >> > The current design is quite similar to that of the Device Orientation
> >> > Event. We discussed the polling option but settled on the current
> design.
> >> > Let me know if you'd like me to dig into archives for some pointers on
> that
> >> > design decision.
> >> >
> >> > I'd be curious to read them.  Off-hand it seems like device
> orientation
> >> > suffers from the same problem.  You wouldn't want the application to
> do too
> >> > much work that would be discarded once it finds out that the
> orientation is
> >> > X instead of Y.
> >>
> >> I think the design guidelines introduced in the following Mozilla
> position
> >> paper are still valid. In this context, specifically:
> >>
> >> [[
> >>
> >> Device APIs should be asynchronous; in particular, user agents should
> not
> >> have to block on return values of Device API function calls, and Device
> APIs
> >> should be driven by callbacks.
> >>
> >>  http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous
> >>
> >> ]]
> >
> > The proposal wasn't to make blocking APIs that query any devices.
>  Instead,
> > you would be able to get synchronous access to the last known value for a
> > device property ("last known battery state", "last known device
> > orientation", etc.).  In particular, you would get access to the last
> known
> > value prior to your page being loaded.
> > Synchronous access to this value seems helpful for the reasons stated in
> > this thread.  But, let me expand on that for a moment.  Suppose an
> > application wanted to know both the battery state and the device
> orientation
> > before generating its content.  It would need to asynchronously query
> both
> > states before proceeding.  That seems quite awkward, especially when the
> > information could be provided synchronously.
> >
>
> In the case of device orientation, having such a synchronous property
> would probably mean having the UA do a lot of wasted work, constantly
> exercising the underlying hardware just in case some Web app might
> need this information at start-up. However, I think it's reasonable to
> expect that Web apps using this API will be built in such a way that
> they will do work in response to orientation changes, so it's perhaps
> natural for them to treat the initial orientation the same way.
>
>
That's a good point.

I guess I feel less strongly about orientation events, especially since
there is such a large continuum of states.  Whereas with battery state,
there are fewer states and less frequent changes.

navigator.onLine and the online/offline events are somewhat comparable
to battery state in my opinion.  Both change at a relatively low frequency.

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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen <
anssi.kostiai...@nokia.com> wrote:

> Hi,
>
> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >
> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen <
> anssi.kostiai...@nokia.com> wrote:
> >
> > On 15.6.2011, at 21.29, ext Darin Fisher wrote:
> >
> > > There should probably be a way to poll the current state.  Much as you
> can poll the document.readyState and respond to progress events, it would
> seem to make sense to have a way to poll the battery state as well as
> respond to battery state change events.
> >
> > The current design is quite similar to that of the Device Orientation
> Event. We discussed the polling option but settled on the current design.
> Let me know if you'd like me to dig into archives for some pointers on that
> design decision.
> >
> > I'd be curious to read them.  Off-hand it seems like device orientation
> suffers from the same problem.  You wouldn't want the application to do too
> much work that would be discarded once it finds out that the orientation is
> X instead of Y.
>
> I think the design guidelines introduced in the following Mozilla position
> paper are still valid. In this context, specifically:
>
> [[
>
> Device APIs should be asynchronous; in particular, user agents should not
> have to block on return values of Device API function calls, and Device APIs
> should be driven by callbacks.
>
>  http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous
>
> ]]
>

The proposal wasn't to make blocking APIs that query any devices.  Instead,
you would be able to get synchronous access to the last known value for a
device property ("last known battery state", "last known device
orientation", etc.).  In particular, you would get access to the last known
value prior to your page being loaded.

Synchronous access to this value seems helpful for the reasons stated in
this thread.  But, let me expand on that for a moment.  Suppose an
application wanted to know both the battery state and the device orientation
before generating its content.  It would need to asynchronously query both
states before proceeding.  That seems quite awkward, especially when the
information could be provided synchronously.



>
> > It seems like this is information that we have available immediately, and
> it is a bit unfortunate that page authors need to delay initialization until
> they receive the initial orientation or battery status event.
>
> In addition to the above mentioned reason, a synchronous API might
> encourage web authors to write badly performing code, i.e. poll the battery
> status via setInterval() too often. In the current event-driven design a new
> event is dispatched only when the battery status changes.
>

Do we have experience showing that such polling abuse is a problem caused by
document.readyState?  I think that people would write setInterval based
polling code if there were no convenient event subscription API.  But, the
proposal is to provide both, just as both are provided for page load
progress information.

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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen <
anssi.kostiai...@nokia.com> wrote:

> Hi,
>
> On 15.6.2011, at 20.25, ext Greg Simon wrote:
>
> > From what I can tell the spec offers no way for the web application to
> initialize any algorithm based on the battery/power state because there is
> no guarantee of "minimum time" when a new document is created and the first
> battery event arrives. Ideally there would be a way to "kick" the UA into
> sending the battery event on demand.
>
> To keep the "minimum time" as small as possible, the first
> BatteryStatusEvent should be fed into an appropriate task queue upon event
> listener registration. An excerpt from the spec:
>
> [[
>
> When an event listener is registered with the event type batterystatus,
> then the User Agent must retrieve the relevant information and dispatch a
> BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS].
>
> ]]
>
> The relevant section in the D3E spec would be:
>
>  http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async
>
> > Otherwise the web application starts at full-throttle (burning battery)
> on a device with 10% battery left until it *drains* enough to get a
> batteryEvent.
>
> I agree we'll need to handle that case, and that's why the above-mentioned
> requirement is in the spec.
>
> On 15.6.2011, at 21.29, ext Darin Fisher wrote:
>
> > There should probably be a way to poll the current state.  Much as you
> can poll the document.readyState and respond to progress events, it would
> seem to make sense to have a way to poll the battery state as well as
> respond to battery state change events.
>
> The current design is quite similar to that of the Device Orientation
> Event. We discussed the polling option but settled on the current design.
> Let me know if you'd like me to dig into archives for some pointers on that
> design decision.
>
>
I'd be curious to read them.  Off-hand it seems like device orientation
suffers from the same problem.  You wouldn't want the application to do too
much work that would be discarded once it finds out that the orientation is
X instead of Y.

It seems like this is information that we have available immediately, and it
is a bit unfortunate that page authors need to delay initialization until
they receive the initial orientation or battery status event.

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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

There should probably be a way to poll the current state.  Much as you can
poll the document.readyState and respond to progress events, it would seem
to make sense to have a way to poll the battery state as well as respond to
battery state change events.

-Darin


On Wed, Jun 15, 2011 at 10:25 AM, Greg Simon  wrote:

> From what I can tell the spec offers no way for the web application to
> initialize any algorithm based on the battery/power state because there is
> no guarantee of "minimum time" when a new document is created and the first
> battery event arrives. Ideally there would be a way to "kick" the UA into
> sending the battery event on demand.
>
> Otherwise the web application starts at full-throttle (burning battery) on
> a device with 10% battery left until it *drains* enough to get a
> batteryEvent.
>
>
>
>
> On Wed, Jun 15, 2011 at 10:08 AM, Alexis Menard <
> alexis.men...@openbossa.org> wrote:
>
>> On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu 
>> wrote:
>> > On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson 
>> wrote:
>> >> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther 
>> wrote:
>> >>> On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
>>  Hi,
>> 
>> >>>
>> 
>>  The use-case for us is to enable content developers to implement
>> rudimentary power management (e.g. to stop "expensive" operations on the
>> page, perhaps save state). I'm not sure if this API is really meant for
>> accurately reporting all the possible power management states of the system
>> as Anssi pointed out.
>> >>>
>> >>> Okay, point on complexity taken. My question is what if you want to
>> add
>> >>> complexity, is there something in the event that prevents that (I have
>> no idea
>> >>> about DOM compatibility issues)? Don't get me wrong I think having
>> more device
>> >>> support is great.
>> >>>
>> >>> My other complain was, it is too simple. E.g. 'isPlugged' has no
>> guarantee
>> >>> that the battery is getting charged. Is this a problem?
>> >>
>> >> Why would a web page care about whether the battery is being charged
>> >> when the device is plugged in?
>> >>
>> >
>> > Because it would know not to start doing things that drain the
>> > battery. For instance, powering up a 3G antenna to download your
>> > latest emails could be annoying to users if the battery level is too
>> > low. 3G takes quite a bit of power and the device would be in danger
>> > of powering down.
>>
>> But if the phone is plugged in it can't power down. Most of modern
>> phones don't switch off anymore even if you have the battery low and
>> you play games, surf WiFi, go 3G as soon as you plugged it in. What
>> Brett meant is that it's useless to know that the battery is charging
>> while the phone is plugged in, you just want to know that it will not
>> switch off in any case so you can do whatever you want.
>>
>> >
>> > Thanks,
>> > Andrei
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>>
>>
>>
>> --
>> Alexis Menard
>> Software Engineer
>> INdT Recife Brazil
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Good point!  Maybe we can use a term that is derived from the name of the
spec?  ENABLE_CSS3_FLEXBOX?

-Darin

On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser wrote:

> Using terms like 'new' in code is rarely a good idea. In a year, the
> context has gone, and 'new' no longer means anything.
>
> Simon
>
>
> On Jun 13, 2011, at 9:38 AM, Tony Chang wrote:
>
> Err, ENABLE_NEW_FLEXBOX.
>
> On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:
>
>> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
>>
>>
>> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
>>
>>> Since it is confusing to me (and may be to others), perhaps a different
>>> name than ENABLE_FLEXBOX should be used, given that we already have flexbox.
>>> Maybe, ENABLE_NEW_FLEXBOX?
>>>
>>> -Sam
>>>
>>> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>>>
>>> Just so people know, it was my recommendation that they just start with a
>>> new renderer and implementation.
>>>
>>> Some other recommendations I would make here (apologies if they have been
>>> implemented already):
>>>
>>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the
>>> name, e.g., RenderDeprecatedFlexibleBox.
>>>
>>> (2) The old flexbox was never patched for vertical writing modes. Please
>>> make sure when you build the new renderer from the ground up that you take
>>> this into account.
>>>
>>> (3) Please consult with rendering experts for any changes you have to
>>> make to base classes, especially RenderBlock and RenderBox. We may be able
>>> to help simplify some of that code, especially compared to the old flexbox.
>>>
>>> (4) Use the old flexbox code as a rough guide, but be aware of its
>>> issues, e.g., too much layout when flexing, box-ordinal stuff is very slow,
>>> etc. I think some of the bugs you tried to fix already should inform this
>>> somewhat.
>>>
>>> Definitely keep rendering experts in the loop on this and have fun
>>> implementing!
>>>
>>> Dave
>>>
>>>
>>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>>>
>>> Hi webkit-dev,
>>>
>>> I wanted to let you know that Ojan and I plan to add flexbox layout
>>> support to WebCore.  WebCore already supports an older flexbox
>>> implementation (display: box), but the new spec is designed to be easier for
>>> developers to understand and more powerful.  The old flexbox will still
>>> remain in WebCore since none of the CSS properties overlap with the new
>>> flexbox spec.  The spec can be found at:
>>> http://www.w3.org/TR/css3-flexbox/ (
>>> http://dev.w3.org/csswg/css3-flexbox/
>>> )
>>>
>>> This support will be behind the ENABLE_FLEXBOX feature define (
>>> https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
>>> tracking the feature's development (
>>> https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature
>>> to eventually be enabled by all ports.
>>>
>>> I am ready to setup a buildbot for tracking the compile and flexbox
>>> related layout tests.  Should I go ahead and get this added to
>>> build.webkit.org's waterfall?
>>>
>>> Thanks,
>>> Tony
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

OK, but it is very nice to ship what you test (i.e., avoid the need to
create a separate build of WebCore for testing).  Continuous integration is
also nice (i.e., no branches).

Marrying those constraints leads to runtime enabling features.  This is
precisely the recipe Chromium uses to great avail for features exposed
through JS.  Why wouldn't we want the same for CSS features?

-Darin


On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth  wrote:

> The difference between runtime and compile time enabling seems like a red
> herring.  The issue is more which configurations to test where and to ship
> where, not how to do the configuring.
>
> Adam
>  On Jun 8, 2011 5:25 PM, "Darin Fisher"  wrote:
> > Are you referring to the additional cost of maintaining different test
> > expectations between the two configs? Agreed, that would suck.
> >
> > So, how painful would it be to add runtime enablement support for new CSS
> > features?
> > On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
> >> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher 
> wrote:
> >>>
> >>>
> >>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson 
> wrote:
> >>>>
> >>>> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher 
> wrote:
> >>>>>
> >>>>> Oh, okay. Why do we have override_features.gypi then?
> >>>>
> >>>> We don't, Adam tried to remove it earlier this week and was foiled by
> > some
> >>>> weird complex failure. We should get rid of it ASAP.
> >>>
> >>> OK ... I guess things have changed.
> >>>
> >>>>>
> >>>>> Regardless, it seems like we could create a mechanism so that the
> > result
> >>>>> of build-webkit
> >>>>> uses different ENABLE_ options than a stock Chromium build. There's a
> >>>>> trivial way to switch
> >>>>> b/w the two in the GYP files.
> >>>>
> >>>> There's danger in testing a different set of ENABLE_s than we ship
> > unless
> >>>> we are really confident in understanding how the ENABLE_'d code
> > interacts
> >>>> with the rest of the codebase.
> >>>
> >>>
> >>> I'm not sure that is a big deal. The Chromium build bots at
> >>> build.chromium.org run DRT built from a Chromium checkout. The
> >>> build.webkit.org bots are intended to provide compile and DRT feedback
> > for
> >>> the Chromium port that is visible to the rest of the WebKit community.
> > If
> >>> the configs between build.webkit.org and build.chromium.org differ,
> maybe
> >>> that is not so bad?
> >>
> >> Boy, that seems like a recipe for pain from my point of view. I'd be
> >> against this unless there was a *big* win for some reason.
> >>
> >> -- Dirk
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Are you referring to the additional cost of maintaining different test
expectations between the two configs?  Agreed, that would suck.

So, how painful would it be to add runtime enablement support for new CSS
features?
On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher  wrote:
>>
>>
>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson  wrote:
>>>
>>> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:
>>>>
>>>> Oh, okay.  Why do we have override_features.gypi then?
>>>
>>> We don't, Adam tried to remove it earlier this week and was foiled by
some
>>> weird complex failure.  We should get rid of it ASAP.
>>
>> OK ... I guess things have changed.
>>
>>>>
>>>> Regardless, it seems like we could create a mechanism so that the
result
>>>> of build-webkit
>>>> uses different ENABLE_ options than a stock Chromium build.  There's a
>>>> trivial way to switch
>>>> b/w the two in the GYP files.
>>>
>>> There's danger in testing a different set of ENABLE_s than we ship
unless
>>> we are really confident in understanding how the ENABLE_'d code
interacts
>>> with the rest of the codebase.
>>
>>
>> I'm not sure that is a big deal.  The Chromium build bots at
>> build.chromium.org run DRT built from a Chromium checkout.  The
>> build.webkit.org bots are intended to provide compile and DRT feedback
for
>> the Chromium port that is visible to the rest of the WebKit community.
 If
>> the configs between build.webkit.org and build.chromium.org differ, maybe
>> that is not so bad?
>
> Boy, that seems like a recipe for pain from my point of view. I'd be
> against this unless there was a *big* win for some reason.
>
> -- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

On Wed, Jun 8, 2011 at 4:59 PM, James Robinson  wrote:

> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:
>
>> Oh, okay.  Why do we have override_features.gypi then?
>>
>
> We don't, Adam tried to remove it earlier this week and was foiled by some
> weird complex failure.  We should get rid of it ASAP.
>
>
OK ... I guess things have changed.



>
>> Regardless, it seems like we could create a mechanism so that the result
>> of build-webkit
>> uses different ENABLE_ options than a stock Chromium build.  There's a
>> trivial way to switch
>> b/w the two in the GYP files.
>>
>
> There's danger in testing a different set of ENABLE_s than we ship unless
> we are really confident in understanding how the ENABLE_'d code interacts
> with the rest of the codebase.
>
>

I'm not sure that is a big deal.  The Chromium build bots at
build.chromium.org run DRT built from a Chromium checkout.  The
build.webkit.org bots are intended to provide compile and DRT feedback for
the Chromium port that is visible to the rest of the WebKit community.  If
the configs between build.webkit.org and build.chromium.org differ, maybe
that is not so bad?

Anyways, all of this is just to avoid what would ultimately be a much better
solution:  it should be possible to develop runtime enabled CSS features.
 Then, we wouldn't worry about different build configs or having to stand-up
different build bots.  It would be easier for the next person wanting to
develop a new CSS feature.

-Darin




> - James
>
>>
>> -Darin
>>
>>
>> On Wed, Jun 8, 2011 at 4:29 PM, James Robinson  wrote:
>>
>>> On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher  wrote:
>>>
>>>> It seems like it doesn't scale very well to have to stand-up new
>>>> buildbots for each
>>>> new feature.  At least in the Chromium port, it is possible for the
>>>> Chromium repo
>>>> to override ENABLE_ flags so that only DRT gets built with a prototype
>>>> feature,
>>>> making it easy to test a prototype feature using existing buildbots.
>>>>
>>>>
>>> If you mean by using feature_overrides.gypi to overwrite features.gypi,
>>> that mechanism doesn't actually work and people have attempted to remove it.
>>>  The bots that we actually pay attention to all use feature_overrides.gypi.
>>>  I would not encourage that pattern.
>>>
>>> - James
>>>
>>> -Darin
>>>>
>>>>
>>>> On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:
>>>>
>>>>> If you're super worried about folks shipping the feature before it's
>>>>> ready, then that approach can make sense.  I'm not sure how well it
>>>>> scales, but we can worry about that problem when we have N such
>>>>> configurations.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
>>>>> > I don't understand how changing the name prevents the feature from
>>>>> being
>>>>> > shipped half-done.  If we're going to ship a half-done feature, we
>>>>> may as
>>>>> > well use the vendor prefixed name so sites don't depend on the goofy
>>>>> name.
>>>>> >
>>>>> > However, I'm willing to run a buildbot for this and that seems better
>>>>> than
>>>>> > shipping a half-done feature.  I don't expect it to be a core builder
>>>>> and
>>>>> > Ojan and I will be the ones keeping it green.  Isn't this what we're
>>>>> doing
>>>>> > for other features like CSS Regions and Exclusions?
>>>>> >
>>>>> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth 
>>>>> wrote:
>>>>> >>
>>>>> >> It seems like the simplest thing is to have an ENABLE macro that's
>>>>> >> turned on and to use the normal bots.  If you're really worried
>>>>> about
>>>>> >> folks shipping the feature half-done by accident, you can use a
>>>>> goofy
>>>>> >> name like -webkit-goofybox (or whatever) and rename it to the final
>>>>> >> name when you're ready.
>>>>> >>
>>>>> >> Adam
>>>>> >>
>>>>> >>
>>>>> >> On Wed, Jun 8, 2011 at 1

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Oh, okay.  Why do we have override_features.gypi then?

Regardless, it seems like we could create a mechanism so that the result of
build-webkit
uses different ENABLE_ options than a stock Chromium build.  There's a
trivial way to switch
b/w the two in the GYP files.

-Darin


On Wed, Jun 8, 2011 at 4:29 PM, James Robinson  wrote:

> On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher  wrote:
>
>> It seems like it doesn't scale very well to have to stand-up new buildbots
>> for each
>> new feature.  At least in the Chromium port, it is possible for the
>> Chromium repo
>> to override ENABLE_ flags so that only DRT gets built with a prototype
>> feature,
>> making it easy to test a prototype feature using existing buildbots.
>>
>>
> If you mean by using feature_overrides.gypi to overwrite features.gypi,
> that mechanism doesn't actually work and people have attempted to remove it.
>  The bots that we actually pay attention to all use feature_overrides.gypi.
>  I would not encourage that pattern.
>
> - James
>
> -Darin
>>
>>
>> On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:
>>
>>> If you're super worried about folks shipping the feature before it's
>>> ready, then that approach can make sense.  I'm not sure how well it
>>> scales, but we can worry about that problem when we have N such
>>> configurations.
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
>>> > I don't understand how changing the name prevents the feature from
>>> being
>>> > shipped half-done.  If we're going to ship a half-done feature, we may
>>> as
>>> > well use the vendor prefixed name so sites don't depend on the goofy
>>> name.
>>> >
>>> > However, I'm willing to run a buildbot for this and that seems better
>>> than
>>> > shipping a half-done feature.  I don't expect it to be a core builder
>>> and
>>> > Ojan and I will be the ones keeping it green.  Isn't this what we're
>>> doing
>>> > for other features like CSS Regions and Exclusions?
>>> >
>>> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:
>>> >>
>>> >> It seems like the simplest thing is to have an ENABLE macro that's
>>> >> turned on and to use the normal bots.  If you're really worried about
>>> >> folks shipping the feature half-done by accident, you can use a goofy
>>> >> name like -webkit-goofybox (or whatever) and rename it to the final
>>> >> name when you're ready.
>>> >>
>>> >> Adam
>>> >>
>>> >>
>>> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai 
>>> wrote:
>>> >> > Kind of. We could make the functionality only work at runtime, but
>>> >> > adding
>>> >> > the properties to the CSS parser would be difficult to make runtime
>>> >> > configurable. So, the CSS properties would parse correctly but do
>>> >> > nothing.
>>> >> > That's especially problematic for properties like "display" that
>>> would
>>> >> > then
>>> >> > get an invalid value.
>>> >> > My current plan was still to test this incrementally. We'd include
>>> tests
>>> >> > as
>>> >> > we went, but skip the flexbox subdirectory. We would just run the
>>> tests
>>> >> > locally during development. This has the downside that other changes
>>> >> > might
>>> >> > break the flexbox tests, but thats a pain I'm willing to live with.
>>> >> > I'm fine doing this differently if people have strong opinions.
>>> >> > Ojan
>>> >> >
>>> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
>>> >> > wrote:
>>> >> >>
>>> >> >> Is it possible for this feature to be enabled at runtime?
>>> >> >>
>>> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
>>> >> >> > New features should be tested incrementally as they are
>>> developed.
>>> >> >> > That means running them on build.webkit.org. The decision to
>>> ship a
>>> >> >> > feature is separate.
>>> >> >> >
>>> >> >> >

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

It seems like it doesn't scale very well to have to stand-up new buildbots
for each
new feature.  At least in the Chromium port, it is possible for the Chromium
repo
to override ENABLE_ flags so that only DRT gets built with a prototype
feature,
making it easy to test a prototype feature using existing buildbots.

-Darin


On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:

> If you're super worried about folks shipping the feature before it's
> ready, then that approach can make sense.  I'm not sure how well it
> scales, but we can worry about that problem when we have N such
> configurations.
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
> > I don't understand how changing the name prevents the feature from being
> > shipped half-done.  If we're going to ship a half-done feature, we may as
> > well use the vendor prefixed name so sites don't depend on the goofy
> name.
> >
> > However, I'm willing to run a buildbot for this and that seems better
> than
> > shipping a half-done feature.  I don't expect it to be a core builder and
> > Ojan and I will be the ones keeping it green.  Isn't this what we're
> doing
> > for other features like CSS Regions and Exclusions?
> >
> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:
> >>
> >> It seems like the simplest thing is to have an ENABLE macro that's
> >> turned on and to use the normal bots.  If you're really worried about
> >> folks shipping the feature half-done by accident, you can use a goofy
> >> name like -webkit-goofybox (or whatever) and rename it to the final
> >> name when you're ready.
> >>
> >> Adam
> >>
> >>
> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai  wrote:
> >> > Kind of. We could make the functionality only work at runtime, but
> >> > adding
> >> > the properties to the CSS parser would be difficult to make runtime
> >> > configurable. So, the CSS properties would parse correctly but do
> >> > nothing.
> >> > That's especially problematic for properties like "display" that would
> >> > then
> >> > get an invalid value.
> >> > My current plan was still to test this incrementally. We'd include
> tests
> >> > as
> >> > we went, but skip the flexbox subdirectory. We would just run the
> tests
> >> > locally during development. This has the downside that other changes
> >> > might
> >> > break the flexbox tests, but thats a pain I'm willing to live with.
> >> > I'm fine doing this differently if people have strong opinions.
> >> > Ojan
> >> >
> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
> >> > wrote:
> >> >>
> >> >> Is it possible for this feature to be enabled at runtime?
> >> >>
> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> >> >> > New features should be tested incrementally as they are developed.
> >> >> > That means running them on build.webkit.org. The decision to ship
> a
> >> >> > feature is separate.
> >> >> >
> >> >> > Adam
> >> >> >
> >> >> >
> >> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
> >> >> > wrote:
> >> >> >> I don't think we want to ship this until we have a reasonably
> >> >> >> feature
> >> >> >> complete implementation of the spec and that we're convinced the
> >> >> >> spec
> >> >> >> is
> >> >> >> stable. I expect that in implementing this we'll find areas of the
> >> >> >> spec
> >> >> >> that
> >> >> >> need reworking, but at this point it's mainly blocked on
> >> >> >> implementation
> >> >> >> experience.
> >> >> >> I'm not sure it's worth setting a bot up just for this, although
> I'm
> >> >> >> not
> >> >> >> opposed to it. I expect we should have this shippable within a
> >> >> >> couple
> >> >> >> months.
> >> >> >>
> >> >> >> Ojan
> >> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth 
> >> >> >> wrote:
> >> >> >>>
> >> >&

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> New features should be tested incrementally as they are developed.
> That means running them on build.webkit.org. The decision to ship a
> feature is separate.
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai  wrote:
>> I don't think we want to ship this until we have a reasonably feature
>> complete implementation of the spec and that we're convinced the spec is
>> stable. I expect that in implementing this we'll find areas of the spec
that
>> need reworking, but at this point it's mainly blocked on implementation
>> experience.
>> I'm not sure it's worth setting a bot up just for this, although I'm not
>> opposed to it. I expect we should have this shippable within a couple
>> months.
>>
>> Ojan
>> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:
>>>
>>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
>>> used ports and use the regular bots?
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
>>> > Hi webkit-dev,
>>> > I wanted to let you know that Ojan and I plan to add flexbox layout
>>> > support
>>> > to WebCore.  WebCore already supports an older flexbox implementation
>>> > (display: box), but the new spec is designed to be easier for
developers
>>> > to
>>> > understand and more powerful.  The old flexbox will still remain in
>>> > WebCore
>>> > since none of the CSS properties overlap with the new flexbox spec.
 The
>>> > spec can be found
>>> >
>>> > at: http://www.w3.org/TR/css3-flexbox/ (
http://dev.w3.org/csswg/css3-flexbox/)
>>> > This support will be behind the ENABLE_FLEXBOX feature define
>>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta
bug
>>> > tracking the feature's development
>>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
feature
>>> > to
>>> > eventually be enabled by all ports.
>>> > I am ready to setup a buildbot for tracking the compile and flexbox
>>> > related
>>> > layout tests.  Should I go ahead and get this added to
>>> > build.webkit.org's
>>> > waterfall?
>>> > Thanks,
>>> > Tony
>>> >
>>> > ___
>>> > webkit-dev mailing list
>>> > webkit-dev@lists.webkit.org
>>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> >
>>> >
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] LocalStorage spec and structured cloning

[Darin Fisher]

I'm concerned that implementing this will only encourage more use of
localStorage.  The API is very poor because it requires synchronous IO and
synchronization between browser contexts, which may live on different
threads.  (Note: Chrome does not implement the required synchronization.)

If we could fix localStorage to be asynchronous and transactional :-) then
it'd be cool.  Of course, one answer is that people should just use
IndexedDB.

FWIW, Jorlow (when he was still working on chrome) expressed similar
sentiments.
On Jun 2, 2011 4:13 PM, "Maciej Stachowiak"  wrote:
>
> Does anyone have an opinion on this Web Storage spec bug? The input of the
WebKit community is desired. And probably Safari and Chrome folks in
particular, if opinions differ.
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
>
> http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that "The
> getItem(key) method must return a structured clone of the current value
> associated with the given key." but all browsers I've tested return a
string
> representation of the value instead."
>
> Regards,
> Maciej
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports

[Darin Fisher]

On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai  wrote:

> On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham  wrote:
>
>> Hi Peter,
>>
>> On Wed, May 18, 2011 at 2:09 PM, Peter Kasting 
>> wrote:
>> >> Google used this same approach with their Chromium port, the side
>> effects of
>> >> which find us in year two (or three?) of the effort to merge those
>> >> changes back into the core WebKit archive.
>> >
>> > Um, what?  The Chromium port is fully upstreamed and has been for some
>> time.
>> >  I'm not sure what you're saying here.  We are not forked and in fact
>> have
>> > no support for building Chromium with anything other than upstream
>> WebKit.
>>
>> I admit that statement was a bit hyperbolic; however the Chromium
>> source base was significantly reorganized when it was a 'secret'
>> project, and took a lot of time to get in sync.  I'm wondering why
>> Google, EA, and others have felt the need to do so.
>>
>> Note that there are still things that are not fully merged:  e.g.,
>> FontPlatformData is still largely forked from the mainline
>> implementation (e.g., arbitrarily different names for members).
>
>
> AFAIK, Chromium didn't actively reorganize the source tree. The source tree
> changed out from under us while we were still a private project. This is
> just a natural side effect of not being part of the mainline source tree.
> Stuff moves around (and it should!) as it makes sense to structure the files
> differently.
>
> Chromium's tree not tracking the move is just oversight in some cases.
>
> Ojan
>


we also learned some lessons the hard way.  i wish we had created a webkit
API from day one, to help insulate webcore better from chrome.  we did
create a layer of insulation (called webkit/glue), but it was way too
squishy and not kept clean.  it was a bit painful to untangle that into a
proper API.

we also didn't go with a vendor branch approach in the beginning.  instead,
we maintained forked files in a mirror tree, which just did not scale as the
number of forked files grew (due to V8 integration mainly).  but yeah,
things like the creation of FrameLoader really caused us to spin our wheels!
;-)

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

Re: [webkit-dev] Progressing on the Android port

[Darin Fisher]

On Fri, May 13, 2011 at 1:48 PM, Lucas De Marchi <
lucas.demar...@profusion.mobi> wrote:

> On Fri, May 13, 2011 at 5:35 PM, Holger Freyther 
> wrote:
> > On 05/12/2011 05:16 PM, Lucas De Marchi wrote:
> >> Hi Holger Freyther,
> >>
> >
> >> I'm glad to hear you will use CMake as the build system. Take a look
> >> on the email I sent yesterday porting GTK to CMake, maybe it will help
> >> you.  Since Android and Chromium/Linux have overlaps, do you think
> >> it'd be easy to build the Chromium port as well?
> >
> > I am not sure about Chromium. When one tries to build Chromium a lot of
> > external code will be downloaded, I don't have the things in my tree
> right now
> > but IIRC these external modules are all having Gyp files so one would
> need to
> > convert these dependencies and it will be quite some work.
>
> Hummn... too bad. Looking at the gyp files, it doesn't seem difficult
> to convert them. But indeed it's quite some work.
>
>
Keep in mind that you'd also need to repeat this exercise whenever you
update to
the latest version of those modules.

If you are planning to make use of more of the same code as Chromium, I
suspect
you will find that using GYP will be the path of least resistance.

Regards,
-Darin




>
> >
> > I am having one specific issue with CMake right now, do you think it
> would be
> > possible to have defaults for WEBKIT_FEATURE(ENABLE_AS_IMAGE "Enable SVG
> as
> > image" DEFAULT ON SVG)? E.g. I need to define ENABLE_GLIB as otherwise I
> end
> > up having a '#define ENABLE_GLIB' in the cmakeconfig.h breaking the
> build.
> >
>
> This is exactly the reason why I committed r86370 when doing the GTK
> port. Now you can do as I did for GTK:
>
> WEBKIT_FEATURE(ENABLE_GLIB_SUPPORT "Enable Glib support" ALWAYS ON)
>
> or ALWAYS OFF if you meant to unconditionally disable it.
>
>
>
> regards,
> Lucas De Marchi
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit unit test framework

[Darin Fisher]

I believe both maruel and jcivelli have had experience contributing changes
to gtest.

While I wouldn't characterize its code as simple, I haven't had trouble
understanding it.  It is a fairly mature project, having been used
internally at Google for ages.  It seems to be fairly well maintained, and
the code is clean to my eyes.  Chances are good that it already has
solutions for much of what you may wish of a unit testing framework.

By the way, I was originally not in favor of using gtest for Chromium.  It
seemed too complicated at first blush.  I had created a very simple testing
framework that I liked for all the reasons you state below.  That was ~5
years ago.  However, I quickly became more than convinced that it was worth
it to use an established tool for unit testing.  It has so many nice
features--features I didn't even know I would appreciate.  It was also
really easy to use.

-Darin


On Wed, Apr 20, 2011 at 4:01 PM, Sam Weinig  wrote:

> I am really not an expert on testing frameworks, and just put together
> something that met my needs (as has been the tradition in this project).
>  That said, the only features I like about TestWebKitAPI is that I know how
> it works and can hack
> it to do what I want, and that it has the ability to run each test in its
> own invocation (I also like the color output from the tests, because it's is
> in color!)
>
> So, my questions for people who have used gtest is, "Is it hackable?" What
> kind of changes have you had success making? Is a death test as scary as it
> sounds?
>
> -Sam
>
>
> On Apr 18, 2011, at 11:36 AM, David Levin wrote:
>
> *Issue: *There has been a long standing bug to add unit tests to WebKit (
> https://bugs.webkit.org/show_bug.cgi?id=21010). It was also 
> mentionedon
>  webkit-dev that it would be helpful in various cases.
>
> *Landscape:* Surveying WebKit, it is looks like there are at least three
> testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools),
> QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI
> has been used so far (as far as I can tell) for testing core WebKit items
> like WTF (though I was unaware of TestWebKitAPI until Friday).
>
> It seems like a good way to think about the issue of which to use in
> general in WebKit would be to decide on what would be desired in our
> framework and then see how each matches up.
>
> Here's my take on this. (It may be biased toward what I am familiar with
> but I welcome others to add their own criteria.)
>
> Criteria
>
> Musts:
>
>- Compatible license with WebKit
>- Builds/Can be built on the many platforms and build systems supported
>by WebKit (ideally without extra installs).
>
> Useful:
>
>- Easy to write tests
>- Hackable to suit our needs
>- Well tested features (to support hackability/stability)
>- Supports filtering of tests so you can run just the test you care
>about (and easily listing the tests).
>- Supports writing out values when there is test failure. (For example,
>if the is verifying that A == B but that is not true, then the values of A
>and B should be printed.)
>- Well documented
>
> thanks,
> dave
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Disallowing modal dialogs during unload events

[Darin Fisher]

As you know, I'm a very strong advocate of this change.  I think even if
other
ports aren't interested in experimenting with this change at the current
time,
that we should proceed to experiment with it in Chromium.  I would very much
like us to have data about how many sites are impacted, so that we can share
that with others.

-Darin


On Wed, Apr 6, 2011 at 4:37 PM, Sreeram Ramachandran wrote:

> We'd like to disallow modal dialogs (i.e., those arising from calls to
> alert, confirm, prompt or showModalDialog) during unload events
> (beforeunload, unload and pagehide) [1]. Chromium wants to do this
> [2]. Since this affects web compatibility, I'd like to get agreement
> from the other webkit ports as well.
>
> The benefits are:
> + Fewer annoyances for users who are trying to leave a page.
> + In the case of tab close, allows the browser to hide the tab before
> it has finished running the unload or pagehide event handlers (doesn't
> apply to beforeunload); gives the impression of better performance.
>
> This doesn't affect returning a non-null value from beforeunload; that
> will still cause the browser to show the stay-or-leave dialog. We
> think that is sufficient to satisfy legitimate needs to warn the user
> about data loss, etc.
>
> Outside webkit, this has been discussed on whatwg, but without a
> definite conclusion [3]. Firefox seems to be considering this as well
> [4].
>
> All in favour, say aye!
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=56397
> [2] http://code.google.com/p/chromium/issues/detail?id=68780
> [3]
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025080.html
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug

[Darin Fisher]

On Thu, Feb 10, 2011 at 9:16 AM, Antonio Gomes  wrote:

>
> It was very common to use this approach on bugzilla.mozilla.org, with each
>> component in the system having its own dummy email address auto-added.  This
>> allows developers to subscribe / unsubscribe from receiving email for
>> various components in the bug system.
>>
>>
> I would *very* much support that.
>
>
> --
> --Antonio Gomes
>


What Mozilla does is they set the "QA Contact" field to an email address of
the form @.bugs.  We don't have that field in
bugs.webkit.org, so we'd need to either add it, some other field, or maybe
we could just get by with adding this email address to the CC list.

Using the "QA Contact" was a convenient hack for Mozilla because 1) they
don't need the field for anything else and 2) the email preferences have a
separate column of options for following the "QA Contact".

I have no idea what it would take to setup something like this for
bugs.webkit.org, but I'm hoping that those who do can chime in with their
thoughts.

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

Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug

[Darin Fisher]

You can also introduce a dummy email address, and then interested folks can
use bugzilla's email preferences to watch that email address.  This is
perhaps a more lightweight version of using a mailing list as there is no
mailing list.

It was very common to use this approach on bugzilla.mozilla.org, with each
component in the system having its own dummy email address auto-added.  This
allows developers to subscribe / unsubscribe from receiving email for
various components in the bug system.

-Darin


On Wed, Feb 9, 2011 at 9:32 AM, Pavel Feldman  wrote:

> Hi WebKit,
>
> As you might know, we have a shortcut to the inspector bug entry form:
> webkit.org/new-inspector-bug. We use it all over the place, our users like
> simplicity it introduces. However, we ended up with 10 (and counting) people
> on the CC list. Fixed CC list has obvious drawbacks:
> - each time we want to add / remove a person from the template, we need to
> make explicit request
> - new guys don't get updates when old bugs change
> - old guys get updates even though they are not interested anymore.
>
> Can we migrate to a more flexible approach (such as introducing
> webkit-inspec...@lists.webkit.org) where we would be able to subscribe /
> unsubscribe? _wms suggested that we discuss it here first.
>
> Thanks
> Pavel
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] beforeload & link (esp rel prefetch)

[Darin Fisher]

Firefox definitely supports rel=prefetch in HTTP Link headers.  I believe it
also supports other rel types, like stylesheet.  The rel=subresource bit is
something new.

Supporting the Link header enables web servers to inject  tags without
modifying the document, which can be useful, especially for intermediaries.

-Darin


On Wed, Jan 12, 2011 at 5:07 PM, Maciej Stachowiak  wrote:

>
> Do other browsers support these values in the HTTP Link header? Do Web
> sites use them? I think the idea of triggering subresource loads from HTTP
> headers instead of the HTML itself is problematic. We should support it only
> to the degree required for Web compatibility.
>
> Regards,
> Maciej
>
> On Jan 12, 2011, at 8:05 AM, Gavin Peters (蓋文彼德斯) wrote:
>
> Folks,
>
> Right now in WebKit, beforeload events are not universally sent for link
> elements.  In particular, link elements with the rel type icon, dns-prefetch
> and prefetch do not generate beforeload events.  In a recent review of bug
> 51941, ap raised the question that perhaps they should be sent.  It's a good
> question!
>
> As background, I'm right now refactoring the HTMLLinkElement to pull out
> the loader that handles the abovementioned three rel types.  I'm doing this
> in preparation for adding Link header support, initially for these three rel
> types, as they are not so controversial as for instance putting
> rel=stylesheet in the HTTP headers.
>
> Then, there's another complication.  After the refactoring described in bug
> 51941, I'd like to move on and implement the Link header, bug 51940.  It's
> clear that beforeload won't make sense for the Link header, since we can't
> allow JS in HTTP, and we can't delay following the Link until we have
> HTML+CSS+JS (since that would defeat the purpose of the HTTP header
> providing quick dispatch).  As well, I will likely add another rel type
> "subresource" to our handling together with the header, which describes
> something like a prefetch, but required for the current page.
>
> So now I see a few questions
>
>1. Should HTML Link rel=prefetch have beforeload events?
>2. How about rel=icon and rel=dns-prefetch ?
>3. If the answer to (1) is yes, then should HTTP Link have events?
> Really?
>4. Should HTML Link permit rel=subresource?
>5. If the answer to (4) is yes, should HTML Link rel=subresource have
>beforeload events?
>
> what do people think?
>
> - Gavin
>
> https://bugs.webkit.org/show_bug.cgi?id=51941
> https://bugs.webkit.org/show_bug.cgi?id=51940
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] beforeload & link (esp rel prefetch)

[Darin Fisher]

Chromium-specific note:
 is loaded externally to WebKit, which will likely complicate
matters here.

-Darin


On Wed, Jan 12, 2011 at 8:52 AM, Ojan Vafai  wrote:

> On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯)  > wrote:
>
>>
>>1. Should HTML Link rel=prefetch have beforeload events?
>>2. How about rel=icon and rel=dns-prefetch ?
>>
>> I don't see why these wouldn't fire beforeload. They are resource requests
> like any others. I don't know enough about HTTP Link to comment on it.
>
>>
>>1. If the answer to (1) is yes, then should HTTP Link have events?
>> Really?
>>2. Should HTML Link permit rel=subresource?
>>3. If the answer to (4) is yes, should HTML Link rel=subresource have
>>beforeload events?
>>
>> what do people think?
>>
>> - Gavin
>>
>> https://bugs.webkit.org/show_bug.cgi?id=51941
>> https://bugs.webkit.org/show_bug.cgi?id=51940
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Best way to track feature evolution from release-to-release

[Darin Fisher]

On Fri, Jan 7, 2011 at 9:30 AM, Ojan Vafai  wrote:

> On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher  wrote:
>
>> On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai  wrote:
>>
>>> Right. Having a shared version number across WebKit builds will never
>>> catch every case (e.g. patches pulled into branches, disabled features,
>>> etc.), but it is better in general than developers using the individual
>>> products' version numbers.
>>>
>>
>> Totally agree.  We probably just need some kind of dotted notation to
>> handle branches.  The WebKit trunk should just increment N in "N.0", and
>> then branches can increment the minor number.
>>
>
> The branches are not cross-port though, right? We already have individual
> product numbers in the UA string that meet this need (e.g. the Chrome or
> Safari version number).
>
> Ojan
>


That's fair.  I think this is a complicated issue due to the likelihood of
features being disabled on a branch.  So, any "version number" corresponding
to the branch point alone may not be sufficient to describe the instance of
WebKit.

Yeah, the individual product numbers may just have to be the solution there
:-/

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

Re: [webkit-dev] Best way to track feature evolution from release-to-release

[Darin Fisher]

On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai  wrote:

> On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa wrote:
>
>> On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher  wrote:
>>
>>> Using svn revision numbers has the downside of not reflecting branches
>>> very well.  A bigger number may correspond to a recent change to an old
>>> branch for instance.  So, you cannot do simple "if version > N" checks to
>>> test for the availability of features.
>>>
>>
>> I think Ojan meant that the version number can be used to learn about
>> bugs such as crashes and incompatibilities that have been fixed but cannot
>> be detected as a feature.
>>
>
> Right. Having a shared version number across WebKit builds will never catch
> every case (e.g. patches pulled into branches, disabled features, etc.), but
> it is better in general than developers using the individual products'
> version numbers.
>
> Ojan
>


Totally agree.  We probably just need some kind of dotted notation to handle
branches.  The WebKit trunk should just increment N in "N.0", and then
branches can increment the minor number.

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

Re: [webkit-dev] Best way to track feature evolution from release-to-release

[Darin Fisher]

On Thu, Jan 6, 2011 at 4:39 PM, Ojan Vafai  wrote:

> On Wed, Jan 5, 2011 at 9:38 AM, Darin Adler  wrote:
>
>> > The user agent string in Chromium cites, for example,
>> "AppleWebKit/534.10". Does this refer directly to the /tags/Safari-534.10
>> code base? In other words, this is just an example of an organization
>> chosing to use a tag created by another organization? Some refer to the
>> Safari-(5##) number as a WebKit release, so it is important to clearly
>> understand the distinction.
>>
>> I believe that many others use WebKit version numbers based on the ones
>> Apple uses. I think this is a good practice, although it might be something
>> worth refining. We do want a WebKit version number to mean something
>> cross-platform, but it’s not obvious how to accomplish that and meet all the
>> other goals of folks using WebKit.
>>
>
> FWIW, Chromium uses the major and minor version numbers listed
> in WebCore/Configurations/Version.xcconfig. We'd be happy to use something
> not tied to Apple's release process as long as Safari did the same. Giving
> web developers one version number to make sense of is important. It would be
> extra awesome if they could easily map from an SVN revision to a version
> number. Frequently a developer will see that a bug is fixed, but won't know
> what the WebKit version number will be.
>
> Some ideas:
> -Use the svn revision number. That has the downside of being tied to SVN
> should we want to change version control systems.
> -Have a file checked in that corresponds to the WebKit "version" at that
> revision. Any port is allowed to increment the number in that file whenever
> they please. It's monotonically increasing, not tied to a given version
> control system or to an individual port's release process.
>
> Ojan
>
>
Using svn revision numbers has the downside of not reflecting branches very
well.  A bigger number may correspond to a recent change to an old branch
for instance.  So, you cannot do simple "if version > N" checks to test for
the availability of features.

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

Re: [webkit-dev] RuntimeEnabledFeatures for JSC (was RE: Getting at Settings object from WorkerContext)

[Darin Fisher]

On Thu, Jan 6, 2011 at 12:47 PM, Darin Adler  wrote:

> On Jan 6, 2011, at 12:41 PM, Joe Mason wrote:
>
> > I took a look at CodeGeneratorJS.pm to see how hard it would be to port
> this over. I have no idea where to start…  The structure of
> CodeGeneratorJS.pm and CodeGeneratorV8.pm seem quite different. This also
> seems like a lot of work to do just to enable/disable one feature, but I
> guess if there’s no framework for enabling/disabling JS features in JSC at
> all then it’s necessary.
>
> I’m sad that the V8 code generator script diverged so much from the
> original. It would be great if they were kept closer. I have refactored them
> to become more similar and even share code whenever I had to modify both,
> such as when making changes to [Reflect].
>
> > Is there wide agreement that porting the RuntimeEnabledFeatures to JSC is
> a good idea?
>
> I think it would probably be good. Not sure why the person who did it
> originally did it V8-only.
>
>
IIRC, there was not much interest from JSC-using ports
for RuntimeEnabledFeatures.

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

Re: [webkit-dev] [chromium] using WEBKIT_API properly

[Darin Fisher]

Correction:  you meant "pure virtual" functions.

(I'm adding a note to the README file about these rules by the way.)

-Darin


On Fri, Dec 3, 2010 at 8:55 AM, Darin Fisher  wrote:

> Yes, indeed.  Thanks Jeremy!
>
>
> On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow  wrote:
>
>> You forgot to mention virtual functions, which is another case where you
>> do _not_ use WEBKIT_API.
>>
>> J
>>
>> On Thu, Dec 2, 2010 at 9:27 PM, Darin Fisher  wrote:
>>
>>> If you do not work on the Chromium port of WebKit, you can stop reading
>>> now.
>>>
>>> I've noticed that there is some confusion about how to use WEBKIT_API
>>> properly.
>>> WEBKIT_API causes a function to be exported from WebKit when it is built
>>> as a DLL,
>>> allowing Chromium to call the function.
>>>
>>> The rule is actually quite simple:
>>>
>>>WEBKIT_API should be affixed to any public, non-inline function that
>>> is intended
>>>for the embedder (Chromium) to call.
>>>
>>> Put another way:
>>> -- Do not apply WEBKIT_API to inline functions.
>>> -- Do not apply WEBKIT_API to private functions.
>>> -- Do not apply WEBKIT_API to public functions within a #if
>>> WEBKIT_IMPLEMENTATION block.
>>>
>>> (Of related note, we never put WEBKIT_API on public constructors and
>>> destructors.
>>> Instead, we have constructors call an initialize method and destructors
>>> call a reset
>>> method.  Those then end up having the WEBKIT_API prefix applied.)
>>>
>>> Thanks!
>>> -Darin
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem

[Darin Fisher]

On Tue, Dec 21, 2010 at 3:59 PM, Darin Fisher  wrote:

> On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson  wrote:
>
>>
>> On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
>>
>>
>>
>> On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher wrote:
>>
>>>
>>>
>>> On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson wrote:
>>>
>>>>
>>>> On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
>>>>
>>>> I'm working on fixing some session history bugs related to a
>>>> HistoryItem's URL property changing.
>>>> See for example the call to HistoryItem::setURL in
>>>> HistoryController::updateForReload [1].
>>>>
>>>> I'm curious about the platform specific fields on WebCore::HistoryItem.
>>>>  *** Do any of those need to
>>>> be updated when the URL of the HistoryItem changes? ***
>>>>
>>>> Here are the fields I'm referring to:
>>>>
>>>> class HistoryItem ... {
>>>> private:
>>>> ...
>>>> #if PLATFORM(MAC)
>>>> RetainPtr m_viewState;
>>>>
>>>>
>>>> This is used for the Page Cache only.  The URL had sure better not
>>>> change while the page is cached!
>>>>
>>>
>>> OK, I will assert that it is 0.
>>>
>>>
>> Awesome, I found a layout test where the URL of the HistoryItem changes,
>> and there is an associated cached page for the HistoryItem!  I presume the
>> right fix is to clear the cached page.
>>
>>
>> No no no!!!
>>
>> Why is anyone trying to do anything to the URL of an item that represents
>> a cached page???
>>
>
> Hmm, the testcase is simply assigning location within onload (the
> equivalent of location.replace).  The document is getting replaced with a
> new document, but the same HistoryItem is being overwritten with the URL of
> the new document.
>
> I'm not super familiar with the cached page implementation since Chromium
> does not enable it, but if that system assumes there is a 1:1 relationship
> between HistoryItems and cached pages / documents, then that could be
> problematic.
>
> I'm toying with
> calling HistoryController::invalidateCurrentItemCachedPage() in this case,
> but maybe that would be suboptimal?
>

OK, false alarm.  The issue is as follows:

The cached page corresponding to the new document is assigned to the
HistoryItem before we change its URL.  In other words, I don't need to do
anything special.

-Darin



>
>
>
>
>>
>> In case you are interested, the layout test where this happens is:
>>  fast/history/timed-refresh-in-cached-frame.html
>>
>>
>> Shouldn't the timed refresh be paused while the page is cached, and only
>> resume once the page is brought out?
>>
>
> The issue comes up well before the  timer expires.  I could
> remove that bit of the testcase, and the issue would remain.  This is all
> about issuing a client redirect on a page that has been cached.
>
> -Darin
>
>
>
>>
>> In other words, should the URL only be changed after the page is restored?
>>
>> ~Brady
>>
>>
>>
>> -Darin
>>
>>
>>>
>>>
>>>>
>>>> OwnPtr > > m_transientProperties;
>>>>
>>>>
>>>> This is to support arbitrary WebKit Mac API and has nothing to do with
>>>> the URL identity of the item.
>>>>
>>>
>>> OK, thanks!
>>>
>>> -Darin
>>>
>>
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem

[Darin Fisher]

On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson  wrote:

>
> On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
>
>
>
> On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher  wrote:
>
>>
>>
>> On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson  wrote:
>>
>>>
>>> On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
>>>
>>> I'm working on fixing some session history bugs related to a
>>> HistoryItem's URL property changing.
>>> See for example the call to HistoryItem::setURL in
>>> HistoryController::updateForReload [1].
>>>
>>> I'm curious about the platform specific fields on WebCore::HistoryItem.
>>>  *** Do any of those need to
>>> be updated when the URL of the HistoryItem changes? ***
>>>
>>> Here are the fields I'm referring to:
>>>
>>> class HistoryItem ... {
>>> private:
>>> ...
>>> #if PLATFORM(MAC)
>>> RetainPtr m_viewState;
>>>
>>>
>>> This is used for the Page Cache only.  The URL had sure better not change
>>> while the page is cached!
>>>
>>
>> OK, I will assert that it is 0.
>>
>>
> Awesome, I found a layout test where the URL of the HistoryItem changes,
> and there is an associated cached page for the HistoryItem!  I presume the
> right fix is to clear the cached page.
>
>
> No no no!!!
>
> Why is anyone trying to do anything to the URL of an item that represents a
> cached page???
>

Hmm, the testcase is simply assigning location within onload (the equivalent
of location.replace).  The document is getting replaced with a new document,
but the same HistoryItem is being overwritten with the URL of the new
document.

I'm not super familiar with the cached page implementation since Chromium
does not enable it, but if that system assumes there is a 1:1 relationship
between HistoryItems and cached pages / documents, then that could be
problematic.

I'm toying with calling HistoryController::invalidateCurrentItemCachedPage()
in this case, but maybe that would be suboptimal?




>
> In case you are interested, the layout test where this happens is:
>  fast/history/timed-refresh-in-cached-frame.html
>
>
> Shouldn't the timed refresh be paused while the page is cached, and only
> resume once the page is brought out?
>

The issue comes up well before the  timer expires.  I could
remove that bit of the testcase, and the issue would remain.  This is all
about issuing a client redirect on a page that has been cached.

-Darin



>
> In other words, should the URL only be changed after the page is restored?
>
> ~Brady
>
>
>
> -Darin
>
>
>>
>>
>>>
>>> OwnPtr > > m_transientProperties;
>>>
>>>
>>> This is to support arbitrary WebKit Mac API and has nothing to do with
>>> the URL identity of the item.
>>>
>>
>> OK, thanks!
>>
>> -Darin
>>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem

[Darin Fisher]

On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher  wrote:

>
>
> On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson  wrote:
>
>>
>> On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
>>
>> I'm working on fixing some session history bugs related to a HistoryItem's
>> URL property changing.
>> See for example the call to HistoryItem::setURL in
>> HistoryController::updateForReload [1].
>>
>> I'm curious about the platform specific fields on WebCore::HistoryItem.
>>  *** Do any of those need to
>> be updated when the URL of the HistoryItem changes? ***
>>
>> Here are the fields I'm referring to:
>>
>> class HistoryItem ... {
>> private:
>> ...
>> #if PLATFORM(MAC)
>> RetainPtr m_viewState;
>>
>>
>> This is used for the Page Cache only.  The URL had sure better not change
>> while the page is cached!
>>
>
> OK, I will assert that it is 0.
>
>
Awesome, I found a layout test where the URL of the HistoryItem changes, and
there is an associated cached page for the HistoryItem!  I presume the right
fix is to clear the cached page.

In case you are interested, the layout test where this happens is:
 fast/history/timed-refresh-in-cached-frame.html

-Darin


>
>
>>
>> OwnPtr > > m_transientProperties;
>>
>>
>> This is to support arbitrary WebKit Mac API and has nothing to do with the
>> URL identity of the item.
>>
>
> OK, thanks!
>
> -Darin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem

[Darin Fisher]

On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson  wrote:

>
> On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
>
> I'm working on fixing some session history bugs related to a HistoryItem's
> URL property changing.
> See for example the call to HistoryItem::setURL in
> HistoryController::updateForReload [1].
>
> I'm curious about the platform specific fields on WebCore::HistoryItem.
>  *** Do any of those need to
> be updated when the URL of the HistoryItem changes? ***
>
> Here are the fields I'm referring to:
>
> class HistoryItem ... {
> private:
> ...
> #if PLATFORM(MAC)
> RetainPtr m_viewState;
>
>
> This is used for the Page Cache only.  The URL had sure better not change
> while the page is cached!
>

OK, I will assert that it is 0.



>
> OwnPtr > > m_transientProperties;
>
>
> This is to support arbitrary WebKit Mac API and has nothing to do with the
> URL identity of the item.
>

OK, thanks!

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

[webkit-dev] Platform specific fields on WebCore::HistoryItem

[Darin Fisher]

I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].

I'm curious about the platform specific fields on WebCore::HistoryItem.  ***
Do any of those need to
be updated when the URL of the HistoryItem changes? ***

Here are the fields I'm referring to:

class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtr m_viewState;
OwnPtr > > m_transientProperties;
#endif

#if PLATFORM(QT)
QVariant m_userData;
#endif

#if PLATFORM(ANDROID)
RefPtr m_bridge;
#endif
};

I'm not sure how these fields are used, and I would greatly appreciate input
from the respective
port maintainers.

Thanks,
-Darin

[1]
http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/loader/HistoryController.cpp&q=updateForReload&exact_package=chromium&sa=N&cd=1&ct=rc
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bools are strictly worse than enums

[Darin Fisher]

On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel  wrote:

> It seems to me, that using bool types for function arguments is strictly
> worse than using an enum.  An enum is always clearer and can be easily
> casted to a bool if needed.
>
> doSomething(something, false);
>
> Is much less readable than:
>
> doSomething(something, AllowNetworkLoads);
>
>
> Do any C++ gurus have further information to add here?  Is my (simple)
> analysis here incorrect?  If not, seems we should forbid boolean values in
> multi-argument methods/constructors in our style and add checks to
> check-webkit-style to prevent further introduction of these confusing
> callsites.
>
> -eric
>


I was under the impression that this was already an encouraged style in
WebKit code.  At least, I really like that is makes call-sites more
self-documenting.

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

Re: [webkit-dev] [chromium] using WEBKIT_API properly

[Darin Fisher]

Yes, indeed.  Thanks Jeremy!

On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow  wrote:

> You forgot to mention virtual functions, which is another case where you do
> _not_ use WEBKIT_API.
>
> J
>
> On Thu, Dec 2, 2010 at 9:27 PM, Darin Fisher  wrote:
>
>> If you do not work on the Chromium port of WebKit, you can stop reading
>> now.
>>
>> I've noticed that there is some confusion about how to use WEBKIT_API
>> properly.
>> WEBKIT_API causes a function to be exported from WebKit when it is built
>> as a DLL,
>> allowing Chromium to call the function.
>>
>> The rule is actually quite simple:
>>
>>WEBKIT_API should be affixed to any public, non-inline function that is
>> intended
>>for the embedder (Chromium) to call.
>>
>> Put another way:
>> -- Do not apply WEBKIT_API to inline functions.
>> -- Do not apply WEBKIT_API to private functions.
>> -- Do not apply WEBKIT_API to public functions within a #if
>> WEBKIT_IMPLEMENTATION block.
>>
>> (Of related note, we never put WEBKIT_API on public constructors and
>> destructors.
>> Instead, we have constructors call an initialize method and destructors
>> call a reset
>> method.  Those then end up having the WEBKIT_API prefix applied.)
>>
>> Thanks!
>> -Darin
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [chromium] using WEBKIT_API properly

[Darin Fisher]

If you do not work on the Chromium port of WebKit, you can stop reading now.

I've noticed that there is some confusion about how to use WEBKIT_API
properly.
WEBKIT_API causes a function to be exported from WebKit when it is built as
a DLL,
allowing Chromium to call the function.

The rule is actually quite simple:

   WEBKIT_API should be affixed to any public, non-inline function that is
intended
   for the embedder (Chromium) to call.

Put another way:
-- Do not apply WEBKIT_API to inline functions.
-- Do not apply WEBKIT_API to private functions.
-- Do not apply WEBKIT_API to public functions within a #if
WEBKIT_IMPLEMENTATION block.

(Of related note, we never put WEBKIT_API on public constructors and
destructors.
Instead, we have constructors call an initialize method and destructors call
a reset
method.  Those then end up having the WEBKIT_API prefix applied.)

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

Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation

[Darin Fisher]

How do you address the discoverability issue that I raised?  asBlob and
asArrayBuffer have the benefit of being detectable at runtime.  but, a
settable responseType does not support detection of supported values.

-Darin



On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers  wrote:

> passing "undefined" as the 4th and 5th arguments seems pretty clunky to me.
>  Since, we already have an "asBlob" attribute, then "asArrayBuffer" like
> Darin suggests seems like it might be better.  However, then we can get into
> cases where both "asBlob" and "asArrayBuffer" are set, and this problem
> would get even worse as new types are added.  So, an attribute called
> "responseType" might be a good solution.  This would be instead of passing
> it as an argument to open(), and instead of having an "asBlob" attribute.
>  This approach seems the cleanest to me, and I'll propose it to the
> appropriate standards group.
>
> Chris
>
> On Mon, Oct 25, 2010 at 12:45 PM, Alexey Proskuryakov wrote:
>
>>
>> 25.10.2010, в 12:34, Chris Marrin написал(а):
>>
>>  request.open("GET", "data.xml", true, "Text");
>>> request.open("GET", "data.xml", true, "XML");
>>> request.open("GET", "data.xml", true, "Bytes");
>>>
>>
>> I'd sure like to try to avoid an explosion in the API. I like Geoff's
>> suggestion of specifying the type of request in open(). Seems like the best
>> API would be to have Geoff's API and then:
>>
>>
>> Note that open() has username and password as its 4th and 5th arguments.
>> So, you'd have to call it like request.open("GET", "data.xml", true,
>> undefined, undefined, "Bytes");
>>
>>  - WBR, Alexey Proskuryakov
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation

[Darin Fisher]

On Mon, Oct 25, 2010 at 12:34 PM, Chris Marrin  wrote:

>
> On Oct 25, 2010, at 12:22 PM, Darin Fisher wrote:
>
> The solution for .responseBlob was to add an .asBlob attribute that would
> need to be set to true before calling .send().  We could do the same for
> .responseArrayBuffer.
>
> -Darin
>
>
> On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen  wrote:
>
>> Hi Chris.
>>
>> I like the efficiency of this approach. And I agree with your premise that
>> a developer will probably only want one type of data (raw, text, or XML) per
>> request, and not more than one.
>>
>> My biggest concern with this idea is that there's nothing obvious about
>> the API pattern of three properties -- .responseText, .responseXML, and
>> .responseArrayBuffer -- that makes clear that accessing one should prohibit
>> access to the others. I wonder if there's a good way to make this clearer.
>>
>> Maybe the API should require the programmer to specify in advance what
>> type of data he/she will ask for. For example, an extra responeType
>> parameter passed to open. The default behavior would be the values currently
>> supported, but you could opt into something specific for extra
>> safety/performance, and new types of data:
>>
>> request.open("GET", "data.xml", true, "Text");
>> request.open("GET", "data.xml", true, "XML");
>> request.open("GET", "data.xml", true, "Bytes");
>>
>
> I'd sure like to try to avoid an explosion in the API. I like Geoff's
> suggestion of specifying the type of request in open(). Seems like the best
> API would be to have Geoff's API and then:
>
> any responseObject();
> DOMString responseType();
>
> That would allow us to expand the types supported without any additional
> API. We'd need to support the current API calls for backward compatibility.
> But now seems like a good time to plan for the future.
>
>
Why is that superior to more specifically named attributes and methods?  I'm
trying to see how you would determine at runtime if a browser's XHR
implementation supported returning an ArrayBuffer.

If the XHR had an .asArrayBuffer attribute, then you could test for the
existence of that attribute.

I'm also not sure why adding new response types is cheaper than adding new
attributes / methods.  In both cases, it seems like we have to have a
similar "standards" discussion.

-Darin



> -
> ~Chris
> cmar...@apple.com
>
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation

[Darin Fisher]

The solution for .responseBlob was to add an .asBlob attribute that would
need to be set to true before calling .send().  We could do the same for
.responseArrayBuffer.

-Darin


On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen  wrote:

> Hi Chris.
>
> I like the efficiency of this approach. And I agree with your premise that
> a developer will probably only want one type of data (raw, text, or XML) per
> request, and not more than one.
>
> My biggest concern with this idea is that there's nothing obvious about the
> API pattern of three properties -- .responseText, .responseXML, and
> .responseArrayBuffer -- that makes clear that accessing one should prohibit
> access to the others. I wonder if there's a good way to make this clearer.
>
> Maybe the API should require the programmer to specify in advance what type
> of data he/she will ask for. For example, an extra responeType parameter
> passed to open. The default behavior would be the values currently
> supported, but you could opt into something specific for extra
> safety/performance, and new types of data:
>
> request.open("GET", "data.xml", true, "Text");
> request.open("GET", "data.xml", true, "XML");
> request.open("GET", "data.xml", true, "Bytes");
>
> Geoff
>
>
>
> On Oct 22, 2010, at 4:47 PM, Chris Rogers wrote:
>
> A few weeks ago I brought up the idea of implementing the
> responseArrayBuffer attribute for XHR:
>
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute
>
> One of the concerns was that it might require double the memory usage since
> the raw bytes would have to be accumulated along with the decoded text as
> it's being built up.  One possible solution which I've been discussing with
> James Robinson and Ken Russell is to defer decoding the text, and instead
> buffer the raw data as it comes in.  If there's any access to responseText
> (or responseXML), then the buffered data can be decoded into text at that
> time, and the buffered raw data discarded.  If that case happens, then from
> that point on no raw data buffering would happen and the text would be
> accumulated as it is right now.  Otherwise, if responseText is never
> accessed then the raw data continues to buffer until it's completely loaded.
>  Then an access to responseArrayBuffer can easily convert the raw bytes to
> an ArrayBuffer.
>
> The idea is that once responseText or responseXML is accessed, then it
> would no longer be possible to access responseArrayBuffer (an exception
> would be thrown).
> Conversely, once responseArrayBuffer is accessed, then it would no longer
> be possible to use responseText or responseXML (an exception would be
> thrown).
> This approach does seem a little strange because of the mutually exclusive
> nature of the access.  However, it seems that it would be hard to come up
> for a reasonable use case where both the raw bytes *and* the text would be
> needed for the same XHR.
>
> How does this sound as an approach?
>
> Chris
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev