August 2010 - webkit-dev - lists.webkit.org

Not enough space message when linking webkit (lots of free disk space)
by Chris Hatko 23 Aug '10

23 Aug '10

I'm running revision 65648 and building cairo-win32 release I'm getting "Not enough space" when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11>fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11>LINK : fatal error LNK1257: code generation failed 11>Build log was saved at "file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm" 11>WebKit - 1 error(s), 1 warning(s). Any idea what I can try? Thanks, Chris

6 6

AXObjectCache memory management?
by Eric Seidel 23 Aug '10

23 Aug '10

Does anyone know why AXObjectCache is not ref counted? It has some manual scheme which seems likely to have bugs in it. http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp#L1742 There just seems to be a lot of code in Document to manage this simple cache. -eric

2 1

Runtime error in WebCore::ScriptExecutionContext::hasOpenDatabases()
by Chris Hatko 22 Aug '10

22 Aug '10

Hi, I'm running revision 65648 and building cairo-win32 release. I had to fix several compile errors to get the build to work. When I start winLauncher I get a runtime error: Unhandled exception at 0x00c829f1 (WebKit_debug.dll) in WinLauncher_debug.exe: 0xC0000005: Access violation reading location 0x00000114. Occurs in: WebCore::ScriptExecutionContext::hasOpenDatabases() on member variable access. Has anyone encountered this before? Any ideas on whats wrong? Thanks, Chris Trace: WebKit_debug.dll!WebCore::ScriptExecutionContext::hasOpenDatabases() Line 78 + 0x11 bytes C++ WebKit_debug.dll!WebCore::PageCache::canCachePageContainingThisFrame(WebCore::Frame * frame=0x04519a30) Line 274 + 0xc9 bytes C++ WebKit_debug.dll!WebCore::PageCache::canCache(WebCore::Page * page=0x04517f78) Line 301 + 0xe bytes C++ WebKit_debug.dll!WebCore::FrameLoader::commitProvisionalLoad() Line 1833 + 0x27 bytes C++ WebKit_debug.dll!WebCore::DocumentLoader::commitIfReady() Line 261 C++ WebKit_debug.dll!WebCore::DocumentLoader::finishedLoading() Line 267 C++ WebKit_debug.dll!WebCore::FrameLoader::init() Line 239 C++ WebKit_debug.dll!WebCore::Frame::init() Line 352 C++ WebKit_debug.dll!WebView::initWithFrame(tagRECT frame={...}, wchar_t * frameName=0x00000000, wchar_t * groupName=0x00000000) Line 2604 C++ WinLauncher_debug.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x000209d8, int nCmdShow=0x00000001) Line 207 + 0x36 bytes C++ WinLauncher_debug.exe!__tmainCRTStartup() Line 589 + 0x1c bytes C

1 0

Could someone explain a bit on document fragments?
by Matt 'Murph' Finnicum 20 Aug '10

20 Aug '10

I see, for a large page, that a document is created and then a number of fragments. Are these fragments all then merged into that document? Or are they merged into one another, forming a new document somehow? Where is that done? What would be a acceptable way to measure the total time spent parsing? Going from parser creation to parser finish doesn't work when there are many document fragments, each with it's own parser. Should I add up the time spent in all of the parsers? Thanks, --Murph

2 1

Re: [webkit-dev] js binding: function argument type checking
by Mo, Zhenyao 19 Aug '10

19 Aug '10

Currently for a function's signature in WebKit, if an argument's type is a wrapper type (those JS objec ts that wrap c++ objects, for example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's type does not match the signature, the input is casted to null and no TypeError is raised. Even though WebKit doesn't use Web IDL specially, I think we can look to the Web IDL spec for guidance on what the behavior should be. According to Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/) unless [AllowAny] is put in the signature, an TypeError should be raised if an argument type does not match its signature. The new automatic code generation for overloaded functions in WebKit DOES raise TypeError when it fails to determine which overloaded variant to call. We definitely need to do the strict type checking for WebGL functions. However, changing the default behavior of the IDL code generators might have a significant compatibility impact. It isn't clear to us whether the current behavior is intentional. If yes, please let us know and we will try to fix the WebGL part only. Otherwise we will modify the general rule instead.

8 18

Six new layout tests missing expected results
by Maciej Stachowiak 19 Aug '10

19 Aug '10

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

4 3

Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
by Ryosuke Niwa 18 Aug '10

18 Aug '10

