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

debug the webkit with visual studio 2005
by 赵经纬 05 Feb '10

05 Feb '10

HI: I am an neebie, i want to debug the webkit with visual studio 2005.now i have finished the steps: 1、 *Installing the Developer Tools* <http://webkit.org/building/tools.html> 2、*Getting WebKit* <http://webkit.org/building/checkout.html> 3、*Building WebKit* <http://webkit.org/building/build.html> now i want to run webkit, i open a Cygwin Shell and type this command in the shell WebKit/WebKitTools/Scripts/run-safari --debug but the result is: ERROR:couldn't determine installed safari path setting enviroments for using microsoft visual studio 2005 x86 tools How can i debug the webkit step by step? thank you!

4 3

Implementation thoughts on HTML5 elements
by Maciej Stachowiak 26 Dec '09

26 Dec '09

Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: ---------- - Sectioning elements: <section>, <article>, <aside>, <hgroup>, <header>, <footer>, <nav> These seem useful - they give a way to represent the semantics of many Web pages nicely, and could work well with accessibility features for navigating around the page, as well as other clever ways of processing Web content. They are also trivial to implement (I already did <nav>). We're fairly interested in doing the rest of these. - <dialog> element This essentially gives the same behavior as <dl> but with appropriate semantics for logs of conversations. It seems useful and easy to implement. - Elements requiring changes to <legend> parsing: <figure>, <details> These elements seem quite useful, but they will be unusable on the public Web until all browsers are updated to change how they parse <legend> and the new versions are widely adopted. Pretty much all current browsers do something idiosyncratic when parsing a <legend> element outside of a <fieldset>, which makes it impossible to make <figure> or <details> degrade gracefully via script or style. We are hesitant to implement elements that authors would feel they are unable to use, or to lead authors astray, so we are hesitant to implement the new elements until either the <legend> parsing issue is widely fixed or HTML5 uses some element other than <legend> for the caption on these elements. We will consider fixing our parsing of <legend> outside <fieldset> soon, though, so that we're not the blocker. - New media elements: <audio>, <video> We love these and have them implemented. We don't see any implementation issues in the current spec. - <canvas> We like this and we have it implemented. We don't see any implementation issues in the current spec. - Newly standard legacy elements: <keygen>, <embed> We had these for a long time before they were in HTML5. It seems like a good idea to cover them in the spec. - <mark> The basic idea for this element seems good, but the suggested UI for exposing it does not seem to entirely match the use cases, and may not be practical to deploy. Having tick marks in the scrollbar for every <mark>, and UI to cycle between them, seems too heavyweight for some of the suggested uses. We are interested in implementing the basics of <mark> soon, but probably not the requirements. - <time> It seems useful for use cases like Microformats to have a clean, unambiguous way to represent a specific time. It seems odd that there are ways to get Date objects to represent the date, time and time zone separately, but no way to get a Date representing the combination of date/time/timezone. Wouldn't the latter be a common use case, and doesn't the JavaScript Date object give sufficient APIs to unpack a Date into its components as needed? - New interactive controls: <meter>, <progress> These elements seem useful and a good idea. These controls are useful in native UI and often get hand-rolled by JavaScript libraries. We would like to expose a default native look, but with full author stylability for these. The only odd requirement is the use of inline text content in the elements to represent the state of the control. Specifying inline textContent may be a clever way to pass the initial state, but it seems very clunk as an interface for dynamically updating the state of the progress bar. Using the max and value IDL attributes of <progress> seems like it would be much easier for authors, and it seems like a problem that these only reflect the markup attributes and not the full state of the control (if the state is currently defined by text content). Likewise for the 6 attributes on <meter>. Assembling up to 6 numbers into a textContent string, which then does not cause the convenient DOM attributes to update, seems very clinky. - Ruby elements: <ruby>, <rp>, <rt> We think these are useful. Google engineers are actively working on the WebKit implementation and some initial patches have landed. - <datalist> Work on this is in progress. We think it is a good idea to offer a way to do true combo boxes, including ones with a dynamic source of filled-in values. - <output> This seems relatively simple to implement and worth implementing. - new <input> element types These seem generally useful, and we already have some implemented to various extents (search, range, email, url tel). The only concern is the sheer number of date and time controls. 6 of the 13 new input types are for dates or times. Are there real use cases for all 6? Do all 6 exhaustively cover the types of time and date input you may want to do in forms?

14 36

Should we put the webkit.org mailing lists on Gmane?
by Adam Roben 15 Dec '09

15 Dec '09

