Re: [webkit-dev] Colors

[Alexey Proskuryakov]

30.08.2010, в 17:45, Darin Adler написал(а):

> Is there any real world problem changing this would solve? If not, the 
> current approach works and is efficient since a color takes just a 32-bit 
> integer plus one more bit to store.


Full support for CMYK and other formats could make printing better, see 
. But we'd need to pass these to 
printing layer unchanged, as opposed to letting color matching convert them to 
RGB.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] DumpRenderTree crashes because of JavaPluginCocoa

[Xianzhu Wang]

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  0x7fff88a8acc4
__exceptionPreprocess + 180
1   libobjc.A.dylib 0x7fff84c620f3
objc_exception_throw + 45
2   CoreFoundation  0x7fff88a8aae7 +[NSException
raise:format:arguments:] + 103
3   CoreFoundation  0x7fff88a8aa74 +[NSException
raise:format:] + 148
4   Foundation  0x7fff8459ea9b -[NSCFDictionary
setObject:forKey:] + 227
5   JavaPluginCocoa 0x00010519fbc4
BP_CreatePluginMIMETypesPreferences + 162
6   WebKit  0x0001003da00e
-[WebBasePluginPackage createPropertyListFile] + 46
7   WebKit  0x0001003d9fcc
-[WebBasePluginPackage pListForPath:createFile:] + 92
8   WebKit  0x0001003db5b7
-[WebBasePluginPackage getPluginInfoFromPLists] + 1975
9   WebKit  0x000100459182
-[WebPluginPackage initWithPath:] + 354
10  WebKit  0x0001003da073
+[WebBasePluginPackage pluginWithPath:] + 51
11  WebKit  0x00010045797d
-[WebPluginDatabase(Internal) _scanForNewPlugins] + 429
12  WebKit  0x000100458344
-[WebPluginDatabase refresh] + 100
13  WebKit  0x00010045824d
+[WebPluginDatabase sharedDatabase] + 157
14  DumpRenderTree  0x0001cfda
_Z14dumpRenderTreeiPPKc + 610
15  DumpRenderTree  0x0001d57f main + 94
16  DumpRenderTree  0x00011fe4 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Colors

[Igor Trindade Oliveira]

Hello,

2010/8/30 Darin Adler :
> On Aug 30, 2010, at 5:51 PM, Igor Trindade Oliveira wrote:
>
>> WebKit supporting ICC profiles could be a good real case.
>
> I think we will want that feature eventually. Changing the Color class would 
> probably not be needed, though, for that. If you start working on that kind 
> of feature, I can help you figure out what it takes, and if it turns out I’m 
> wrong we are definitely open to changing the class design. We won’t just 
> change the class based on “Why not?”
>
>    -- Darin
>
>


There are some pieces from webkit i looked to do this work.
Already there is an initial ColorSpace enum in
Webkit(WebCore/platform/graphics/ColorSpace.h) and a color
transformation(SRGBA<->RGBA) in
WebCore/platform/graphics/ImageBuffer.cpp.

I was looking first in color because it is used by css
parserColorFromValue and some kind of colors(gammut) are not correctly
converted to CMYK(they are out of gammut).

Igor
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Colors

[Darin Adler]

On Aug 30, 2010, at 5:51 PM, Igor Trindade Oliveira wrote:

> WebKit supporting ICC profiles could be a good real case.

I think we will want that feature eventually. Changing the Color class would 
probably not be needed, though, for that. If you start working on that kind of 
feature, I can help you figure out what it takes, and if it turns out I’m wrong 
we are definitely open to changing the class design. We won’t just change the 
class based on “Why not?”

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Colors

[Igor Trindade Oliveira]

Hello,

yeah. Webkit supporting ICC profiles could be a good real case.

Igor

2010/8/30 Darin Adler :
> Is there any real world problem changing this would solve? If not, the 
> current approach works and is efficient since a color takes just a 32-bit 
> integer plus one more bit to store.
>
>    -- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Colors

[Darin Adler]

Is there any real world problem changing this would solve? If not, the current 
approach works and is efficient since a color takes just a 32-bit integer plus 
one more bit to store.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Colors

[Igor Trindade Oliveira]

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

[Kinuko Yasuda]

On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth  wrote:

> On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak  wrote:
> > Yes. The file-related stuff should all be in one directory, I think.
>
> Ok.  I moved the files from WebCore/html to WebCore/fileapi.
>
> 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?
>
> Are these the files you're talking about?
>
> WebCore/storage/DOMFilePath.cpp
> WebCore/storage/DOMFilePath.h
> WebCore/storage/DOMFileSystem.cpp
> WebCore/storage/DOMFileSystem.h
> WebCore/storage/DOMFileSystem.idl
> WebCore/storage/FileEntry.cpp
> WebCore/storage/FileEntry.h
> WebCore/storage/FileEntry.idl
> WebCore/storage/FileSystemCallback.h
> WebCore/storage/FileSystemCallback.idl
> WebCore/storage/FileSystemCallbacks.cpp
> WebCore/storage/FileSystemCallbacks.h
> WebCore/storage/LocalFileSystem.cpp
> WebCore/storage/LocalFileSystem.h
>
> I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do
> it.
>

There are some more files... I'll make a cl to move them to WebCore/fileapi.

Thanks,

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

Re: [webkit-dev] Accelerated 2D Tesselation Implementation

[Kenneth Russell]

On Mon, Aug 30, 2010 at 1:10 PM, Chris Marrin  wrote:
>
> On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote:
>
>> On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher  wrote:
>>> On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth  wrote:

 On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin  wrote:
> That's why I still think this should all go into a branch for now. It
> will help us all see the results without having to deal with the issues of
> (2) right now.

 An alternative to a branch is to use a run-time setting.  That worked
 well for the HTML5 parser project.  If there's a clean abstraction
 boundary in the code, we can use that as the branch point for the
 setting.  The advantage of using a run-time setting is that you can
 leverage all the tools for working on trunk (including code reviews,
 etc) but you can avoid disturbing the vast majority of other
 developers while your feature bakes.

 Adam
>>>
>>> Such a runtime setting already exists for toggling accelerated canvas 2d on
>>> and off.
>>
>> This GPU based path rendering support is initially only going to be
>> hooked in to the accelerated 2D canvas implementation, which since
>> it's already covered by this run-time flag will not disturb other
>> developers.
>>
>> I am going to substantially restructure the code based on feedback and
>> submit new patches, but still against trunk.
>
> Given all the discussion that has gone on, I agree that trunk is the right 
> place to do this. But I remain concerned about antialiasing.
>
> On that subject. If you were to have to do multi-sampling to solve the AA 
> problem, does it make sense to skip the anti-aliasing on the edges of the 
> spline triangles? Would that buy any performance?

Multisampling doesn't handle the pixels covering the cubic curves. The
fragment shader is only run once per pixel, so to get antialiasing for
these regions with this algorithm, it's necessary to compute the
distance function to the curve in the shader.

-Ken
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accelerated 2D Tesselation Implementation

[Chris Marrin]

On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote:

> On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher  wrote:
>> On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth  wrote:
>>> 
>>> On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin  wrote:
 That's why I still think this should all go into a branch for now. It
 will help us all see the results without having to deal with the issues of
 (2) right now.
>>> 
>>> An alternative to a branch is to use a run-time setting.  That worked
>>> well for the HTML5 parser project.  If there's a clean abstraction
>>> boundary in the code, we can use that as the branch point for the
>>> setting.  The advantage of using a run-time setting is that you can
>>> leverage all the tools for working on trunk (including code reviews,
>>> etc) but you can avoid disturbing the vast majority of other
>>> developers while your feature bakes.
>>> 
>>> Adam
>> 
>> Such a runtime setting already exists for toggling accelerated canvas 2d on
>> and off.
> 
> This GPU based path rendering support is initially only going to be
> hooked in to the accelerated 2D canvas implementation, which since
> it's already covered by this run-time flag will not disturb other
> developers.
> 
> I am going to substantially restructure the code based on feedback and
> submit new patches, but still against trunk.

Given all the discussion that has gone on, I agree that trunk is the right 
place to do this. But I remain concerned about antialiasing.

On that subject. If you were to have to do multi-sampling to solve the AA 
problem, does it make sense to skip the anti-aliasing on the edges of the 
spline triangles? Would that buy any performance?

-
~Chris
cmar...@apple.com




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accelerated 2D Tesselation Implementation

[Kenneth Russell]

