September 2010 - webkit-dev - lists.webkit.org

Flaky test hit list
by Adam Barth 19 Oct '10

19 Oct '10

Tonight I wrote a new webkit-patch command for detecting flaky tests. Here the tests that have flaked out on the Snow Leopard (Tests) build bot during the last 2000 revisions. This makes a good "hit list" of tests to fix to reduce flakiness. (The worst offenders are at the bottom). Take aways: 1) compositing/geometry/limit-layer-bounds-transformed-overflow.html is by far the worst offender. 2) The websocket tests are ridiculously flaky. 3) The appcache tests also have a serious flakiness problem. I'll run the last 10000 revisions over night and report on the results. Adam === Results === Occurances Test name 1 compositing/reflections/nested-reflection-animated.html 1 fast/css/font-face-download-error.html 1 fast/dom/collection-null-like-arguments.html 1 fast/history/history-subframe-with-name.html 1 fast/js/sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.2_A5_T1.html 1 fast/js/sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.2_A5_T2.html 1 fast/js/vardecl-preserve-arguments.html 1 http/tests/appcache/different-https-origin-resource-main.html 1 http/tests/appcache/fallback.html 1 http/tests/appcache/manifest-redirect.html 1 http/tests/appcache/origin-quota.html 1 http/tests/appcache/resource-redirect.html 1 http/tests/appcache/top-frame-3.html 1 http/tests/appcache/update-cache.html 1 http/tests/appcache/xhr-foreign-resource.html 1 http/tests/cache/subresource-expiration.html 1 http/tests/loading/basic-credentials-sent-automatically.html 1 http/tests/misc/uncacheable-script-repeated.html 1 http/tests/navigation/changing-frame-hierarchy-in-onload.html 1 http/tests/navigation/ping-cross-origin-from-https.html 1 http/tests/navigation/ping-cross-origin.html 1 http/tests/navigation/post-goback-same-url.html 1 http/tests/plugins/get-url.html 1 http/tests/plugins/npapi-response-headers.html 1 http/tests/plugins/third-party-cookie-accept-policy.html 1 http/tests/security/credentials-in-referer.html 1 http/tests/security/cross-frame-access-protocol-explicit-domain.html 1 inspector/debugger-pause-on-breakpoint.html 1 inspector/extensions-events.html 1 media/audio-constructor.html 1 media/video-currentTime-set.html 1 plugins/destroy-stream-twice.html 1 plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html 1 svg/custom/use-invalid-style.svg 1 transitions/transition-end-event-transform.html 1 websocket/tests/send.html 1 websocket/tests/simple-stress.html 1 websocket/tests/sub-protocol-with-space.html 1 websocket/tests/url-no-trailing-slash.html 1 websocket/tests/url-with-empty-query.html 1 websocket/tests/url-with-query.html 1 websocket/tests/websocket-pending-activity.html 1 websocket/tests/workers/close-in-onmessage-crash.html 2 http/tests/appcache/foreign-iframe-main.html 2 http/tests/appcache/local-content.html 2 http/tests/appcache/main-resource-hash.html 2 http/tests/appcache/non-html.xhtml 2 http/tests/appcache/reload.html 2 http/tests/css/css-image-loading.html 2 http/tests/plugins/cross-frame-object-access.html 2 http/tests/security/cross-frame-access-port-explicit-domain.html 2 security/block-test.html 2 websocket/tests/bad-sub-protocol-non-ascii.html 2 websocket/tests/handshake-fail-by-sub-protocol-mismatch.html 2 websocket/tests/simple.html 2 websocket/tests/unicode.html 3 http/tests/appcache/cyrillic-uri.html 3 http/tests/appcache/deferred-events-delete-while-raising.html 3 http/tests/appcache/remove-cache.html 3 http/tests/appcache/top-frame-4.html 3 http/tests/navigation/image-load-in-unload-handler.html 3 websocket/tests/handshake-fail-by-cross-origin.html 3 websocket/tests/httponly-cookie.pl 3 websocket/tests/long-invalid-header.html 3 websocket/tests/sub-protocol.html 3 websocket/tests/url-with-query-for-no-query.html 4 fast/canvas/webgl/gl-object-get-calls.html 4 http/tests/navigation/anchor-basic.html 4 websocket/tests/bad-sub-protocol-control-chars.html 4 websocket/tests/frame-length-longer-than-buffer.html 4 websocket/tests/frame-length-skip.html 4 websocket/tests/frame-lengths.html 4 websocket/tests/reload-crash.html 4 websocket/tests/url-with-credential.html 5 websocket/tests/bad-sub-protocol-empty.html 5 websocket/tests/error-detect.html 5 websocket/tests/handshake-error.html 6 websocket/tests/handshake-challenge-randomness.html 6 websocket/tests/null-character.html 7 http/tests/security/cross-origin-css.html 7 websocket/tests/bufferedAmount-after-close.html 7 websocket/tests/close-on-unload.html 7 websocket/tests/frame-length-overflow.html 7 websocket/tests/handshake-fail-by-no-cr.html 8 websocket/tests/multiple-connections.html 9 websocket/tests/alert-in-event-handler.html 9 websocket/tests/close-on-unload-and-force-gc.html 10 websocket/tests/bad-handshake-crash.html 11 websocket/tests/cross-origin.html 12 http/tests/navigation/ping-same-origin.html 13 websocket/tests/close-on-unload-reference-in-parent.html 15 websocket/tests/close-on-navigate-new-location.html 19 media/audio-controls-rendering.html 50 compositing/geometry/limit-layer-bounds-transformed-overflow.html

