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

Re: [webkit-dev] Misplaced files
by Maciej Stachowiak 31 Aug '10

31 Aug '10

On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: > We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. > Maybe we should move them to the new directory too? Yes. The file-related stuff should all be in one directory, I think. Regards, Maciej > > On Fri, Aug 27, 2010 at 6:01 PM, Maciej Stachowiak <mjs(a)apple.com> wrote: > > On Aug 27, 2010, at 5:15 PM, Adam Barth wrote: > > > On Fri, Aug 27, 2010 at 4:08 PM, Maciej Stachowiak <mjs(a)apple.com> wrote: > >> On Aug 27, 2010, at 3:55 PM, Adam Barth wrote: > >>> Looking through WebCore/html I noticed the files below. I'm not sure > >>> they belong in WebCore/html because they don't appear to be > >>> HTML-specific. Rather, they seem like generic web platform APIs > >>> (e.g., they could be exposed to SVG or whatever other markup languages > >>> we choose to support in the future). Should we move these to > >>> WebCore/page, WebCore/dom, or should we make a new location for these > >>> sorts of things? > >> > >> I think the File API (which all of these are related to) deserves its own directory right under WebCore. > > > > Ok. I can take care of that. Thoughts on names? WebCore/file ? > > I would say file-api or fileapi or something, since it seems more likely than other cases to get confused with the general concept of files. > > Regards, > Maciej > > _______________________________________________ > webkit-dev mailing list > webkit-dev(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >

7 9

Colors
by Igor Trindade Oliveira 31 Aug '10

31 Aug '10

Hi, Looking Webkit color class(WebCore/platform/graphics/Color.*) all the colours format are always converted to rgb/rgba format. But Qt for example can handle many kind of colors like hsl, cmyk and rgba (all supported by webkit). is There any kind of reason to always convert colors to rgba? Theses converts could not be used just like a fallback when the graphics api does not have support for these formats? Igor

3 6

Re: [webkit-dev] WebKit2 SharedSecondaryProcess model
by Balazs Kelemen 31 Aug '10

31 Aug '10

Seems like I misunderstood the concept. I assumed that the shared process model means that there could be multiply UI process instances that uses the same web process, virtually when the second MiniBrowser is launched it connects to the existing web process. By taking a deeper look into the WebContext and WebProcessProxy classes, I have realized that the shared process model is about using one web process for multiply views (what is cool) and not for multiply processes (what would be more cool from my point of view :) ). What do you think about my idea? Primarily on embedded devices it would be great to use the web engine as a server process because it could save a lot of memory. I think the current design is not too far for supporting that. Mainly we should find a correct way of connecting the new UI process to the existing web process, and the Connection should be per page instead of per process (or we should rework the WebProcess to not be a singleton?). On 08/30/2010 08:22 PM, Sam Weinig wrote: > Hi Balazs, > > Does it not work currently? If not, can you please file bugs on what > is not working. We plan on making the shared process model the default > model for the API, but it will probably have the caveat that it will > not support InjectedBundles. > > -Sam > > On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb(a)inf.u-szeged.hu > <mailto:kb@inf.u-szeged.hu>> wrote: > > Hi all! > > I am wondering about do you plan for the mac and win to support the > shared web process model? > Actually, I have played around with that for Qt. I have a working, > proof > of concept implementation. The visited links and the back-forward list > features are broken, but apart from that the browsers are working with > the shared web process. I had to rework common parts of the code for > achieving that, and I would like to contribute it in small parts. I > think if we want to support that model in the future than we should > start to implement it as soon as possible to assure that our > design fits > the needs of that. > > Cheers! > Balazs Kelemen > _______________________________________________ > webkit-dev mailing list > webkit-dev(a)lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >

1 0

DumpRenderTree crashes because of JavaPluginCocoa
by Xianzhu Wang 31 Aug '10

31 Aug '10

Hi, I encountered a problem yesterday that all layout tests crashed on Mac Snow Leopard. DumpRenderTree produces the following output when run from command line: $ time ./DumpRenderTree 2010-08-31 10:39:25.847 DumpRenderTree[26725:903] The requested plugin at (/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home) cannot be loaded on this system. Using CurrentJDK instead. 2010-08-31 10:39:25.849 DumpRenderTree[26725:903] An uncaught exception was raised 2010-08-31 10:39:25.849 DumpRenderTree[26725:903] *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: WebPluginMIMETypes) 2010-08-31 10:39:25.850 DumpRenderTree[26725:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: WebPluginMIMETypes)' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff88a8acc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff84c620f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff88a8aae7 +[NSException raise:format:arguments:] + 103 3 CoreFoundation 0x00007fff88a8aa74 +[NSException raise:format:] + 148 4 Foundation 0x00007fff8459ea9b -[NSCFDictionary setObject:forKey:] + 227 5 JavaPluginCocoa 0x000000010519fbc4 BP_CreatePluginMIMETypesPreferences + 162 6 WebKit 0x00000001003da00e -[WebBasePluginPackage createPropertyListFile] + 46 7 WebKit 0x00000001003d9fcc -[WebBasePluginPackage pListForPath:createFile:] + 92 8 WebKit 0x00000001003db5b7 -[WebBasePluginPackage getPluginInfoFromPLists] + 1975 9 WebKit 0x0000000100459182 -[WebPluginPackage initWithPath:] + 354 10 WebKit 0x00000001003da073 +[WebBasePluginPackage pluginWithPath:] + 51 11 WebKit 0x000000010045797d -[WebPluginDatabase(Internal) _scanForNewPlugins] + 429 12 WebKit 0x0000000100458344 -[WebPluginDatabase refresh] + 100 13 WebKit 0x000000010045824d +[WebPluginDatabase sharedDatabase] + 157 14 DumpRenderTree 0x000000010000cfda _Z14dumpRenderTreeiPPKc + 610 15 DumpRenderTree 0x000000010000d57f main + 94 16 DumpRenderTree 0x0000000100001fe4 start + 52 ) terminate called after throwing an instance of 'NSException' Abort trap (core dumped) real 3m38.911s user 0m0.042s sys 0m13.951s =============================== I tried to remove /Library/Internet Plug-Ins/JavaPluginCocoa.bundle, then DumpRenderTree worked. Anyone has encountered the same problem and/or has better solution? BTW, why is crash reporting for DumpRenderTree so slow (3.5 minutes)? Thanks, Xianzhu

1 0

Dummy Document in HTMLTreeBuilder::FragmentParsingContext
by Roland Steiner 30 Aug '10

30 Aug '10

Hi knowledgeable WebKit folks! I'm currently trying to debug an annoying loader/resource request bug that seems to originate with the dummy Document used in HTMLTreeBuilder::FragmentParsingContext. It seems that in some cases the DocLoader that is created with this dummy is assigned to a Request object, which seems to be the underlying reason of the bug that I'm seeing. Instead of just throwing additional RefPtr at the problem to make it go away, I wondered why this dummy document is necessary in the first place. Wouldn't it be more correct to just use the document assigned to the passed-in DocumentFragment (or context element)? I.e., would bad things happen if I removed this dummy? - Roland

2 1

skipping tests on Chromium
by Eric Carlson 30 Aug '10

30 Aug '10

What is the correct way to skip a layout test on Chromium now that platform/chromium/Skipped has been removed? eric

2 3

We need OwnPtrHashMap
by Adam Barth 30 Aug '10

30 Aug '10

Sorry for the late-night webkit-dev spam, but in deploying adoptPtr, I've noticed a number of places where have a HashMap that owns its values as OwnPtrs. Unfortunately, this very clumsy currently. Each instance of this pattern has its own way of hacking around the problem, which might or might not result in memory errors. We really should have an OwnPtrHashMap (to complement RefPtrHashMap) that understands how to handle this case correctly. Is anyone interested in working this problem? Adam

4 6

Changes to line-by-line code reviews
by Adam Barth 30 Aug '10

30 Aug '10

Based on some feedback, I'm going to try to improve the line-by-line review tool. I've landed the first iteration of the new design, which should be usable and have roughly the same functionality as the old design. I'll be adding new features shortly. The main difference is you now access the line-by-line review feature using the "Formatted Diff" link in bugs.webkit.org instead of the "Review Patch" link. I made this change so that folks who like the old "Review Patch" tool won't be bothered by the new tool. If you have feature requests, let me know. I'll post an update once the tool is awesomified. Thanks, Adam

4 8

WebKitTools/Script/generate-coverage-data
by Eric Seidel 30 Aug '10

30 Aug '10

Has anyone looked at our coverage-generating scripts in a while? Seems to die trying to build libANGLE these days, but I believe the scripts have been dead for much longer. I'm interested in finding (and removing) dead code from WebCore. There is a whole bunch more dead code now that the LegacyHTMLDocumentParser has been removed. I'd like to rip it out. I was hoping gcov / generate-coverage-data would help me do that. -eric

2 4

deduplicate-results
by Eric Seidel 28 Aug '10

28 Aug '10

I'm very glad to see work being done to remove some of our redundant layout test results: http://trac.webkit.org/changeset/66124 I'm curious what the status of that work is. Do we expect all duplicates are gone now? or just chromium's? -eric

3 2