On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher  wrote:
> On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth  wrote:
>>
>> On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin  wrote:
>> > That's why I still think this should all go into a branch for now. It
>> > will help us all see the results without having to deal with the issues of
>> > (2) right now.
>>
>> An alternative to a branch is to use a run-time setting.  That worked
>> well for the HTML5 parser project.  If there's a clean abstraction
>> boundary in the code, we can use that as the branch point for the
>> setting.  The advantage of using a run-time setting is that you can
>> leverage all the tools for working on trunk (including code reviews,
>> etc) but you can avoid disturbing the vast majority of other
>> developers while your feature bakes.
>>
>> Adam
>
> Such a runtime setting already exists for toggling accelerated canvas 2d on
> and off.

This GPU based path rendering support is initially only going to be
hooked in to the accelerated 2D canvas implementation, which since
it's already covered by this run-time flag will not disturb other
developers.

I am going to substantially restructure the code based on feedback and
submit new patches, but still against trunk.

-Ken

> -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] WebKit2 SharedSecondaryProcess model

[Sam Weinig]

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  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@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] Dummy Document in HTMLTreeBuilder::FragmentParsingContext

[Adam Barth]

We use a dummy document there to match the processing model in the
spec.  If we used the real document, we'd have to add a bunch of
branches to the HTMLTreeBuilder that aren't in the spec to get the
correct answer when parsing.

How is this document getting associated with a request object?  That
seems like real bug.  The dummy document has a NULL frame, which means
it shouldn't be kicking off any requests.

Adam


On Mon, Aug 30, 2010 at 4:12 AM, Roland Steiner
 wrote:
> 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
> ___
> 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

[Dimitri Glazkov]

// 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  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] skipping tests on Chromium

[Eric Carlson]

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] We need OwnPtrHashMap

[Maciej Stachowiak]

On Aug 29, 2010, at 9:34 PM, Maciej Stachowiak wrote:

> 
> On Aug 29, 2010, at 9:14 PM, Maciej Stachowiak wrote:
> 
>> Yet another possibility is to use a hash to do the de-duping instead of 
>> sorting; I can't tell from context if the sorting is needed for any purpose 
>> other than subsequent de-duping.
> 
> Turns out this doesn't work - the CSS Media Queries spec specifically 
> requires serializing in sorted order and we have a test to that effect:
> http://dev.w3.org/csswg/cssom/#serializing-media-queries
> https://bugs.webkit.org/show_bug.cgi?id=39220
> 
> So it's down to violating the type system or writing my own sort.

OK, you silently guilted me into writing a non-copying sort function.



 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

[Darin Fisher]

On Mon, Aug 30, 2010 at 9:11 AM, Maciej Stachowiak  wrote:

>
> On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote:
>
> On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth  wrote:
>
>> On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak  wrote:
>> > Yes. The file-related stuff should all be in one directory, I think.
>>
>> Ok.  I moved the files from WebCore/html to WebCore/fileapi.
>>
>> 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?
>>
>> Are these the files you're talking about?
>>
>> WebCore/storage/DOMFilePath.cpp
>> WebCore/storage/DOMFilePath.h
>> WebCore/storage/DOMFileSystem.cpp
>> WebCore/storage/DOMFileSystem.h
>> WebCore/storage/DOMFileSystem.idl
>> WebCore/storage/FileEntry.cpp
>> WebCore/storage/FileEntry.h
>> WebCore/storage/FileEntry.idl
>> WebCore/storage/FileSystemCallback.h
>> WebCore/storage/FileSystemCallback.idl
>> WebCore/storage/FileSystemCallbacks.cpp
>> WebCore/storage/FileSystemCallbacks.h
>> WebCore/storage/LocalFileSystem.cpp
>> WebCore/storage/LocalFileSystem.h
>>
>> I'm happy to move them to WebCore/fileapi, but I'm also happy for you to
>> do it.
>>
>> Thanks,
>> Adam
>>
>>
>
> How about just moving everything into WebCore/storage?  This is all
> storage-related stuff.
>
>
> I think the File API is large enough to deserve its own directory. In fact,
> it might be worth splitting up the remaining contents of the storage
> directory too. It is confusing to have large but almost entirely separate
> APIs all piled into one directory. It is true they are all
> "storage-related", but that is a pretty broad theme, and LocalStorage, SQL
> Storage, Indexed DB and File API have little or no interaction with each
> other.
>
> Regards,
> Maciej
>
>
>
>
That's fair.  Plus, there are a lot of files in there already.

