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

New Feature - Resource Timing
by James Simonsen 22 Mar '12

22 Mar '12

Hello webkit-dev, The W3C Performance WG has been working on a Resource Timing spec. The spec is starting to stabilize and we'd like to start landing it in WebKit too. Resource Timing is a follow up to Navigation Timing, which is already in WebKit. Resource Timing allows site developers to collect detailed network timing information for the subresources they load. The data is exposed through the window.performance namespace and we expect developers to ping this information back to the server with their other analytics data. For security reasons, the spec limits the detailed information to same-origin resources, but there is also a provision for a CORS-like header to allow cross-origin resource timing. Resource Timing will be behind ENABLE(WEB_TIMING) since it relies on some of the same infrastructure as Navigation Timing. We can add an additional ENABLE to keep Resource Timing separate from Navigation Timing if that's desired. The current draft of the Resource Timing API is here: http://w3c-test.org/webperf/specs/ResourceTiming/ A meta-bug to track the necessary work is here: https://bugs.webkit.org/show_bug.cgi?id=61138 Please post any feedback. Thanks! James

6 12

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

DumpRenderTree for the EFL port :)
by Leandro Pereira 04 Nov '11

04 Nov '11

Hey, At last, the EFL port of WebKit got a DumpRenderTree implementation! We're still working on ironing out a lot of bugs found by some of the LayoutTests, but the DRT (and ImageDiff) code has been submitted to Bugzilla. It would be awesome if anyone could help reviewing these patches. DumpRenderTree patches: https://bugs.webkit.org/show_bug.cgi?id=62034 https://bugs.webkit.org/show_bug.cgi?id=61974 https://bugs.webkit.org/show_bug.cgi?id=61962 https://bugs.webkit.org/show_bug.cgi?id=61958 ImageDiff patch: https://bugs.webkit.org/show_bug.cgi?id=61942 Thanks, Leandro

3 4

New feature flag proposal: Joystick API
by Scott Graham 06 Oct '11

06 Oct '11

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

11 23

More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)
by TAMURA, Kent 04 Oct '11

04 Oct '11

Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime, datetime-local, month, time, and week types. * We're going to implement dedicated UIs for them, and will want to disable it temporarily. * Their current implementations are insufficient and one might not want to ship them in browsers, but they were already shipped in some browsers. On Tue, May 24, 2011 at 09:57, Keishi Hattori <keishi(a)webkit.org> wrote: > Hi webkit-dev, > I just wanted to notify everyone that I will be adding a new feature > flag, INPUT_COLOR. http://webkit.org/b/61273 > This flag will enable <input type=color> > I need this flag because the color picker UI needs to be implemented > individually for each platform, and it is going to take some time. > Also the current text field implementation will be disabled. This is > to avoid feature detection so that web pages can fall back to JS color > pickers. > Thanks! > Keishi > _______________________________________________ > webkit-dev mailing list > webkit-dev(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google

2 3

Replacing DOM Mutation Events
by Adam Klein 23 Sep '11

23 Sep '11

Greetings webkit-dev, It's generally agreed upon in the web community, and in WebKit specifically, that DOM Mutation Events are a bad thing. See, e.g., discussion on https://bugs.webkit.org/show_bug.cgi?id=8191 (relating to DOMAttrModified, and why WebKit does not wish to implement it) and https://lists.webkit.org/pipermail/webkit-dev/2010-August/013805.html (a discussion of replacing DOM mutations with something better, or removing them entirely). In late June, Jonas Sicking and Olli Pettay from Mozilla put forward proposals on public-webapps (http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1318.html) to replace mutation events with a different API, one that avoids the problems associated with the existing spec. Rafael Weinstein has helpfully summarized the public-webapps thread (which is now upwards of 200 messages long) in http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html, and discussion is ongoing in http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html. Any WebKit folks interested in the future of mutation events in the DOM are invited to join that discussion, and their input would be much appreciated. I've also put together a partial implementation of Jonas' most recent proposal and uploaded my work-in-progress patch to https://bugs.webkit.org/show_bug.cgi?id=66079. Note that this is very early work, and if I were submitting it for review it would be in much smaller chunks, but I welcome any comments or questions on the code as-is. - Adam

2 3

Early deletion of DocumentLoader instances
by Raphael Kubo da Costa 22 Sep '11

22 Sep '11

Hey there, While working on the EFL port, I've noticed that sometimes a FrameLoader's DocumentLoader ends up being deleted too early (FrameLoader::setDocumentLoader causes the current DocumentLoader to be deref'ed and freed), in the sense that later on Document::explicitClose tries to access this DocumentLoader instance that has already been freed, causing a crash. I couldn't find any abnormal behaviour that could deref the DocumentLoaders more than they should have been. Are there any recommended places where I should look to check what's going on? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi

6 13

Chromium Mac moving to Skia
by Adam Barth 21 Sep '11

21 Sep '11

Hi WebKit, In an effort to make the Chromium port more consistent across platforms, we're moving the Chromium Mac port from CoreGraphics to Skia. This should mostly have little effect on the rest of the WebKit community, but you'll be seeing some patches shortly that shuffle a bunch of test expectations around so that we can make the transition carefully and avoid regressions. Specifically, we're planing to do the following: 1) Move the chromium-mac and chromium-mac-leopard results directories to chromium-mac-cg and chromium-mac-cg-leopard, respectively. This will let use keep both CG and Skia results during the transition so that we can compare them and avoid regressions. 2) Introduce MACCG modifies for test_expectations. This will let use have separate expectations for CG and Skia. 3) Introduce new chromium-mac and chromium-mac-leopard results directories, which will correspond to the new Skia configuration. 4) Move the Chromium Mac builders on build.webkit.org over to using the Skia configuration. Two of these steps will generate somewhat large svn update steps. I'd like to thank you in advance for being patient with us as we make this transition. If you have any questions or concerns, please feel to respond to this thread or to ask Cary or myself. Thanks again, Adam

4 8