6 16

Fwd: Ruby Text Enhancements
by Eric Mader 14 Oct '10

14 Oct '10

Sent from the wrong email alias... Begin forwarded message: > From: webkit-dev-owner(a)lists.webkit.org > Subject: Re: [webkit-dev] Ruby Text Enhancements > Date: September 24, 2010 1:55:19 PM HST > To: mader_eric(a)apple.com > > You must be subscribed in order to post to this mailing list. > > > From: Eric Mader <mader_eric(a)apple.com> > Subject: Re: [webkit-dev] Ruby Text Enhancements > Date: September 24, 2010 1:55:15 PM HST > To: Roland Steiner <rolandsteiner(a)google.com> > Cc: David Hyatt <hyatt(a)apple.com>, WebKit Development <webkit-dev(a)lists.webkit.org>, Yasuo Kida <kida(a)apple.com> > > > I have prototyped something that seems to more-or-less work. Here's what I did: > > 1) Changed RenderRubyRun to subclass these methods: > virtual int marginTop() const; > virtual int marginBottom() const; > virtual int marginLeft() const; > virtual int marginRight() const; > > > 2) added these members to RenderRubyRun: > mutable bool m_haveHorizontalMargins; > mutable int m_leftMargin; > mutable int m_rightMargin; > > 3) Added this private method to RenderRubyRun: > void getHorizontalMargins() const; > > 4) Here's what marginLeft() and MarginRight() look like: > int RenderRubyRun::marginLeft() const > { > getHorizontalMargins(); > > return m_leftMargin; > } > > int RenderRubyRun::marginRight() const > { > getHorizontalMargins(); > > return m_rightMargin; > } > > And here's getHorizontalMargins(): > void RenderRubyRun::getHorizontalMargins() const > { > if (m_haveHorizontalMargins) { > return; > } > > RenderText* rubyRenderText = static_cast<RenderText*> (rubyText()->firstChild()); > RenderText* baseRenderText = static_cast<RenderText*> (rubyBase()->firstChild()); > int rubyLength = rubyRenderText->firstTextBox()->width(); > int baseLength = baseRenderText->firstTextBox()->width(); > int leftMargin = RenderBlock::marginLeft(); > int rightMargin = RenderBlock::marginRight(); > > if (baseLength < rubyLength) { > RenderObject* prevSibling = parent()->previousSibling(); > RenderObject* nextSibling = parent()->nextSibling(); > bool prevIsText = prevSibling && prevSibling->isText(); > bool nextIsText = nextSibling && nextSibling->isText(); > > // FIXME: handle odd difference? > if (prevIsText) > leftMargin += (baseLength - rubyLength) / 2; > > if (nextIsText) > rightMargin += (baseLength - rubyLength) / 2; > } > > m_leftMargin = leftMargin; > m_rightMargin = rightMargin; > m_haveHorizontalMargins = true; > > } > > This method makes several assumptions that I'm not 100% sure are always safe: > * That a RenderRuby object holds only 1 RenderRubyRun object. > * That the text for the ruby text and ruby base are always the direct child of the RenderRubyText and RenderRubyBase object. > * That the neighboring text is always a direct sibling of the RenderRuby object. > > One enhancement I know is needed is to look at successive neighboring objects to make sure that there's enough text there that the overhanging part of the ruby text doesn't overshoot the neighbor(s) as well and bump into something it can't overlap. > > Does this general approach look right? > > Regards, > Eric Mader > > On Sep 22, 2010, at 12:59 PM, Eric Mader wrote: > >> >> On Sep 21, 2010, at 7:16 PM, Roland Steiner wrote: >> >>> Hi Eric, >>> >>> comments inline: >>> >>> On Wed, Sep 22, 2010 at 6:57 AM, Eric Mader <emader(a)apple.com> wrote: >>> >>> On Sep 20, 2010, at 9:52 PM, Roland Steiner wrote: >>>> Oh vey, that's ambituous! :) There's so many corner cases I foresee on this one that I was just too happy to postpone it when we originally discussed to leave out CSS3 ruby stuff from the initial implementation, which is purely based off HTML5 - including supporting multiple base/text pairs within a single ruby, and line-breaking within the ruby. >>> Yes, it's a bit scary. ;-) I don't think I could implement the whole thing at once, so I'm looking at doing a partial implementation. Maybe the first round would only check to be sure that the neighboring blocks aren't <ruby> blocks. >>> >>> I would actually suggest cutting it down further and at first doing it only where the neighbor is plain text - this should still catch 90% of the cases where you'd want overhang and should vastly reduce the corner cases. You can verify and compute this rather easily when layouting the ruby, and you'd not need to worry about different glyph heights of neighboring inline elements, or about replaced elements interfering. Overhang would be basically be the minimum of: maximum overhang, or length of neighboring text run, or available/remaining space on the line. The latter factor may also cause you to need to break the ruby or move it to the next line altogether. >> >> I'll look at this idea too. What do I need to do to find the neighboring inline elements? >> >>> I'm looking at using a RenderOverflow object to implement this. Can you point me at any documentation for this class, other than what's in the code? I'm having some trouble sorting out what all the various rectangles used in conjunction with this object represent. >>> >>> I have to say I'm not personally familiar with RenderOverflow, either (haven't used it with ruby). Just judging from the description it stores overflow rectangles for stuff that is actual content (layout overflow) and stuff that is pure "cosmetic rendering", such as shadows or reflections (visual overflow). For ruby overhang you'd be looking at layout overflow in principle (unless the overhang text also has shadows and stuff, which may add to the visual overflow), AFAICT. But as I said, I'm not really an expert here. >> >> I've been looking at RenderOverflow, and I'm beginning to suspect that it's not the best way to proceed. Now I'm thinking that the negative margins are the way to go. My guess is that I need to set the margins on either the RenderRubyRun object or perhaps the RenderRuby object itself. To compute the correct margins, it looks to me like I'll need to access the widths of the RenderRubyText and RenderRubyBase objects. So far, I haven't been able to work out how to do that. Any clues would be greatly appreciated. >> >>> Cheers, >>> >>> - Roland >> >> Regards, >> Eric >> > > >

4 13

Should we recommend explicit constructors as part of WebKit style?
by David Levin 14 Oct '10

14 Oct '10

This came up before: https://lists.webkit.org/pipermail/webkit-dev/2010-May/012873.html but I'd like to understand it a bit better. It feels there were two points of view: 1. Use explicit only when necessary to prevent an undesirable implicit conversion like int to vector. 2. Use explicit except when it is desirable to allow an implicit conversion that makes the code simpler. For example, the String <-> AtomicString makes the bindings generator code simpler since it doesn't need to know which the underlying method takes. Are there any reasons beyond personal preference to select either of these? Starting list: Pro's for #1 It is a pain to remember to put explicit every time you have a constructor with one argument. Pro's for #2 It would prevent accidental mistakes that happen with implicit constructors. dave

6 7

New Rich Text Editing Test suite
by Roland Steiner 07 Oct '10

07 Oct '10

[Apologies if you have seen this already!] Hi all, As a lot of folks here can probably attest to (Hi, Ryosuke! ;) ), the current state of rich text editing amongst various browsers is not ideal. WebKit is better than most, but still not perfect, either. In order to document this and provide a general overview of what works, what plain doesn't, and what is incompatible, we are currently setting up a new rich text editing test suite as part of the larger browserscope ( http://www.browserscope.org) framework. It is largely an extension and generalization of the already existing "RichText" suite there. At the moment we mainly focus on "contentEditable" and related functionalities in JavaScript (i.e., execCommand(), queryCommandValue(), etc.), as well as selection, but aim to extend this for user input and IME in the future, if at all possible. We hope this test suite will help in identifying the main problem areas (by being a handy, friendly, colorful list of bugs), foster discussion about different opinions on implementation, and thus in turn drive interoperability between browsers. The goal is to reach a common set of editing capabilities with well-defined behavior that is (even more) useful for web authors. A beta version can be accessed at http://www.browserscope.org/richtext2/test (note that being beta, the suite is not yet accessible from the main page at http://www.browserscope.org) Please understand that we are still adding and cleaning up tests, and details of the presentation. But at even at the current, early stage it should give a good idea of the direction of the suite. Indeed, as achieving consensus on the tests contained in the suite is meant to be a community effort, it is bound to change and being extended over time, as it solidifies based on contributions from all sides. Since this can only benefit from the participation of as many folks as possible, we would like to ask for input from everyone interested in the area (even if it's just to grumble - I am happy to solidify past and current grievances into new shiny red tests! ;) ). Thusly, for suggestions, criticism, and general discussion on the suite and/or any tests therein, please post a mail (or many!) at the browserscope mailing list at browserscope(a)googlegroups.com. Best regards, - Roland Steiner

3 13

Re: [webkit-dev] Announcing new port: EFL
by haithem rahmani 05 Oct '10

05 Oct '10

Hi, Just a simple question: - It seems that the EFL port of webkit is based on EFL/X11 api. is there plans to support other EFL backends especially directfb ? WebkitGtk is doing that with (--with-target=directfb) option. regards. Haithem. -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him.

2 2

Re: [webkit-dev] Rationale for PlatformRefPtr?
by Martin Robinson 01 Oct '10

01 Oct '10

On Thu, Sep 30, 2010 at 4:53 PM, Martin Robinson <martin.james.robinson(a)gmail.com> wrote: > On Thu, Sep 30, 2010 at 3:20 PM, Darin Adler <darin(a)apple.com> wrote: >> For example, for Core Foundation and Cocoa we made RetainPtr. For JavaScript we made JSRetainPtr. For GTK I think we should have GTKRefPtr. >> Is there really code where the abstraction of having a single shared PlatformRefPtr is useful? Could someone show me an example of this working? Resent from correct address: Hey Darin, I'll try to clear up the confusion around this and perhaps clearer minds can suggest a better approach. There are several ports that use third party libraries with reference counted types. GTK+ / EFL / and gstreamer based ports use GObject and its associated reference-counting mechanism. In addition, Cairo-based ports (including GTK+ and the WinCairo port) use Cairo reference counted types (which don't use GObject) and ports that use FontConfig also have reference counted types (that is also unrelated to GObject or Cairo). We'd like to share the same templated class for all of these smart pointers to avoid duplicate code. So the idea is that PlatformRefPtr is a smart pointer for your platform-specific reference counted pointers. Unless there is some smart way to do this, to have a GRefPtr, CairoRefPtr and FontConfigRefPtr we would have to duplicate the entire class (which is the way that JSRetainPtr and RetainPtr work). I'm not attached to the name in any way. I would just like for these different ports to share a smart pointer class. Martin