-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

[Maciej Stachowiak]

On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote:

> On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth  wrote:
> On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak  wrote:
> > Yes. The file-related stuff should all be in one directory, I think.
> 
> Ok.  I moved the files from WebCore/html to WebCore/fileapi.
> 
> 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?
> 
> Are these the files you're talking about?
> 
> WebCore/storage/DOMFilePath.cpp
> WebCore/storage/DOMFilePath.h
> WebCore/storage/DOMFileSystem.cpp
> WebCore/storage/DOMFileSystem.h
> WebCore/storage/DOMFileSystem.idl
> WebCore/storage/FileEntry.cpp
> WebCore/storage/FileEntry.h
> WebCore/storage/FileEntry.idl
> WebCore/storage/FileSystemCallback.h
> WebCore/storage/FileSystemCallback.idl
> WebCore/storage/FileSystemCallbacks.cpp
> WebCore/storage/FileSystemCallbacks.h
> WebCore/storage/LocalFileSystem.cpp
> WebCore/storage/LocalFileSystem.h
> 
> I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do 
> it.
> 
> Thanks,
> Adam
> 
> 
> 
> How about just moving everything into WebCore/storage?  This is all 
> storage-related stuff.

I think the File API is large enough to deserve its own directory. In fact, it 
might be worth splitting up the remaining contents of the storage directory 
too. It is confusing to have large but almost entirely separate APIs all piled 
into one directory. It is true they are all "storage-related", but that is a 
pretty broad theme, and LocalStorage, SQL Storage, Indexed DB and File API have 
little or no interaction with each other.

Regards,
Maciej



___
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

[Dimitri Glazkov]

We never had platform/chromium/Skipped, as far as I know. 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.

:DG<

On Mon, Aug 30, 2010 at 8:52 AM, Eric Carlson  wrote:
>
>  What is the correct way to skip a layout test on Chromium now that 
> platform/chromium/Skipped has been removed?
>
> 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] skipping tests on Chromium

[Eric Carlson]

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

eric


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

[Darin Fisher]

On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth  wrote:

> On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak  wrote:
> > Yes. The file-related stuff should all be in one directory, I think.
>
> Ok.  I moved the files from WebCore/html to WebCore/fileapi.
>
> 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?
>
> Are these the files you're talking about?
>
> WebCore/storage/DOMFilePath.cpp
> WebCore/storage/DOMFilePath.h
> WebCore/storage/DOMFileSystem.cpp
> WebCore/storage/DOMFileSystem.h
> WebCore/storage/DOMFileSystem.idl
> WebCore/storage/FileEntry.cpp
> WebCore/storage/FileEntry.h
> WebCore/storage/FileEntry.idl
> WebCore/storage/FileSystemCallback.h
> WebCore/storage/FileSystemCallback.idl
> WebCore/storage/FileSystemCallbacks.cpp
> WebCore/storage/FileSystemCallbacks.h
> WebCore/storage/LocalFileSystem.cpp
> WebCore/storage/LocalFileSystem.h
>
> I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do
> it.
>
> Thanks,
> Adam
>
>

How about just moving everything into WebCore/storage?  This is all
storage-related stuff.

-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] WebKit2 SharedSecondaryProcess model

[Balazs Kelemen]

   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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Dummy Document in HTMLTreeBuilder::FragmentParsingContext

[Roland Steiner]

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Misplaced files

[Adam Barth]

On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak  wrote:
> Yes. The file-related stuff should all be in one directory, I think.

Ok.  I moved the files from WebCore/html to WebCore/fileapi.

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?

Are these the files you're talking about?

WebCore/storage/DOMFilePath.cpp
WebCore/storage/DOMFilePath.h
WebCore/storage/DOMFileSystem.cpp
WebCore/storage/DOMFileSystem.h
WebCore/storage/DOMFileSystem.idl
WebCore/storage/FileEntry.cpp
WebCore/storage/FileEntry.h
WebCore/storage/FileEntry.idl
WebCore/storage/FileSystemCallback.h
WebCore/storage/FileSystemCallback.idl
WebCore/storage/FileSystemCallbacks.cpp
WebCore/storage/FileSystemCallbacks.h
WebCore/storage/LocalFileSystem.cpp
WebCore/storage/LocalFileSystem.h

I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it.

Thanks,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev