Re: [webkit-dev] A catalog of iOS-specific changes related to the WebThread
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)
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))
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))
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
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
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)
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() ?
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?
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
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
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
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() ?
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
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
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)
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
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
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
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
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
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
[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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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)?
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: [webkit-dev] a ping landed
I don't think it is the norm. This one is special for the reasons already stated. -Darin On Mon, Oct 4, 2010 at 11:17 PM, Dirk Pranke dpra...@chromium.org wrote: Keeping it off by default until it has some mainstream acceptance seems like a bit of a self-defeating policy for new features; is this often done in WebKit? -- Dirk On Mon, Oct 4, 2010 at 10:12 PM, Maciej Stachowiak m...@apple.com wrote: Since a ping has been controversial in the past (for arguably bogus reasons, but controversial nontheless), I suggest we keep it off by default until we find it has some mainstream acceptance and/or we discover that more ports want it. Regards, Maciej P.S. We haven't decided yet if we want it on for the ports Apple ships, but it's probable we will turn it on sooner or later. On Oct 4, 2010, at 6:51 PM, Jeremy Orlow wrote: Given that a ping really doesn't open up any new privacy holes (just makes it easier for sites to get the data they're going to gather anyway without slowing down the experience for the user), it seems like we might as well enable it by default. If a port doesn't want it, they can always disable it, right? Thanks, J On Fri, Oct 1, 2010 at 12:39 PM, Nate Chapin jap...@chromium.org wrote: This is a few days late, but I just wanted to let the team know that, as of http://trac.webkit.org/changeset/68166, WebKit can support a ping (but support is disabled by default). The reason I left it disabled by default is that some ports may want to have a mechanism for disabling pings, and I didn't want anyone to accidentally pick it up before they were ready. I'm happy to flip it to enabled by default if that's what people prefer. ~Nate ___ 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
