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

2013-02-11 Thread Darin Fisher
Thanks for the heads up!
-Darin


On Sun, Feb 10, 2013 at 1:53 PM, Maciej Stachowiak m...@apple.com 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 this is needed)

 ___
 webkit-dev mailing list

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

2013-02-08 Thread Darin Fisher
On Fri, Feb 8, 2013 at 2:05 PM, Maciej Stachowiak m...@apple.com wrote:


 On Feb 8, 2013, at 1:41 PM, Adam Barth aba...@webkit.org 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))

2013-02-02 Thread Darin Fisher
On Sat, Feb 2, 2013 at 4:16 PM, James Robinson jam...@google.com wrote:



 On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen kbal...@webkit.org 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-devhttps://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))

2013-01-31 Thread 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 e...@webkit.org 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 a...@webkit.org
 wrote:
 
  31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а):
 
  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

2012-11-06 Thread 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

2012-10-11 Thread 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 simon...@chromium.orgwrote:

 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)

2012-09-13 Thread Darin Fisher
On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth aba...@webkit.org wrote:

 On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org 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() ?

2012-08-13 Thread 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 kin...@chromium.org 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 kin...@chromium.orgwrote:

 On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org 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 kin...@chromium.orgwrote:

 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?

2012-07-30 Thread 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 xuewen.w...@torchmobile.com.cnwrote:


 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

2012-07-25 Thread 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 aba...@webkit.org 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 aba...@webkit.org 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

2012-07-16 Thread Darin Fisher
On Mon, Jul 16, 2012 at 2:57 AM, Jochen Eisinger joc...@chromium.orgwrote:




 On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher da...@chromium.org wrote:



 On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth aba...@webkit.org 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 joc...@chromium.orgwrote:

 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 aba...@webkit.org wrote:

 On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger 
 joc...@chromium.orgwrote:

 On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa rn...@webkit.orgwrote:

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

2012-07-13 Thread Darin Fisher
On Fri, Jul 13, 2012 at 10:59 AM, Eric Seidel e...@webkit.org wrote:

 bikeshedding

 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

 /bikeshedding

 On Fri, Jul 13, 2012 at 7:17 AM, Andrei Bucur abu...@adobe.com 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 alexis.men...@openbossa.org
 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 simon.fra...@apple.com
 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 rn...@webkit.org
 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 e...@webkit.org 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 abu...@adobe.com
 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 stea...@adobe.com
   Date: Thursday, July 12, 2012 7:39 PM
   To: Adam Barth aba...@webkit.org, Andrei Bucur abu...@adobe.com
 
  
   Cc: webkit-dev@lists.webkit.org 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 aba...@webkit.org
   To: Andrei Bucur abu...@adobe.com
   Cc: webkit-dev@lists.webkit.org 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 abu...@adobe.com
 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
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 

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

2012-06-11 Thread 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 kin...@chromium.org 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

2012-06-10 Thread Darin Fisher
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:



 On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger joc...@chromium.orgwrote:

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

2012-04-30 Thread Darin Fisher
On Sun, Apr 29, 2012 at 3:44 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Apr 27, 2012 at 1:49 AM, Nat Duca nd...@chromium.org 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)

2012-04-29 Thread Darin Fisher
On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.comwrote:

 On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote:

 I read https://trac.webkit.org/wiki/DeprecatingFeatures, 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

2012-04-16 Thread Darin Fisher
On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com 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 m...@apple.com 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

2012-04-16 Thread Darin Fisher
On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt oli...@apple.com wrote:


 On Apr 16, 2012, at 1:00 PM, Darin Fisher da...@chromium.org wrote:

 On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com 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 m...@apple.com 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 proposal: restricting window.blur/focus

2012-04-04 Thread 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 joc...@chromium.org 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

2012-04-04 Thread Darin Fisher
On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote:


 On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org 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 joc...@chromium.orgwrote:

 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

2012-04-04 Thread Darin Fisher
On Wed, Apr 4, 2012 at 11:17 AM, Jochen Eisinger joc...@chromium.orgwrote:



 On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote:

 On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote:


 On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org 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 joc...@chromium.orgwrote:

 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 iframe seamless

