[webkit-dev] js-test-(pre|post).js in http tests
Any particular reason we aren't using js-test-pre and js-test-post harness code in our http tests, other than the fact that it's additional http resources loaded per test? I could spend a year improving our current tests; they are completely fugly. Thanks, Jarred ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js-test-(pre|post).js in http tests
Which tests are you referring to? I've certainly written HTTP tests that use the JS test harness, e.g., http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/filesystem/resolve-uri.html. Note the resources are in fact copied to a special '/js-test-resources/' directory to make them accessible via HTTP. - Adam On Mon, Dec 19, 2011 at 7:08 AM, Jarred Nicholls jar...@webkit.org wrote: Any particular reason we aren't using js-test-pre and js-test-post harness code in our http tests, other than the fact that it's additional http resources loaded per test? I could spend a year improving our current tests; they are completely fugly. Thanks, Jarred ___ 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] js-test-(pre|post).js in http tests
On Mon, Dec 19, 2011 at 1:57 PM, Adam Klein ad...@chromium.org wrote: Which tests are you referring to? I've certainly written HTTP tests that use the JS test harness, e.g., http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/filesystem/resolve-uri.html. Note the resources are in fact copied to a special '/js-test-resources/' directory to make them accessible via HTTP. Ahh beautiful, I was unaware the resources were copied to an accessible path prior to the test run. A did a physical search for the files and a poor grep for their potential use in http/tests. Thanks Adam for the tip! - Adam On Mon, Dec 19, 2011 at 7:08 AM, Jarred Nicholls jar...@webkit.orgwrote: Any particular reason we aren't using js-test-pre and js-test-post harness code in our http tests, other than the fact that it's additional http resources loaded per test? I could spend a year improving our current tests; they are completely fugly. Thanks, Jarred ___ 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] Tending to moderator requests
Sorry for the upcoming flood of old webkit.org email. I'm tending to old moderator requests. - Adele ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Dropping support for WML?
I am Sorry for my previous email. My internal signature was included in the email. Please ignore the signature. Kent, do you make a bug for your suggestion ? - gyuyoung I think it's ok to keep WML code if we can avoid the form control issue. We can terminate the form control abstraction for HTML and WML. e.g. - Merge dom/InputElement to html/HTMLInputElement - Merge dom/InputElement to wml/WMLInputElement - Remove dom/InputElement - Copy RenderTextControlSingleLine as RenderTextControlWML - RenderTextControlSingleLine only supports HTMLInputElement - RenderTextControlWML only supports WMLInputElement We would have some duplicated code. But it would be better than the current situation. ___ 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] Support for EFL port of WebKit2
Hello Webkit Developers, In parallel to the active support of WebKit EFL port, on behalf of Samsung platform team, I would like to announce that Samsung will make the best effort to build up the WebKit2 EFL port. Samsung wanna work with WebKit2 maintainers closely for the improvement of WebKit2 project. Bug 61838 - [EFL][WK2] Support for EFL port of WebKit2 (https://bugs.webkit.org/show_bug.cgi?id=61838) ought to be used to manage all bugs related to EFL port of Webkit2. Regards, Gyuyoung Kim ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compiling chromium webkit unit tests on Mac
bcc: both lists. Please avoid cross-posting to such wide lists -- trust me, you don't really want ensuing conversation insanity. Also, build-webkit --chromium will produce the unit tests binary. :DG On Wed, Oct 12, 2011 at 10:31 AM, Fady Samuel fsam...@chromium.org wrote: Hi all, I apologize for sending this out to such a broad audience, but I'd like to know how to compile the chromium webkit unit tests on Mac? I tried this: xcodebuild -project third_party/WebKit/Source/WebKit/chromium/WebKit.xcodeproj -configuration Debug -target webkit_unit_tests It complains about a missing libskia. How do I build skia then? Or is there a better way to build the unit tests? Thanks, Fady ___ 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] Remote Debugging v8 - Android
Hi, Jose. Our team had implemented the remote debugging feature on our custom Android port. This[1] is a brief article about that. I hope it helps you. (It is under development, so you cannot get the code yet) Thanks, Young Han. [1] http://dev.dorothybrowser.com/2011/07/27/131175732.html On Thu, Jul 7, 2011 at 3:46 PM, JOSE MANUEL CANTERA FONSECA j...@tid.eswrote: Hi there, ** ** I have two technical questions concerning the Webkit Remote Debugging Protocol. ** ** a/ What is the difference / relationship between this protocol and the v8 remote debugging capabilities? ** ** b/ How this protocol could be enabled for an Android device? ** ** all the best ** ** thanks ** ** -- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ___ 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] Question of new mailing list for WebKit EFL port
Hello Eric, As you may be aware of it, recently, many webkit efl contributors are submitting EFL patches to Bugzilla. So, In my opinion, it may be the time to have any system to share webkit efl news with EFL developers. Some significant patches need to be notified to all EFL developers, and moreover we sometimes have to share any news or notifications related to EFL with them. For example, - any notification related with removal of existing API. - any notification related with adding of new API and as well as coding style newly added and so on. If we will have *webkit-efl* mailing list like other port, It would be very useful for efl developers and it can be used as communication channel before we submit any big change into webkit bugzilla. But, unfortunately, I don't know the way to make mailing list yet. So, I would like to get your help, Shall I know how to make it or who is responsible for it ? Thank you, Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remote Debugging v8 - Android
Hi, Jose. Our team had implemented the remote debugging feature on our custom Android port. This[1] is a brief article about that. I hope it will be helpful. (It is under development, so you cannot get the code yet) Regards, Young Han. [1] http://dev.dorothybrowser.com/2011/07/27/131175732.html On Thu, Jul 7, 2011 at 3:46 PM, JOSE MANUEL CANTERA FONSECA j...@tid.eswrote: Hi there, ** ** I have two technical questions concerning the Webkit Remote Debugging Protocol. ** ** a/ What is the difference / relationship between this protocol and the v8 remote debugging capabilities? ** ** b/ How this protocol could be enabled for an Android device? ** ** all the best ** ** thanks ** ** -- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ___ 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] gmail.com is not loaded through winlauncher
Hi, I am trying to load gmail.com from winLauncher but this page is not loaded. but when I try to load google.com it's load successfully. Is there any setting variable , I need to set? Please help me. Thanks, Moumita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [W3C AR CG] start of the Augmented Reality Web discussion
Hello Communities! Welcome to the recently launched W3C AR Community Group http://www.w3.org/community/ar/ that is gathering the discussions that we'll try to organize and forward to all the related Communities that could be interested in a described objectives and Augmented Reality, at a whole. The topic subject is meant to stay the same, so i hope - there would not be a cross-posting storm. I propose all the interested in organizational help for W3C AR Web, to join the http://lists.w3.org/Archives/Public/public-ar/ mailing list and create the relevant topics along with the participation in all of the tools of proposed W3C CG platform. Response to this digest particularly - could nicely fit in the native public...@w3.org topic with the same subject. Please, excuse me for cross-posting whenever. - Rob Manson said: I'm not sure where the discussion around defining a specific implementation comes from. Personally, I've never proposed that in any way and the points both Blair and Thomas make about this seem logical and obvious to me so +1 to that. If this is because of the initial description of the W3C AR Community Group then that's really just an artefact of the setup process and I think we should refine this to match exactly the points that have been raised. As for an all encompassing Web AR standard...or any standard coming out of the W3C AR Community Group...I don't think this is the goal for these Community Groups at all. They are not Working Groups. As far as I'm aware they're a new tool for the W3C to encourage broader engagement with specific communities of interest. However, I do think there is a lot of benefit to having a specific W3C Community Group focused on AR that can help draw a consistent thread through all the other Web Standards that are being defined. From my experience each of the Working Groups are very busy and often get caught within their own silo of thinking. Giving AR a clearly defined voice within the W3C and helping it engage with the broader community just seems like a good idea to me. I would hope that this would be a perfect fit for the Argon project and any other similar projects. Thomas Wrobel said: Id just point out, if you are focusing on Web-based AR, that thats an AR browser implementation solution - so you shouldn't also cover the standard for the data itself, as they are two very different things*. (Just as HTML specification specifies how html code should be displayed - it doesn't say what languages and technology's the browser should use to do that. Browsers can thus be coded in many languages, and use all sorts of techniques to display the same results. AR browsers should be the exact same). The discussion of the data standard and code to display that standard are thus two separate discussions, and the goal should be quite explicit on which it aims to do. My reply in-line and else: The discussion of the data standard and code to display that standard are thus two separate discussions, and the goal should be quite explicit on which it aims to do. What I have learned from the situation of ancient and newer browser wars is - Competition is a must. - Interoperability that comes from never-ending Standardization is a must. - Open Source is a way that works considerably well and often - better for the Web Browsers For example - compare the W3C standards, implementation rate in closed source browsers and in open sourced -- that is, among other, due to a simple and obvious complexity of implementation and relevance of some recommendations to a small, and by this, not always considerable parts of Internet society. Moreover - even the largest Open Source projects doesn't comply to many of the W3C recommendations. Of-course it is a complex process with a complex products, don't get me wrong -- i don't say that some W3CanonicalBrowser could have done it better. But it worse a thoughtful consideration that the developers of these user-agents are actually - the most active contributors to the whole Web process involving W3C and other SDO's or kinds. Even more, in the scope of the proposed and approved testing, experimentation, and implementation among other - are the actually these meanings for the creation of Open AR Web platform, by that - AR Web Browser. Emerging, first line standards that we may consider for W3C standardized AR Web, like WebCL, WebGL, other Khronos web and these AR Web related like -- all This Communities are successfully enlisting and/or discussing -- most of them require an open sourced browser to, actually, implement, test, evaluate the AR Web. I don't see, how this Community Group could productively and openly work for native WebGL or WebRTC implementations, for example, without an actual work with the Open Source code. +1 for Argon (http://argonbrowser.org/) especially if https://research.cc.gatech.edu/kharma/ , http://www.augmentedenvironments.org/lab/ and other relevant groups would
Re: [webkit-dev] new APIs for strokes with dash in Canvas
I spent some time trying to find it, but couldn't. This bugzilla seems to be the only place we can get information at the moment. https://bugzilla.mozilla.org/show_bug.cgi?id=662038 On Fri, Sep 23, 2011 at 1:44 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 22 Sep 2011, Darin Fisher wrote: Do you know if anyone is working to add this to the spec for Canvas? It seems like it may not take much to get it added, given that FF already has an implementation. Dashed lines are on my list but were not a high priority. If there are implementations then I'm happy to add it -- the only reason I hadn't added it is because the moment I add anything to canvas, everyone implements it, dropping whatever else they were working on, and so if I keep adding canvas features nothing else gets done... :-) Is there any documentation on how this patch and Gecko's implementation work and what they support? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js-test-(pre|post).js in http tests
19.12.2011, в 7:08, Jarred Nicholls написал(а): I could spend a year improving our current tests; they are completely fugly. Generally speaking, I think that it's not worth it making existing tests pretty for the sake of prettiness or even consistency. It is very easy to lose some intended non-obvious properties of tests that way, as well as to lose unintended testing. We certainly don't want to only test HTML and JS code that adheres to WebKit style guide! There are certainly many situations where it makes great sense to rework tests. Making results cross-platform (for example by switching to text-only or to reftests) is something that is always very welcome. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js-test-(pre|post).js in http tests
2011/12/19 Alexey Proskuryakov a...@webkit.org: Generally speaking, I think that it's not worth it making existing tests pretty for the sake of prettiness or even consistency. It is very easy to lose some intended non-obvious properties of tests that way, as well as to lose unintended testing. We certainly don't want to only test HTML and JS code that adheres to WebKit style guide! There are certainly many situations where it makes great sense to rework tests. Making results cross-platform (for example by switching to text-only or to reftests) is something that is always very welcome. I am sure there is plenty of room for improvement. E.g.: -https://bugs.webkit.org/show_bug.cgi?id=71091 (the test did not do anything) -https://bugs.webkit.org/show_bug.cgi?id=70672 (the test was not testing what it was supposed to test) Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js-test-(pre|post).js in http tests
Yes we certainly have many useless/broken tests in the repository. Alexey is correct, that it's difficult to tell when a test is useless however. :) -eric On Mon, Dec 19, 2011 at 6:16 PM, Benjamin Poulain benja...@webkit.org wrote: 2011/12/19 Alexey Proskuryakov a...@webkit.org: Generally speaking, I think that it's not worth it making existing tests pretty for the sake of prettiness or even consistency. It is very easy to lose some intended non-obvious properties of tests that way, as well as to lose unintended testing. We certainly don't want to only test HTML and JS code that adheres to WebKit style guide! There are certainly many situations where it makes great sense to rework tests. Making results cross-platform (for example by switching to text-only or to reftests) is something that is always very welcome. I am sure there is plenty of room for improvement. E.g.: -https://bugs.webkit.org/show_bug.cgi?id=71091 (the test did not do anything) -https://bugs.webkit.org/show_bug.cgi?id=70672 (the test was not testing what it was supposed to test) Benjamin ___ 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
