November 2010 - webkit-dev - lists.webkit.org

Is it OK to remove Frame::setIsDisconnected() and isDisconnected() ?
by Sverrir Á. Berg 09 Apr '12

09 Apr '12

Working on a change in FrameTree and noticed that the checks in top() and parent() for 'checkForDisconnectedFrame' rely on a flag in Frame that as far as I can tell is never set.So my naive question is: Can I remove the corresponding code from Frame and FrameTree? If not I would like if somebody could explain how they are used so I don't break anything with my change. More detail: * My search for calls to Frame::setIsDisconnected reveals no callers in WebKit, Chromium or Google code search. * This functionality is disjoint from Frame::disconnectOwnerElement(). Thanks, Sverrir

4 6

Throwing SECURITY_ERR on cross-origin window.location property accesses
by Mihai Parparita 27 Mar '12

27 Mar '12

I was wondering if it would be a reasonable change to make accessing location.href (and other location properties) throw SECURITY_ERR when accessed across origins (https://webkit.org/b/43504) This initially was reported on the Chrome side (http://crbug.com/17325) but it looks like neither the JSC nor V8 bindings do this, so fixing it across the board seemed reasonable. >From my investigations, it looks like IE and Gecko both throw an exception in this case, and the HTML5 spec mentions it too ( http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#se… ). I realize that we're cautious around the access checks for security reasons (based on changes like https://trac.webkit.org/changeset/48619) but this seems safe since 1) we were returning control to the script at that point anyway 2) we already throw exceptions in some cases in that code: https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.… Thanks, Mihai

8 20

Accelerated 2D Tesselation Implementation
by Chris Marrin 03 Mar '12

03 Mar '12

Hi Ken, It would help me, and I think many others, if we could have a discussion of how exactly your tessellation logic works and what it is intended to do. For instance, is the algorithm you're using based on Loop-Blinn? I'm a bit familiar with that algorithm and some of the problems it has with rendering this type of geometry. For instance, there are typically anti-aliasing artifacts at the points where the interior triangles touch the edges. These are described in section 5.1 of the paper and the authors added additional (and not well described) logic to solve the problem. If you could describe your algorithm a bit and show some expected results with typical cases, that would be really helpful. For those not familiar with Loop-Blinn, here is a link to their original paper, presented at Siggraph 2005: Resolution Independent Curve Rendering using Programmable Graphics ... It's a great algorithm for rendering resolution independent 2D objects using the GPU. It has potential to render both 2D shapes (as used in Canvas and SVG) and text glyphs. It's advantage is that once you generate the triangles for the shape, you can render the shape at any resolution. It's disadvantage is that the triangle generation is quite expensive, so mutating shapes can potentially be slower than a simpler resolution dependent tessellation. ----- ~Chris cmarrin(a)apple.com

6 17

ImageLoader class
by Sergiy Byelozyorov 09 Jul '11

09 Jul '11

Hello, I am writing my own class using ImageLoader. Can somebody, please, help me with these questions: 1. How do I know that the image was loaded already? Can I set up callback somehow? 2. What should functions sourceURI() and dispatchLoadEvent() do? 3. What is pixel format for m_imageLoader.image()->image()->data()->data()? Is this the right way to access loaded image raw pixel data? 4. How can I handle animations (e.g. GIF files)? How do I know when the next image in the animation suquence is ready? Another callback? 5. Which image formats are supported? Can I add my own, like HDR? Thank you. Sergiy

1 1

parallel painting
by Zoltan Herczeg 10 Jun '11

10 Jun '11

Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan

8 10

Any objections to switching to Xcode 3.2.4 or newer?
by Darin Adler 03 Jun '11

03 Jun '11

Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I ask because this adds a "developmentRegion = English" string to the project file but the older versions of Xcode remove that string. If we all agree to use the newer version, then we can let that string get checked in. If some of us are using the older version it will be frustrating because the string will be removed each time someone edits the project file with an older version and checks it in. If no one objects, we’ll start checking in the project files with developmentRegion in there. -- Darin

6 7

WebKit blog post proposal: Remote debugging with Web Inspector.
by Pavel Feldman 02 May '11

02 May '11

Hi guys, As some of you know, we are working on a remote debugging feature in Web Inspector. There are many good reasons behind the project including the following: - Debugging WebKit on embedded devices - Shaping up a good protocol for ourselves - Introducing external SDKs on top of the protocol for IDE integrations and alternate front-ends We've had serialized interaction with the out-of-process inspector for quite a while in Chromium. We were upstreaming it into WebKit and have reached an important milestone recently: all the interaction between the inspected page and inspector is entirely serialized on the WebKit level. All the embedder needs to do is to implement a socket that would serve the inspector front-end files and provide our messaging with appropriate transport. Now this socket is likely to be platform-specific, implemented on the WebKit and/or host browser levels. It also makes more sense to implement socket on mobile platforms first. However, we've done a proof-of-concept implementation in Chromium and it is now in a demoable state! See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. The communication is established by means of a WebSocket. The interesting thing about the implementation is that inspector front-end is fetched from the host browser, so that there is no mess with protocol versioning and no need in exposing the interaction protocol any time soon. So I made the demo and it looked cool. I thought maybe we do a blog post on it. The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. Front-end is working as a pure HTML5 application (obviously full of WebKit-specific styles, but still) which is impressive. Now the project is nowhere complete in terms of finalizing the message format and the protocol itself, but there is no intention to expose it right now. We'd like to let it live with fetchable front-end and mature before we expose the protocol and commit to any level of interface support. What do you think, is it ready for a blog post? Thanks Pavel

12 17

Hunspell based spellchecker
by Hajime Morita 27 Apr '11

27 Apr '11

Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like "TextChecker* textChecker() = 0;" to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. -- morrita

11 18

WebKit2 build system
by Balazs Kelemen 11 Apr '11

11 Apr '11

Hi folks! While I worked on the Qt port of WebKit2, I faced with some build issues. To solve these problems it seems like common parts of WebKit2 should change, that is why I thought that discussing them in the list would be useful. There are two main problem I see: * Usage of precompiled header. Without using WebKitPrefix.h as a precompiled header it seems like includes are broken. The reason why I dislike precompiled header is that distcc does not support it. * Include paths. The common files in WebKit2 includes headers in the form #include <WebKit2/xyz.h> while the real place of the file is for example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by copying headers into the build dir and set the includepath to contain it, but I do not think it is a good practice. I think WebKit2 would be more portable if we could solve these problems. Please share your thoughts with me!

6 5

SearchBox API
by Tony Gentilcore 20 Mar '11

20 Mar '11

Hi All, We are working on adding instant search integration to Chrome. This requires a DOM API which only the default search provider has permission to access. As some of you may have seen, earlier this week I sent a proposal for such an API to the WHATWG [1]. Is this something that other ports might be interested in supporting in the future? In any case, are there objections to beginning to land this under flag guard and vendor prefix? -Tony [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028818.html

5 17