2012-03-30 Thread 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
iframe seamless, 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 e...@webkit.org 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 da...@chromium.org wrote:
 
 
  On Fri, Mar 30, 2012 at 4:01 PM, Eric Seidel e...@webkit.org wrote:
 
  Per http://www.webkit.org/coding/adding-features.html
 
 
  I'm working on adding iframe seamless 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 /
  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?

2012-03-07 Thread 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 m...@apple.com 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

2012-02-28 Thread Darin Fisher
Nice.  Is there a plan for modularizing Settings?
On Feb 28, 2012 12:30 AM, Adam Barth aba...@webkit.org 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

2012-02-28 Thread Darin Fisher
Good idea!
-Darin

On Tue, Feb 28, 2012 at 8:46 AM, Adam Barth aba...@webkit.org 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 da...@chromium.org wrote:
  Nice.  Is there a plan for modularizing Settings?
 
  On Feb 28, 2012 12:30 AM, Adam Barth aba...@webkit.org 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

2012-02-28 Thread 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 simon.fra...@apple.comwrote:

 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 aba...@webkit.org 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 da...@chromium.org wrote:
  Nice.  Is there a plan for modularizing Settings?
 
  On Feb 28, 2012 12:30 AM, Adam Barth aba...@webkit.org 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

2012-02-28 Thread Darin Fisher
On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov a...@webkit.org 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] Removing obsolete File attributes

2012-02-24 Thread 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 a...@webkit.org 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] Removing obsolete File attributes

2012-02-24 Thread Darin Fisher
On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.com 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 a...@webkit.orgwrote:


 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

2012-02-24 Thread Darin Fisher
On Fri, Feb 24, 2012 at 12:13 PM, Maciej Stachowiak m...@apple.com wrote:


 On Feb 24, 2012, at 12:06 PM, Darin Fisher wrote:



 On Fri, Feb 24, 2012 at 12:00 PM, Maciej Stachowiak m...@apple.com 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

2012-02-24 Thread Darin Fisher
On Fri, Feb 24, 2012 at 1:47 PM, Jochen Eisinger joc...@chromium.orgwrote:



 On Fri, Feb 24, 2012 at 10:38 PM, Eric Seidel e...@webkit.org 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 a...@webkit.org
 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] DOM Rendering synchronization with javascript

2012-02-17 Thread Darin Fisher
webkitRequestAnimationFrame may be helpful to you.

Regards,
-Darin



On Fri, Feb 17, 2012 at 11:00 AM, Ian Johnson enja...@gmail.com 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

2012-01-28 Thread 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 bre...@chromium.org wrote:

 On Sat, Jan 28, 2012 at 5:28 PM, Joe Mason jma...@rim.com 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

2012-01-28 Thread Darin Fisher
On Sat, Jan 28, 2012 at 6:01 PM, Adam Barth aba...@webkit.org wrote:

 On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain benja...@webkit.org
 wrote:
  On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson bre...@chromium.org
 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

2012-01-27 Thread Darin Fisher
On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.orgwrote:

 On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org 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

2012-01-27 Thread Darin Fisher
On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote:

 On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com 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

2012-01-26 Thread Darin Fisher
On Thu, Jan 26, 2012 at 6:11 PM, Benjamin Poulain benja...@webkit.orgwrote:

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

2011-12-07 Thread 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 aba...@webkit.org 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 da...@apple.com 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]

2011-10-12 Thread 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 a...@webkit.org 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] New feature flag proposal: Joystick API

2011-10-06 Thread 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 simon.fra...@apple.comwrote:

 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] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore

2011-10-06 Thread 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 m...@apple.com 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] pthreads and other threading primitives

2011-09-26 Thread Darin Fisher
On Mon, Sep 26, 2011 at 10:47 AM, Alexey Proskuryakov a...@webkit.org 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] Mouse Lock API

2011-09-22 Thread Darin Fisher
On Thu, Sep 22, 2011 at 2:23 PM, Alexey Proskuryakov a...@webkit.org 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

2011-09-22 Thread Darin Fisher
On Thu, Sep 22, 2011 at 2:38 PM, Alexey Proskuryakov a...@webkit.org 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] new APIs for strokes with dash in Canvas

2011-09-22 Thread 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 joybro...@gmail.com 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

2011-09-21 Thread Darin Fisher
On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.org 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

2011-09-21 Thread Darin Fisher
On Wed, Sep 21, 2011 at 12:46 PM, Peter Kasting pkast...@chromium.orgwrote:

 On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.orgwrote:

 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] ENABLE flag cleanup strawman proposal