On Wed, Aug 18, 2010 at 2:31 PM, Ojan Vafai <ojan(a)chromium.org> wrote: > > My intuition is that very few sites or extensions actually depend on them > being synchronous. > I agree. I worked on some extension app this spring but all I needed to know was when the subtree of certain nodes change so that I can go ahead and modify them. There was no need to prevent the change or catch synchronously. That alone, I think would address the majority of mutation-event related > crashing and does not prevent us from adding newer, better APIs. > Agreed. If we can postpone all mutation events until the end of each compose edit command, we'll be able to prevent the majority of crashes. I think reducing mutation event support down to just DOMSubtreeModified, and >> firing it only at the very end of operations that should be atomic, would >> greatly reduce the risk of mutation-event-induced crashing, but would >> probably still serve the key use cases. >> > > Agreed. > Ditto. Best, Ryosuke Niwa Software Engineer Google Inc.

1 0

DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
by Ojan Vafai 18 Aug '10

18 Aug '10

On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth <abarth(a)webkit.org> wrote: > On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak <mjs(a)apple.com> wrote: > > If mutation events tend to break editing, one simple solution is to turn > then off within the scope of editing operations and send a single mutation > event at the end. It's not clear if that kind of solution would be > appropriate to expose to Web content, though; you can't do the RAII idiom in > JavaScript so there could be too much risk of staying stuck in the "mutation > events deferred" state. On the other hand, a dynamic-wind-style solution > might be appropriate. This is one tiny example of how the same abstractions > might not be right internally and externally. > > If we don't already have it, we definitely want a RAII for turning off > mutation events (or at least ASSERTing that we're not trying to fire > them) for the parser. The new and old tree builders might explode if > they ever fire a mutation event. I'm trying to figure out what we should do with DOM Mutation Events. The general agreement from the www-dom discussion of mutation events was that they are the wrong abstraction for editing related code. beforeinput/input events meet editing needs better. So, that leaves a small list of relatively low-priority use-cases. See http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them. Mutation events are a huge source of crashes and they complicate WebCore code considerably. 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. Here's some options I see: 1. 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. 2. Drop support for them with no replacement. 3. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. 4. 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) Do any of these options sound feasible or is the only option to do the very large amount of work to make existing mutation events work? Ojan

6 8

c bindings
by daniel19851023 18 Aug '10

18 Aug '10

Hi all, I want to use C to operate DOM tree. Does it means I want to binding C to DOM tree? I find that in the folder of webcore\bindings, there are some folders, like js, objc. In my opinion, the purpose of folders is binding the js or objc to DOM tree ,then it could operate DOM tree. So, if i want to operate DOM tree using C, whether or not I should do something on this folder? Also, I find that there is a idl file called DOMCore in the webkit\win\interface, some methods which operating DOM tree in this file and provided by interface, if I implement all this interface, does it means I have binding C to DOM tree? Rgds, Daniel 网易邮箱，没有垃圾邮件的邮箱。

1 0

ANGLE compile failure?
by Eric Uhrhane 17 Aug '10

17 Aug '10

