Re: [webkit-dev] Settings and Preferences in layout tests
Brady Eidson beid...@apple.com writes:
On Sep 26, 2012, at 2:46 PM, Tony Chang t...@chromium.org 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)
{
RetainPtrCFStringRef keyCF(AdoptCF,
JSStringCopyCFString(kCFAllocatorDefault, key));
NSString *keyNS = (NSString *)keyCF.get();
RetainPtrCFStringRef 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
[webkit-dev] Catching events in JavaScript and the onload event
Hello. I'm trying to figure out how to give a WebKit program hints that JavaScript is going to change the DOM structure my manipulating it's tree (e.g. IMG 'src' attribute change). Can anyone give me some pointers where should I look at. And another related question... The 'onload' event should be triggered only then when all resources are loaded and the DOM tree is constructed. In other words, the page is ready to be rendered to the user. But, as I use Gtk+ and the off-screen widget I can explicitly 'draw' the WebKit surface when I receive an 'onload' event from Webkit. But the problem is that the page is some times still half-rendered (missing images). Any ideas why is the event behaving this way? Best regards, -- Greets, Luka Napotnik, www: http://napotnik.info ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WKCreateCTLineWithUniCharProvider
On Sep 26, 2012, at 2:34 AM, Glenn Adams gl...@skynav.com wrote: Where can I find the source for WKCreateCTLineWithUniCharProvider? I'm working on a bug [1] in which I will need to at least understand and perhaps modify its behavior. Basically, to fix this bug, I need to pass character context from adjacent text runs (or adjacent inline text nodes) that will be used to affect the shaping substitutions but not otherwise participate in width or drawing behavior. Or is this functionality only exposed to Apple staffers? [If so, then I will instead approach doing a trial fix on one of the platforms that uses harfbuzz.] Regards, Glenn [1] https://bugs.webkit.org/show_bug.cgi?id=6148 WKCreateCTLineWithUniCharProvider is a wrapper around Core Text private API. It does the same thing that the public function CTLineCreateWithAttributedString does, except that instead of taking an attributed string as a parameter, it takes a pointer to a callback function that returns runs of characters and attributes. Core Text source code is not published. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Skipped files are going away
Last call on this ... I will be removing the files later today unless something goes awry :). -- Dirk On Fri, Sep 21, 2012 at 3:41 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Now that we're on the new TestExpectations syntax, I'm planning to remove the Skipped files (and support for them from NRWT). I have a change posted that will add minimal support for the syntax to old-run-webkit-tests in https://bugs.webkit.org/show_bug.cgi?id=97276 ; basically any file or directory listed in a TestExpectations file will be skipped *regardless of the expectation listed*. I can make things smarter if need be, but it's not clear to me how many people if any are still using ORWT so the need doesn't seem to be there. Please comment on the bug ASAP if you disagree and would like ORWT to be smarter in this area :). Once that change lands, my plan is to copy all of the entries from the existing Skipped files over into their corresponding TestExpectations files, and then delete the Skipped files, and then delete the code that supports the Skipped files in NRWT and ORWT. I hope to do this early next week. If you have any objections, now would be a good time to speak up! Note that all of this is being done in the oft-requested name of simplifying the number of different ways we have to handle failing tests. Also, I will remind people that the new TestExpectations syntax is a superset of the old Skipped file syntax, so there shouldn't be any good reason to keep the old files around. However, if you know something I don't, please mention it :). Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Skipped files are going away
Now landed in http://trac.webkit.org/changeset/129788 . Let me know if there are any problems. -- Dirk On Thu, Sep 27, 2012 at 10:15 AM, Dirk Pranke dpra...@chromium.org wrote: Last call on this ... I will be removing the files later today unless something goes awry :). -- Dirk On Fri, Sep 21, 2012 at 3:41 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Now that we're on the new TestExpectations syntax, I'm planning to remove the Skipped files (and support for them from NRWT). I have a change posted that will add minimal support for the syntax to old-run-webkit-tests in https://bugs.webkit.org/show_bug.cgi?id=97276 ; basically any file or directory listed in a TestExpectations file will be skipped *regardless of the expectation listed*. I can make things smarter if need be, but it's not clear to me how many people if any are still using ORWT so the need doesn't seem to be there. Please comment on the bug ASAP if you disagree and would like ORWT to be smarter in this area :). Once that change lands, my plan is to copy all of the entries from the existing Skipped files over into their corresponding TestExpectations files, and then delete the Skipped files, and then delete the code that supports the Skipped files in NRWT and ORWT. I hope to do this early next week. If you have any objections, now would be a good time to speak up! Note that all of this is being done in the oft-requested name of simplifying the number of different ways we have to handle failing tests. Also, I will remind people that the new TestExpectations syntax is a superset of the old Skipped file syntax, so there shouldn't be any good reason to keep the old files around. However, if you know something I don't, please mention it :). Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Skipped files are going away
Sorry for the long stream of messages on this ... in case it's not clear, all I did with this change was cut and paste the entries from one file into the other (since the TestExpectations file syntax is a superset of the Skipped syntax) and do some minimal de-duping so that run-webkit-tests --lint-test-files would pass. Different ports use different organization methods for these files, and I didn't attempt to follow each port, nor reorganize entries that were being skipped but really should've been failures or flakes or something else. I leave each port to do their own cleanup, but of course I'll be happy to troubleshoot/answer questions, etc :). -- Dirk On Thu, Sep 27, 2012 at 12:24 PM, Dirk Pranke dpra...@chromium.org wrote: Now landed in http://trac.webkit.org/changeset/129788 . Let me know if there are any problems. -- Dirk On Thu, Sep 27, 2012 at 10:15 AM, Dirk Pranke dpra...@chromium.org wrote: Last call on this ... I will be removing the files later today unless something goes awry :). -- Dirk On Fri, Sep 21, 2012 at 3:41 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Now that we're on the new TestExpectations syntax, I'm planning to remove the Skipped files (and support for them from NRWT). I have a change posted that will add minimal support for the syntax to old-run-webkit-tests in https://bugs.webkit.org/show_bug.cgi?id=97276 ; basically any file or directory listed in a TestExpectations file will be skipped *regardless of the expectation listed*. I can make things smarter if need be, but it's not clear to me how many people if any are still using ORWT so the need doesn't seem to be there. Please comment on the bug ASAP if you disagree and would like ORWT to be smarter in this area :). Once that change lands, my plan is to copy all of the entries from the existing Skipped files over into their corresponding TestExpectations files, and then delete the Skipped files, and then delete the code that supports the Skipped files in NRWT and ORWT. I hope to do this early next week. If you have any objections, now would be a good time to speak up! Note that all of this is being done in the oft-requested name of simplifying the number of different ways we have to handle failing tests. Also, I will remind people that the new TestExpectations syntax is a superset of the old Skipped file syntax, so there shouldn't be any good reason to keep the old files around. However, if you know something I don't, please mention it :). Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental features in Safari Web Inspector
Pavel, thanks for your suggestions. I'll be looking into this on Monday ;-) Mihai Balan | Quality Engineer / WebKit team | miba...@adobe.commailto:miba...@adobe.com | +4-031.413.3653 / x83653 | Adobe Systems Romania From: pfeld...@google.com [mailto:pfeld...@google.com] On Behalf Of Pavel Feldman Sent: Thursday, September 27, 2012 2:21 AM To: Dean Jackson Cc: Mihai Balan; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Experimental features in Safari Web Inspector On Sep 27, 2012 1:56 AM, Dean Jackson dinomailto:d...@apple.com@mailto:d...@apple.comapple.commailto:d...@apple.com wrote: On 26/09/2012, at 6:15 PM, Mihai Balan mibalanmailto:miba...@adobe.com@mailto:miba...@adobe.comadobe.commailto:miba...@adobe.com wrote: We have recently been working on some WebInspector features related to CSS Regions. Most of the work was done using Chromium's Developer Tools, as this allowed us to have this work under a DevTools experiment flag. Now that this work has reached a more stable state, it would be useful to test it under Webkit/Safari, too. So, my question for you is this (ok, that's actually two questions): 1. Is there a way to enable / disable features in Safari DevTools the way it is in Chromium's? It doesn't have to be a GUI, though No. We should probably enable experiments in WebKit nightly (i.e. Experiments tab will be enabled in WebKit Web Inspector's settings at all times). I can do that for you or r+ such a patch. 2. What is the general policy for WebInspector features? How and when do they get enabled by default, at least in the nightlies? (Since regions are already enabled by default in the nightlies, IMO it would make sense to have the web inspector regions features, too) The process of adding features into WebKit Web Inspector is very lightweight. When you think the feature is ready for the prime time, make a patch moving it out of experimental. We will review it and suggest if something is missing. Regards Pavel Safari's Web Inspector lives in the Safari.app, so nightlies do not automatically get new features. The best thing to do is implement it in the Open Source inspector (as you've done) and Apple will (hopefully) merge it in. You can also file a bug at bugreporter.apple.comhttp://bugreporter.apple.com explicitly requesting it. Dean ___ webkit-dev mailing list webkitmailto:webkit-dev@lists.webkit.org-dev@mailto:webkit-dev@lists.webkit.orglists.webkit.orgmailto:webkit-dev@lists.webkit.org http://http://lists.webkit.org/mailman/listinfo/webkit-devlists.webkit.orghttp://lists.webkit.org/mailman/listinfo/webkit-dev/mailman/http://lists.webkit.org/mailman/listinfo/webkit-devlistinfohttp://lists.webkit.org/mailman/listinfo/webkit-dev/http://lists.webkit.org/mailman/listinfo/webkit-devwebkithttp://lists.webkit.org/mailman/listinfo/webkit-dev-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Getting compilation errors even after INSPECTOR has been disabled!!
Hi, I am getting the following compilation errors while building WebCore c1xx : fatal error C1083: Cannot open source file: '..\..\..\..\output\Debug\obj\WebCore\DerivedSources\InspectorFrontend.cpp': No such file or directory I have disabled INSPECTOR flag in wtf/platform.h , but am still getting these errors. It's the windows port of Apple webkit and being built in VS2008 express edition on VISTA x64. Any hints to get rid of them? -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