2011-09-15 Thread Darin Fisher
On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote:

 I've updated the spreadsheet of all ENABLE flags to match TOT (as of
 this afternoon):


 https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Yncauthkey=CJCDiooKhl=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

2011-07-27 Thread 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 scot...@chromium.org 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: a download=filename

2011-07-20 Thread 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 a download=filename 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

2011-07-15 Thread Darin Fisher
Are any other browsers implementing it?
On Jul 14, 2011 5:47 PM, Ryosuke Niwa rn...@webkit.org 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

2011-07-15 Thread 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 rn...@webkit.org wrote:

 No, as far as I know.

 - Ryosuke

 On Fri, Jul 15, 2011 at 11:04 AM, Darin Fisher da...@chromium.org wrote:

 Are any other browsers implementing it?
 On Jul 14, 2011 5:47 PM, Ryosuke Niwa rn...@webkit.org 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

2011-07-15 Thread Darin Fisher
On Fri, Jul 15, 2011 at 2:08 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Jul 15, 2011 at 2:01 PM, Darin Fisher da...@chromium.org 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] Slow idioms with WTF::String

2011-07-12 Thread Darin Fisher
On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com 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*, Vectorchar, 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 VectorUChar 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?

2011-07-09 Thread 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 aba...@webkit.org 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

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

2011-07-01 Thread Darin Fisher
On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler da...@apple.com 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] Does NRWT let you indicate that a test should fail with a particular failure diff?

2011-07-01 Thread Darin Fisher
On Fri, Jul 1, 2011 at 3:37 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Fri, Jul 1, 2011 at 3:24 PM, Darin Fisher da...@chromium.org wrote:
  On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler da...@apple.com 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 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

2011-06-27 Thread Darin Fisher
On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov a...@webkit.org 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

2011-06-26 Thread Darin Fisher
On Sun, Jun 26, 2011 at 1:53 PM, Sreeram Ramachandran
sree...@chromium.orgwrote:

 On Sun, Jun 26, 2011 at 13:40, Ryosuke Niwa rn...@webkit.org wrote:
  On Sun, Jun 26, 2011 at 1:37 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
  On Sun, Jun 26, 2011 at 1:34 PM, Sreeram Ramachandran
  sree...@chromium.org 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

2011-06-17 Thread 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

2011-06-17 Thread Darin Fisher
On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote:

 On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote:
 
 
  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.
 

 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

2011-06-17 Thread 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 e...@webkit.org 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 da...@chromium.org wrote:
 
 
  On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com
 wrote:
 
  On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org
 wrote:
  
  
   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.
  
 
  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

2011-06-16 Thread 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

2011-06-15 Thread 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 gregsi...@chromium.org 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 andr...@google.com
 wrote:
  On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org
 wrote:
  On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org
 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

2011-06-13 Thread 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 simon.fra...@apple.comwrote:

 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 t...@chromium.org wrote:

 Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.


 On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility
 )

 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

2011-06-08 Thread Darin Fisher
Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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] Adding ENABLE_FLEXBOX to WebCore

2011-06-08 Thread 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 aba...@webkit.org 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 t...@chromium.org 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 aba...@webkit.org 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 o...@chromium.org 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 da...@chromium.org
   wrote:
  
   Is it possible for this feature to be enabled at runtime?
  
   On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org
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 aba...@webkit.org
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 t...@chromium.org
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

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

2011-06-08 Thread Darin Fisher
On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote:

 On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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 jam...@google.com wrote:

 On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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 aba...@webkit.org
 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 o...@chromium.org
 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 da...@chromium.org
 
   wrote:
  
   Is it possible for this feature to be enabled at runtime?
  
   On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org
 
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

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

2011-06-08 Thread 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 dpra...@chromium.org wrote:
 On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote:


 On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote:

 On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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

2011-06-08 Thread 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 aba...@webkit.org 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 da...@chromium.org 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 dpra...@chromium.org wrote:
  On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org
 wrote:
 
 
  On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com
 wrote:
 
  On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org
 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] LocalStorage spec and structured cloning

2011-06-02 Thread 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 m...@apple.com 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

2011-05-18 Thread Darin Fisher
On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai o...@chromium.org wrote:

 On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham bfulg...@gmail.com wrote:

 Hi Peter,

 On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@google.com
 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

2011-05-16 Thread 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 ze...@selfish.org
 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

2011-04-20 Thread 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 wei...@apple.com 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 
 mentionedhttp://lists.macosforge.org/pipermail/webkit-dev/2009-January/006359.htmlon
  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

2011-04-07 Thread 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 sree...@google.comwrote:

 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

2011-02-10 Thread Darin Fisher
On Thu, Feb 10, 2011 at 9:16 AM, Antonio Gomes toniki...@gmail.com 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 component@product.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

2011-02-09 Thread 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 pfeld...@chromium.org 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)

2011-01-12 Thread Darin Fisher
Chromium-specific note:
link rel=icon is loaded externally to WebKit, which will likely complicate
matters here.

-Darin


On Wed, Jan 12, 2011 at 8:52 AM, Ojan Vafai o...@chromium.org wrote:

 On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯) gav...@chromium.org
  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] beforeload link (esp rel prefetch)

2011-01-12 Thread 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 link tags without
modifying the document, which can be useful, especially for intermediaries.

-Darin


On Wed, Jan 12, 2011 at 5:07 PM, Maciej Stachowiak m...@apple.com 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] Best way to track feature evolution from release-to-release

2011-01-07 Thread Darin Fisher
On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org wrote:

 On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:

 On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher da...@chromium.org 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

2011-01-07 Thread Darin Fisher
On Fri, Jan 7, 2011 at 9:30 AM, Ojan Vafai o...@chromium.org wrote:

 On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher da...@chromium.org wrote:

 On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org 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] RuntimeEnabledFeatures for JSC (was RE: Getting at Settings object from WorkerContext)

2011-01-06 Thread Darin Fisher
On Thu, Jan 6, 2011 at 12:47 PM, Darin Adler da...@apple.com 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] Best way to track feature evolution from release-to-release

2011-01-06 Thread Darin Fisher
On Thu, Jan 6, 2011 at 4:39 PM, Ojan Vafai o...@chromium.org wrote:

 On Wed, Jan 5, 2011 at 9:38 AM, Darin Adler da...@apple.com 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] [chromium] using WEBKIT_API properly

2011-01-04 Thread 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 da...@chromium.org wrote:

 Yes, indeed.  Thanks Jeremy!


 On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow jor...@chromium.org 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 da...@chromium.org 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] Platform specific fields on WebCore::HistoryItem

2010-12-21 Thread 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)
RetainPtrid m_viewState;
OwnPtrHashMapString, RetainPtrid   m_transientProperties;
#endif

#if PLATFORM(QT)
QVariant m_userData;
#endif

#if PLATFORM(ANDROID)
RefPtrAndroidWebHistoryBridge 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.cppq=updateForReloadexact_package=chromiumsa=Ncd=1ct=rc
___
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

2010-12-21 Thread Darin Fisher
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com 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)
 RetainPtrid 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.




 OwnPtrHashMapString, RetainPtrid   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

2010-12-21 Thread Darin Fisher
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:



 On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com 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)
 RetainPtrid 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





 OwnPtrHashMapString, RetainPtrid   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

2010-12-21 Thread Darin Fisher
On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:


 On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:



 On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:



 On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com 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)
 RetainPtrid 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 meta refresh 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





 OwnPtrHashMapString, RetainPtrid   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

2010-12-21 Thread Darin Fisher
On Tue, Dec 21, 2010 at 3:59 PM, Darin Fisher da...@chromium.org wrote:

 On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:


 On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:



 On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.orgwrote:



 On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.comwrote:


 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)
 RetainPtrid 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 meta refresh 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





 OwnPtrHashMapString, RetainPtrid   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] [chromium] using WEBKIT_API properly

2010-12-03 Thread Darin Fisher
Yes, indeed.  Thanks Jeremy!

On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow jor...@chromium.org 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 da...@chromium.org 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] Bools are strictly worse than enums

2010-12-03 Thread Darin Fisher
On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel e...@webkit.org 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


[webkit-dev] [chromium] using WEBKIT_API properly

2010-12-02 Thread 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

2010-10-25 Thread 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 gga...@apple.com 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


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

2010-10-25 Thread 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 crog...@google.com 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 a...@webkit.orgwrote:


 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] SearchBox API

2010-10-15 Thread Darin Fisher
I think we're just coming at this from the point of view of trying to avoid
UA-specific APIs exposed to web content.  It seems risky to build APIs
outside of WebKit that may be adopted by other UAs.  We can certainly
revisit this if that ever becomes reality.

(Our current implementation exists on window.chrome.* by the way.)

-Darin



On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote:


 http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html
 would be more compelling with a video. :)

 I agree with Darin, this sounds like Browser-exposed DOM API.  Not
 something that WebKit has any business adding.

 -eric

 On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote:
  On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote:
 
  In any case, are there objections to beginning to land this under flag
 guard and vendor prefix?
 
  Yes, I do have an objection.
 
  Browser-specific API can be injected by the browser and doesn’t need to
 be built into WebKit. Safari already has some DOM API accessible only to
 search providers. WebKit has an architecture that allows this to be done
 without WebKit code changes.
 
  I suggest we put this feature in browsers, not the engine.
 
 -- 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


Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-13 Thread Darin Fisher
On Tue, Oct 12, 2010 at 10:39 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 12, 2010, at 10:03 PM, Darin Fisher wrote:

 On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote:

 On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:

 Hmm, I've found weak pointer abstractions to be very useful.  The issue
 with reference counting is that it is easy to introduce memory leaks, and
 has been mentioned, it is sometimes nice to have deterministic object
 destruction.


 We used to have lots of problems with leaking refcounted objects back when
 most refcounting was done manually, but this has become much less common as
 we deployed smart pointers.


 I was referring to reference cycles that are just as easily (if not more
 easily since the reference counting is hidden) created when you use smart
 pointers for managing references.


 For whatever reason, we don't seem to have had a lot of leaks from
 reference cycles. Nearly all the ones I ended up investigating back in the
 day turned out to be a ref() with no paired deref().

 I do believe that it's a real risk, just not one that has hit us a lot.


This kind of memory leak was (is still?) very common in Mozilla where
everything is reference counted (thanks to COM).

Seeing two classes having owning references to one another always gives me
the shakes, due to past miseries :-/






 It is also nice to avoid having to have explicit clear() functions and
 then add checks to every other method to assert that they are not called
 after clear().


 Well, if you have a weak pointer you have to check weak pointer validity,
 so you don't save any checks.


 True.  The difference is that the null checks are done at the call site
 instead.  In the abstract sense, what's the difference, right?  I agree,
 but

 In some cases however I find it nice when writing a class to have fewer
 states:  after construction, you can call methods; post destruction, you
 cannot call methods.  With an intermediate clear() function, you now have an
 uninitialized state to contend with.  This can make some classes a bit more
 noisy / less readable.


 The my weak pointer has now cleared itself state is exactly the same as
 the someone explicitly asked me to release some resources state. You deal
 with it either by making methods no-ops after that point, or making it
 illegal to call them and enforce it with an assert. It's exactly isomorphic
 in that regard.


Sure, but if you are only reading the class, then there is a big difference.
 You have one less state to consider for that class.  True, the state moves
to the caller(s), but at least when you are reading the code for the class,
you can ignore that and therefore have less to worry about.  Less to worry
about can be a nice thing :-)





 The cost isn't just the null checks. You need either storage for all the
 backpointers, or the smaller storage overhead for a refcounted handle. But
 then almost by definition you have more overhead than refcounting, since you
 have a refcounted object plus more work.


 That's right.  I wouldn't use WeakPtr unless that overhead was worth it.
  It is not that normal for WeakPtr to be used in Chrome.  There is one very
 notable example, which I'll come back to.

 Note the use case restrictions I sited above (see: We tend to use this in
 cases in which:).  Let me elaborate on that.  If there are many consumers
 interested in a shared resource _and_ if I'd like the shared resource to
 have deterministic destruction, then enter WeakPtr.  Without it, I would
 need to keep a list of consumers registered on the shared resource, and have
 some kind of notification from the destructor of the shared resource sent
 out to each registered consumer.  In that notification, the consumers would
 need to clear their back pointers.  This implementation without WeakPtr
 involves a list of pointers to maintain as well as a loop in the destructor
 of the shared resource.  Each of the consumers still needs to null check the
 shared resource before dereferencing it.  Clearly, WeakPtr is superior in
 this case.

 I'm not sure how often the above pattern appears in WebKit.  Perhaps it is
 rare.


 It's possible it will come up. So far, the use cases we have had for
 clearing backpointers have usually involved a unique client that the object
 which may get destroyed first already has a pointer to. If broadcast death
 notification was a more common pattern, I would be all in favor of WeakPtr.
 As things stand, I'd worry that people would use it for unicast death
 notifaction, which would be a little wasteful.


Agreed that it would be unfortunate if it were overused, and it might be
tempting for people to overuse it.  I haven't seen this to be a problem in
Chromium... yet.

There is also the unicast death notification use case that I mentioned
below: the Timer example.

-Darin






 I do think weak pointers have their uses

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 12, 2010, at 12:44 PM, James Robinson wrote:

 On Tue, Oct 12, 2010 at 9:47 AM, Chris Marrin cmar...@apple.com wrote:


 On Oct 11, 2010, at 5:15 PM, Maciej Stachowiak wrote:

 
  On Oct 11, 2010, at 4:03 PM, Chris Marrin wrote:
 
 
  On Oct 11, 2010, at 3:35 PM, James Robinson wrote:
 
  On Mon, Oct 11, 2010 at 3:15 PM, Chris Marrin cmar...@apple.com
 wrote:
 
  For accelerated 2D rendering we created a class called DrawingBuffer.
 This encapsulates the accelerated drawing surface (usually in the GPU) and
 the compositing layer used to display that surface on the page. The drawing
 surface (which is called a Framebuffer Object or FBO) is allocated by
 GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently
 this is a weak reference. DrawingBuffer has a ::create() method and you pass
 the GraphicsContext3D to that method.
 
  If you destroy the GraphicsContext3D, DrawingBuffer has a stale
 pointer. If you were to try to destroy the DrawingBuffer it would attempt to
 use that pointer (to destroy its FBO) and crash or worse. Currently we have
 an implicit policy that you should never destroy a GraphicsContext3D before
 its DrawingBuffers are all destroyed. That works fine in the current use
 case, CanvasRenderingContext2D. And we can follow that same policy when in
 the future when we use DrawingBuffer in WebGLRenderingContext.
 
  My concern is that this sort of implicit policy can lead to errors in
 the future when other potential clients of these classes use them. So I
 posted https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I
 move the creation of DrawingBuffer to the GraphicsContext3D and keep back
 pointers to all the DrawingBuffers allocated so they can be cleaned up when
 GraphicsContext3D is destroyed. In talking to James R. he's concerned this
 adds unnecessary complexity and would rather stick with the implicit policy.
 
  So is this something I should be concerned about, or is an implicit
 policy sufficient in this case?
 
  Before somebody suggests it, I think Chris and I are in agreement that
 neither GraphicsContext3D nor DrawingBuffer should be RefCounted.  They both
 have clear single-ownership semantics.
 
  True, although Simon and I just chatted and he pointed out that
 Refcounting both classes would solve this problem. The fact that
 GraphicsContext3D wouldn't need a back pointer to DrawingBuffer means we
 wouldn't have any circular references. I don't think the overhead of
 refcounting is an issue here, so maybe that would be a simpler solution?
 
  I think having two independent objects that must be deleted in a
 specific order, or else you crash, is a hazardous design. APIs (even
 internal APIs) are better when they do not have a way to be used wrong.
 So, I think this should be changed one way or the other.
 
  I have to say that to my taste, refcounting seems like a cleaner
 solution than ad-hoc weak pointers. I'm skeptical of the claim that
 refcounting is not good for a heavyweight object. If there's really a time
 when special resources (VRAM, etc) need to be freed at a known point in
 program code, then it may be better to have an explicit close type
 function instead of counting on the destructor. On the other hand, this
 might end up being roughly equivalent to the clear backpointers solution,
 but moves the complexity of being in a possibly-invalid state from
 DrawingBuffer to GraphicsContext3D.
 
  Either way, I am pretty confident that a design where objects must be
 destroyed in a specific order is not the best choice.

 So it seems like we have two choices: 1) my current patch, which uses
 backpointers to manage the lifetime of the weak pointers, or 2) refcounting.
 My current approach has the advantage that the resources are cleared as soon
 as the DrawingBuffer is destroyed. But it is more complex and therefore more
 error prone. I think that complexity is manageable so that would be my
 preferred implementation. But refcounting is simpler and my current patch
 has a clear() method on DrawingBuffer which gets rid of all the resources. I
 could leave that method and change to a refcounted model, so the author can
 control when the resources are destroyed.


 Another option would be to generalize the WeakPtrT implementation from
 that patch into a generic class and use that.  Then that logic could be
 implemented, reviewed and tested independently from the graphics code.  I
 know that Maciej has expressed concern about this pattern in the past due to
 the runtime cost it imposes.

 Ref counting is a fairly blunt instrument but it would fit in best with the
 rest of the codepath.


 Weak pointers are both more complicated than refcounting and introduce a
 comparable or possibly even greater level of runtime cost. So if there's
 ever a problem that can be solved either way, I would tend to prefer
 refcounting.

 Regards,
 Maciej



Hmm, I've found weak pointer 

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote:

 On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:

 Hmm, I've found weak pointer abstractions to be very useful.  The issue
 with reference counting is that it is easy to introduce memory leaks, and
 has been mentioned, it is sometimes nice to have deterministic object
 destruction.


 We used to have lots of problems with leaking refcounted objects back when
 most refcounting was done manually, but this has become much less common as
 we deployed smart pointers.


I was referring to reference cycles that are just as easily (if not more
easily since the reference counting is hidden) created when you use smart
pointers for managing references.




 It is also nice to avoid having to have explicit clear() functions and then
 add checks to every other method to assert that they are not called after
 clear().


 Well, if you have a weak pointer you have to check weak pointer validity,
 so you don't save any checks.


True.  The difference is that the null checks are done at the call site
instead.  In the abstract sense, what's the difference, right?  I agree,
but

In some cases however I find it nice when writing a class to have fewer
states:  after construction, you can call methods; post destruction, you
cannot call methods.  With an intermediate clear() function, you now have an
uninitialized state to contend with.  This can make some classes a bit more
noisy / less readable.



 I don't think explicit close calls are that bad. I think it's actually a
 better pattern when you hold significant resources other than just some
 memory (e.g. VRAM, file handles, sockets, limited kernel resources, window
 server handles...). That way, cleaning up your external resources does not
 become dependent on your ownership strategy for the object.


I agree.  Reference counting has many great use cases.  I'm not at all
against it.  I just find that there are use cases for smart weak pointers
sometimes.




 In the Chromium code base, we have a helper for weak pointers:
 http://src.chromium.org/viewvc/chrome/trunk/src/base/weak_ptr.h?view=markup

 We tend to use this in cases in which:

 1) there are many consumers interested in holding a back pointer to some
 shared resource, and
 2) we'd like the shared resource to die at some predictable time.

 Without a utility like this, the alternative is to make the shared resource
 notify each of the consumers about the impending destruction of the shared
 resource.

 It is true that WeakPtrT adds a null check in front of each method call
 made by the consumers, but that runtime cost is often justified in exchange
 for reduced code complexity (i.e., eliminating the need to notify consumers
 when the shared resource dies).


 The cost isn't just the null checks. You need either storage for all the
 backpointers, or the smaller storage overhead for a refcounted handle. But
 then almost by definition you have more overhead than refcounting, since you
 have a refcounted object plus more work.


That's right.  I wouldn't use WeakPtr unless that overhead was worth it.  It
is not that normal for WeakPtr to be used in Chrome.  There is one very
notable example, which I'll come back to.

Note the use case restrictions I sited above (see: We tend to use this in
cases in which:).  Let me elaborate on that.  If there are many consumers
interested in a shared resource _and_ if I'd like the shared resource to
have deterministic destruction, then enter WeakPtr.  Without it, I would
need to keep a list of consumers registered on the shared resource, and have
some kind of notification from the destructor of the shared resource sent
out to each registered consumer.  In that notification, the consumers would
need to clear their back pointers.  This implementation without WeakPtr
involves a list of pointers to maintain as well as a loop in the destructor
of the shared resource.  Each of the consumers still needs to null check the
shared resource before dereferencing it.  Clearly, WeakPtr is superior in
this case.

I'm not sure how often the above pattern appears in WebKit.  Perhaps it is
rare.




 I do think weak pointers have their uses, but only in relatively unusual
 cases (e.g. when you'd have a cycle otherwise). It doesn't sound like a huge
 win in this case.


WebCore::Timer is a good example of a smart weak pointer class.  It is
intended to be allocated as a member variable and hold a back pointer to the
containing class.  When the containing class object is destroyed, the Timer
member is also destroyed, and any outstanding timer event is cancelled.

In Chromium, we also have a mechanism to call methods on a class
asynchronously.  This mechanism builds on top of WeakPtr.  There is a
templatized factory class that you instantiate as a member of the class you
want to call methods on asynchronously.  (It is called
ScopedRunnableMethodFactory

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
On Tue, Oct 12, 2010 at 6:37 PM, James Robinson jam...@google.com wrote:

 On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote:

 On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote:

 Hmm, I've found weak pointer abstractions to be very useful.  The issue
 with reference counting is that it is easy to introduce memory leaks, and
 has been mentioned, it is sometimes nice to have deterministic object
 destruction.


 We used to have lots of problems with leaking refcounted objects back when
 most refcounting was done manually, but this has become much less common as
 we deployed smart pointers.


 It is also nice to avoid having to have explicit clear() functions and
 then add checks to every other method to assert that they are not called
 after clear().


 Well, if you have a weak pointer you have to check weak pointer validity,
 so you don't save any checks. I don't think explicit close calls are that
 bad. I think it's actually a better pattern when you hold significant
 resources other than just some memory (e.g. VRAM, file handles, sockets,
 limited kernel resources, window server handles...). That way, cleaning up
 your external resources does not become dependent on your ownership strategy
 for the object.


 In the Chromium code base, we have a helper for weak pointers:

 http://src.chromium.org/viewvc/chrome/trunk/src/base/weak_ptr.h?view=markup

 We tend to use this in cases in which:

 1) there are many consumers interested in holding a back pointer to some
 shared resource, and
 2) we'd like the shared resource to die at some predictable time.

 Without a utility like this, the alternative is to make the shared
 resource notify each of the consumers about the impending destruction of the
 shared resource.

 It is true that WeakPtrT adds a null check in front of each method call
 made by the consumers, but that runtime cost is often justified in exchange
 for reduced code complexity (i.e., eliminating the need to notify consumers
 when the shared resource dies).


 The cost isn't just the null checks. You need either storage for all the
 backpointers, or the smaller storage overhead for a refcounted handle. But
 then almost by definition you have more overhead than refcounting, since you
 have a refcounted object plus more work.

 I do think weak pointers have their uses, but only in relatively unusual
 cases (e.g. when you'd have a cycle otherwise). It doesn't sound like a huge
 win in this case.


 Another other advantage of weak pointers over refcounted pointers is that
 with a combination of OwnPtr/WeakPtr it that the ownership is explicit
 and easy to examine locally.  By this I mean if I have:

 class A {
   OwnPtrT m_t;
 };

 class B {
 private:
   WeakPtrT m_t;
 };

 it's immediately and locally obvious which object is responsible for the
 lifetime of the T.  With the alternative:

 class A {
   RefPtrT m_t;
 };

 class B {
   RefPtrT m_t;
 };



^^^ Looks like a memory leak too :-)

One then hopes for up-to-date documentation about how the memory leak is
broken.

-Darin





 there's no way to know which class drives the lifetime of the T without
 reading through the definitions of both A and B (and any other class that
 holds a RefPtr).  This makes it much harder to review changes to A or to B
 without carefully reading through many mostly-unrelated classes.  This is
 especially true when

 A concrete example of this is LayerRendererChromium which used to have an
 OwnPtrGraphicsContext3D member variable, took a
 PassOwnPtrGraphicsContext3D parameter in its create() factory function and
 exposed a GraphicsContext3D* getter.  The lifetime of the GraphicsContext3D
 associated with the compositor was crystal clear just by examining
 LayerRendererChromium.h - it took exclusive ownership of the context at
 creation time and retained exclusive ownership for the lifetime of the
 LayerRendererChromium.  Now that GraphicsContext3D is ref counted, it's not
 nearly as obvious whether the LayerRendererChromium is supposed to be the
 exclusive owner of the underlying context or whether callers might extend
 its lifetime (especially since the GraphicsContext3D* getter now allows
 callers to grab their own references).  Ambiguous and non-local ownership
 semantics makes code harder to review and reason about.

 - James


 Regards,
 Maciej



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


Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
Caused more harm than good?

-Darin


On Tue, Oct 12, 2010 at 10:06 PM, Darin Adler da...@apple.com wrote:

 Not sure it is relevant to this discussion, but WebKit had a weak pointer
 class back in 2002 and I removed it.

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


  1   2   3   >