I'm getting the same failure in two clients, and the second has nothing checked out. This is on OSX 10.5.8, using the standard webkit build scripts and code synced yesterday [several times, same error]. Given that I don't hear anyone else screaming, there's probably something wrong with my environment, but I can't see what it is. I've got Xcode 3.1.4 with Component versions Xcode IDE: 1203.0 Xcode Core: 1204.0 ToolSupport: 1186.0. I've used these clients many times before without any issues, and haven't changed anything I can think of recently. Does this error look familiar to anyone? Here's the compile error: CompileC /Users/ericu/two/src/third_party/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/i386/RenderLayerBacking.o /Users/ericu/two/src/third_party/WebKit/WebCore/rendering/RenderLayerBacking.cpp normal i386 c++ com.apple.compilers.gcc.4_2 cd /Users/ericu/two/src/third_party/WebKit/WebCore /Developer/usr/bin/gcc-4.2 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fno-exceptions -fno-rtti -fpascal-strings -fasm-blocks -O0 -Werror -Wnon-virtual-dtor -Wnewline-eof -DDISABLE_THREAD_CHECK -DENABLE_3D_RENDERING -DENABLE_BLOB -DENABLE_CHANNEL_MESSAGING -DENABLE_CLIENT_BASED_GEOLOCATION -DENABLE_DATABASE -DENABLE_DATALIST -DENABLE_DOM_STORAGE -DENABLE_EVENTSOURCE -DENABLE_FILTERS -DENABLE_GEOLOCATION -DENABLE_ICONDATABASE -DENABLE_JAVASCRIPT_DEBUGGER -DENABLE_MATHML -DENABLE_METER_TAG -DENABLE_OFFLINE_WEB_APPLICATIONS -DENABLE_PROGRESS_TAG -DENABLE_RUBY -DENABLE_SANDBOX -DENABLE_SHARED_WORKERS -DENABLE_SVG -DENABLE_SVG_ANIMATION -DENABLE_SVG_AS_IMAGE -DENABLE_SVG_DOM_OBJC_BINDINGS -DENABLE_SVG_FONTS -DENABLE_SVG_FOREIGN_OBJECT -DENABLE_SVG_USE -DENABLE_VIDEO -DENABLE_WEB_SOCKETS -DENABLE_WORKERS -DENABLE_XPATH -DENABLE_XSLT -DWEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -fvisibility-inlines-hidden -fno-threadsafe-statics -mmacosx-version-min=10.5 -gdwarf-2 -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/WebCore.hmap -Wall -Wextra -Wcast-qual -Wchar-subscripts -Wextra-tokens -Wformat=2 -Winit-self -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wcast-align -Wshorten-64-to-32 -F/Users/ericu/two/src/third_party/WebKit/WebKitBuild/Debug -F/System/Library/Frameworks/Carbon.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/Debug/include -IForwardingHeaders -Iicu -I/usr/include/libxslt -I/usr/include/libxml2 -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/Debug/WebCoreSQLite3 -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/Debug/DerivedSources/WebCore -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/Debug/usr/local/include -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/DerivedSources/i386 -I/Users/ericu/two/src/third_party/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/DerivedSources -include /var/folders/zz/zzzivhrRnAmviuee+++GEk++2YA/-Caches-/com.apple.Xcode.4675/SharedPrecompiledHeaders/WebCorePrefix-flbhrwccotacjkdrgwesqfsgvooy/WebCorePrefix.h -c /Users/ericu/two/src/third_party/WebKit/WebCore/rendering/RenderLayerBacking.cpp -o /Users/ericu/two/src/third_party/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/i386/RenderLayerBacking.o In file included from /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/GraphicsContext3D.h:30, from /Users/ericu/two/src/third_party/WebKit/WebCore/rendering/RenderLayerBacking.cpp:36: /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:29:30: error: ANGLE/ShaderLang.h: No such file or directory In file included from /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/GraphicsContext3D.h:30, from /Users/ericu/two/src/third_party/WebKit/WebCore/rendering/RenderLayerBacking.cpp:36: /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:37: error: ‘EShLangVertex’ was not declared in this scope /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:38: error: ‘EShLangFragment’ was not declared in this scope /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:47: error: ‘TBuiltInResource’ has not been declared /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:53: error: ‘ShHandle’ does not name a type /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:54: error: ‘ShHandle’ does not name a type /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:58: error: ‘TBuiltInResource’ does not name a type /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h: In member function ‘void WebCore::ANGLEWebKitBridge::setResources(int)’: /Users/ericu/two/src/third_party/WebKit/WebCore/platform/graphics/ANGLEWebKitBridge.h:47: error: ‘m_resources’ was not declared in this scope Here's my environment: MANPATH=/opt/local/share/man:/usr/share/man:/usr/local/share/man:/usr/X11/share/man:/usr/X11/man HOSTNAME=dhcp-172-22-70-120.mtv.corp.google.com TERM_PROGRAM=Apple_Terminal TERM=xterm-color SHELL=/bin/bash TMPDIR=/var/folders/zz/zzzivhrRnAmviuee+++GEk++2YA/-Tmp-/ Apple_PubSub_Socket_Render=/tmp/launch-tBG2sv/Render TERM_PROGRAM_VERSION=240.2 VIM_LIST=yes EMAIL_ADDRESS=ericu(a)chromium.org SVN_EDITOR=commit-log-editor USER=ericu COMMAND_MODE=unix2003 SSH_AUTH_SOCK=/tmp/launch-jj5NQU/Listeners __CF_USER_TEXT_ENCODING=0x1243:0:0 PATH=/opt/local/bin:/opt/local/sbin:/Users/ericu/bin:/Users/ericu/bin/depot_tools:/Users/ericu/one/src/third_party/WebKit/WebKitTools/Scripts:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin/g4bin:/usr/local/sbin INPUTRC=/Users/ericu/.inputrc PWD=/Users/ericu/four/src/third_party/WebKit/WebCore/platform EDITOR=/Users/ericu/bin/mvim_nofork LANG=en_US.UTF-8 PS1=[\W] SHLVL=1 HOME=/Users/ericu LOGNAME=ericu PYTHONPATH=/Library/GoogleCorpSupport/Python/2.5 DISPLAY=/tmp/launch-2i75P4/org.x:0 SECURITYSESSIONID=a82880 _=/usr/bin/env OLDPWD=/Users/ericu/four/src/third_party/WebKit Thanks, Eric

2 4