Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?
Darin Adler writes: > On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa wrote: > >> Sam Weinig writes: >> >>> Hello, >>> >>> Is anyone using the LevelDB backend to IndexedDB? >> >> The EFL and GTK+ ports are. > > Are you sure? > > Since the GTK+ port is now WebKit2-only, then it can’t be using the > LevelDB back end at this time, because I believe nobody has made it > work in WebKit2 yet. Right, so it's only the build system that sets WTF_USE_LEVELDB to 1 and builds the LevelDB stuff in ThirdParty. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?
Sam Weinig writes: > Hello, > > Is anyone using the LevelDB backend to IndexedDB? The EFL and GTK+ ports are. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Geoffrey Garen writes: > Concepts we plan to remove: > Features #defines that haven't gained traction Do you already have anything in mind? Is the process described in the DeprecatingFeatures article on the wiki still going to be followed? -- Intel Finland Oy Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Geoffrey Garen writes: > Also: > Adopt libc++ My FreeBSD hat appreciates that, but can you elaborate? Is there something specific to libc++ not present in, say, libstdc++, that is going to be used? -- Intel Finland Oy Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] do you want "WK1" and "WK2" keywords in the TestExpectations files?
Dirk Pranke writes: > So, it seems like WK1 and WK2 keywords might be useful. However, I > don't really want to add more divergence between ports, so it would be > nice to have everyone agree to use it if we were to add it. > > What do you all think? Would you like this feature, and would you all > use it ? At least on the EFL side I think things are good the way they are: we have platform/efl for common stuff and platform/efl-wk1 and platform/efl-wk2 for WK1- or WK2-specific stuff (not only TestExpectations files but also test results). If we got rid of those and put everything together in platform/efl, I think we'd end up with a very big TestExpectations file and don't know what we'd do with the occasional different results for WK1 and WK2. > However, this is a little awkward and gets worse if you also need to > support different expectations for multiple different configs (e.g., > mac-lion vs mac-snowleopard vs mac-mountainlion). It wouldn't really solve this problem, right? -- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is UseV8.cmake still used?
Kentaro Hara writes: > EFL and other ports used to have an option to build with V8, but it > looks like the option is no longer supported. For example, UseV8.cmake > is already out of sync with existing V8 binding files. > > - Would it be OK to remove UseV8.cmake? > > - Would it be OK to remove #if PLATFORM(CHROMIUM) from all V8 binding files? > > If anyone has a plan to support the option in the near future, I'll > keep them as is. No objections from the EFL side, I guess -- it's never been used by any of our build bots and I'm not even sure if the Samsung folks have finished their work on it. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Idle build bots?
Hey there, Looking at build.webkit.org I see many white bubbles in all bots, and the most recent commits have been pending in them for a few hours. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Settings and Preferences in layout tests
Brady Eidson writes:
> On Sep 26, 2012, at 2:46 PM, Tony Chang wrote:
>> I suppose we're biased in Mac-land where the mechanism originated,
>> but the "API" is simply a single string based API that only had to
>> be implemented once.
>>
>> Your comment leads me to understand that at least one other port
>> doesn't have simple string based preferences.
[...]
>> I think for all the major ports, they are simple string based
>> preferences. However, adding a new overridePreference call means
>> updating 5 WebKit API interfaces (Mac, Win, Chromium, GTK+, QT), and
>> updating 5 DRTs and 1 WTR. Compared to updating a single
>> internal.settings implementation, this is a lot of work.
> I think you misunderstand what I meant.
>
> The Mac DRT implementation of overridePreference has the following
> implementation:
>
> void TestRunner::overridePreference(JSStringRef key, JSStringRef
> value)
> {
> RetainPtr keyCF(AdoptCF,
> JSStringCopyCFString(kCFAllocatorDefault, key));
> NSString *keyNS = (NSString *)keyCF.get();
>
> RetainPtr valueCF(AdoptCF,
> JSStringCopyCFString(kCFAllocatorDefault, value));
> NSString *valueNS = (NSString *)valueCF.get();
>
> [[WebPreferences standardPreferences]
> _setPreferenceForTestWithValue:valueNS forKey:keyNS];
> }
>
> This works for any preference; Even a new one that has never been
> twiddled in a regression test before.
The situation seems to be improving as more ports move towards WebKit2,
where adding new preferences to overridePreferences is normally a matter
of touching a (few) file(s) in Source/WebKit2/Shared.
However, for chromium and ports using DRT this does not help much, as
the Mac code ends up being the exception: all the other DRTs (chromium,
blackberry, Qt, EFL, GTK+) implement some variation of a big switch
mapping that string into an API of some sort, so even if the preference
already exists in the WebKit layer one needs to add more code to DRT
simply to call that.
And sometimes there's even more than one way of achieving the same
thing, such as changing the "WebKitDisplayImagesKey" preference or
calling testRunner.disableImageLoading().
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL bot needs to rebuild WebCore derived sources
Raphael Kubo da Costa writes: > Geoffrey Garen writes: > >> Hi folks. >> >> The EFL build is failing because the bot did not rebuild WebCore >> derived sources, despite a change to CodeGeneratorJS.pm. > > Do you have a bug number for the change? I'd like to double-check if we > don't have a build system problem here. Hopefully fixed in <http://trac.webkit.org/changeset/127249>. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL bot needs to rebuild WebCore derived sources
Geoffrey Garen writes: > Hi folks. > > The EFL build is failing because the bot did not rebuild WebCore > derived sources, despite a change to CodeGeneratorJS.pm. Do you have a bug number for the change? I'd like to double-check if we don't have a build system problem here. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Is the style bot OK?
I've been trying to send a patch to bug 78600 for a few hours, but the style bot is always rejecting [1] it when trying to apply a separate patch. Does the bot need some love? [1] https://bugs.webkit.org/show_bug.cgi?id=78600#c2 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WEBKITOUTPUTDIR documentation
Seo Sanghyeon writes: > Building WebKit document at http://www.webkit.org/building/build.html > seems to suggest that WEBKITOUTPUTDIR only works on Windows, > but this is not the case. > > Current wording doesn't tell how to customize build location on non-Mac > and non-Windows platforms. > > Can someone reword this? The website code is part of the SVN tree; you can also do that and submit a patch via bugs.webkit.org if you feel like doing so. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DumpRenderTree for the EFL port :)
Leandro Pereira writes: > At last, the EFL port of WebKit got a DumpRenderTree implementation! > We're still working on ironing out a lot of bugs found by some of the > LayoutTests, but the DRT (and ImageDiff) code has been submitted to > Bugzilla. It would be awesome if anyone could help reviewing these > patches. ... And we finally finished upstreaming our work a few weeks ago, with baselines being committed some time later. We'd like to thank everyone, especially those who helped review our changes (eseidel, rniwa, tkent, tonikitoo, kenneth, mrobinson and so many others). Cheers! -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
Leandro Pereira writes: > What's the preferred way to commit a ton of baselines for a port that > currently has none? > > On our internal EFL tree, there is about 125MB of baselines for both > pixel and text tests. Unfortunately we were unable to share our > baselines with similar ports, due to slight differences in results. > > This is pretty much unreviewable, so I pretend to commit this > directly, in batches (one commit per toplevel directory in > LayoutTests/platform/efl) in the next weeks. Any objections or > suggestions? Bringing the thread back from the dead. We're almost there with upstreaming our DumpRenderTree code, so the time to upload the baselines is coming. Right now, our LayoutTests/platform/efl is about 126M in size. One nice thing we've managed to do since the last time we talked about this is that we've started using smfr's mock scrollbar theme commits to reduce the differences in scrollbar size and appearance, so at least this should be common with other ports. Anyway, are there any options besides simply svn commit'ting all these files? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DumpRenderTree for the EFL port :)
Leandro Pereira writes: > At last, the EFL port of WebKit got a DumpRenderTree implementation! > We're still working on ironing out a lot of bugs found by some of the > LayoutTests, but the DRT (and ImageDiff) code has been submitted to > Bugzilla. It would be awesome if anyone could help reviewing these > patches. Thanks to eseidel, a few of our patchas have already made their way upstream. Unfortunately, he needs to take a break from too much exposure to C-style code, so we need someone else to review our remaining patches :-) The remaining DRT patches are: https://bugs.webkit.org/show_bug.cgi?id=61962 https://bugs.webkit.org/show_bug.cgi?id=61974 https://bugs.webkit.org/show_bug.cgi?id=63086 https://bugs.webkit.org/show_bug.cgi?id=61974 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Early deletion of DocumentLoader instances
Darin Adler writes: > On May 23, 2011, at 1:34 PM, Raphael Kubo da Costa wrote: > >> While working on the EFL port, I've noticed that sometimes a >> FrameLoader's DocumentLoader ends up being deleted too early >> (FrameLoader::setDocumentLoader causes the current DocumentLoader to >> be >> deref'ed and freed), in the sense that later on >> Document::explicitClose tries to access this DocumentLoader instance >> that has already been freed, causing a crash. > > This looks like a basic design problem. The document has a pointer to > the document loader, and keeps that pointer even after the document > loader has been destroyed. That is a broken design. > > Also, there is a Document::setDocumentLoader function, but nobody ever > calls it. I could submit a patch to remove it, if that's desirable. > What we need are some test cases showing problems caused by this > mistake that we can use as regression tests; Hmm, I wonder how to write a test for this. I've experienced this crash while writing some DRT code for the EFL port. In short, I reuse the same Frame and Frame::loader() to load each layout test page, and the code will occasionally crash when some page's contents are delivered. Should I try to create a manual-test for WebCore? > then we should fix it by making some better relationship between the > Document and DocumentLoader that guarantees we won’t have a dangling > pointer. Either reference counting to keep the object alive, or code > to zero out the pointer at some point before the object is deleted. r80507 added a check for m_frame before using it (Document also has a raw Frame pointer). Perhaps the same should be done here? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Early deletion of DocumentLoader instances
Hey there, While working on the EFL port, I've noticed that sometimes a FrameLoader's DocumentLoader ends up being deleted too early (FrameLoader::setDocumentLoader causes the current DocumentLoader to be deref'ed and freed), in the sense that later on Document::explicitClose tries to access this DocumentLoader instance that has already been freed, causing a crash. I couldn't find any abnormal behaviour that could deref the DocumentLoaders more than they should have been. Are there any recommended places where I should look to check what's going on? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
