[webkit-dev] No coverage of pixel tests
Hi there, Since Blink forked none of the build bots are running pixel tests. This means that we are not catching painting regressions where the rendertree text dump is unaffected by the regression. Given that in the vast majority of cases a rebaseline to the pixel result also entails a rebaseline to the rendertree result and vice versa the additional overhead of enabling pixel tests and keeping them up to date is not the 'current effort x 2'. In most cases the rebaselining needs to be done anyway, the rebaseliner just needs to update the png result while they're at it. So are we likely to see this situation change in the near future? If not, reviewers and patch authors take note I guess! Thanks, Robert ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Commit Queue is Wedged
Hi there, The commit queue is stuck and 19 patches are now pending. Looks like the problem started about 8 hours ago. Thanks, Robert ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: run-webkit-tests now generates pixel results in retry
This will allow us to rebaseline BOTH test and image expected results PRIOR to landing patches. You're welcome. Great stuff. Thanks for doing this! A question for the Qt/gtk/efl ports: do you plan to put some testers on the EWS queue? If not, I think you should shout if you do not want authors to add just the text part of new results and advise what they should do instead. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Wednesday, 20 March 2013, Ryosuke Niwa wrote: Please don't add lines to TestExpectations saying that they just need rebaselines and then leave. OK. That means I will have to pull the new results from the bots, which is fine - but in the case of the Mac port (and any other bot that does not run pixel tests) the result will be that trunk will get fresh text results but retain stale png results. If that is OK then you need to publish that information somewhere as I suspect I'm not the only contributor who has hesitated to make Mac's test results inconsistent. That would reduce the test coverage we have, and effectively disables the test. If you're adding those entires, please be sure to remove them ASAP. Better yet, don't add them unless you have to rebaseline hundreds of tests. It's not acceptable to leave those entries in TestExpectations for days. We've batted back and forth on this list for at least a year on the correct approach for landing and rebaselining. My approach is to land results for the platform that I build, suppress tests that require rebaselining on other platforms, and open a bug so sheriffs can add/rebaseline results as appropriate. My impression from recent discussion on this topic was that this was the way that worked best for everybody.I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. Presumably this will be discussed at the contributors' meeting - it would be good to make sure that all the relevant people required for consensus on this topic can attend the discussion and settle this once and for all! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan
li...@roberthogan.netjavascript:_e({}, 'cvml', 'li...@roberthogan.net');
wrote:
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
I used to pull results from the bots where possible but creating
inconsistency between png/text results is not good.
It is unfortunate but it's much better than losing the complete test
coverage.
If that's the case then I'm happy to land whatever garden-o-matic pulls
in or I can sweep from the bots, even if it means that png results for Mac,
Qt, et al. go bad as a result.
I guess we will always have ports whose bots do not run pixel tests so if
those ports are happy to live with the downsides of doing that then there
really is no obstacle to authors owning the job of updating the baselines
for all ports when they land a change.
IMHO ports who don't run pixel tests would be better off deleting any png
results they have in the tree. Is there a reason Mac hasn't done that?
Don't you get lots of failures when you run pixel tests locally?
Yes, but I'd argue that it's better than losing the test coverage.
By the way, we can easily address this problem by always generating pixel
results for unexpectedly failing tests. Namely, we can force --pixel when
we're retrying tests.
Perhaps NRWT could produce txt and png results for all tests marked with
REBASELINE or similar in TestExpectations. That would avoid the need to
turn the bots red on each platform for at least one build cycle.
Or is that something we can live with?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] is DNS for webkit.org down?
This has started happening again I think. As of 8.30pm GMT Monday evening. On Sunday 01 July 2012 15:34:36 William Siegrist wrote: There was a network issue that has since been resolved. If you're still having trouble, please let me know. -Bill On Jun 30, 2012, at 8:17 PM, Dirk Pranke wrote: Hi all, It seems like DNS for webkit.org is down ... I can still get to build.webkit.org, but everything else is timing out? -- Dirk ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] is DNS for webkit.org down?
Looks like the problem (for me at least) is with Google's DNS servers - 8.8.8.8 and 8.8.4.4. OpenDNS and co. work fine. On Tuesday 03 July 2012 20:37:30 Robert Hogan wrote: This has started happening again I think. As of 8.30pm GMT Monday evening. On Sunday 01 July 2012 15:34:36 William Siegrist wrote: There was a network issue that has since been resolved. If you're still having trouble, please let me know. -Bill On Jun 30, 2012, at 8:17 PM, Dirk Pranke wrote: Hi all, It seems like DNS for webkit.org is down ... I can still get to build.webkit.org, but everything else is timing out? -- Dirk ___ 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 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] Is converting pixel tests to reftests kosher for imported libraries?
On Thursday 12 April 2012 00:58:47 Ryosuke Niwa wrote: On Wed, Apr 11, 2012 at 4:45 PM, Ojan Vafai o...@chromium.org wrote: I agree with the sentiment that we should be upstreaming these to the W3C, but I don't see why we would require upstreaming them first instead of committing them locally and then upstreaming them. How do we know whether a reference file came from W3C repository or not. (Maybe by the fact it's named *-expected.html?) Yes, that is it exactly. Presumably that's by design - as NRWT currently won't use anything like *-ref.htm unless it's in a manifest. Also, there are directories with reftest.list but without reference files for some tests. The last time I checked, you were opposed to having bot reftest.list and *-expected.html / *-expected-mismatch.html files. Have you changed your opinion on this? It would be good if this was allowed. It would allow us to import the reftest.list from the CSS test suite while keeping our own reference results in there for tests in the suite that don't have them yet. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS 2.1 Test Suite
On Wednesday 11 April 2012 20:11:23 Alan Stearns wrote: The best way to judge whether a reference result is correct is to submit the result to the W3C CSS 2.1 test suite and have it reviewed. The only way this test suite will get more reference results is if people like us volunteer to submit references. If it's useful to us to have these 'homebrew reference results' then it will be useful to everyone else who uses the suite. Agreed. This will help us land the tests that already pass and won't slow down the effort to fix the css tests that we don't. We can agree to only import css tests with reftests and get NRWT working on them. I hope to do this in: https://bugs.webkit.org/show_bug.cgi?id=83048 However I do think we need a decision on how we: 1. Land fixes for currently broken tests that don't have a reftest. 2. Clean up the existing css2.1/20110323 folder. If it's just a case of living with pixel results for now I'm happy with that. But I think allowing them to live outside css2.1/20110323 would encourage me and others to write reftests while we're fixing the tests' results on WebKit. From listening to Maciej, Ojan and Ryosuke it is not an option to keep homebrew reftests in css2.1/20110323 for two good reasons: it breaks important assumptions in the way the reftest harness works, and it is better to keep imported test suites clean and unmodified. So it's either 1 or 2 above I think. I would prefer 2 as it won't bloat git checkouts so much and will make fixes easier to land. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS 2.1 Test Suite
On Tuesday 10 April 2012 22:35:13 Ryosuke Niwa wrote: As we have previous discussed following https://lists.webkit.org/pipermail/webkit-dev/2012-March/019782.html, it's hard to judge whether a given reference result is enough to cover everything the test intends to test. e.g. you can have a bug such that both the test and the reference file ends up having the same rendering result. Definitely - and this will certainly be the case with some of the css tests, but a minority. A *lot* of them are along the lines of 'this text/box is green'. For the tests we write to fix failing CSS tests this will definitely be something to watch out for in review. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS 2.1 Test Suite
On Wednesday 11 April 2012 20:27:23 Dirk Pranke wrote: What does clean up the existing folder entail? Just move any -expected.html file out of there and generate pixel results. Or move the test and its -expected.html into a folder in fast/css. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] importing test suites (was: CSS 2.1 Test Suite)
On Wednesday 11 April 2012 23:29:56 Dirk Pranke wrote: 1) What is the best way to add these tests to the tree? Should we add them one-at-a-time with -expected files that we have created? Should we add them all at once and SKIP the tests until we have generated -expected results for each test? Or should we only import subsets that have official -expected files? Here is a good example of this in action: http://trac.webkit.org/changeset/113076 The tests all come unmodified from the CSS test suite, the -expected.html files were created by me. The CSS test suite does not used the -expected.html semantic. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CSS 2.1 Test Suite
Hi there, We currently add tests from the CSS 2.1 suite as we fix them. They get added to the css2.1/20110323 folder in LayoutTests. Most of them don't have native reference tests yet in the suite so we (mostly I) have been adding homebrew reference results to the folder to avoid generating pixel results on all platforms. (see http://webkitmemes.tumblr.com/post/20788159625 !) These reference-results are easily removed once superseded but it might be cleaner just to move them, and the associated css tests, to a folder of their own in fast/css. That will allow css2.1/20110323 to be a clean import that the 8500 or so passing tests can be added to in 20 or 30 batches.[1] It will also make NRWT's reftests harness work with the suite. Does anyone object to that approach? The only thing going against it seems to be the principle that imported tests should be stored separately and together but this is more a case of using them to fix bugs and prevent future regressions while allowing a clean import of the CSS 2.1 test suite to take place in parallel. The problem this does not solve is how we avoid creating pixel results for tests that already pass but which do not have reftests of their own. Again I would be in favour of putting these in fast/css and keeping them there until reftests are added to the suite. This would allow us to prevent them regressing and come up with a reftest for them that can be submitted to the CSS test suite guys. The end result would be that we only directly import to the css2.1 folder those tests in the CSS test suite that have ref tests native to the suite. Thanks, Robert [1] I keep a local and relatively up to date copy of the passing and failing tests in separate folders in my checkout. Yes I know I should create bugs for them and get started on landing the passes. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)
On Monday 09 April 2012 22:42:33 Dirk Pranke wrote: Hi all, Recently I've noticed more people making changes and adding test failure suppressions to various ports' test_expectations.txt files. This is great! Hi Dirk, It would be good to have a page describing the right thing to do for each of the ports for each of the following situations: - Adding a new test with rendtree/pixel results - Changing the rendtree/pixel results for existing tests I think the correct practice will differ between ports as only the Chromium bots (AFAIK) check pixel results. So this has the unfortunate consquence that when you change the expected pixel result for a test that has pixel results on all platforms you end up with stale png results in the tree for those that you are not in a position either to generate yourself or persuade someone on #webkit to generate for you. Thanks, Robert ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
On Wednesday 14 March 2012 08:44:46 Ashod Nakashian wrote: From: Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de To: WebKit Development webkit-dev@lists.webkit.org Cc: Sent: Wednesday, March 14, 2012 1:31 AM Subject: [webkit-dev] Git/SVN is slow G ood morning WebKit crowd, since at least some weeks, updating git.webkit.org and/or svn.webkit.org is extremely slow for me. I have a git fetch rate below 3KiB/s average - surfing the web and/or downloading anything else is acceptable with my 10MBit connection. I'm located near Cologne, in Germany -- do any other european WebKittens suffer from the same problems? It has always been pretty slow for me too (Ireland), occasionally as bad as you describe but more often in the 80-100KiB/s average. Thanks for sharing the chromium mirror tip. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] does anyone use the advanced --print options to new-run-webkit-tests besides me?
On Wednesday 25 January 2012 21:09:35 Dirk Pranke wrote: On Wed, Jan 25, 2012 at 11:20 AM, Robert Hogan rob...@roberthogan.net wrote: On Wednesday 25 January 2012 07:38:07 Ryosuke Niwa wrote: On somewhat related note, can we simplify the output of new-run-webkit-tests on bots? It's way too noisy as is. Maybe hide all DEBUG information? It would be nice if there was a separate output containing just the results summary. This often differs from the contents of results.html. And since the bots seem to be hammered most of the day, retrieving the output for just the summary can be painful. When you say the results summary, what specifically are you referring to? I'm guessing something along the lines of what gets printed at the end of the run (what you would get with '--print actual,one-line-summary,unexpected-results')? Yes, that's it in a nutshell! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] API for Handling Browser Fingerprinting
Hi, I am trying to build a set of requirements for an anti-fingerprinting API in WebKit. I have a wiki page where I've started dumping all the things such an API needs to worry about: https://trac.webkit.org/wiki/Fingerprinting From an implementation point of view I've started by looking at two primary sources for leaking distincitive information about the user: DOM objects and CSS Style sheets. Even though these are hard to solve, by the standards of the other items they are the nearest to low-hanging fruit and the shape of the solution required is relatively straightforward. At the moment, WebKit doesn't offer a dedicated mechanism for managing the information exposed by DOM objects. However it is possible to use something of a side-channel to manage the objects that JSCore does not consider read- only, e.g. Navigator and Screen (since https://bugs.webkit.org/show_bug.cgi?id=41802). In Qt's case, I'm referring to QWebFrame::addToJavaScriptWindowObject(), which allows a client to add a custom object to the DOM and by a happy side-effect also allows you to overload replaceable built-in objects. This approach comes unstuck for read-only objects in JSCore, namely document, window and history. The properties exposed by these objects are mostly stored internally by WebCore or inspected directly from the user's application environment. The same goes for CSS. It seems a good thing, in it's own right, for WebCore to pass this sort of inspection through WebKit so that ports can decide the level of client delegation required, e.g. through FrameLoaderClient or ChromeClient. I've submitted patches for this at: https://bugs.webkit.org/show_bug.cgi?id=56274 (DOM) https://bugs.webkit.org/show_bug.cgi?id=56482 (CSS) Note that I'm talking primarily about a client-facing API rather than a web-facing API that can be used by extensions. This is a product of my own use-case - which is a browser that implements an anti-fingerprinting policy itself. A web-facing API faces inherent problems with sites circumventing it maliciously - see https://www.torproject.org/torbutton/en/design/#jshooks and the links to side-stepping overloading firefox's window object there. I'm not saying this is a problem that exists in WebKit too, but it is a problem to which client-facing API is much less vulnerable. So can you guys give me some feedback on this? Am I going the right way about exposing the user's environment information to the port and client in 56274 and 56482? Thanks, Robert - ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On Thursday 13 January 2011 17:02:15 Alexey Proskuryakov wrote: As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. Could you elaborate on this a bit? I don't understand the potential breakage. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] git and svn out of sync?
Hi, I committed http://trac.webkit.org/changeset/74869 from a git-svn checkout. The change hasn't propagated to git.webkit.org for some reason. My git-svn copy is set up to point directly to refs/remotes/origin/master per the recommendation in: https://trac.webkit.org/wiki/UsingGitWithWebKit#Updating I landed the commit with: Tools/Scripts/webkit-patch --ignore-builders --git-commit=HEAD land and encountered no errors: rob...@mwenge:~/Development/WebKit$ Tools/Scripts/webkit-patch --ignore- builders --git-commit=HEAD land [webkit.py autoinstall messages snipped] Parsing ChangeLog: /home/robert/Development/WebKit/Tools/ChangeLog No bug id provided and --reviewer= not provided. Not updating ChangeLogs with reviewer. Parsing ChangeLog: /home/robert/Development/WebKit/Tools/ChangeLog Committed r74869: http://trac.webkit.org/changeset/74869 Committed r74869: http://trac.webkit.org/changeset/74869 No bug id provided. Hopefully no-one else commits before this becomes too difficult to repair.. Let me know if I can provide any more clues. Thanks, Robert ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git and svn out of sync?
Looks like this was a false alarm. The revision is now in git. It took an awfully long time to sync though. Was there a problem, or does the git repo wait for a minimum number of revisions before sync'ing? On Sunday 02 January 2011 18:47:40 Robert Hogan wrote: Hi, I committed http://trac.webkit.org/changeset/74869 from a git-svn checkout. The change hasn't propagated to git.webkit.org for some reason. My git-svn copy is set up to point directly to refs/remotes/origin/master per the recommendation in: https://trac.webkit.org/wiki/UsingGitWithWebKit#Updating I landed the commit with: Tools/Scripts/webkit-patch --ignore-builders --git-commit=HEAD land and encountered no errors: rob...@mwenge:~/Development/WebKit$ Tools/Scripts/webkit-patch --ignore- builders --git-commit=HEAD land [webkit.py autoinstall messages snipped] Parsing ChangeLog: /home/robert/Development/WebKit/Tools/ChangeLog No bug id provided and --reviewer= not provided. Not updating ChangeLogs with reviewer. Parsing ChangeLog: /home/robert/Development/WebKit/Tools/ChangeLog Committed r74869: http://trac.webkit.org/changeset/74869 Committed r74869: http://trac.webkit.org/changeset/74869 No bug id provided. Hopefully no-one else commits before this becomes too difficult to repair.. Let me know if I can provide any more clues. Thanks, Robert ___ 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] Hunspell based spellchecker
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. The Qt folks on the list can correct me if I'm wrong but this would be very welcome for Qt. I don't see how a WebCore spellchecker could be anything but a good thing! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [56661] trunk
On Monday 29 March 2010 21:16:59 Alexey Proskuryakov wrote: What is an application plugin outside of Qt context? This change will make all port authors scratch their heads trying to understand what they want to return from isApplicationPluginMIMEType(). There was a lot of discussion about this on the bug and the patch initially was quite Qt specific. I tried to reduce the possible head scratching with: // Check to see if a mime type is a plugin implemented by the // browser (e.g. a Qt Plugin). static bool isApplicationPluginMIMEType(const String mimeType); I think it was a toss-up between making the function very specific to Qt (and implemeting it in Qt port's allowPlugins()) and catering for the eventuality that other ports would some day also want to make the same distinction Qt does between first-party and third-party plugins. I think that this should be more obviously Qt-specific. - WBR, Alexey Proskuryakov On 27.03.2010, at 5:46, rob...@webkit.org wrote: Revision 56661 Author rob...@webkit.org Date 2010-03-27 05:46:35 -0700 (Sat, 27 Mar 2010) Log Message 2010-03-26 Robert Hogan rob...@roberthogan.net Reviewed by Simon Hausmann. Allow plugins implemented by the application, such as mimetype 'x-qt-plugin', when pluginsEnabled is false. The purpose of disabling plugins is to prevent the execution of third-party code that may be untrustworthy. Qt plugins are implemented by the client rather than loaded from an external source, so the client should have the opportunity to consider them separately from other plugins. Add a function MimeTypeRegistry::isApplicationPluginMIMEType() that WebKit uses in conjunction with arePluginsEnabled() to determine if it should attempt to load a plugin. If isApplicationPluginMIMEType() returns true, WebKit will load the plugin even if arePluginsEnabled() is false. Currently, only Qt has application-implemented plugins: these use the mimetype 'x-qt-plugin' and 'x-qt-styled-widget'. This patch permits Qt clients' reimplementation of QWebPage::createPlugin() to decide whether or not to create a Qt plugin, even when arePluginsEnabled is false. For all platforms apart from Qt, isApplicationPluginMIMEType() returns false. https://bugs.webkit.org/show_bug.cgi?id=32196 Test: plugins/application-plugin-plugins-disabled.html * loader/FrameLoader.cpp: (WebCore::FrameLoader::requestObject): * platform/MIMETypeRegistry.h: * platform/brew/MIMETypeRegistryBrew.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/chromium/MIMETypeRegistryChromium.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/gtk/MIMETypeRegistryGtk.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/haiku/MIMETypeRegistryHaiku.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/mac/MIMETypeRegistryMac.mm: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/qt/MIMETypeRegistryQt.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/win/MIMETypeRegistryWin.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/wince/MIMETypeRegistryWince.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/wx/MimeTypeRegistryWx.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): 2010-03-26 Robert Hogan rob...@roberthogan.net Reviewed by Simon Hausmann. Allow plugins implemented by the application, such as mimetype 'x-qt-plugin', when pluginsEnabled is false. For all platforms apart from Qt, isApplicationPluginMIMEType() returns false. https://bugs.webkit.org/show_bug.cgi?id=32196 * platform/qt/plugins/application-plugin-plugins-disabled- expected.txt: Added. * plugins/application-plugin-plugins-disabled-expected.txt: Added. * plugins/application-plugin-plugins-disabled.html: Added. 2010-03-26 Robert Hogan rob...@roberthogan.net Reviewed by Simon Hausmann. Allow plugins implemented by the application, such as mimetype 'x-qt-plugin', when pluginsEnabled is false. Add support for LayoutTestController.WebKitPluginsEnabled https://bugs.webkit.org/show_bug.cgi?id=32196 * DumpRenderTree/gtk/DumpRenderTree.cpp: (resetDefaultsToConsistentValues): * DumpRenderTree/gtk/LayoutTestControllerGtk.cpp: (copyWebSettingKey): * DumpRenderTree/qt/DumpRenderTreeQt.cpp: (WebCore::WebPage
Re: [webkit-dev] [webkit-changes] [56661] trunk
On Monday 29 March 2010 21:28:15 Adam Barth wrote: I think this change is wrong. We should just pass the mime type along with the allowPlugins call and let the client decide what to do instead of teaching WebCore about some client-level concept. Adam OK. I'll roll it out and make the rule specific to the Qt port unless someone shouts stop! Thanks, Robert On Mon, Mar 29, 2010 at 1:16 PM, Alexey Proskuryakov a...@webkit.org wrote: What is an application plugin outside of Qt context? This change will make all port authors scratch their heads trying to understand what they want to return from isApplicationPluginMIMEType(). I think that this should be more obviously Qt-specific. - WBR, Alexey Proskuryakov On 27.03.2010, at 5:46, rob...@webkit.org wrote: revision56661authorrob...@webkit.orgdate2010-03-27 05:46:35 -0700 (Sat, 27 Mar 2010) Log Message 2010-03-26 Robert Hogan rob...@roberthogan.net Reviewed by Simon Hausmann. Allow plugins implemented by the application, such as mimetype 'x-qt-plugin', when pluginsEnabled is false. The purpose of disabling plugins is to prevent the execution of third-party code that may be untrustworthy. Qt plugins are implemented by the client rather than loaded from an external source, so the client should have the opportunity to consider them separately from other plugins. Add a function MimeTypeRegistry::isApplicationPluginMIMEType() that WebKit uses in conjunction with arePluginsEnabled() to determine if it should attempt to load a plugin. If isApplicationPluginMIMEType() returns true, WebKit will load the plugin even if arePluginsEnabled() is false. Currently, only Qt has application-implemented plugins: these use the mimetype 'x-qt-plugin' and 'x-qt-styled-widget'. This patch permits Qt clients' reimplementation of QWebPage::createPlugin() to decide whether or not to create a Qt plugin, even when arePluginsEnabled is false. For all platforms apart from Qt, isApplicationPluginMIMEType() returns false. https://bugs.webkit.org/show_bug.cgi?id=32196 Test: plugins/application-plugin-plugins-disabled.html * loader/FrameLoader.cpp: (WebCore::FrameLoader::requestObject): * platform/MIMETypeRegistry.h: * platform/brew/MIMETypeRegistryBrew.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/chromium/MIMETypeRegistryChromium.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/gtk/MIMETypeRegistryGtk.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/haiku/MIMETypeRegistryHaiku.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/mac/MIMETypeRegistryMac.mm: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/qt/MIMETypeRegistryQt.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/win/MIMETypeRegistryWin.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/wince/MIMETypeRegistryWince.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): * platform/wx/MimeTypeRegistryWx.cpp: (WebCore::MIMETypeRegistry::isApplicationPluginMIMEType): 2010-03-26 Robert Hogan rob...@roberthogan.net Reviewed by Simon Hausmann. Allow plugins implemented by the application, such as mimetype 'x-qt-plugin', when pluginsEnabled is false. For all platforms apart from Qt, isApplicationPluginMIMEType() returns false. https://bugs.webkit.org/show_bug.cgi?id=32196 * platform/qt/plugins/application-plugin-plugins-disabled-expected.txt: Added. * plugins/application-plugin-plugins-disabled-expected.txt: Added. * plugins/application-plugin-plugins-disabled.html: Added. 2010-03-26 Robert Hogan rob...@roberthogan.net Reviewed by Simon Hausmann. Allow plugins implemented by the application, such as mimetype 'x-qt-plugin', when pluginsEnabled is false. Add support for LayoutTestController.WebKitPluginsEnabled https://bugs.webkit.org/show_bug.cgi?id=32196 * DumpRenderTree/gtk/DumpRenderTree.cpp: (resetDefaultsToConsistentValues): * DumpRenderTree/gtk/LayoutTestControllerGtk.cpp: (copyWebSettingKey): * DumpRenderTree/qt/DumpRenderTreeQt.cpp: (WebCore::WebPage::resetSettings): * DumpRenderTree/qt/LayoutTestControllerQt.cpp: (LayoutTestController::overridePreference): Modified Paths trunk/LayoutTests/ChangeLog trunk/WebCore/ChangeLog trunk/WebCore/loader
[webkit-dev] [QtWebKit] exposing JScript Objects to Clients
Hi there,
At the moment WebKit does not deliberately expose any of the properties of
Javascript objects to clients. Those it does expose seem to be as much by
luck as anything else. One example is navigator.useragent, which in Qt's
case ultimately returns whatever the client has set in userAgentForUrl().
The more common case is illustrated by the other properties of the
navigator object. Here is the return value for navigator.appname as defined
in NavigatorBase.cpp:
String NavigatorBase::appName() const
{
return Netscape;
}
I would like to make it possible for the client to control the values
returned by JS objects - this is so that my project (http://torora.net) can
ensure that the anonymity set of torora's users is properly preserved. For
example, Torora would always ensure that the value returned for
navigator.platform would be 'WinXP' (regardless of the user's actual OS).
This would protect the user from a website collating information on a user
and possibly uniquely identifying them.[1]
The only way I can think of providing this API is as follows (taking the
navigator object as an example):
1. Copy WebCore/page/Navigator.cpp to WebCore/page/qt/NavigatorQt.cpp and
exclude Navigator.cpp from the Qt build.
2. In NavigatorQt.cpp implement the return values by calling virtual
functions in QWebPage. Following the example of userAgentForUrl() this
would take the form of:
String NavigatorBase::appName() const
{
String appName = m_frame-loader()-appName();
if (appName.isEmpty())
return NavigatorBase::appName();
return appName;
}
which calls:
String FrameLoaderClientQt::appName()
{
if (m_webFrame) {
return m_webFrame-page()-appName();
}
return String();
}
where page()-AppName() is a virtual function in QWebPage that returns an
empty string if it is not reimplemented by the client.
3. NavigatorQt.cpp would have to do this for all elements of the navigator
object that it wanted to offer for client control.
The same approach would have to be used for the date, screen and window
objects, though in the case of Torora there are other ways of ensuring
those values do not give away anything so my only actual requirement at the
moment is to control the navigator object,
I see a couple of disadvantages to this approach:
1. Likely performance hit.
2. Customized implementations of functions in the qt/ folder of the
WebCore/page directory are for functions not implemented at all in the base
code, rather than for replacing the ones that are.
3. It's a very cumbersome way of doing things.
A proper hooking mechanism (where clients could control all javascript
objects) for javascript would seem to require a major overhaul to
webcore/javascriptcore, and I have no idea how it would work or even if it
would be possible.
So my questions are:
- Is the above approach acceptable for QtWebKit?
- Is there any effort already underway for a hooking mechanism for jscore?
- Is there an alternative approach anyone can think of?
[1] Torora already does this by providing a patch to webkit when building
from source. The patch crudely overrides existing values with a 'safe' set
of hardcoded values.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
