[webkit-dev] New feature : Network Information API
Title: Samsung Enterprise Portal mySingle Hello WebKit folks, I'd like to introduce new feature - Network Information API. This feature is to provide an interface for Web Applications to access the underlying network information of device. In Web Application case, they need to know what current network interface it uses. Because, it is important to know current network backbone(wifi, 3g, 4G and so on) in mobile domain. Thus, Web Application can let user know whether current network bearer is 3G or wifi via this new functionality. In addition, in streaming service case, Web Application can control content resolution according to kind of network.Spec : http://www.w3.org/TR/netinfo-api/ I file a bug for this feature. Bug 73528. (https://bugs.webkit.org/show_bug.cgi?id=73528). However, submitted patch is still prototype. I will improve the submitted patch according to advices or opinions. Cheers, Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Status of the Inspector client in the Gtk+ WebKit port
Hi, I'd like to ask about the status of the current inspector (WebKitWebInspector) status in the Gtk+ port on the master branch. Is it functional? I got it built, enabled via --enable-developer-extras run-time option and exposed via the embedding API in GtkLauncher, but then all I get is the empty HTML/JS w/ just the grey toolbar when I click on Inspect Item in the contextual menu. Any thoughts? -Ilyes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature : Network Information API
Hi Gyuyoung, This is great news! Can I ask you also to take a look at the editor's draft http://dev.w3.org/2009/dap/netinfo/#connection-interface so that you can keep it in mind as you design the feature, since the draft will at some point likely become the next TR. Cheers John On Thu, Dec 1, 2011 at 9:27 AM, Gyuyoung Kim gyuyoung@samsung.comwrote: Hello WebKit folks, I'd like to introduce new feature - Network Information API. This feature is to provide an interface for Web Applications to access the underlying network information of device. In Web Application case, they need to know what current network interface it uses. Because, it is important to know current network backbone(wifi, 3g, 4G and so on) in mobile domain. Thus, Web Application can let user know whether current network bearer is 3G or wifi via this new functionality. In addition, in streaming service case, Web Application can control content resolution according to kind of network. Spec : http://www.w3.org/TR/netinfo-api/ I file a bug for this feature. Bug 73528. ( https://bugs.webkit.org/show_bug.cgi?id=73528). However, submitted patch is still prototype. I will improve the submitted patch according to advices or opinions. Cheers, Gyuyoung. ___ 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] New feature : Network Information API
Title: Samsung Enterprise Portal mySingle Hello John, Yes, I already made a prototype patch based on the editor's draft. Current patch should be improved further further. I will submit new patch soon. Cheers, Gyuyoung. --- Original Message --- Sender : John Knottenbeltjknot...@chromium.org Date : 2011-12-01 19:22 (GMT+09:00) Title : Re: [webkit-dev] New feature : Network Information API HiGyuyoung, This is great news! Can I ask you also to take a look at the editor's drafthttp://dev.w3.org/2009/dap/netinfo/#connection-interfaceso that you can keep it in mind as you design the feature, since the draft will at some point likely become the next TR. Cheers John On Thu, Dec 1, 2011 at 9:27 AM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hello WebKit folks, I'd like to introduce new feature - Network Information API. This feature is to provide an interface for Web Applications to access the underlying network information of device. In Web Application case, they need to know what current network interface it uses. Because, it is important to know current network backbone(wifi, 3g, 4G and so on) in mobile domain. Thus, Web Application can let user know whether current network bearer is 3G or wifi via this new functionality. In addition, in streaming service case, Web Application can control content resolution according to kind of network.Spec : http://www.w3.org/TR/netinfo-api/ I file a bug for this feature. Bug 73528. (https://bugs.webkit.org/show_bug.cgi?id=73528). However, submitted patch is still prototype. I will improve the submitted patch according to advices or opinions. Cheers, Gyuyoung. ___webkit-dev mailing listwebkit-dev@lists.webkit.orghttp://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] Status of the Inspector client in the Gtk+ WebKit port
Hi Martin, Have you run 'make install' or set the WEBKIT_INSPECTOR_PATH environment variable? Yes. I understand that the inspector's JS and HTML files are post-processed and then installed in the final destination location. I'm getting (just) this on my shell: ** Message: console message: undefined @0: TypeError: 'undefined' is not a function Running the inspector w/o a 'make install' resulted in WebKit complaining about not finding the sources in the right place. Running the unprocessed code lead to few - kind of - fatal errors when trying to run the inspector's JS back-end code. Why I'm not getting the full UI of the inspector (the icons) at least? -Ilyes On Thu, Dec 1, 2011 at 11:02 AM, Martin Robinson mrobin...@webkit.org wrote: On Thu, Dec 1, 2011 at 10:53 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: I got it built, enabled via --enable-developer-extras run-time option and exposed via the embedding API in GtkLauncher, but then all I get is the empty HTML/JS w/ just the grey toolbar when I click on Inspect Item in the contextual menu. Have you run 'make install' or set the WEBKIT_INSPECTOR_PATH environment variable? --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using C++ constant local variables in WebKit
On Thu, Dec 1, 2011 at 4:26 AM, Ojan Vafai o...@chromium.org wrote: I don't mind using const in some cases, but I share Darin's concern of littering the code with consts. I'd prefer that we come up with a fairly conservative guideline about when to use it. I'm not sure what that would look like. We could start with, what's special about this case, or string parsing in general that makes using const more valuable? Littering the code with anything is bad. Has misuse of consts been a significant practical problem? Perhaps we don't need a specific rule here. antti ___ 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] Status of the Inspector client in the Gtk+ WebKit port
Hi, My bad. I'm so used to build WebKit with most build options disabled. Reverted to a default build configuration and it indeed looks good. Thanks, -Ilyes On Thu, Dec 1, 2011 at 2:35 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi Martin, Have you run 'make install' or set the WEBKIT_INSPECTOR_PATH environment variable? Yes. I understand that the inspector's JS and HTML files are post-processed and then installed in the final destination location. I'm getting (just) this on my shell: ** Message: console message: undefined @0: TypeError: 'undefined' is not a function Running the inspector w/o a 'make install' resulted in WebKit complaining about not finding the sources in the right place. Running the unprocessed code lead to few - kind of - fatal errors when trying to run the inspector's JS back-end code. Why I'm not getting the full UI of the inspector (the icons) at least? -Ilyes On Thu, Dec 1, 2011 at 11:02 AM, Martin Robinson mrobin...@webkit.org wrote: On Thu, Dec 1, 2011 at 10:53 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: I got it built, enabled via --enable-developer-extras run-time option and exposed via the embedding API in GtkLauncher, but then all I get is the empty HTML/JS w/ just the grey toolbar when I click on Inspect Item in the contextual menu. Have you run 'make install' or set the WEBKIT_INSPECTOR_PATH environment variable? --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style bot complains of missing binary data in diff when deleting .png test results
The change you suggest for VCSUtils.pm seems fine to me, but if you use 'webkit-patch upload', it'll generate a diff that svn-apply can successfully apply. On Wed, Nov 30, 2011 at 5:42 PM, Alan Stearns stea...@adobe.com wrote: David, This is a bug where I accidentally turned on a pixel result, then needed to remove the .pngs when I fixed the problem: https://bugs.webkit.org/show_bug.cgi?id=73343 The patch had two lines like this: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ Which resulted in this output from style-queue: Failed to run [u'/mnt/git/webkit-style-queue/Tools/Scripts/svn-apply', u'--force'] exit_code: 9 Error: the Git diff contains a binary file without the binary data in line: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ. Be sure to use the --binary flag when invoking git diff with diffs containing binary files. at /mnt/git/webkit-style-queue/Tools/Scripts/VCSUtils.pm line 667, ARGV line 45. Thanks, Alan On 11/30/11 5:36 PM, David Levin le...@chromium.org wrote: Perhaps you could give a bug that has an example of what you are talking about. For me it is hard to guess at what the complaint by the style bot is. dave On Wed, Nov 30, 2011 at 5:20 PM, Alan Stearns stea...@adobe.com wrote: If I delete a .png test result and I make a git diff without using the --binary flag, the style EWS bot complains. I can see why it would complain if I were rebasing the file - you need the binary data to see what's changed. It makes less sense to me to add the binary data to the diff if the file is just being deleted. Should VCSUtils.pm detect a ... and /dev/null differ line and let it through? Are there dependencies on the binary data in svn-apply or other tools? I'm planning on replacing some pixel-based verification with reftests in the near future, and so I'll be deleting quite a few .png files. I don't mind slinging around all that binary data, but if it's not really needed I'd rather leave it out. Thanks, Alan ___ 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] Using C++ constant local variables in WebKit
On Thu, Dec 1, 2011 at 6:49 AM, Antti Koivisto koivi...@iki.fi wrote: On Thu, Dec 1, 2011 at 4:26 AM, Ojan Vafai o...@chromium.org wrote: I don't mind using const in some cases, but I share Darin's concern of littering the code with consts. I'd prefer that we come up with a fairly conservative guideline about when to use it. I'm not sure what that would look like. We could start with, what's special about this case, or string parsing in general that makes using const more valuable? Littering the code with anything is bad. Has misuse of consts been a significant practical problem? Perhaps we don't need a specific rule here. I guess not. My real problem is that I don't have a good sense of cases where it makes sense to use const with local variable, so it's hard for me to review patches that add it. But maybe you're right, if it is uses rarely enough, it's not worth the effort of coming up with a guideline. antti ___ 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] Using C++ constant local variables in WebKit
On Thu, Dec 1, 2011 at 10:48 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Dec 1, 2011 at 6:49 AM, Antti Koivisto koivi...@iki.fi wrote: On Thu, Dec 1, 2011 at 4:26 AM, Ojan Vafai o...@chromium.org wrote: I don't mind using const in some cases, but I share Darin's concern of littering the code with consts. I'd prefer that we come up with a fairly conservative guideline about when to use it. I'm not sure what that would look like. We could start with, what's special about this case, or string parsing in general that makes using const more valuable? Littering the code with anything is bad. Has misuse of consts been a significant practical problem? Perhaps we don't need a specific rule here. I guess not. My real problem is that I don't have a good sense of cases where it makes sense to use const with local variable, so it's hard for me to review patches that add it. A good rule of thumb is when a local variable is never assigned of new value other than initialization, the constness of the variable is hard to see in the code, and some other code depends on that fact, and ; i.e. there is an assumption that the variable's value never changes. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [GTK] Buildslave changes
The bot is now deployed and so far, working well :) Thanks Adam for the help! Philippe On Wed, 2011-11-30 at 17:03 -0500, Adam Roben wrote: On Nov 30, 2011, at 4:34 PM, Philippe Normand wrote: Can we get new buildbot credentials for the new slave or can we reuse the 32-bits Debug ones? It'd be great if we can coordinate on this migration soon :) Credentials are a slave name/password pair. If you're using the old slave name for the new machine then you should use the old password too. If you're adding a new slave name, you should post a patch to bugs.webkit.org to do so and CC me. Once the patch lands I'll update the master and send you a password. -Adam signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] query on eventsender
On Nov 22, 2011, at 2:35 AM, Antaryami Pandia wrote: Can eventsender be used to send click events on options of a drop down combo box? No. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] naming conventions for reftests and the w3c test suites
Hi all, You may be aware that some people are working on getting w3c-style reftests to work in our infrastructure (using new-run-webkit-tests). The few existing reftests we have follow a naming convention of testname-expected.html or testname-expected-mismatch.html. This makes it easy to determine by looking at a directory which files are tests (vs. expected output or references only), and also which tests are reftests as opposed to tests that have baselines or reference output. The W3C is recommending (at least in the CSS WG) that reference files that are not themselves tests should be named as testname-ref.html (or the appropriate extension); test files can also live in a reftest subdirectory. (*) One can debate the various naming conventions; I don't particularly care what they are as long as they are something consistent, obvious, and easily automated. However, the naming conventions are currently not normative; they are a should rather than a must. I think the should should be changed to a must, and I'd like to ask this of the testing WG with the WebKit community's endorsement. Any one object to this or have other thoughts? -- Dirk (*) Note that it is acceptable for tests to use other tests as references, though, so not all reference files will end in -ref.html, so at least at the moment you can't tell that a file that doesn't end in -ref.html isn't both a test and a reference. See http://wiki.csswg.org/test/reftest#the-reftest-reference for more. It would also be good to allow for a -notref.html for expected mismatches; I'm not sure that that is explicitly standardized, but it should be. Once we establish a standard, it would also make sense to rename our existing reftests. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] naming conventions for reftests and the w3c test suites
Do we know if Mozilla's test suite follow such a convention? Given we already have tables/mozilla, there appears be an interest to import some Mozilla tests to WebKit. e.g. I'm planning to import Mozilla's reftests for unicode-bidi: isolate / plaintext as well. If their test suite don't follow such a convention, I'm not certain if there's a much benefit in asking this. Furthermore, if we expect there will be only few reference files that don't start with ref-, notref-, don't ends with -ref.*, -notref.* and are not in a subdirectory of a directory named either reference and reftest, then we can treat all those files as traditional pixel tests. - Ryosuke On Thu, Dec 1, 2011 at 1:58 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, You may be aware that some people are working on getting w3c-style reftests to work in our infrastructure (using new-run-webkit-tests). The few existing reftests we have follow a naming convention of testname-expected.html or testname-expected-mismatch.html. This makes it easy to determine by looking at a directory which files are tests (vs. expected output or references only), and also which tests are reftests as opposed to tests that have baselines or reference output. The W3C is recommending (at least in the CSS WG) that reference files that are not themselves tests should be named as testname-ref.html (or the appropriate extension); test files can also live in a reftest subdirectory. (*) One can debate the various naming conventions; I don't particularly care what they are as long as they are something consistent, obvious, and easily automated. However, the naming conventions are currently not normative; they are a should rather than a must. I think the should should be changed to a must, and I'd like to ask this of the testing WG with the WebKit community's endorsement. Any one object to this or have other thoughts? -- Dirk (*) Note that it is acceptable for tests to use other tests as references, though, so not all reference files will end in -ref.html, so at least at the moment you can't tell that a file that doesn't end in -ref.html isn't both a test and a reference. See http://wiki.csswg.org/test/reftest#the-reftest-reference for more. It would also be good to allow for a -notref.html for expected mismatches; I'm not sure that that is explicitly standardized, but it should be. Once we establish a standard, it would also make sense to rename our existing reftests. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] naming conventions for reftests and the w3c test suites
On Thu, Dec 1, 2011 at 2:08 PM, Ryosuke Niwa rn...@webkit.org wrote: Do we know if Mozilla's test suite follow such a convention? Given we already have tables/mozilla, there appears be an interest to import some Mozilla tests to WebKit. e.g. I'm planning to import Mozilla's reftests for unicode-bidi: isolate / plaintext as well. If their test suite don't follow such a convention, I'm not certain if there's a much benefit in asking this. It still seems useful to me; if the W3C establishes a standard, then it may be that we can also get Mozilla to adopt it. Furthermore, if we expect there will be only few reference files that don't start with ref-, notref-, don't ends with -ref.*, -notref.* and are not in a subdirectory of a directory named either reference and reftest, then we can treat all those files as traditional pixel tests. That's true, we could. However, allowing much flexibility here just seems like unnecessary complexity and I'd prefer to avoid it. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [gtk] OpenGL headers are not listed as a dependency
I followed this instruction http://trac.webkit.org/wiki/BuildingGtk and I've got a configure error: GL/gl.h not found. When I installed mesa-common-dev, linker said it cannot find -lGL Is something wrong with my distribution? I'm running Ubuntu 11.10. Or I should install opengl package or something? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [gtk] OpenGL headers are not listed as a dependency
Got it working by installing these packages: libgl1-mesa-glx libgl1-mesa-dev Probably, It should've been written in the instruction. On 2 December 2011 01:30, John Yani van...@gmail.com wrote: I followed this instruction http://trac.webkit.org/wiki/BuildingGtk and I've got a configure error: GL/gl.h not found. When I installed mesa-common-dev, linker said it cannot find -lGL Is something wrong with my distribution? I'm running Ubuntu 11.10. Or I should install opengl package or something? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] naming conventions for reftests and the w3c test suites
I've talked with plinss on IRC and confirmed that we can assume any files that do not match either one of the following criteria as tests: - Not in a subdirectory of a directory named support, reference, or reftest - Filename doesn't start with ref- or notref- - Filename doesn't end with -ref.* or -nonref.* i.e. we're okay as long as someone adds new tests that violates this convention. In fact, he told me that this convention is MUST. Every new non-test reference file MUST end with ref- or nonref-. Apparently it's not worded properly on the said page. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EWS bots don't run when missing binary data in diff [was Re: Style bot complains of missing binary data in diff when deleting .png test results]
On Wed, Nov 30, 2011 at 5:46 PM, David Levin le...@chromium.org wrote: On Wed, Nov 30, 2011 at 5:42 PM, Alan Stearns stea...@adobe.com wrote: This is a bug where I accidentally turned on a pixel result, then needed to remove the .pngs when I fixed the problem: https://bugs.webkit.org/show_bug.cgi?id=73343 The patch had two lines like this: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ Which resulted in this output from style-queue: Failed to run [u'/mnt/git/webkit-style-queue/Tools/Scripts/svn-apply', u'--force'] exit_code: 9 Error: the Git diff contains a binary file without the binary data in line: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ. Be sure to use the --binary flag when invoking git diff with diffs containing binary files. at /mnt/git/webkit-style-queue/Tools/Scripts/VCSUtils.pm line 667, ARGV line 45. Ah, your issue is with how the patch is applied and that it fails and it causes the style bot to fail. This seems like a general EWS issue. It would be good to run the builds run for your patch as well even though you didn't have the binary in there. Yeah, the issue is slightly subtle because we don't want to run the tests without the binary test data. However, for the style and build-only bots, that makes a lot of sense. We'll probably need to do some Perl hacking to teach svn-apply not to error out in these cases. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
