Re: [webkit-dev] Elliot Sprehn is now a reviewer
On Mon, Mar 11, 2013 at 3:46 PM, Eric Seidel e...@webkit.org wrote: May our generated content (and general render safety and speed) live long and prosper. :) Don't forget the Shadow DOM! Congrats Elliott! Ask Kling to get you the keys for the reviewers lounge. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto koivi...@iki.fi wrote: The problem with ComposedShadowTreeWalker is not that it is an iterator but that it is ill-defined and complex. It calls back to non-trivial, mutating functions on the structure being traversed (ContentDistributor::distribute!). Simply traversing a tree with it can apparently end up marking the tree for style recalc. This is a really good point. It encapsulates traversal of the composed tree, but this tree's integrity is maintained lazily, which means that as you traverse it, you could force the update. That ain't awesome. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Opera and WebKit
Welcome, Opera folks! Exciting stuff. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 1:28 PM, Eric Seidel e...@webkit.org wrote: * I wish I felt like reviewers understood/trusted each other more. * *I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying.* This is a big one for me (as you would've guessed :). All others seem surmountable if only we could somehow fix this. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Custom Elements
On Tue, Jan 29, 2013 at 7:21 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Jan 29, 2013 at 6:22 PM, Hajime Morrita morr...@chromium.orgwrote: I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Usually specs explain a bit what it is for and give examples toward that goal. Not this spec :( This is all my fault. I've been focusing on getting the actual matter of the spec right, guided by Mozilla's implementation feedback. Can you please summarize what problem Custom Elements is solving for for lazy people like me? :) Custom elements are part of the bigger umbrella of Web Components. There's a nice document that explains how everything fits in to the Web Components--and here's the section on custom elements: http://www.w3.org/TR/components-intro/#custom-element-section Hope this helps! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations
I don't have Dirk's patience, stamina and determination to explain and evangelize the advantages of better awareness of current LayoutTests coverage, I will chime in saying that I gladly support any effort to improve it. I am especially excited about the ability to distinguish failing, passing, and failing-in-different-way expectations. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)
On Thu, May 17, 2012 at 9:11 AM, Darin Adler da...@apple.com wrote: On May 17, 2012, at 4:30 AM, Ojan Vafai wrote: I have a proposal that hopefully addresses everyone's concerns, is minimally different from the current format *and* unifies the format with Skipped lists (i.e. Skipped lists as they exist today are valid test_expectations.txt format). The changes from the current format are as follows: -Leaving out any outcomes means the test is skipped, unless the test has a SLOW modifier, in which case the implied outcome is PASS. -Remove the SKIP modifier entirely. -Make everything but the test name case-insensitive. -Have the test name be the last item on the line -Separate modifiers/outcomes/testname with a common delimiter (i.e. :) -Any line starting with // or # is a comment -Including a bug entry is optional (maybe only if the test is skipped or wontfix?) -Bugs are listed as URLs, except for the bug_ojan format. Examples: foo/bar.html # Skipped wontfix : foo/bar.html # Skipped and we never intend to fix it. For things like dashboard compatibility tests that only Apple will ever want to make pass wontfix : text : foo/bar.html # We never intend to fix this, but we expect it to run and fail text diff. Will still fail if the test times out or crashes. webkit.org/b/12345 : text image : foo/bar.html # Flaky. Sometimes only fails text diff, sometimes only fails pixel diff. slow mac debug : foo/bar.html # Given extra time to run on mac debug, but is expected to pass. image+text : foo/bar.html # Fails both text and pixel diffs bug_ojan : fail : foo/bar.html # Fails and ojan is taking responsibility to address the failure. bug_ojan : foo/bar.html # Skipped and ojan is taking responsibility to address it. # The following would give lint errors image : text : foo/bar.html # two outcomes listed in separate groupings slow text : foo/bar.html # outcome listed with non-outcome modifier crbug.com/12345 text : foo/bar.html # outcome listed with non-outcome modifier crbug.com/12345 : wontfix : foo/bar.html # two non-outcomes modifiers listed in separate groupings Direction seems good. I’d like to think it through and give some more detailed feedback on some of the specifics, but here are some immediate thoughts. I don’t understand why we need the : or + separators. Why not just a list of space-separated words and URLs that can be a mix of modifiers and outcomes? I don’t think we need to support the same words for both modifiers and outcomes. If we want to enforce some kind of order, that would be OK, to reduce arbitrary differences. Maybe it's the Stockholm syndrome talking, but I actually quite like the clear delineation between test modifiers and test expectations. My intuitive reaction to the attempts to bunch them all together is that it will make both writing and reading of a test expectation harder. Having them on either side of the test file also helps, since the test file functions as a natural delimiter. I certainly don't want to be trying to recall who's-on-firsts of modifiers and expectations, if they are on the same side of the file. Sure, there are some bugs in existing formats (like SLOW being a modifier), but can we just fix those and avoid boiling the ocean? :) :DG Instead of bug_ojan I’d prefer a format more like bug(ojan). I’d like to see a list of the modifier and outcome words so I can easily review them. Maybe the test specifier (name or directory name) should come first, before the modifiers and outcomes. -- 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] Simplifying syntax in test_expectations.txt (bug 86691)
Could that be because you haven't actually tried using it? :) On Thu, May 17, 2012 at 4:40 PM, Darin Adler da...@apple.com wrote: Seriously, syntax is a significant barrier. Having to know which special characters to use. I don’t see this “clear delineation” you speak of. Just special punctuation I have to use to satisfy the computer. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)
Sorry, didn't mean to come across as flip. To illustrate, here's an example: WIN SNOWLEOPARD : foo.html = TEXT IMAGE # on all windows platforms and SL, test foo.html is flaky -- fails either with text or pixel results. Easy. TEXT WIN SNOWLEOPARD IMAGE foo.html # fails with text on all windows platforms and SL, oh, and actually it's flaky with pixel results, the foo.html test does. Less easy. Worse yet, since the expectations are commonly updated, you now need to fish through the whole set of specifiers and mentally separate them into expectations and modifiers, then update. It's more likely that this will happen: TEXT WIN SNOWLEOPARD IMAGE LINUX foo.html #test foo.html fails with text on all windows platforms and SL, oh, and actually it's flaky with pixel results, oh, and also on linux, the foo.html test does. :DG On Thu, May 17, 2012 at 4:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Could that be because you haven't actually tried using it? :) On Thu, May 17, 2012 at 4:40 PM, Darin Adler da...@apple.com wrote: Seriously, syntax is a significant barrier. Having to know which special characters to use. I don’t see this “clear delineation” you speak of. Just special punctuation I have to use to satisfy the computer. -- Darin ___ 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
On Tue, May 1, 2012 at 2:06 PM, Maciej Stachowiak m...@apple.com wrote: On May 1, 2012, at 12:20 PM, Eric Seidel e...@webkit.org wrote: Work is complete, fully working. Passing all the tests I could come up with: https://github.com/eseidel/webkit/compare/master...seamless I'm uploading and landing patches once reviewed again in bugzilla. I do not plan to add an ENABLE, as this work is complete and will all be landed by end of week, assuming timely reviews. I'd like to request an ENABLE for risk mitigation purposes (so anyone shipping in the near future could turn it off without having to revert a large patch set.) I agree with Maciej. Despite my huge r3sp3ct for your coding skills I have very little doubt that there will be bugs and things we'll need to fix (and that may slip out into a shipping release). So a flag sounds like a decent protection from those. :DG 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] Should we move methods from layoutTestController/etc... to internals?
On Tue, Feb 21, 2012 at 12:15 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, It appears to me window.internals is a superior solution to expose cross-platform features to our test harness compared to other interfaces implemented in DumpRenderTree and WebKitTestRunner such as layoutTestController and friends. Should we try to move methods of layoutTestController and friends that expose WebCore-level features to internals? Moving methods to internals would reduce DRT/WTR's code size, and lower the entry barrier for new ports. For example, PlainTextController seems to exist only to expose Range::text(). But this function can be exposed via internals for testing purposes instead since it doesn't depend on any port-specific code. I think that's a good idea! Of course, there will be interfaces that rely on WebKit-layer code (e.g. TextInputController) we shouldn't be moving. Right. 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] Should we move methods from layoutTestController/etc... to internals?
On Tue, Feb 21, 2012 at 3:39 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 21, 2012 at 3:14 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 21, 2012, at 1:21 PM, Ryosuke Niwa wrote: I'd prefer getting rid of the entire interface when possible. We're obviously removing layoutTestController, textInputController, etc... at the moment though. I think it's helpful to organize the methods by functional area instead of dumping them all onto one giant interface. layoutTestController for example has far too many methods, in my opinion. We would not design a public API where every method is on one global interface, and our testing API should not look that way either. I would like to see our test API split up more, rather than combined into a single interface. Yeah, that'll be nice. Maybe morrita and dglazkov have an idea on how to do this nicely? I kind of like this plan: https://bugs.webkit.org/show_bug.cgi?id=76423 :DG I'm also confused about your examples of interfaces you are obviously removing. Did you mean obviously not removing? Sorry. Yes, it should read obviously NOT removing. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing Shadow DOM spec in WebKit
Hi WebKit! I wanted to let you know that we are planning to implement the Shadow DOM specification (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) in WebKit. For now, its public-facing APIs will hide behind ENABLE(SHADOW_DOM) flag and help gather implementer and developer feedback. Shadow DOM spec is part of the Web Components effort (see overview here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html), and is on the standards track in the WebApps WG. Work is ongoing (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14972), with participation from Microsoft and Mozilla. Adobe also expressed interest in contributing. In addition, Shadow DOM is being considered as the replacement of similar plumbing in SVG for SVG v.Next. This particular effort is just starting in SVG WG. The meta bug to follow is https://bugs.webkit.org/show_bug.cgi?id=63606. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compiling chromium webkit unit tests on Mac
bcc: both lists. Please avoid cross-posting to such wide lists -- trust me, you don't really want ensuing conversation insanity. Also, build-webkit --chromium will produce the unit tests binary. :DG On Wed, Oct 12, 2011 at 10:31 AM, Fady Samuel fsam...@chromium.org wrote: Hi all, I apologize for sending this out to such a broad audience, but I'd like to know how to compile the chromium webkit unit tests on Mac? I tried this: xcodebuild -project third_party/WebKit/Source/WebKit/chromium/WebKit.xcodeproj -configuration Debug -target webkit_unit_tests It complains about a missing libskia. How do I build skia then? Or is there a better way to build the unit tests? Thanks, Fady ___ 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] Cleaning up directories in WebCore
I agree. My personal favorite is the moving out of the side-loaded features. This looks like a great way to add clarity to what WebCore really means. :DG On Fri, Nov 18, 2011 at 2:19 AM, Eric Seidel e...@webkit.org wrote: SGTM. manual-tests is a no-brainer for sure. On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote: I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! 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] Enable REQUEST_ANIMATION_FRAME on all ports? (was Re: ENABLE flag cleanup strawman proposal)
James, this is a crazy cool mail. I found it full of TILs and think its guts totally should be on our blog. Bonus points: pictures. :DG On Mon, Sep 26, 2011 at 9:48 PM, James Robinson jam...@google.com wrote: On Sun, Sep 25, 2011 at 6:52 PM, Darin Adler da...@apple.com wrote: On Sep 25, 2011, at 12:20 AM, James Robinson wrote: The TIMER based support for RAF is very new (only a few weeks old) and still has several major bugs. I'd suggest letting it bake for a bit before considering turning it on for all ports. Got it. Fundamentally I don't think this feature can be implemented reasonably well with just timers, so port maintainers should take a really careful look at the level of support they want to have for this feature when deciding if they want to support it. This may contradict the recommendation above. If the timer-based version is too low quality then maybe we shouldn’t put ports in the position of shipping with a substandard implementation rather than simply having the feature omitted. Perhaps if I expand on my concerns a bit it'll be clearer what the right option is. The goal of requestAnimationFrame is to allow web authors to have high-quality script-driven animations. To use a concrete example, when playing angry birds (http://chrome.angrybirds.com/) and flinging a bird across the terrain, the RAF-based animation should move the bird at a uniform rate across the screen at the same framerate as the physical display without hitches or interruptions. An additional goal is that we shouldn't do any unnecessary work for frames that do not show up on screen, although it's generally necessary to do this in order to satisfy the first goal as I'll show below. There are two main things that you need in order to achieve this that are difficult or impossible to do with a WebCore Timer: a reliable display-rate aligned time source, and a source of feedback from the underlying display mechanism. The first is easiest to think about with an example. When the angry bird mentioned above is flying across the screen, the user should experience the bird advancing by the same amount every time their display's update refreshes. Let's assume a 60Hz display and a 15ms timer (as the current REQUEST_ANIMATION_FRAME_TIMER code uses), and furthermore assume (somewhat optimistically) that every frame takes 0ms to process in javascript and 0ms to display. The screen will update at the following times (in milliseconds): 0, 16 2/3, 33 1/3, 50, 66 2/3, 83 1/3, 100, etc. The visual X position of the bird on the display is directly proportional to the time elapsed when the rAF handler runs, since it's interpolating the bird's position, and the rAF handler will run at times 0, 15, 30, 45, 60, etc. We can thus determine the visual X position of the bird for each frame: Frame 0, time 0ms, position: 0, delta from last frame: Frame 1, time 16 2/3ms, position: 15, delta from last frame: 15 Frame 2, time 33 1/3ms, position: 30, delta from last frame: 15 Frame 3, time 50 0/3 ms, position: 45, delta from last frame: 15 Frame 4, time 66 2/3 ms, position: 60, delta from last frame: 15 Frame 5, time 83 1/3 ms, position: 75, delta from last frame: 15 Frame 6, time 100 0/0 ms, position: 90, delta from last frame: 15 Frame 7, time 116 2/3ms, position: 105, delta from last frame: 15 Frame 8, time 133 1/3ms, position: 120, delta from last frame: 15 Frame 9, time 150 0/3 ms, position: 150, delta from last frame: 30 (!) Frame 10, time 166 2/3 ms, position: 165, delta from last frame: 15 Frame 11, time 183 1/3 ms, position: 180, delta from last frame: 15 Frame 12, time 200 0/0 ms, position: 195, delta from last frame: 15 What happened at frame 9? Instead of advancing by 15 milliseconds worth, the bird jumped forward by twice the normal amount. Why? We ran the rAF callback twice between frames 8 and 9 - once at 135ms and once at 150ms. What's actually going on here is we're accumulating a small amount of drift on every frame (1.6... milliseconds, to be precision) between when the display is refreshing and when the callbacks are being invoked. This has to catch up sometime so we end up with a beat pattern every (16 2/3) / abs(16 2/3 - 15) = 10 frames. The same thing happens with a perfect 16ms timer every 25 frames, or with a perfect 17ms timer every 50 frames. Even a very close timer will produce these regular beat patterns and as it turns out the human eye is incredibly good at picking out and getting annoyed by these effects in an otherwise smooth animation. For this reason, you really need a precise time source that is tied in to the actual display's refresh rate. Not all displays are exactly 60Hz - at smaller form factors 50 or even 55hz displays are not completely unheard of. Additionally the normal clock APIs aren't always precise enough to stay in sync with the actual display - particularly on windows it's really hard to find a clock
Re: [webkit-dev] Implementing style scoped
On Mon, Sep 12, 2011 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote: Hi all, After several discussions on the whatwg@ mailing list and others, we would like to go forward with adding style scoped to WebKit. Overview: Style rules within style scoped only apply to the parent element of style scoped (the scoping element), as well as descendants of it. Any other nodes are unaffected. This allows authors to style specific parts of a page without requiring ID prefixes. It also has potential performance benefits, as scoped rules do not need to be evaluated outside their scope. As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element) in that we would match selectors only up to, and including, the scoping element. E.g.,: It sounds like there wasn't consensus to make this spec change. In particular, Hixie's last comments seemed to disagree with the proposed change. My preferences would be: 1. Implement what the spec says rather than diverging. 2. Get the spec actually changed, or at least agreement in principle to change the spec, then implement the proposed behavior. 3. Make sure to webkit prefix it and maybe even call the attribute something other than scoped if we are not confident of the spec change coming through. It's definitely *not* ok to call the attribute scoped but not match what the spec says, in my opinion. I would strongly prefer #1 or #2 to #3. I don't have any particular opinion on the substantive issue, but I don't think we should just diverge without agreement from others. Yeah. You're right. We should get Hixie to change the spec. I don't think we should implement currently spec'd behavior or change the name. That last option sounds exceptionally bad. Roland, can you post on that thread and request the spec change? :DG 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] Code Search for webkit.org
I 3 codesearch. It's fast, and it's accurate. :DG On Thu, Sep 8, 2011 at 2:52 PM, Eric Seidel e...@webkit.org wrote: I'm curious how other developers search the WebKit code? I use http://codesearch.google.com/#search/q=package:webkit from time to time. If others do too, we should make it a redirect from cs.webkit.org (like we do for cia.webkit.org). Or maybe folks have better code search solutions? grep -r? -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] Top Crasher: Shadow DOM and Editing Collide Again
Thanks for bringing this up Ryosuke! I looked over the problem. It seems, the issue is as follows (generalized from the specific conditions): a) When an editing command runs, it modifies DOM in discrete steps. For instance, the SplitTextNodeCommand first inserts a node, then removes data from existing node (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/editing/SplitTextNodeCommand.cppl=98). b) Some of these operations may force style recalc. For example, modifying that existing node in SplitTextNodeCommand eventually may call FrameSelection::textWillBeReplaced (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/editing/FrameSelection.cppl=379). c) Depending on the state of the tree, the node (or parent of the node for text nodes) that's being modified could have its style recalculated. For example, if a sibling + universal selector are at play, the whole tree is basically doomed to always have its style recalculated (see repro in bug). d) This situation produces two unwanted results: 1 -- the style is calculated in the middle of the editing command run, producing definitely incorrect results (for example, in the repro in bug, you will have style calculated for a string aa in the text area, since we first insert data, and then remove data. This is usually wall-papered over by the next style recalc, which is triggered at the end of the editing command. 2 -- the style recalc my trigger forms machinery to assume that this change is for realz and start updating its form values, and, as it happens in the repro on bug, stomp over the CharacterData we just started to update, leading to BOOM. Did I get the details right? If so, the feasible three solutions that I can imagine are: A. Ensure that any layout that's forced by an editing operation is performed in a specific order, ensuring that the forced style recalc does not find the tree in a mid-transition state. For example, this particular crash could be fixed by changing the order of operations to update character data first. B. Change editing commands to force layout only at the end of the operation, making the commands more atomic. C. Add case-specific hacks to areas of code where we know there are troubles. For example, we could add a flag to HTMLTextAreaElement to say please ignore, this is not a real style recalc, the real one is coming up. What do you think? :DG On Sun, Aug 28, 2011 at 7:16 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, We have a nightmare of editing v.s. shadow DOM again. The WebKit bug 66241 is currently the top renderer crasher in Chromium (probably affecting Safari 5.1 as much as well). The problem is that when the shadow DOM is modified by the editing code, the shadow host's style is marked dirty and updateLayout ends up calling updateFromElement on the shadow host. RenderTextControl*::updateFromElement then recreates the children of innerTextElement, and invalidates all positions, ending selections, etc... that editing code holds, causing the crash. We can certainly add band aids in the editing code to check the nullity of positions and node ref-pointers and exit early when they are null. However, this would result in wrong behavior because editing operations will end up bailing out early in the middle of doing something. It appears to me that there are a couple of approaches we can take but none of them are promising: Avoid marking the shadow host dirty when editing code is modifying its shadow tree - This approach is a little fragile in that there's nothing that stops authors from writing selectors that matches shadow host with certain nodes in its shadow tree, in which case the problem persists. Avoid re-creating innerTextElement's contents when the shadow host's style changes - This requires a lot of work and may not be feasible in some cases because authors can override -webkit-apperance and there are certain properties such as whitespace, direction, etc... that need to propagate from the shadow host. Make editing code aware of this situation and update positions and node references as needed - As far as I can tell, this is infeasible. It'll require us creating some XPath-like objects at every other line in editing, and computing node references and positions back from those objects. Are there any clever alternatives here? 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] Top Crasher: Shadow DOM and Editing Collide Again
On Mon, Aug 29, 2011 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: Thanks for the analysis, Dimitri. On Mon, Aug 29, 2011 at 12:01 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 1 -- the style is calculated in the middle of the editing command run, producing definitely incorrect results (for example, in the repro in bug, you will have style calculated for a string aa in the text area, since we first insert data, and then remove data. This isn't really unwanted. It happens everywhere in editing and we need those style recalculation in place because editing code inherently relies on renderStyle. i.e. updating styles at intermediate states are needed by editing code. Makes sense. 2 -- the style recalc my trigger forms machinery to assume that this change is for realz and start updating its form values, and, as it happens in the repro on bug, stomp over the CharacterData we just started to update, leading to BOOM. This is the problem. It's same thing as if mutation event listeners started modifying DOM in the middle of an editing command. Right. A. Ensure that any layout that's forced by an editing operation is performed in a specific order, ensuring that the forced style recalc does not find the tree in a mid-transition state. I don't think this approach is feasible given that it requires us modifying hundreds of lines of editing code. B. Change editing commands to force layout only at the end of the operation, making the commands more atomic. I can safely say this is impossible because editability itself depends on style; i.e. whether a node is editable or not is determined by -the value webkit-user-modify. Nodes without renderers are treated differently than nodes with renderers in editing code. C. Add case-specific hacks to areas of code where we know there are troubles. For example, we could add a flag to HTMLTextAreaElement to say please ignore, this is not a real style recalc, the real one is coming up. As far as I'm concerned, this is the only practical solution among the three. I'm still quite skeptical as to why we'd have to re-create descendent nodes of innerTextElement upon style recalc / layout. It seems odd that the life time of the shadow DOM is tied to its host's style change. I just realized what's going on here. The lifetime of the shadow DOM _used_ to be tied to the HTMLTextAreaElement's RenderObjects. Kent-san changed that and now the shadow DOM's lifecycle matches that of the rest of the DOM. However, the update cycle still assumes that the shadow DOM lives on the RenderObjects, and does this really freaky thing with shuttling updated value via an extra style recalc (see http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLTextAreaElement.cppl=349). We should just fix that and move updating code out of updateFromElement. :DG - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building Chromium port of WebKit on Windows
On Thu, Aug 25, 2011 at 6:45 AM, Mikhail Naganov mnaga...@chromium.org wrote: Hello Chromium port maintainers, Back at you, Chromium port maintainer! :) In order to figure out why my patch was failing to compile on the Chromium WebKit bot, I went a long way of compiling the port on my machine. And it was a tough experience! As for the instructions on on how to do the build, I could only refer to this page: http://trac.webkit.org/wiki/Chromium and bot logs. And they were not enough for me, so I would like to ask you some questions, as that might be helpful for other people trying to build this port. Thank you for doing this! There are very few engineers who work on Chromium WebKit in Windows. We desperately need your help. - it looks like VS2008 is required to build the Chromium port (as for Chromium itself), while building plain WebKit requires VS2005 (according to http://www.webkit.org/building/tools.html). Does that mean it's impossible to use a single checkout of WebKit for building both? I vaguely remember that Chromium made this switch, but it didn't click with me that you can't build the WebKit port using VS2008. You can certainly use single checkout -- provided you have both VS2005 and VS2008 installed. - from bot logs, it looks like 'update-webkit' and 'build-webkit' scripts are launched under Strawberry Perl, not from cygwin, as all paths are of MS-DOS style. I tried this way, and it didn't worked at all. E.g. for some reason it couldn't find Python, although I have it in path; Yes! Here are the instructions that I wrote for setting up the the bots, parts of them should really be moved to the Chromium page: http://trac.webkit.org/wiki/BuildBot#Non-cygwinWinRequirements - then I followed instructions from http://trac.webkit.org/wiki/Chromium and ran those scripts under cygwin. It almost worked, except for the issues below: - ffmpeg.rules, libjpeg.rules and webcore_bindings_sources.rules were expected to be found in project directories, while actually they were generated into Source\WebKit\chromium; - several Python scripts (from Source\WebCore\WebCore.gyp\scripts) were receiving MS-DOS paths for output, which were becoming incorrect after applying os.path.abspath to them (under cygwin, the function was just prefixing paths with '/cygdrive/c/...'); - also it looks like several output paths were of MS-DOS style, because I've found generated files under paths like 'C?/src/WebKit/...', and was needed to copy them to their designated locations; - and vice versa, in generated .rc files there were cygwin-style paths to resources, resulting in a failure for Visual Studio's resources compiler to find them; - and, as I was building the port with VS2005, I've encountered some compilation and linking problems mostly fixable by installing hotfixes. I have tried to do the build on two machines, so I hope this isn't a problem of a particular system configuration. But the bot works fine, and this makes me think that perhaps I was doing something wrong or missing some important steps. Yeah, all those are a result of you trying to run this in cygwin. Can you please try the instructions for build bots and update the wiki? :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building Chromium port of WebKit on Windows
On Thu, Aug 25, 2011 at 10:21 AM, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 25, 2011 at 10:07 AM, Mikhail Naganov mnaga...@chromium.org wrote: I'm not sure we are on the same page. I'm talking about Chromium port of WebKit, where Chromium checkout is _inside_ WebKit's Source/WebKit/chromium, as opposed to when you have full WebKit checkout inside Chromium's third_party. Yes, we're saying always use the latter, as it lets you test the same things and it's much more well-supported and tested :) FWIW, I use the former exclusively on Mac. I don't see a need for a typical WebKit developer who lives in WebCore to ever carry a Chromium checkout. :DG PK ___ 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
We should do this right, you won't hear any arguments from me. But I am also sure that W3C time investment is a code word for years of soul-sucking bureaucratic drudgery. As such, I don't think you meant we should be using W3C process as the measuring stick for doing things right in WebKit. There would not be WebKit if we did. What I hope you meant instead is: * study the problem in the larger context of a Web platform * come up with a set of use cases that cover the problem * design a solution based on the use cases * build consensus with browser vendors while prototyping it in WebKit * write a spec and a test suite that makes sense * submit this to W3C as time permits. That's what we've always done, right? :DG On Wed, Aug 24, 2011 at 10:21 AM, Simon Fraser simon.fra...@apple.com wrote: My main objection to adding this is that it's just one of many different types of input device, and if we add these piecemeal for each device that takes our fancy, we'll end up with a horrible mishmash of different input events. I'd prefer a more general strategy of thinking about all the various types of input events (e.g. joysticks, remote controls, assistive devices), and having an API that caters for all of them. This of course would require significant W3C time investment. Simon On Aug 24, 2011, at 9:43 AM, Dimitri Glazkov wrote: On Wed, Aug 24, 2011 at 9:39 AM, Scott Graham scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.com wrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. There's certainly work to be done in improving the design. I'm not proposing to slavishly implement the API exactly as specified there. However, I would like to prototype and help with the design of this API by iterating an implementation in the Chromium port. Is a feature flag inappropriate for this? i.e. Should that sort of prototype work be kept downstream indefinitely or until we have a draft spec? FWIW, keeping implementation downstream (that is in Chromium) is basically an equivalent of forking, and we should work hard to avoid that. But certainly not by just rejecting prototyping outright -- because the only workaround for that is forking. :DG ___ 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
If it's helpful, I can attempt to document these bits of methodology somewhere on our wiki. Another thing -- perhaps we could point newcomers like Scott to Whatwg as the forum for design discussions, rather than referring to W3C process? :DG On Wed, Aug 24, 2011 at 11:25 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We should do this right, you won't hear any arguments from me. But I am also sure that W3C time investment is a code word for years of soul-sucking bureaucratic drudgery. As such, I don't think you meant we should be using W3C process as the measuring stick for doing things right in WebKit. There would not be WebKit if we did. What I hope you meant instead is: * study the problem in the larger context of a Web platform * come up with a set of use cases that cover the problem * design a solution based on the use cases * build consensus with browser vendors while prototyping it in WebKit * write a spec and a test suite that makes sense * submit this to W3C as time permits. That's what we've always done, right? :DG On Wed, Aug 24, 2011 at 10:21 AM, Simon Fraser simon.fra...@apple.com wrote: My main objection to adding this is that it's just one of many different types of input device, and if we add these piecemeal for each device that takes our fancy, we'll end up with a horrible mishmash of different input events. I'd prefer a more general strategy of thinking about all the various types of input events (e.g. joysticks, remote controls, assistive devices), and having an API that caters for all of them. This of course would require significant W3C time investment. Simon On Aug 24, 2011, at 9:43 AM, Dimitri Glazkov wrote: On Wed, Aug 24, 2011 at 9:39 AM, Scott Graham scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.com wrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. There's certainly work to be done in improving the design. I'm not proposing to slavishly implement the API exactly as specified there. However, I would like to prototype and help with the design of this API by iterating an implementation in the Chromium port. Is a feature flag inappropriate for this? i.e. Should that sort of prototype work be kept downstream indefinitely or until we have a draft spec? FWIW, keeping implementation downstream (that is in Chromium) is basically an equivalent of forking, and we should work hard to avoid that. But certainly not by just rejecting prototyping outright -- because the only workaround for that is forking. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Thu, Jun 30, 2011 at 1:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Hi Sam! On Wed, Jun 29, 2011 at 7:50 PM, Sam Weinig wei...@apple.com wrote: Hi Dimitri, First of all, nice work on getting to this point! Thanks, it's been a nice, long slog :) It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? I think you're right, more work is needed in getting more consensus on the first step. I am glad this thread generated so much excitement, even if mixed with confusion. As a result, we've taken this thread to public-webapps. Maciej is asking exactly the same questions here: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1387.html Please follow along :) I posted a follow-up on public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0975.html Please chime in with your observations, concerns, critiques and cheers. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
Hi Sam! On Wed, Jun 29, 2011 at 7:50 PM, Sam Weinig wei...@apple.com wrote: Hi Dimitri, First of all, nice work on getting to this point! Thanks, it's been a nice, long slog :) It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? I think you're right, more work is needed in getting more consensus on the first step. I am glad this thread generated so much excitement, even if mixed with confusion. As a result, we've taken this thread to public-webapps. Maciej is asking exactly the same questions here: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1387.html Please follow along :) :DG - Sam On Jun 28, 2011, at 7:42 PM, Dimitri Glazkov wrote: Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ 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] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 6:49 AM, Dominic Cooney domin...@chromium.org wrote: On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. I think webkitShadowRoot makes sense—it is precise, the parallelism with the constructor name makes sense, and the reflexive shadowHost/shadowRoot is nice. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? The aforelinked document (http://dglazkov.github.com/component-model/dom.html) doesn't really explain the reasons . I also found a list of use cases: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. But there's not really an explanation of how this proposal meets the use cases, and from cursory examination it seems to blatantly violate one of them in a way that XBL2 did not: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation These are good questions; Dimitri is a better person to answer them than me. On the security and isolation use case: I take the point about exposing shadowRoot running counter to using shadow DOM as a security boundary. I’m skeptical about that particular use case. I think isolation should be supported by something that puts less emphasis on presentation and is more closely related to the isolation boundary web pages have today (ie iframes.) Easier isolation is appealing, but feels like a pork-barrel amendment to XBL use cases. I have been and am going to keep arguing against it in other venues. Right -- we discussed this on public-webapps a while back: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0900.html. I'd like to see all of this explained better before putting this experimental API in the tree. If we are going to invent a new thing instead of implementing XBL2 or working with the relevant standards groups to improve XBL2, I think everyone should understand the reasoning for doing so. XBL2 is an awesome spec, and we borrow from it as much as can (in fact, most of style/event plumbing follows the spec pretty precisely), but in trying to tackle an immense
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 3:35 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? Also, I'll post on public-webapps as a follow-up to our earlier discussions and present this API-let as the first step forward. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Shadow DOM API (first iteration) ready for landing
Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Extra review requirement for web-facing API? (Was: Re: Spellcheck API for WebKit)
It's partially my fault. I saw the train wreck coming, but got distracted with other stuff and did not follow through. I think the problem was that: 1) I should've been more firm in insisting on waiting for feedback from webkit-dev. 2) Brent had no business reviewing that patch. To prevent this from happening again, we should remind everyone to: 1) Only review things they are comfortable with; 2) Seek WebKit elder's review for public-facing APIs I don't think we need an explicit two-level review policy. If anything, we need super-reviewers instead. :DG On Wed, Jun 22, 2011 at 11:31 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 22, 2011 at 11:28 AM, Simon Fraser simon.fra...@apple.com wrote: Thank you, Adam. Given this fiasco, I'm temped to propose that we require two levels of review for new web-facing API. That sounds reasonable. But adding, say, new CSS property or supporting new event that has been implemented by other browsers do not seem that risky. So maybe only new in the sense of it hasn't been implemented by other major browsers? - Ryosuke ___ 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] window.internals is teh hot. Help make it work on all platforms
As of http://trac.webkit.org/changeset/87948, we have a new, less painful way to write WebCore tests: the window.internals object. Similar to window.layoutTestController, this object is only exposed when DRT runs. Unlike window.layoutTestController, you don't have to wade in every port's implementation of DumpRenderTree and plumb the calls through each port's layer to implement your WebCore-related layout test methods. As an example, see how simple it is to expose all shadow DOM-related methods with window.internals: https://bugs.webkit.org/show_bug.cgi?id=61671. This is possible, because the implementation of the window.internal object actually lives in WebCore (http://trac.webkit.org/browser/trunk/Source/WebCore/testing/), but is built as a separate library, which is linked into DumpRenderTree. There is a tiny bit of port-specific code that then facilitates construction and injection of the object instance, allowing the actual testing code to stay port-independent. Obviously, this is not a replacement for window.layoutTestController. Here's a set of simple rules you should follow when deciding where to add your testing hooks: 1) Does the code you are testing reside entirely in WebCore? If yes, use window.internals. 2) Otherwise, use window.layoutTestController. End-to-end tests are still a huge part of our testing infrastructure. Finally, A CALL TO ACTION. Currently, the window.internals object only work on platform/mac and platform/chromium. We need heroes to help implement it for other ports. If you are a hero, please fix one of these bugs: https://bugs.webkit.org/show_bug.cgi?id=61071 https://bugs.webkit.org/show_bug.cgi?id=61074 https://bugs.webkit.org/show_bug.cgi?id=61076 Thank you, heroes! And thank you Hajime Morrita, Darin Adler, Alexey Proskuryakov, and Mark Rowe for ideas and direction. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
Hello,
SUMMARY: we would like to introduce a webkit-resource URL scheme for
CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the
ControlPart enum
(http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ThemeTypes.hl=48exact_package=chromium),
which is exposed as the -webkit-appearance CSS attribute. For
example:
video::-webkit-media-controls-play-button {
-webkit-appearance: media-play-button;
}
In addition, the state of the button is further adjusted by looking at
the runtime state or media characteristics of the element (is the user
currently hovering or clicking on the element? is it playing? is it
streaming? has an error occurred?). This happens at the port layer, in
RenderTheme implementation.
With impending introduction of media element pseudo-classes and the
patch in bug 58342 landing, we will be able to sense these extra
states at the CSS level:
video:playing::-webkit-media-controls-play-button:hover {
-webkit-appearance: media-play-button-playing-hover;
}
This would result in a lot less of mindless style-flipping
RenderTheme/MediaControlElement code and provide more flexibility for
each port to design their pretty things.
However, sticking with existing -webkit-appearance strategy will
result in ControlPart enum exploding as combinatorial math suggests.
Which is a ...
PROBLEM: We need a way to somehow in CSS associate an element state
with a relatively arbitrary key to avoid ControlPart from becoming the
tallest enum ever.
SOLUTION: Looking at the current media controls implementations, most
of the -webkit-appearance states are kind of like background images,
each reflecting appearance of an element at a particular state. Thus,
it seems we should be able to solve this by just using CSS
backgrounds:
video:playing::-webkit-media-controls-play-button:hover {
background: url(/media-controls/play-button-hover.png);
}
That is how the authors would style the media controls. However, at
the UA level, we shouldn't probably be loading resources from random
sites. Instead, we need a way to bake these images into the WebKit
runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover {
background: url(webkit-resource:/media-controls/play-button-hover.png);
}
A quick poll of smart people (abarth and smfr) seems to indicate it's
not a completely horrid idea.
WDYT? Thoughts? Comments?
:DG
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-resource: referring to resources in User Agent stylesheet
It would be extremely easy to limit it to UA sheets only.
:DG
On Tue, Apr 26, 2011 at 2:05 PM, Sam Weinig wei...@apple.com wrote:
Would we want this to be web facing? Or should we limit it to inside the
built-in stylesheets?
-Sam
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
Hello,
SUMMARY: we would like to introduce a webkit-resource URL scheme for
CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the
ControlPart enum
(http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ThemeTypes.hl=48exact_package=chromium),
which is exposed as the -webkit-appearance CSS attribute. For
example:
video::-webkit-media-controls-play-button {
-webkit-appearance: media-play-button;
}
In addition, the state of the button is further adjusted by looking at
the runtime state or media characteristics of the element (is the user
currently hovering or clicking on the element? is it playing? is it
streaming? has an error occurred?). This happens at the port layer, in
RenderTheme implementation.
With impending introduction of media element pseudo-classes and the
patch in bug 58342 landing, we will be able to sense these extra
states at the CSS level:
video:playing::-webkit-media-controls-play-button:hover {
-webkit-appearance: media-play-button-playing-hover;
}
This would result in a lot less of mindless style-flipping
RenderTheme/MediaControlElement code and provide more flexibility for
each port to design their pretty things.
However, sticking with existing -webkit-appearance strategy will
result in ControlPart enum exploding as combinatorial math suggests.
Which is a ...
PROBLEM: We need a way to somehow in CSS associate an element state
with a relatively arbitrary key to avoid ControlPart from becoming the
tallest enum ever.
SOLUTION: Looking at the current media controls implementations, most
of the -webkit-appearance states are kind of like background images,
each reflecting appearance of an element at a particular state. Thus,
it seems we should be able to solve this by just using CSS
backgrounds:
video:playing::-webkit-media-controls-play-button:hover {
background: url(/media-controls/play-button-hover.png);
}
That is how the authors would style the media controls. However, at
the UA level, we shouldn't probably be loading resources from random
sites. Instead, we need a way to bake these images into the WebKit
runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover {
background: url(webkit-resource:/media-controls/play-button-hover.png);
}
A quick poll of smart people (abarth and smfr) seems to indicate it's
not a completely horrid idea.
WDYT? Thoughts? Comments?
:DG
___
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-resource: referring to resources in User Agent stylesheet
On Tue, Apr 26, 2011 at 7:50 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote: On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble jer.no...@apple.com wrote: FWIW, WebKit/mac generates these images programmatically, so there's not really a URL for play button hover state which can be targeted. That said, if the URL scheme could be overloaded to handle generated content, I guess this could still work. WebKit/mac could either parse the URL path and special case media-controls/play-button-hover.png, or define our own URL scheme, e.g. background: url(webkit-generated:media-play-button-playing-hover); But then we're just back to something functionally identical to -webkit-appearance. I guess what I'm getting at is, if support for webkit-resource: is added, great. However, at least one port will still need the old behavior. Yes! The -webkit-appearance must stay. This is purely an additive thing. Would we end up with different stylesheets for different ports, then? (Or is media control styling already different between ports?) Yeah, it's already different. :DG Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Dropping support for WML?
On Fri, Apr 8, 2011 at 10:08 AM, Darin Adler da...@apple.com wrote: On Apr 8, 2011, at 2:09 AM, Ryosuke Niwa wrote: We have been discussing the possibility of dropping WML support in WebKit on IRC for a while now because • None of core ports (Mac, Windows, GTK, Qt, Chromium) use it by default • Maintenance cost is high I’ll just add one other thing: HTML form element implementations have factoring that are twisted and complicated because of WML in a way that makes working on those classes unpleasant for me. It would make form work considerably easier if we drop WML support. This is possibly the main practical argument for dropping it. I totally agree. -- 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] Progress
I know that Adam Barth was the driving force behind this, since it was his turn at gardening WebKit (that's a Chromium thing http://www.chromium.org/developers/how-tos/webkit-merge-1). I wonder if we as a community would benefit from a cross-organizational rotation like this? Remembering strong negative reaction to this idea last time -- (more process is bad!) -- but hey, all-green tree is freaking amazing. :DG On Fri, Apr 1, 2011 at 6:30 AM, Adam Roben aro...@apple.com wrote: -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev Screen Shot 2011-04-01 at 9.29.19 AM.png___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
I am so glad you guys are test-driving gardening too. Yay team! :) :DG On Fri, Apr 1, 2011 at 7:09 AM, Adam Roben aro...@apple.com wrote: Major kudos to Adam (Barth) for all his gardening efforts this week! (Somehow this slipped out of my previous message.) -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
First, let me warm the tone of this thread a bit with an earnest salute to Adam for trying to solve the problem by actually doing _something_, rather than talking about it, as we've done for years now. My own contributions to the matter are small and insignificant in comparison. To recall, we do have a real and present problem. Adding files to the all the build systems (and _always_ missing at least one) sucks balls. Needing to use XCode to add new files to WebKit is silly. On the other hand, we have an otherwise well-established and rather smooth workflow and we don't want to give that up, either. With the gyp conversion at this stage, we now have a possible solution to this problem. Given that there aren't any other viable alternatives in the present, please consider the most productive way of contributing: filing well-formulated bugs, blocking bug 55018 (https://bugs.webkit.org/showdependencytree.cgi?id=55018hide_resolved=1). We can then discuss these specific problems and adjust the shape of the solution accordingly. :DG On Thu, Mar 24, 2011 at 1:30 AM, Maciej Stachowiak m...@apple.com wrote: On Mar 24, 2011, at 12:28 AM, Adam Barth wrote: On Wed, Mar 23, 2011 at 8:46 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 23, 2011, at 3:33 AM, Adam Barth wrote: From my perspective, approach (2) is more desirable than checking in generated project files because approach (2) encapsulates Apple-internal build process to Apple folks, more specifically to the Apple folks who interact with the Apple-internal build system. Checking in generated project files, on the other hand, imposes a maintenance burden on all WebKit contributors. I believe Apple submissions generally happen with greater frequency than the rate at which new files are added to the project. Furthermore: When files are added to the project, the patch submitted must already run the tool to regenerate projects, and is already going to submit a patch, so the maintenance burden of the Xcode projects being checked in is low. But having to regenerate project files and then check them in on a branch adds extra steps, doing things that are not done in the normal course of development, and therefore may have bitrotted. Thanks, that's helpful information. Looking at http://trac.webkit.org/log/trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj, it looks like files are added to the project on the order of once a day. I slightly underestimated how often files are added to the project (no wonder our build has gotten so slow!), but the rate is similar. (Side note: it looks like 382 files have been added to the WebCore build over the past year, a ~25% growth rate - if this rate continues, we are in big trouble.) I don't think you are going to get Apple folks enthusiastic about switching to a build system that creates significantly more work for us, on the basis that it saves everyone else a small amount of work. For that matter, slowing down the pace of Apple engineers' development would be a bad thing for the project overall, not just for Apple. I certainly have no desire to slow down the pace of development for anyone. My overarching goal here is to increase developer productivity for everyone by removing the need to learn and correctly modify N build systems just to add, remove, or move a file. From this discussion, it sounds like folks are generally comfortable with replacing the existing xcodeproj files with ones generated by GYP. Before taking that step, I'm going to spend some more time polishing the GYP-generated xcodeproj files, hopefully addressing some of Mark's concerns. (I'm also told there are some scheduling issues, which I'm happy to accomodate.) I'm slightly skeptical that checking in generated files will scale as we unify more of the build systems, but we can cross that bridge when we come to it. Other ports probably do not have so many strange requirements driven by an external build system, so I'm not sure it will be as necessary. That being said the average WebKit developer updates or builds much more often than he or she changes a project file, so it may be the right tradeoff to save people the most total time. 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
[webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
Dear WebKit,
It seems we have a bit of a conundrum with spec-conforming element
rendering. The
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-meter-element-0,
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0,
and
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-input-element-as-a-range-control
all state something along these lines:
When the control is wider than it is tall (or square), the control is
expected to be a horizontal slider, with the lowest value on the right
if the 'direction' property on this element has a computed value of
'rtl', and on the left otherwise. When the control is taller than it
is wide, it is expected to be a vertical slider, with the lowest value
on the bottom.
How shall we accomplish this?
Today, we happily use -webkit-appearance to apply platform-specific
appearance to the controls. The trouble is, the value of
-webkit-appearance is going to be different depending on the value of
logical width.
For example, consider input type=range style=width: 100%; height: 200px
http://jsfiddle.net/dglazkov/qmnKN/1/embedded/result/
If the logical width of the control is over 200px, the property
-webkit-appearance: sliderthumb-horizontal applies to it.
As you size the window down, at the point where the width of the
control is less than 200px, the property -webkit-appearance:
sliderthumb-vertical should start apply to it.
One could imagine something like this for a set of rules to describe this:
input[type=range]:horizontal::-webkit-slider-thumb {
-webkit-appearance: sliderthumb-horizontal;
}
input[type=range]:vertical::-webkit-slider-thumb {
-webkit-appearance: sliderthumb-vertical;
}
where horizontal and vertical pseudo-classes are applied according
to logical width/height ration of the control box. This seems gross,
since we'll need to create a new rendering primitive
(RenderGrossOrientationAwareBox?), which re-matches style during
layout, as early as the logical width of a box can be determined.
Tab pointed out to me that introducing something like this would also
be a bad idea, since the logical width/height ration may be affected
by the newly-re-matched rules:
foo:vertical {
width: 1px; /* no longer vertical */
}
So it sucks. Please help with better ideas?
Our options:
a) add a gross hack in layout for these elements to re-match style
after calculating logical width
b) do something even grosser.
c) do something more brilliant.
d) not implement this part of the spec.
P.S. This is a continuation of discussion on
https://bugs.webkit.org/show_bug.cgi?id=54440.
:DG
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
On Fri, Mar 4, 2011 at 12:16 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Mar 2011, Dimitri Glazkov wrote: Today, we happily use -webkit-appearance to apply platform-specific appearance to the controls. The trouble is, the value of -webkit-appearance is going to be different depending on the value of logical width. Why not have a value of 'appearance' that automatically uses the right orientation, instead of having orientation-specific values? You are correct, the theme can paint correctly oriented slider controls in by looking at the box size it's painting. Hyatt pointed out the same thing on #webkit. However, the issue still exists in the cases of meter and progress. They are using plain-old CSS gradient rules, not magic platform painter (calked RenderTheme in WebKit). :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Test Expectations: A Pipe Dream
(re-sending to webkit-dev, since this idea was just mentioned on #webkit) If wishes were fishes, checking layout tests expectations into WebKit would work like so: * Authors of layout tests never need to submit test expectations with their patches * All new patches are flagged by a Layout Test Expectations Resolver (LaTER from here on). * LaTER is a set of EWS bots (one for each platform). It takes the new patch, applies/builds/runs tests/generates expectations. * Newly generated expectations are compared against existing expectations. A minimal set of changes for each platform is created. * This set of generated expectations is merged with the changes in the original patch, and attached to bug as a new patch, obsoleting the original patch. LaTER knows not to chew on this patch again. * The rest of the process (review/cq/land) is the same as it was before. Thoughts? Comments? More crazy ideas? :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Sun, Dec 19, 2010 at 3:22 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-18, at 08:43, Darin Adler wrote: On Dec 18, 2010, at 2:23 AM, Adam Barth wrote: While we're in the mood to rename directories, would these renamings make sense: WebKitSite = WebSite WebKitExamplePlugins = ExamplePlugins LayoutTests = Tests I would use Website http://en.wikipedia.org/wiki/Website rather than WebSite. But to me that raises the question of what to call BugsSite. My 2¢: Add a top-level Sites directory and then do the following: WebKitSite = Sites/webkit.org BugsSite = Sites/bugs.webkit.org PlanetWebKit = Sites/planet.webkit.org I like it! :DG - Mark ___ 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] cr-mac-ews
You need to rm -rf /Projects/CrMacEWS/WebKit/chromium/third_party. We had to do the same for build.webkit.org builders this week. You're right, the dependency management -- the underlying cause of all cr-specific build pain -- has gotten pretty hairy. :DG On Sat, Dec 4, 2010 at 5:39 PM, Eric Seidel e...@webkit.org wrote: Has been broken for days. http://queues.webkit.org/queue-status/cr-mac-ews Any thoughts from Chromium peeps how it's supposed to be fixed? We seem to be having increasing trouble keeping the Cr EWS bots running w/o hand-holding. -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] cr-mac-ews
That's what happens when you let non-build-people do build-people work :) :DG On Sun, Dec 5, 2010 at 10:20 AM, Marc-Antoine Ruel mar...@chromium.org wrote: You need to use --force on automated testing. We didn't have to clobber any slave. M-A Le 5 décembre 2010 12:57, Adam Barth aba...@webkit.org a écrit : maruel mentioned something about command-line flags we can pass to gclient to make it more robust. Adam On Sun, Dec 5, 2010 at 9:49 AM, Dimitri Glazkov dglaz...@chromium.org wrote: You need to rm -rf /Projects/CrMacEWS/WebKit/chromium/third_party. We had to do the same for build.webkit.org builders this week. You're right, the dependency management -- the underlying cause of all cr-specific build pain -- has gotten pretty hairy. :DG On Sat, Dec 4, 2010 at 5:39 PM, Eric Seidel e...@webkit.org wrote: Has been broken for days. http://queues.webkit.org/queue-status/cr-mac-ews Any thoughts from Chromium peeps how it's supposed to be fixed? We seem to be having increasing trouble keeping the Cr EWS bots running w/o hand-holding. -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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbot Performance
I would venture to guess that's probably it. :DG On Tue, Oct 19, 2010 at 9:21 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: Ins't this due to the fact Chromium bots run pixel tests and others don't? - Ryosuke On Tue, Oct 19, 2010 at 9:17 AM, Eric Seidel e...@webkit.org wrote: That does not sound expected or desired. Could you point me to which Chromium builders are responsible for so much data? I suspect this is an artifact of new-run-webkit-tests or how the Chromium builders are set up. On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com wrote: Right now, /results/ is served from the new storage and is receiving test results data since a day or two ago. For anything older, you will get redirected to /old-results/ which is on the old storage. This probably breaks your code if you are trying to load /results/ and walk backwards in revisions. We should probably look at adding some sort of map to the /json/builders/ data instead. On a side note, Chromium test results account for 75% of the 700GB of result data, SnowLeopard is 11%, then everyone else. I assume Chromium generating so much more data than everyone else is expected and desired? -Bill On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote: The most frequent consumer of the historical data is webkit-patch, which uses it to map from revisions to builds: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L109 It's used when we're walking back through revisions trying to find when the build broke, or when the user passes us a revision and expects us to know build information about such. It's possible we could move off that map with some re-design. One thing which would *hugely* speed up webkit-patch failure-reason (and sherriff-bot, and other commands which use the build_to_revision_map) is if we could make the results/ pages paginated. :) I would be nice to keep all the build data for forever. Even if after some date in the past its on a slower server. -eric On Sat, Oct 16, 2010 at 12:38 AM, William Siegrist wsiegr...@apple.com wrote: On Oct 14, 2010, at 10:13 AM, William Siegrist wrote: On Oct 14, 2010, at 9:27 AM, William Siegrist wrote: I am in the process of moving buildbot onto faster storage which should help with performance. However, during the move, performance will be even worse due to the extra i/o. There will be a downtime period in the next few days to do the final switchover, but I won't know when that will be until the preliminary copying is done. I am trying not to kill the master completely, but there have been some slave disconnects due to the load already this morning. I'll let everyone know when the downtime will be once I know. The copying of data will take days at the rate we're going, and the server is exhibiting some strange memory paging in the process. I am going to reboot the server and try copying with the buildbot master down. The master will be down for about 15m, if I can't get the copy done in that time I will schedule a longer downtime at a better time. Sorry for the churn. Most of build.webkit.org is now running on the newer/faster storage. However, the results data[1] is hundreds of gigabytes, going back 6 months, and the new storage is not big enough. Does anyone have any opinion on how much data to keep in results? Does anyone ever look back more than a month or two? For now, the results will still come up a slowly, but hopefully the rest of buildbot is a little more responsive. We're still planning to move all of webkit.org to better hardware soon, but we hit some delays in that process. [1] http://build.webkit.org/results/ Thanks -Bill ___ 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] Can node-renderer()-node() == node ever be false?
Any takers? :) https://bugs.webkit.org/show_bug.cgi?id=45821 :DG On Tue, Sep 14, 2010 at 9:16 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Ok, after following down a few rabbit holes, I can with some degree of certainty say that node-renderer()-node() == 0 can only at the end of RenderWidget::destroy(), but that is clearly not the case we're fishing for. Even if we modify the loop to start at the parent, we're jumping into the render tree to find a node to fire an event on, which is unhealthy for various layering reasons. In summary, to quote the great protagonists from a TV show: Exterminate! Exterminate! :DG On Tue, Sep 14, 2010 at 7:19 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Sounds good, I will look into this. FWIW, when I remove this loop, I see no regressions in layout tests, including the tests added with the same commit as the loop. :DG On Tue, Sep 14, 2010 at 5:55 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 14, 2010, at 5:41 PM, Dimitri Glazkov wrote: Sorry, I meant node-renderer()-node() != 0. My bad. This loop will always exit in in the first iteration. It definitely is possible for renderers to have a null result from node(). I do not know for sure that it's impossible for node-renderer()-node() to be null under any circumstances. Anonymous renderers and inline continuations are among the ways a null node pointers. It might be that in all such circumstances, the renderer won't be returned by any node's renderer() method. It would be worth some analysis. - Maciej :DG On Tue, Sep 14, 2010 at 4:45 PM, Adam Roben aro...@apple.com wrote: On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote: I've been looking at this line here and it doesn't seem to make sense to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153 It looks like the loop in question will always exit early, because it short-circuits to node-renderer()-node() == node, which seems like it always will be true. At least, that's what the layout tests say when I remove it. I don't see anything in that loop that is equivalent to node-renderer()-node() == node. All I see are null-checks. Note that line 2154 declares a new variable with the name node. I don't know anything else about this code or what you're asking, though. -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] Can node-renderer()-node() == node ever be false?
Dear WebKit, I've been looking at this line here and it doesn't seem to make sense to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153 It looks like the loop in question will always exit early, because it short-circuits to node-renderer()-node() == node, which seems like it always will be true. At least, that's what the layout tests say when I remove it. The loop was added here: http://trac.webkit.org/changeset/25057/trunk/WebCore/page/EventHandler.cpp Can the elders and the wizards of WebKit shine the light upon my forehead and provide me with the mirth of understanding? :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can node-renderer()-node() == node ever be false?
Sorry, I meant node-renderer()-node() != 0. My bad. This loop will always exit in in the first iteration. :DG On Tue, Sep 14, 2010 at 4:45 PM, Adam Roben aro...@apple.com wrote: On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote: I've been looking at this line here and it doesn't seem to make sense to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153 It looks like the loop in question will always exit early, because it short-circuits to node-renderer()-node() == node, which seems like it always will be true. At least, that's what the layout tests say when I remove it. I don't see anything in that loop that is equivalent to node-renderer()-node() == node. All I see are null-checks. Note that line 2154 declares a new variable with the name node. I don't know anything else about this code or what you're asking, though. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can node-renderer()-node() == node ever be false?
Sounds good, I will look into this. FWIW, when I remove this loop, I see no regressions in layout tests, including the tests added with the same commit as the loop. :DG On Tue, Sep 14, 2010 at 5:55 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 14, 2010, at 5:41 PM, Dimitri Glazkov wrote: Sorry, I meant node-renderer()-node() != 0. My bad. This loop will always exit in in the first iteration. It definitely is possible for renderers to have a null result from node(). I do not know for sure that it's impossible for node-renderer()-node() to be null under any circumstances. Anonymous renderers and inline continuations are among the ways a null node pointers. It might be that in all such circumstances, the renderer won't be returned by any node's renderer() method. It would be worth some analysis. - Maciej :DG On Tue, Sep 14, 2010 at 4:45 PM, Adam Roben aro...@apple.com wrote: On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote: I've been looking at this line here and it doesn't seem to make sense to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153 It looks like the loop in question will always exit early, because it short-circuits to node-renderer()-node() == node, which seems like it always will be true. At least, that's what the layout tests say when I remove it. I don't see anything in that loop that is equivalent to node-renderer()-node() == node. All I see are null-checks. Note that line 2154 declares a new variable with the name node. I don't know anything else about this code or what you're asking, though. -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] Can node-renderer()-node() == node ever be false?
Ok, after following down a few rabbit holes, I can with some degree of certainty say that node-renderer()-node() == 0 can only at the end of RenderWidget::destroy(), but that is clearly not the case we're fishing for. Even if we modify the loop to start at the parent, we're jumping into the render tree to find a node to fire an event on, which is unhealthy for various layering reasons. In summary, to quote the great protagonists from a TV show: Exterminate! Exterminate! :DG On Tue, Sep 14, 2010 at 7:19 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Sounds good, I will look into this. FWIW, when I remove this loop, I see no regressions in layout tests, including the tests added with the same commit as the loop. :DG On Tue, Sep 14, 2010 at 5:55 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 14, 2010, at 5:41 PM, Dimitri Glazkov wrote: Sorry, I meant node-renderer()-node() != 0. My bad. This loop will always exit in in the first iteration. It definitely is possible for renderers to have a null result from node(). I do not know for sure that it's impossible for node-renderer()-node() to be null under any circumstances. Anonymous renderers and inline continuations are among the ways a null node pointers. It might be that in all such circumstances, the renderer won't be returned by any node's renderer() method. It would be worth some analysis. - Maciej :DG On Tue, Sep 14, 2010 at 4:45 PM, Adam Roben aro...@apple.com wrote: On Sep 14, 2010, at 6:46 PM, Dimitri Glazkov wrote: I've been looking at this line here and it doesn't seem to make sense to me: http://trac.webkit.org/browser/trunk/WebCore/page/EventHandler.cpp#L2153 It looks like the loop in question will always exit early, because it short-circuits to node-renderer()-node() == node, which seems like it always will be true. At least, that's what the layout tests say when I remove it. I don't see anything in that loop that is equivalent to node-renderer()-node() == node. All I see are null-checks. Note that line 2154 declares a new variable with the name node. I don't know anything else about this code or what you're asking, though. -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] attached()
Overall, this is a great change. It just needs to also take into the account HTMLPluginImageElement. :DG On Thu, Sep 9, 2010 at 10:23 AM, David Hyatt hy...@apple.com wrote: On Sep 9, 2010, at 12:17 PM, Eric Seidel wrote: I'm not sure what you mean. You mean that the change in my patch to run the lazyAttach logic from insertedIntoDocument may cause additional style recalcs? The new element needs style calculated regardless. Marking an element with childNeedsStyleRecalc doesn't recalculate the style for that object to my knowledge. Oh I thought lazyAttach was actually marking nodes as needing a full style recalc. If it's not then I guess that's fine. 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
Re: [webkit-dev] skipping tests on Chromium
// Doesn't apply to Chromium (QuickTime-specific behavior) WONTFIX SKIP : test/name = TIMEOUT :DG On Mon, Aug 30, 2010 at 9:43 AM, Eric Carlson eric.carl...@apple.com wrote: On Aug 30, 2010, at 8:59 AM, Dimitri Glazkov wrote: We never had platform/chromium/Skipped, as far as I know. Ah, I saw that platform/chromium/Skipped was removed in r66261 and assumed it was a change. Instead, we use the expectations file: http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt Instead of skipping tests, we still run them, but expect them to fail. This allows for both being able to see how the test fails and pulling down baselines when it just needs to be updated. What is the correct METADATA for a new media test that doesn't apply to Chromium (it is for a QuickTime specific behavior)? I think the test will fail because it uses a movie you probably don't support, so filing a bug seems like unnecessary busy work. I think the test will time out but I don't know so what is the correct EXPECTATIONS? eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Six new layout tests missing expected results
Yep. It's his. He doesn't have a Mac, so he's been trying to collect results from the bot pretty much all day today. Given that he's not a committer either, that's twice as hard :) :DG On Wed, Aug 18, 2010 at 7:37 PM, David Levin le...@chromium.org wrote: Fady, it looks (http://trac.webkit.org/search?q=tables/hittesting/filltable-emptycells.html) like this is due to your patch. dave On Wed, Aug 18, 2010 at 7:32 PM, Maciej Stachowiak m...@apple.com wrote: Who knows what is up with these? I'm guessing they came from the same patch. Please fix if you know what these are about. fast/table/simple_paint.html - new tables/hittesting/filltable-emptycells.html - new tables/hittesting/filltable-levels.html - new tables/hittesting/filltable-outline.html - new tables/hittesting/filltable-rtl.html - new tables/hittesting/filltable-stress.html - new ___ 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] Getting rid of WebCore.xcodeproj developmentRegion diff
Hi all, After a mini-b*tchfest on #webkit, Eric suggested I take it to the mailing lists :) It seems that we have this annoying little diff thrashing around in WebCore/WebCore.xcodeproj/project.pbxproj: http://trac.webkit.org/changeset/65520/trunk/WebCore/WebCore.xcodeproj/project.pbxproj http://trac.webkit.org/changeset/65468/trunk/WebCore/WebCore.xcodeproj/project.pbxproj http://trac.webkit.org/changeset/65349/trunk/WebCore/WebCore.xcodeproj/project.pbxproj http://trac.webkit.org/changeset/65344/trunk/WebCore/WebCore.xcodeproj/project.pbxproj ... Do you guys know of the cause of this and how we can make it go away? :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
No apologies necessary! This was illuminating to me too, even though I _might have_ been the guy who put the we probably don't want to run these comment in :P :DG On Wed, Aug 11, 2010 at 11:19 AM, Eric Seidel e...@webkit.org wrote: Clearly I was misinformed. My apologies for using the webkit-dev list to track down this chromium-specific issue. On Wed, Aug 11, 2010 at 11:09 AM, Mads Sig Ager a...@chromium.org wrote: The V8 buildbots are running the sputnik tests and they do catch regressions for us. In the V8 repository we have a list of V8 test expectations for the sputnik tests. http://build.chromium.org/buildbot/v8/waterfall -- Mads On Wed, Aug 11, 2010 at 7:32 PM, Ojan Vafai o...@chromium.org wrote: Just looking at the history, it looks like when the tests were originally checked in, they had no expected results. So someone on the chromium team skipped them all. There's a comment in http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt that we probably don't want to run these, but I think that comment is just wrong. On Wed, Aug 11, 2010 at 9:31 AM, Eric Seidel e...@webkit.org wrote: If these tests are actually valuable, then maybe my question then belongs: Why is Chromium no longer running these tests? (Assuming my source is correct.) -eric On Wed, Aug 11, 2010 at 7:10 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 10, 2010, at 2:26 PM, Alexey Proskuryakov wrote: 10.08.2010, в 14:00, Adam Barth написал(а): A better long-term fix might be to finish new-run-webkit-tests so we can run the tests in parallel. One reason to move the tests to run-javascriptcore-tests is that people working on JS run these more often (sometimes not even building WebCore until ready to submit a patch). If these tests can catch regressions from non-JS-engine changes (and according to Adam's message, they have done so at least once), then we need to run them in the full browser engine context, even if we also have a version that runs in a JS-only command-line tool. As another data point, some of the Sputnik tests are currently failing in WebKit2 on Mac, so they are detecting a problem that they wouldn't be able to if they ran JS-only. 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 ___ 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 Mutation Events. WAS: Fwd: webkit editing rewrite?
On Mon, Aug 9, 2010 at 9:28 PM, Geoffrey Garen gga...@apple.com wrote:
As Ojan indicated,
the use cases for DOM Mutation events are extremely limited and to me,
most of them feel like we should be solving them differently anyway.
This is the question I'm most interested in.
You say the use cases are limited. How do you know? Are you speaking about
when you would use mutation events, or do you have data on when authors use
them on the web? Is one of the limited use cases on a high traffic web site?
I don't have any data -- just my own intuition at this point.
Does Mozilla share your opinion? Do others?
It would be awesome if Mozilla shared my opinion. We should hook up
with them and have a beer-laden discussion. I heard they like beer.
I have the same questions about Ojan's claim.
Good! Let's try to answer them together.
For example, in every one of the use cases listed in Wiki, the
mutation events are just workarounds for deficiencies of today's Web.
Just take a gander:
Keeping updated statistics of page DOM -- these are things that a
browser should do. If we have a JS developer who writes a selector
engine (for justifiable reasons, of course) -- we as browser
developers have failed our users. We should be providing this
functionality out-of-the-box.
Widgetify dynamically created markup -- this cries for a decent
behavior attachment construct.
Poor man's XBL -- dude, the title says it all.
For browser extensions (not for web page authors) -- again, we should
be solving this with allowing XBL-like behavior attachment
capabilities and certainly not mutation events.
However, with the introduction of extensions into Chromium and Safari,
DOM Mutation events experience a sort of renaissance, being used to
sense the DOM changes to re-apply modifications (rewrite URLs, text,
etc.).
This is an interesting data point.
If we just need an event for an extension to reapply its magic to new
content, a global, asynchronous DOMContentChanged event might work.
Yes. After extensions launched, I managed to get into fixing some of
the mysterious isolated-world-related crashes and was amazed to find
out how many extensions use this anti-pattern:
document.body.addEventListener(DOMNodeInserted, function() {
process() }, false);
If we introduced an API like that, and gave extensions developers time to
update, we could probably remove mutation events without harming extensions.
I'd like to give the same kind of consideration to data about web content.
With this in mind, I think we should do #1 and #3, then #2 after some
time and loud over-communication (like Inspector warnings, blog posts,
billboards on Hwy 101 etc.).
I'm not sure this plan makes sense. If we plan to do #2 (remove mutation
events), #1 (make mutation events asynchronous) may not be worth the effort.
You're probably right.
Also, I'm not sure that the best time to remove mutation events depends on
what we do (communication) -- it most likely depends on what others do
(changing web content not to use mutation events, or not).
On the other hand, I would be willing to chip in to see Friends Don't Let
Friends Use DOM Mutation Events in big letters over highway 101 :).
Yes! Yes! Big Comic Sans letters! :)
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). :DG On Mon, Aug 9, 2010 at 5:11 PM, Geoffrey Garen gga...@apple.com wrote: Hi Ojan. Mutation events are a huge source of crashes and they complicate WebCore code considerably. Indeed. I also think mutation events unnecessarily complicate the API space from a web content author's perspective. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. I think this is the key question -- how does existing content use mutation events, and what would we risk by changing or eliminating them? Another important question is whether/how important DOM API compatibility tests, like the Acid tests, use mutation events. What's the best way to answer these questions? I think that answer will probably guide our perspective on the options you listed. Here's some options I see: Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. This seems like the most appealing option if (a) backwards compatibility requires us to keep mutation events, but (b) making them asynchronous doesn't harm that backwards compatibility in significant ways. Drop support for them with no replacement. This seems like the most appealing option if mutation events just aren't used. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. This seems like the most appealing option if we're going to try to coordinate our action on mutation events with third party changes. (Otherwise, the beforeinput/input events can be an independent concern.) Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). I just skimmed this API description, but my take on it is that it's very similar to #1 -- it's still a pretty intrusive set of mutation-related APIs, just an asynchronous one. I'm not convinced by Jonas Sicking's claim that this API is significantly different because it lacks a bubble / capture phase. I don't think that was ever the main problem with mutation events. So, I prefer #1 to #4, since #4 just seems like a more complicated way to avoid the burden of synchronous mutation events. Geoff ___ 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] Crash in RenderLayer related to setStyle() - Questions
Coincidentally, http://webkit.org/coding/dom-element-attach.html
:DG
On Sat, Jul 24, 2010 at 9:53 AM, Dan Bernstein m...@apple.com wrote:
On Jul 23, 2010, at 3:48 PM, Alex Milowski wrote:
I've identified a crash with the MathML implementation related to use of
CSS style rules that cause a RenderLayer instance to be created. In the
MathML code's various createRenderer() methods, they always call
RenderObject::setStyle() on the object they've just created.
When the setStyle() method is called, a style difference is calculated
and propagated. If you call setStyle() inside your createRenderer()
method, you're calling it on an unattached RenderObject instance.
Further, if there happens to be a rule like:
math {
overflow: auto;
}
you'll get a layer created by RenderBoxModelObject. That layer
will get the style change.
Right now, as the code stands, you'll get an exception and crash
due to the fact that the RenderLayer code makes some assumptions
about the RenderObject instance being attached to the tree.
The fix is trivial but my question is basically: what's the right thing
to do here? Should the setStyle() be called in createRenderer() ? It
seems like the answer is no because the style gets associated
somewhere else. If I remove the call, the crash is also fixed (without
any change to RenderLayer) and the tests still all pass for MathML.
Further, should RenderLayer be made more safe? Should it check
for zero pointer values in a couple places and avoid this?
If we shouldn't be calling setStyle() in createRenderer(), then fixing
RenderLayer would just hide that fact. While an ASSERT wouldn't
hide things, it would still only arise when a layer is created.
I know how to fix the MathML code and I just want to make
sure I understand why calling setStyle() is bad.
I'm not sure what should be done about RenderLayer or otherwise.
Suggestions?
Do not call setStyle() from createRenderer(). Node::createRendererIfNeeded()
calls setAnimatableStyle() on the renderer after setting it as the node’s
renderer, so there is no need for createRenderer() to call setStyle(); and as
you saw, calling it before setting the node’s renderer violates the
assumption that the pointers between node and renderer are in a consistent
state (which is not to say that renderer-node-renderer is always the
original renderer).
___
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] Chromium bots red; does someone know how to fix it?
I'll fix. Sorry about that. :DG On Wed, Jul 7, 2010 at 12:40 PM, Darin Adler da...@apple.com wrote: Who has the knowledge and access needed to fix problems like this? svn: Working copy '/Users/cltbld/Desktop/BuildSlaveData/WebKit-BuildSlave/chromium-mac-release/build/WebKit/chromium/sdch/open-vcdiff' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: Working copy '/WebKit-BuildSlave/chromium-linux-release/build/WebKit/chromium/third_party' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: Working copy '/WebKit-BuildSlave/chromium-linux-release-tests/build/WebKit/chromium/tools/gyp' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Because of this the Chromium bots aren’t building, so I may be breaking Chromium left and right! -- 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] Git repository stuck / behind?
Yup. It's borked. :DG On Sat, Jun 26, 2010 at 5:33 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Is the Git repository stuck / behind / borked? It doesn't seem to have any revisions after 61865. -- Dirk ___ 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] Commit Queue Author Changes
This is great! Thanks guys for putting this together. The dominance of e...@webkit.org as the most prolific committer is about to come to an end! :P :DG On Sat, Jun 26, 2010 at 8:56 PM, William Siegrist wsiegr...@apple.com wrote: The Commit Queue now commits with its own account (commit-queue, instead of eric's account). However, if you are a committer, and you use the commit queue, the server should fix up the author of the commit automatically so you are listed instead. For those who are not committers, your commits will still have commit-qu...@webkit.org as an author. Going forward, if you notice a commit that you did not get credit for from the CQ, please let me know. Also, the queue status app is now available at the following URL: http://queues.webkit.org/ And thanks to Eric and Adam for their help with this. -Bill ___ 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] Cr Linux bot Hosed
I kicked it. :DG On Mon, May 17, 2010 at 11:27 PM, Eric Seidel e...@webkit.org wrote: Could someone with access to the Cr-Linux bot give it a kick? http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/6703/steps/svn/logs/stdio it's filesystem seems to have turned read-only. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
On Wed, Apr 21, 2010 at 9:23 AM, Marc-Antoine Ruel mar...@chromium.org wrote: May I ask why it is being done this way, that is, having one really large list of build files and using include / exclude regexs to trim the list? i.e. why is there not a WebCoreCommon.gypi, WebCoreWinCommon.gypi, WebCoreChromium.gypi, etc.? Are you guys using scripts to create WebCore.gypi? We did this to optimize for writes (http://diveintomark.org/archives/2007/12/28/receipts). With one file, it's a no-brainer to add new files to the build. The maintainers of the ports can then use regexps and explicit lists to exclude builds as needed. It's worked pretty well for us. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
Do it. :DG On Thu, Apr 15, 2010 at 2:22 PM, Aaron Boodman a...@chromium.org wrote: I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? - a ___ 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 Icon license?
I just reached out to the Russian icon powerhouse, Turbomilk (turbomilk.com), and they're interested in pitching in as well. Maybe we should have a contest? :DG On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote: Would you happen to know how WebKit icon is licensed? The icon currently on webkit.org has the icon for Apple’s Safari web browser in it. Because of that, Apple has provided no license to use the icon; we are continuing to use it with informal permission from Apple. Given that WebKit has been more than just the rendering engine Safari uses for quite some time now, I wonder if it'd be worth trying to come up with something unique for the project. One benefit would be that it could be used more freely. Anyone with graphic design skillz going to the WebKit meeting? :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.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
[webkit-dev] WebKit Icon license?
Dear WebKit folk, Would you happen to know how WebKit icon is licensed? :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Chromium layout test expectations coming today
WebKit folks, We're finally ready to land our port's expected results in the WebKit tree. It's been a long journey, but we are now to the point where it no longer makes sense to keep Chromium expectations separate from the rest of the WebKit. It's a pretty large chunk of files, so please bear with us -- you may experience longer-than-expected checkout time for this commit. We are also actively working on porting test_shell (Chromium's test harness) to DumpRenderTree, to enable running the tests on WebKit waterfall. Until then, you can see test run results on WebKit canaries: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Webkit+(webkit.org)builder=Webkit+Linux+(webkit.org)builder=Webkit+Mac+(webkit.org). :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Chromium layout test expectations coming today
I agree that the idea of only pulling down expectations that you would actually need sounds great -- in fact we did try to think of ways of how this could be accomplished. So far, no great proposal materialized, but it doesn't mean the door of opportunity closes at this commit. I would think of this as more of a two-step solution: Step 1: Align Chromium port with the rest of the WebKit world and diminish the cost/pain of WebKit gardening. Step 2: Come up with a better way to track dependencies and optional components in WebKit. Step 3: Profit. :DG On Fri, Mar 19, 2010 at 10:26 AM, Evan Martin e...@chromium.org wrote: Before you commit it: Would it make sense to stuff this data somewhere outside of the main checkout, like we do in Chrome with the deps/ dir? I know that's a departure from how the WebKit test results currently work, but I also expect people are not going to be too happy about XXXmb of not-useful-to-them data showing up in their checkouts. (I guess a step two of this proposal would be to move the other test results alongside this new location.) Technical details of this proposal are vague, but I wanted to get it out there before you hit the commit button. :) On Fri, Mar 19, 2010 at 10:13 AM, Dimitri Glazkov dglaz...@chromium.org wrote: WebKit folks, We're finally ready to land our port's expected results in the WebKit tree. It's been a long journey, but we are now to the point where it no longer makes sense to keep Chromium expectations separate from the rest of the WebKit. It's a pretty large chunk of files, so please bear with us -- you may experience longer-than-expected checkout time for this commit. We are also actively working on porting test_shell (Chromium's test harness) to DumpRenderTree, to enable running the tests on WebKit waterfall. Until then, you can see test run results on WebKit canaries: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Webkit+(webkit.org)builder=Webkit+Linux+(webkit.org)builder=Webkit+Mac+(webkit.org). :DG ___ 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] Chromium layout test expectations coming today
The expectations are in as of r56278. Huge thanks to Dirk Pranke for battling svn all day! :DG On Fri, Mar 19, 2010 at 10:13 AM, Dimitri Glazkov dglaz...@chromium.org wrote: WebKit folks, We're finally ready to land our port's expected results in the WebKit tree. It's been a long journey, but we are now to the point where it no longer makes sense to keep Chromium expectations separate from the rest of the WebKit. It's a pretty large chunk of files, so please bear with us -- you may experience longer-than-expected checkout time for this commit. We are also actively working on porting test_shell (Chromium's test harness) to DumpRenderTree, to enable running the tests on WebKit waterfall. Until then, you can see test run results on WebKit canaries: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Webkit+(webkit.org)builder=Webkit+Linux+(webkit.org)builder=Webkit+Mac+(webkit.org). :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
To summarize the thread: 1) We're adopting when in doubt, roll it out approach to patches that turn tree red. 2) Need to find a way to run Mac-EWS for non-committers. 3) Enable build-break emails to webkit-dev or another opt-in mailing list What else? :DG On Fri, Feb 26, 2010 at 9:08 AM, Adam Barth aba...@webkit.org wrote: Well, the total bill is a bit bigger, but yeah. :) Adam On Fri, Feb 26, 2010 at 9:05 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: That is some of the best 9 cents spend ever! Kenneth On Fri, Feb 26, 2010 at 1:58 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth aba...@webkit.org wrote: Amazon tells me that our current bots use about 4 GB/month of download bandwidth and 600 MB/month of upload bandwidth. I presume almost all of the bandwidth is to update the working copies of the four bots hosted there. In case you're curious, Amazon charges us 9 cents/month for that much bandwidth. 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 tree is on fire: a tragedy of the commons
On Fri, Feb 26, 2010 at 9:44 AM, Eric Seidel e...@webkit.org wrote: The bots take 15 minutes to cycle. The moment the build is broken, thats FIX_TIME + BOT_CYCLE_TIME until their green again. I think we should cap the fix grace period at something like 15 minutes, that means no more than 30 minutes of tree redness per break. That might be too aggressive to start with for WebKit, but I think we should move towards that. I would re-write rule one as something like this: 1. Comment in the bugzilla bug when the build breaks. If there is no bugzilla bug, comment in #webkit. 2. 15 minutes after the break or 10 minutes after the comment, with no reply from the breaker, roll out the patch. Sounds great. Is this going to be a new page on webkit.org? :DG -eric On Fri, Feb 26, 2010 at 9:32 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 26.02.2010 um 18:17 schrieb Dimitri Glazkov: To summarize the thread: 1) We're adopting when in doubt, roll it out approach to patches that turn tree red. 2) Need to find a way to run Mac-EWS for non-committers. 3) Enable build-break emails to webkit-dev or another opt-in mailing list What else? I'm a bit scared of rule 1. How about we define a minimum delay when to roll-out patches, after they break something? Let's say, if a commit breaks the tree, give the commiter a time frame of 30 minutes to fix it - otherwhise roll-out (we could even automate that.) Example: When landing a SVG patch, that worked fine on Leopard, but broke Snow Leopard, I'd like to have some time to identify wheter it's the fault of my patch, or a platform specific problem. If it's the fault of my patch, I have no problem with reverting. But if I can't immediately fix the problem, because it's a platform specific issue, which can not be fixed (in terms of WebKit), then adding to the Skipped list, and filing a new bug just takes 5 minutes. Reverting the whole patch, just to reland it with a Skipped list addition is a bit too much work for me. What do others think? Cheers, Niko ___ 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] Increasing the number of cross-platform/port expected results
I agree. We should organize cross-browser-test-fest and pick each other's brains. I like the idea of introducing ref tests and I think they are teh hot. My only concern would be to the amount effort of converting existing tests to that, so I think we should start small. :DG On Tue, Feb 23, 2010 at 10:04 AM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, Feb 23, 2010 at 12:58 PM, Dirk Schulze vb...@gmx.de wrote: Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. -Sam ___ 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] Buildbot Emails
Do you guys think it may be a good idea to bring the concept of tree closure to WebKit? :DG On Mon, Feb 8, 2010 at 5:29 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2010, at 4:45 PM, Eric Seidel wrote: Historically build.webkit.org would email people when their changes broke the tree. This was disabled some time ago. I would very much like to see it re-enabled. Could someone point me as to how that would happen (I'm happy to code up a patch), or flip the magical switch themselves? I'd actually like to see it email a mailing list, in addition to the individuals it guesses are to blame. That could be either webkit-dev or a new list. Maybe some won't want the spam but I bet a lot of people would like to find out about every build break. If it's at all possible, it would be great to email all of the patch author, the reviewer and the committer (if different from the patch author). I also think it would be neat if we could have a bot that alerts about build breaks on IRC in #webkit. And finally, it might be good to have extra notice if a build remains broken for some time (every 24 hours maybe?) 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] Running pixel tests on build.webkit.org
It's baiscally just run-webkit-tests --reset-results --pixel-tests. No magic :) See run-webkit-tests --help for more info. BTW, Victor is working to port the rebaselining tool to build.webkit.org. You may want to check with him -- maybe he's close to finishing the patch. :DG On Mon, Jan 11, 2010 at 9:06 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow jor...@chromium.org wrote: Plan 3 seems like the best (and simplest) one until the infrastructure for the others (and/or a champion for fixing currently failing tests) is available. What would it take to go with plan 3? I guess someone needs to rebaseline everything that's currently failing, check them in, and then someone (like bdash?) needs to flip a switch on the bots...? Did I miss anything? Are there instructions on how to do the rebaselining anywhere? I've only ever created pixel baselines for Chromium before (where we have a pretty neat tool that pretty much does it for you). Does anyone know? I'm happy to do the rebaselining if someone can tell me how and we agree to turn pixel tests on on the bots. On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene p...@chromium.org wrote: And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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] Touch-supporting layout tests
I think it's really cool that we have some touch events-related layout tests landing in the tree. But... is there a chance we could move them to a directory that would allow easy filtering-out for ports that don't support touch events? fast/events/touch/, for instance? :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Running pixel tests on build.webkit.org
Are we planning to run pixel tests on the build bots? What's the general opinion here? We're running them over at Chromium and it seems like a really good idea. Case in point: Change http://trac.webkit.org/changeset/52900 broke a bunch of layout tests, all pixel results, and as such didn't register on the waterfall. I rolled out the change for now. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] First Early Warning System (EWS) bot online
Anything that's pronounced Ooze is bound to be awesome. Keep up the good work, guys! :DG On Wed, Dec 16, 2009 at 1:06 AM, Adam Barth aba...@webkit.org wrote: In the wee hours of the morning, I turned on a new bot, which is the first part of the Early Warning System (EWS) that Eric and I have been building. The EWS bots are very much like the style-queue, except they test compilation instead of style. == Executive Summary == When a patch is posted for review, each EWS bot applies the patch locally and runs build-webkit. If build-webkit succeeds, the bot does nothing. If build-webkit fails, the bot adds a comment to the bug indicating the failure and posts a link to the build log. == Goals == The goal of the EWS is to help us not break the build by providing an early warning for patches that break the build. By posting the build output, the EWS should give contributors some idea how to fix the build even if they can't compile the broken port themselves. If you're especially interested in a particular port, you can subscribe to EWS notifications about that port. When the EWS detects that a patch will break the build for that port, the EWS will automatically CC you on the bug. Currently, I'm the only person subscribed to EWS notifications. If you'd like to subscribe to a particular port, let me know. == Social Contract == Like the style-queue, the EWS is purely advisory. Contributors and reviewers are free to ignore the warnings if they believe the warnings are erroneous or they decide (for whatever reason) to break the build in question. == Frequently Asked Questions == Q) What ports does the EWS support? A) The first EWS bot is for the Chromium port. I have a bot for the Qt port working too, but the build time for the Chromium port was much shorter, so I'm starting with it. My goal is to eventually have a bot for every port (although I haven't worked out the operational issues for non-Linux ports). Q) I wish the EWS supported the foobar port. Can I run an EWS bot myself? A) Yes! The EWS is fully distributed. Anyone can run a EWS bot for whatever platform they're interested in. The bots coordinate via a web service. If you're serious about running an EWS bot for your port, let me know and we can make that happen. Q) Why doesn't the EWS post a success message? I like positive re-enforcement. A) I'm worried about spamming bugs with too many happy status messages. If we have N ports with EWS bots, we don't want to have N happy status messages. Eric and I have some ideas for a more passive success indicator. Once things are running smoothly, we can share some mocks with the list. Q) Why doesn't the bot run the LayoutTests? I'd like to know when I break the LayoutTests on other platforms. A) We'd eventually like to run the LayoutTests, but we're starting with compilation because it's faster and easier. Q) How does the EWS differ from a try server? A) The EWS is similar to a try server farm, but the goal is different. Developers frequently send experimental patches to try servers to see what happens. When you post a patch for review, the expectation is that the patch has some chance of getting r+ed and landed. That means EWS failures should be unusual and worth notifying the subscribers about. Q) How does the EWS deal with patches that don't apply cleanly to TOT? A) The EWS ignores them. It's unclear whether a non-applying patch is good or bad. It might just be dependent on another patch that hasn't been landed yet. Our experience with the style-queue is that most patches apply to TOT when they're posted, so I don't think this is a big limitation. Let me know if you have any questions. You can follow everything the bots do by subscribing to webkit-bot-watch...@googlegroups.com, but you'll mostly see a bunch of style-queue traffic because the style-queue is much noisier than the EWS. We'll eventually turn http://webkit-commit-queue.appspot.com/ into an awesome dashboard where you can see all the exciting things the bots are up to. Happy hacking! 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] GlobalScript in WebKit
Reading this, I am reminded of a great commentary by Alex Russell, written nearly 3 years ago: http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/ Despite of what I may think about SharedScript, I am certain that waiting -- whether for standards community or Web developers to embrace or reject our ideas -- is not the right answer. If we really want to move the Web platform forward, we can't afford a feedback cycle this long. Especially, when we have an opportunity for close collaboration with Web developers of some of the most JS-intensive Web properties. Experimenting is great. We should experiment. This doesn't mean we shouldn't discuss technical merits of the proposed solution, including more efficient ways of accomplishing the same thing. :DG On Thu, Nov 26, 2009 at 9:44 AM, Dmitry Titov dim...@chromium.org wrote: What I meant was it would be nice, for the sake of discussion, to share the experience of real life applications that used SharedWorkers or inter-window communications for sharing of significant portions of code and data. Google apps may be a partial example but it is a real life example of concrete issues with proposed solution that sounds pretty generic and useful for other web apps. It is only prudent to take their feedback rather then replace it with our own theories about future of the web. No doubt this is a new mechanism and it's good to question it, since it has costs even as experimental API. Gut feelings vary, some app devs say they need it to solve real issues, we dont hear from other app devs who were facing similar issues and solved it differently. Seems there is no strong argument to kill it nor bless it. Why don't make it experimental and see? If it was possible to implement it in extension or plugin, we would run it as another Gears-like experiment, but it can not be done in a plugin... I believe there could be good arguments that simply didn't surface yet, and hope to hear them. Dmitry. On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting pkast...@google.com wrote: On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov dim...@chromium.org wrote: BTW, could you tell what's the 'course' that would be reverted? Meaning, before we decide that SharedWorkers and inter-window communication are insufficient, and a further proposal should be entertained by the standards community. PK ___ 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] GlobalScript in WebKit
Guys, this thread is getting out of hand. I am waiting for Godwin's law to strike any second now. Can I make a gentle suggestion to perhaps break out new conversations into separate topics? :) Your friendly neighborhood mailing list maid, :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bright Future Tomorrow vs. Boring Today, was: GlobalScript in WebKit
Indeed. I tend to think that designing specs to work in the future with future applications in a great leap of engineering faith is not the approach that's worked. The argument that we should design for new applications made from scratch smells very XHTMLey to me. Let's take realistic small steps instead. :DG On Mon, Nov 30, 2009 at 4:29 PM, David Levin le...@google.com wrote: On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 30 Nov 2009, Dmitry Titov wrote: That also pretty much means if we won't do SharedScript, we'll need to explore other opportunities toward efficient sharing of code and data which does not make people to write a multithreaded UI as SharedWorker solution would do. We have practically zero positive response to SharedWorkers being used this way. Granted, this is just one company but the limited unscientific poll kind of shows the direction... The pushback on SharedWorkers at Google is because Google teams don't want to rewrite their apps to work with workers -- SharedScript lets them handle some of the cases SharedWorkers would get them, without having to rewrite as much code. Presenting this as a SharedWorker vs SharedScript thing is a false dichotomy. SharedWorkers and SharedScript serve different purposes for the people who want to use each. The majority of applications are not written to do all of their logic in a background thread, so it is odd to me that it is espoused as the right paradigm on web developers. There is a certain amount of logic that makes sense to happen on the main thread and be shared across windows. However, we should not be basing the platform's progress on transition cost avoidance of one company. Google can afford to rewrite GMail if it comes down to that. It is not in the Web's long term interests for us to design features that are optimised for the transition phase at the cost of the long-term health of the Web. On the other hand, just because there is a hammer, it doesn't mean that everything is a nail no matter how much we want it to be. What we should be looking at is what API do teams prefer to work with when starting from scratch, And it makes a lot of sense for new apps to do some logic that is quick on the main thread (and not proxy it off to another thread). because on the long term that will be the far more common case than transitioning from a legacy codebase. I don't think that our (Google's) response is representative here. Based on my 10+ years of experience as an app developer, I think the response is very representative of what I'd want. 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
Re: [webkit-dev] On the greeness of the GTK+ bot
On Mon, Nov 16, 2009 at 5:56 AM, Xan Lopez x...@gnome.org wrote: On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva g...@gnome.org wrote: On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote: Eric and I are working on a bot that might help this situation. Essentially, the bot will try out patches on Qt and GTK and add a comment to the bug if the patch regresses the build. Our plan is to start with compiling, but we'd eventually like to run the tests as well. That sounds like an awesome idea. Thanks for working on it. Build breakages themselves have become less of an issue for us in recent times - people are definitely more aware of our bots, and are acting on fixing them when they break. I think such an automated approach to running the build, and tests for upcoming patches will surely help with giving this a second step forward. This is nice to see, but as Gustavo says build breakage is not too much an issue at the moment for us: the build does not break very often, and when it does people usually take the time to figure out what happened and either do fix it themselves or poke us about it. That being said, this could be improved in any number of ways and I'm happy to see it getting ever better. What is effectively a black hole with respect to our time is the tests breakage, though. We get new tests failing very regularly (either through new tests or through new code making old tests fail), and once the bots are red people tend to pay even less attention to them, so they spiral out of control in a positive feedback loop until we have tests failing in the double digits in a matter of days (or hours!). Of course in an ideal world we'd have a team big enough to always have at least one person looking at this and fixing the problems the moment they arise, but unfortunately this is not the case. This is a huge issue with the Chromium port as well. We spend quite a bit of effort tracking down failing tests, only to discover that the failure is due to one-port baselines or new functionality added to DRT. I wonder if the approach we have today in regards to tests is not sustainable with multiple vibrant ports, each spending way to much time catching up. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Layering weirdness in chrome tree
Gah. I just realized this didn't go through to webkit-dev. Resending from the right email address. On Tue, Nov 10, 2009 at 12:46 PM, Dimitri Glazkov dglaz...@google.com wrote: Please pardon the dust -- upstreaming these files is just the first step in getting a working port up. You're right, some of these are the artifact of extracting inter-dependencies while staying in flight. Now that they're in WebKit tree, we'll be able to move them into the proper places. :DG On Tue, Nov 10, 2009 at 11:53 AM, Oliver Hunt oli...@apple.com wrote: I just noticed that there are a bunch of WebCore platform implementations being landed in Chrome's WebKit API rather than in WebCore/platform. This seems incorrect to me as there is no other place where this sort of mis-layering occurred, the obvious files that stand out are: ApplicationCacheHost.cpp GraphicsContext3D.cpp MediaPlayerPrivateChromium.cpp PlatformMessagePortChannel.* ResoureHandle.cpp DOMUtilitiesPrivate.* I see no obvious reason for these being placed in WebKit -- as far as I can tell these represent a layering violation: it's not possible to build the WebCore directory into it's own library due to the hard dependency on the chrome webkit 'api'. --Oliver ___ 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] take 2: unwritten rules of webkit style
ship it.
:DG
On Thu, Sep 3, 2009 at 8:43 AM, David Levinle...@chromium.org wrote:
I've updated the text based on the discussion from yesterday with added
verbage in green (I didn't try to show removed text unless the whole
recommendation was removed.)
As a side note, before being put in the style guide several of these items
would be fleshed out slightly with good/bad examples.
New version
Comments
Usually, comments should look like sentences by beginning with a capital and
ending with a period (punctation). One exception may be end of line comments
like this if (x == y) // false for NaN.
There should be a single space after punctation and before the next
sentence.
There should only be a single space before end of line comments. An
exception is if one is lining up several end of line comments.
Use FIXME: to denote items that need to be addressed in the future.
Copyright formatting
If you modify over 10 lines of code in a file, please add your copyright
line in the file.
Ideally, the line would the follow these rules pattern for uniformity.
In copyright entries, don't use ranges for years.
Use capital (C) for the copyright and no comma after the last year.
Each line should have its own Copyright (C) before it.
Example of two well formed copyright lines:
* Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights
reserved.
* Copyright (C) 2009 Somebody email
Function parameters
Don't put in parameter names in function declarations if they don't add
information. A good rule of thumb is if the parameter type name contains
the parameter name (without trailing numbers or pluralization), then the
parameter name isn't needed. Usually, there should be a parameter name for
bools, strings, and numerical types.
Use enums instead of bools for parameters if the value's meaning will be
ambiguous at the calling site.
Good:
doSomething(myData, m_memberBool1, 0, m_memberBool2, localBool);
setFlag(true);
Bad:
doSomething(myData, true, 0, false, true);
doSomething(param1, localBool1 (localBool2 || localBool3));
Classes/Structs
There should not be a blank line before the first item in class/structs. Add
a blank line before public:, protected:, and private: otherwise. No blank
line after them.
Each section should be defined only once, and they should be in the
order public:, protected:, and private:.
One class per file. Ideally one struct per file too, but sometimes small
structs that are only used in a cpp file may be in place.
Constants
Constant variables should be named just like a variable and have no special
prefix
Line length
There is no line length limit. However, at about 120-180 characters, the
line is getting long and you may want to consider wrapping it.
Braces
There should be at least one space after a brace and one space before a
closing brace (when there are any characters before or after them
respectively including another brace).
#include statements
All ifdef'ed includes should be in a section after all other includes. Don't
use ifdef's around includes if you don't need to. For example, if you
include a header that has if ENABLE(FEATURE) around its contents, you don't
need to repeat the if ENABLE when including it.
#if(def) statements
If an #if(def) spans more than a few lines, end it like this:
#endif // WhateverWasInTheIf
Namespaces
If a namespace spans more than a few lines, end it like this
} // namespace NameOfNamespace
Misc
Files should end with a trailing newline.
Removed
Misc
Do not use static initializers for classes/structs. Use DEFINE_STATIC_LOCAL
instead (or AtomicallyInitializedStatic if the initialization should be
threadsafe).
Reason: This is more of a coding guideline and should have likely have its
own document like RefPtr.
Indentation
Additional clauses in a conditional may be indented 4 extra spaces to
visually separate them from the statement to be executed.
Like this
if (condition1
condition2)
statement;
Reason: Currently not widely agreed upon.
Unaddressed items from the discussion
Changing the rules around when to include { } around items.
Reason: I'm not attempting to change anything here. Just trying to document
widely accepted rules that aren't written in the current style guide.
Naming for non-const globals.
Reason: There isn't consensus around this right now. It sounds like several
people would like to have a standard here, so please start
a conversation for this (and the naming of statics in classes).
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
Re: [webkit-dev] unwritten rules of webkit style
I don't think the intent of this thread was to create new rules. Let's
stick with documenting existing style practices.
:DG
On Wed, Sep 2, 2009 at 12:16 PM, Yong Liyong...@torchmobile.com wrote:
For multi-line condition, the following style is most readable to me.
if (condition1
condition2)
{
// code...
}
- Original Message -
From: Yong Li
To: David Levin
Cc: WebKit Development
Sent: Wednesday, September 02, 2009 3:05 PM
Subject: Re: [webkit-dev] unwritten rules of webkit style
Current guideline also contains these 2 cases that {} should be used. I
think when the condition is multi-lined, this should also apply.
(BTW, hate the existing rule no braces for one line. it doesn't give any
benefit. worse than always use braces)
if (condition) {
// Some comment
doIt();
}
if (condition) {
myFunction(reallyLongParam1, reallyLongParam2, ...
reallyLongParam5);
}
- Original Message -
From: David Levin
To: Yong Li
Cc: WebKit Development
Sent: Wednesday, September 02, 2009 2:56 PM
Subject: Re: [webkit-dev] unwritten rules of webkit style
On Wed, Sep 2, 2009 at 11:54 AM, Yong Li yong...@torchmobile.com wrote:
{} should be added in this case:
if (condition1
condition2)
statement;
Not according to current WebKit style because it is a single line statement.
___
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] JavaScript bindings changed to call scriptExecutionContext virtual function?
In this case, we could probably reuse the isNodeSubType from CodeGeneratorV8.pm (http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/CodeGeneratorV8.pm#L337), which in turn uses FindParentsRecursively from CodeGenerator.pm (http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/CodeGenerator.pm#L123). But I haven't looked at the problem in detail, just yelling random stuff from sidelines. :DG On Sun, Aug 2, 2009 at 2:44 AM, Adam Barthaba...@webkit.org wrote: On Sun, Aug 2, 2009 at 2:09 AM, Darin Adlerda...@apple.com wrote: On Aug 2, 2009, at 2:05 AM, Adam Barth wrote: In any case: https://bugs.webkit.org/show_bug.cgi?id=27931 I'll have a patch shortly. Please let me know if there are other call sites you'd like changed. Thanks! Once you pointed out this was not due to a recent change, I had resolved to fix it myself, but I’m glad you’re going to tackle it. Generally speaking no call site that has a Node* should call scriptExecutionContext(). So rather than listing the call sites I want changed, I’d instead suggest that we make Node::scriptExecutionContext() private and then make sure no Node member functions or members functions of friend classes call the function. I tried this, and it looks like there are a bunch of instances in the generated bindings that weren't found by cscope. Basically, this line of CodeGeneartorJS needs to know whether impl is a subclass of Node*: push(@implContent, JSDOMGlobalObject* globalObject = toJSDOMGlobalObject(imp-scriptExecutionContext());\n); It's a bit too late at night for me to wrap my mind around the code generator, but that's a clear next step. 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] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Fri, Jul 10, 2009 at 11:06 AM, David Kilzerddkil...@webkit.org wrote: So, does anyone think this would be a bad idea, or have any alternate suggestions on how to improve things? What about adding support for waf to gyp? +1. I think GYP took the right step back from project files to a meta-format from which you could generate project files, and we have a pretty good record at Chromium to show that this was a good idea. The only format I'm not sure if we could automate reliably would be the XCode format (at least, on non-Mac machines), because IIUC we'd need some sort of parser for it, but Apple is the only port maintaining those directly IIUC, as now Chromium will be using GYP to update their XCode projects. If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. GYP generates very nice XCode projects -- they are always properly sorted, logically structured, and clean. So even if we couldn't solve the XCode issue, that would drop it to updating two locations tops. I count 6 build systems in use currently (SCons support was added and removed within the last year): - Apple's Xcode - Apple's vcproj (also used by at least one other Windows port) - wx Bakefile (which will be replaced by waf soon) - Qt Qmake - GTK GNUMakefile - Google's gyp (added recently) Are any of the other ports going to switch to generating their build files using gyp? While I have no cycles to do it, I certainly hope that somebody would try. Switching to GYP for our port was an incredible experience. No more vcproj-muddling, needing to have a Mac to edit XCode files, and trying to understand how various build systems work. This approach also encourages you to unify the thinking about targets/actions/rules, and GYP has already solved this problem for pretty much all known platforms. I highly encourage you guys to check out Chromium and see it in action. The generation occurs silently at each update (which is something that could be hooked in to update-webkit script), it's accurate, and very seamless. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
To add to this, GYP also only generates files for _your_ platform on checkout. Even to the degree that on Windows, it would generate VS2008 projects if you had it installed, and VS2005 otherwise. To be precise, the selection is not automatic (you need an env variable) to avoid dual-VS installs ambiguity. :DG On Fri, Jul 10, 2009 at 11:32 AM, Mike Pinkertonpinker...@chromium.org wrote: On Fri, Jul 10, 2009 at 2:20 PM, Dimitri Glazkovdglaz...@chromium.org wrote: If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. GYP generates very nice XCode projects -- they are always properly sorted, logically structured, and clean. I think the difference worth highlighting here is that GYP doesn't *edit* Xcode projects. That is explicitly a non-goal. It generates new ones from scatch every time (but is smart enough not to touch anything if nothing would change). As a result, it doesn't need to know about all the various ways a project file could change from state A to state B. In Chromium, we don't have any Xcode files checked in, they're generated (again, from scratch, replacing whatever was there before) on every checkout. If you want to make local changes during the course of your development, that's fine (and helpful to test small tweaks), but the only canonical representation of the Xcode project file is in GYP. -- Mike Pinkerton Mac Weenie pinker...@google.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
We certainly would love to see that happen and gladly commit helping to make this happen. :DG On Fri, Jul 10, 2009 at 3:15 PM, Maciej Stachowiakm...@apple.com wrote: I think our number of different build systems is getting out of hand. Since gyp is being successfully used to build across platforms, and maintained by people who also work on some WebKit ports (and can thus likely be adapted to our needs), I'd like to consider whether we can use it for Apple's ports, and maybe consider rolling it out to additional ports over time. The gyp strategy of creating platform-native project files sounds like a good general approach. - Maciej On Jul 9, 2009, at 9:23 PM, Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ 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] Coding convention of constants
If we're voting, then +1 to [1]. If we're not voting, then oops. :DG On Thu, Jul 9, 2009 at 12:50 PM, Darin Adlerda...@apple.com wrote: On Jul 8, 2009, at 9:08 PM, KwangYul Seo wrote: I found another style which starts with k. [4] platform/chromium/PopupMenuChromium.cpp static const int kMaxVisibleRows = 20; static const int kMaxHeight = 500; static const int kBorderSize = 1; static const TimeStamp kTypeAheadTimeoutMs = 1000; 2009/7/9 KwangYul Seo kwangyul@gmail.com Hi, It seems that there are three coding styles regarding static const int constants. [1] rendering/RenderImage.cpp static const int maxAltTextWidth = 1024; static const int maxAltTextHeight = 256; [2] rendering/RenderVideo.cpp (prefixed with c) static const int cDefaultWidth = 300; static const int cDefaultHeight = 150; [3] storage/SQLTransaction.cpp (start with a capital letter) static const int DefaultQuotaSizeIncrease = 1048576; http://webkit.org/coding/coding-style.html WebKit Coding Style Guidelines does not mention this issue. All 3 styles are acceptable? I don’t think we have consensus on this yet. I personally prefer (1). -- 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] Please welcome GYP to the our dysfunctional build family
Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus
Go abarth! Here's a couple of considerations: 1) For now, we've been concentrating on moving the remaining bits of the V8 bindings and project files upstream. Your proposed refactoring will more than likely involve modifying .gyp files. Perhaps it would be better to wait just a bit more until I upstream .gypis to avoid the super-painful two-sided patches? 2) There is at least two folks who are actively working on improving performance and eliminate inconsistencies in V8 bindings. cc'ing to loop them in. Mads, Anton, you should be on webkit-dev, if you aren't already :) 3) One of the big tasks on my horizon is refactoring V8 bindings to align them closer with JSC bindings, especially in the areas of event listeners and meaning of IDL attributes in the code generator. I would also love to implement an equivalent of the generated toJS(..). So please think about this when you're hacking on the proxy. 4) In the same spirit of aligning with JSC bindings, it would be great if your refactoring dissolved V8Proxy into new files/classes that are similar in convention/spirit to those on JSC side. The goal here is to make it easier to adjust V8 bindings after JSC bindings change. Thanks for taking on this! I am going to try and visit SFO next week, so perhaps we could meet up and do some strategery about this refactoring. :DG On Fri, Jul 3, 2009 at 12:23 PM, Adam Barthaba...@webkit.org wrote: If you're uninterested in the V8 bindings, you can skip this email. Clocking in at 3255 lines (plus a 682-line header file), V8Proxy is out of control. Historically a bridge from the V8 bindings to the V8 engine, V8Proxy is responsible for a number of tasks including: 1) Creating new contexts 2) Implementing security checks 3) Supervising garbage collection 4) Caching event listeners 5) Executing scripts 6) Converting between frames, contexts, and global objects 7) Manging DOM wrappers 8) etc, etc, etc I propose we separate these concerns into a number of distinct classes that have clear, understandable purposes before things get worse. Please let me know if you have any in-progress patches to V8Proxy. I'd like to lock that file sometime next week while I rip it apart and put it back together. Thanks, Adam P.S., FrameLoader: you've escaped for now, but don't think I'm not watching you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New approach for DOM attributes that reflect content attributes
I'll take care of the V8 bindings. :DG On Sun, Jun 21, 2009 at 10:26 PM, Darin Adlerda...@apple.com wrote: There are many attributes in the DOM that are simply covers for getting and setting HTML or SVG attributes. The HTML 5 draft calls this reflection of content attributes. Currently we do this by writing getter and setter functions. For example, see the placeholder and useMap attributes of HTMLInputElement. A better way to do this is to declare that the attribute reflects a content attribute in the .idl file, and have the bindings call setAttribute and getAttribute directly. I plan to do this, with the following syntax. This indicates that the title attribute reflects a content attribute named title: attribute [Reflect] DOMString title; This indicates that the className DOM attribute reflects a content attribute named class: attribute [Reflect=class] DOMString className; This indicates that the src DOM attribute reflects a content attribute named src, but that the result is a completed URL, not the raw attribute value: attribute [ReflectURL] DOMString src; I’m going to begin this work with this bug https://bugs.webkit.org/show_bug.cgi?id=25425. That bug talks about a need to change the details of various getters and setters, and I decided it was better not to do this, but rather to have the getters and setters be auto-generated. I will implement this for the JavaScript bindings and Objective-C bindings, but someone else will have to take care of the V8 bindings. Once the bindings are working, I plan to remove the functions in the DOM implementation classes. So I would delete the HTMLInputElement::placeholder and HTMLInputElement::setPlaceholder functions once the [Reflect] attribute has been used for them. For now I will begin by implementing [Reflect] and using it in a few places, but I won’t delete any functions from the DOM implementation classes yet. -- 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] Crashes are mine
The recent crashes in layout tests are mine. Will fix before the end of the day. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing code between WebCore/bindings/js and WebCore/bindings/v8
It would really, really awesome (IMHO) to put some extra effort into minimizing bindings divergences. I think there's already some good foundation laid in this regard in the form of Script* classes (look for bindings/(js|v8)/Script* files) . I was once imagining that we could split out code generation into: a) conversion/instantiation helper functions (these will be different for V8 and JSC) b) the actual bindings, written using Script* stuff and common for both engines. Then we could rewrite (wee!) all of our custom bindings to use Script* as well and live happily ever after. :DG On Wed, May 27, 2009 at 11:50 AM, David Levin le...@google.com wrote: On Wed, May 27, 2009 at 11:47 AM, Adam Barth aba...@webkit.org wrote: 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.cpp#L285. I presume Sam is a good contact for the JSC bindings. Who's a good contact for the V8 bindings? dglazkov Thanks, 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] Chromium Unforking: Please hold off on big changes for a day or so
Dear WebKit contributors, We are attempting to completely unfork Chromium this afternoon and would love to have a no port breakage while we're doing this. If it is at all possible, could you hold off on making big changes to WebCore or JS bindings that may potentially affect Chromium port or layout test results? This should only take a day or so -- once we're pulling from ToT and have our build infrastructure switched over, you can resume breaking stuff :) :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 :DG On Fri, Mar 6, 2009 at 9:20 AM, Darin Adler da...@apple.com wrote: On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Oh wait. He did an in-place update patch. I'll ask him. :DG On Fri, Mar 6, 2009 at 9:25 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 :DG On Fri, Mar 6, 2009 at 9:20 AM, Darin Adler da...@apple.com wrote: On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Unforking Chromium: The Upstreaminess Dashboard
As you may know, we at the Chromium project have been working toward being on the ToT WebKit, so that we could become productive members of the WebKit community. You can see the progress of our effort here: http://build.chromium.org/merge/ The page lists all WebKit files to which we made changes, each file having two meters. The first meter shows the difference (lines added=green, removed=red, unchanged=gray) between revision of a WebKit file in the Chromium tree (http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/) and that of the last WebKit merge revision. That is, you can see the changes remaining after the merge for each file. The second meter shows the difference between Chromium's WebKit file and its cousin at the ToT WebKit. In other words, you can see how our changes relate to those made in the WebKit trunk. You can also click on each meter to see a side-by-side diff for each file. The fewer reds and greens we see in vs. [EMAIL PROTECTED] column, the closer we are to the unforking. Hope this helps! I will try to update this page every day or so. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