2 5

Rationale for PlatformRefPtr?
by Darin Adler 30 Sep '10

30 Sep '10

What is the core idea behind PlatformRefPtr? There is a lot of ambiguity about what the “platform” is. I’m not sure we should have a single RefPtr template that tries to guess what the platform is and does that style of reference counting. For example, for Core Foundation and Cocoa we made RetainPtr. For JavaScript we made JSRetainPtr. For GTK I think we should have GTKRefPtr. Is there really code where the abstraction of having a single shared PlatformRefPtr is useful? Could someone show me an example of this working? -- Darin

1 0

XHR responseArrayBuffer attribute
by Chris Rogers 30 Sep '10

30 Sep '10

I've noticed that the responseArrayBuffer attribute has recently been added to the XMLHttpRequest-2 specification: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-att… I was interested to know if anybody was planning on implementing that attribute soon. If not, I would like to add this myself. Regards, Chris Rogers

9 23

Re: [webkit-dev] Flaky test hit list
by Eric Seidel 30 Sep '10

30 Sep '10

On Thu, Sep 30, 2010 at 11:06 AM, Eric Seidel <eseidel(a)google.com> wrote: > I've filed bugs for the top two: > >> 19 media/audio-controls-rendering.html > > https://bugs.webkit.org/show_bug.cgi?id=46924 > >> 50 compositing/geometry/limit-layer-bounds-transformed-overflow.html > > https://bugs.webkit.org/show_bug.cgi?id=46912 > > > The websocket tests already have a bug: > https://bugs.webkit.org/show_bug.cgi?id=33307 > > As well as lots of other individual websocket test bugs: > https://bugs.webkit.org/show_bug.cgi?id=33444 > https://bugs.webkit.org/show_bug.cgi?id=37124 > https://bugs.webkit.org/show_bug.cgi?id=37147 > https://bugs.webkit.org/show_bug.cgi?id=45918 >

1 0

Force rebuild on QT Minimal?
by Chris Fleizach 30 Sep '10

30 Sep '10

Is there a way to force a clean build on QT minimal. It looks like it just didn't update building CSSPrimitiveValueMappings.h I tried the Force Build button, but it didn't do a clean build thx

1 0