Gmane (<http://gmane.org>) provides a few features that could be useful for thewebkit.org mailing lists, including: * a nicer web interface than Mailman's * indexed search (maybe better than Mailman's, certainly at least as good, and with a better interface) * a mail-to-news gateway (good for people who like news readers) I think it would be good to put our mailing lists on Gmane (including importing the archives of the lists). If we do this, I'd suggest using the names gmane.comp.web.webkit. {dev,changes,unassigned,etc.}. This matches what other similar projects (like Chromium) have done. Getting the lists posted and imported just requires filling out a web form (for posting the lists) and sending an email (to request the import). I'm happy to take responsibility for doing this if people are in favor of it. -Adam

5 8

Sharing code between WebCore/bindings/js and WebCore/bindings/v8
by Adam Barth 03 Dec '09

03 Dec '09

I've been doing some work recently in our JavaScript bindings. As part of this work, I've noticed that WebCore/bindings/js and WebCore/bindings/v8 have drifted apart in some details. It's kind of ridiculous that we have so much duplicated code in these two folders. We should try to re-organize our bindings to share as much code as possible. 1) Where should the common code live? One option is to have: WebCore/bindings/js <--- common code WebCore/bindings/jsc <--- JSC specific WebCore/bindings/v8 <--- V8 specific 2) How much should we try to share? For example, we could have an abstracted notion of ArgList that works for both engines, or we could be happy to factor out common routines like createWindow <http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDOMWindowCustom.…>. I presume Sam is a good contact for the JSC bindings. Who's a good contact for the V8 bindings? Thanks, Adam

4 5

How to deal with localized strings
by Michelangelo De Simone 19 Nov '09

19 Nov '09

Hi guys, I'm gonna implement the support to the "validationMessage" HTML5 DOM attribute of form control elements, it shall return a string that describes which validation state the element is in. AFAIK this should be a localized string to be presented to the user: I tought to write a simple: enum ValidationMessage {STD_MSG1, STD_MSG2, etc...} in HTMLFormControlElement to have a simple representation of the standard messages and then leave the localization to the embedder. In order to accomplish this in HTMLFormControlElement::validationMessage() I should return the localized string obtained from the embedder and this is the trouble I went into: how such a thing is usually done in WebKit? I'd appreciate any help you may provide. Thank you. -- Bye, Michelangelo, a future ex-gsocer

3 4

Documenting common null pointer errors
by Adam Barth 06 Oct '09

06 Oct '09

In reviewing patches, I feel like I'm commonly pointing out DOMWindow::frame and Document::frame, etc, can be null in some circumstances. Would it be useful to have a diagram of the major objects (Page, Frame, DOMWindow, Document, etc) somewhere on webkit.org that shows their relation, which links can be null, and which objects change / are preserved during navigation? If so, I'm happy to create this with my current knowledge, and hopefully folks with more experience will add parts that I don't know. What's the best medium to make this easy to update in the future? SVG? ASCII art? Adam

7 15

Fwd: Whitespace changes
by Eric Seidel 09 Sep '09

09 Sep '09

On Thu, Aug 27, 2009 at 11:55 AM, Peter Kasting <pkasting(a)google.com> wrote: > Maintaining a cultural attitude that is widely positive towards cleanup > makes people feel less reticent about cleaning up, and taking ownership of, > code; frowning on certain types of cleanup makes people less likely to do > _any_ cleanup. > +1 I'd love to have perfectly style conferment code at the cost of a few extra svn revisions. For this particular change: http://trac.webkit.org/changeset/47808, I wasn't aware we had a policy regarding trailing whitespace. It seems such a policy will be hard to keep since XCode doesn't support removing trailing whitespace. :( -eric

3 2

New marking model for GC collected objects
by Oliver Hunt 02 Sep '09

02 Sep '09

Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here. The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack. The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack. The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); } Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); } And that's it, you're done. It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error. --Oliver

3 5

Changes to prepare-ChangeLog
by Eric Seidel 02 Sep '09

02 Sep '09

Background: Reviewers spend too much time correcting errors which should be caught by tools. This is frustrating both to contributers and reviewers. One such class of errors are missing or incorrect information in ChangeLogs. I'm trying to fix that. As part of: http://trac.webkit.org/changeset/45464 prepare-ChangeLog now takes an optional --bug= argument and is able to fill in more than before: % prepare-ChangeLog --bug=26383 Running status to find changed, added, or removed files. Reviewing diff to determine which lines changed. Change author: Eric Seidel <eric(a)webkit.org>. Description from bug 26383: "prepare-ChangeLog should have a --bug= argument and use it for url autofill". Editing the ../WebCore/ChangeLog file. Results in: 2009-07-01 Eric Seidel <eric(a)webkit.org> Reviewed by NOBODY (OOPS!). prepare-ChangeLog should have a --bug= argument and use it for url autofill https://bugs.webkit.org/show_bug.cgi?id=26383 DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION Tests: fast/foo.html * foo.cpp: Added. Running prepare-ChangeLog by default will however output more boiler-plate: 2009-07-01 Eric Seidel <eric(a)webkit.org> Reviewed by NOBODY (OOPS!). SHORT DESCRIPTION/BUG TITLE GOES HERE (OOPS!) BUG URL GOES HERE (pass --bug= to autofill) DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION LIST OF TESTS, OR EXPLANATION WHY TESTING IS IMPOSSIBLE GOES HERE (OOPS!) * foo.cpp: Added. However, hopefully the boilerplate is more helpful than before. Unfortunately everyone will now see: DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION in their initial ChangeLogs. This may be annoying to seasoned contributers (and I'm open to removing it). But hopefully it will lead to better ChangeLogs overall. Looking forward to your comments! -eric

27 75