[webkit-dev] Enable MICRODATA feature by default
I am planning to enable MICRODATA feature by default in WebKit. Microdata master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Microdata spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html Currently we have support for Microdata DOM API's to interacting with microdata using microdata attributes like itemscope, itemtype, itemprop, itemref, itemid through JavaScript. Also we have added support for HTMLPropertiesCollection, PropertyNodeList interfaces to intract with microdata item-properties. As of now, WebKit EFL and Blackberry port has already enabled MICRODATA by default. Mozilla and Opera has also enabled the support for Microdata DOM API. Please let me know your thoughts on the same. Thanks and Regards, Arko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable MICRODATA feature by default
Do we pass tests W3C submitted by Opera Mozilla? - Ryosuke On Mon, Jul 30, 2012 at 11:35 PM, Arko Saha ngh...@motorola.com wrote: I am planning to enable MICRODATA feature by default in WebKit. Microdata master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Microdata spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html Currently we have support for Microdata DOM API's to interacting with microdata using microdata attributes like itemscope, itemtype, itemprop, itemref, itemid through JavaScript. Also we have added support for HTMLPropertiesCollection, PropertyNodeList interfaces to intract with microdata item-properties. As of now, WebKit EFL and Blackberry port has already enabled MICRODATA by default. Mozilla and Opera has also enabled the support for Microdata DOM API. Please let me know your thoughts on the same. Thanks and Regards, Arko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable MICRODATA feature by default
I have tested the test : http://w3c-test.org/html/tests/submission/Opera/microdata/001.html 255 Pass 82 Fail Most of the failed cases are specific to their implementation and for others, I need to check. Regards, Arko On Tue, Jul 31, 2012 at 12:07 PM, Ryosuke Niwa rn...@webkit.org wrote: Do we pass tests W3C submitted by Opera Mozilla? - Ryosuke On Mon, Jul 30, 2012 at 11:35 PM, Arko Saha ngh...@motorola.com wrote: I am planning to enable MICRODATA feature by default in WebKit. Microdata master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Microdata spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html Currently we have support for Microdata DOM API's to interacting with microdata using microdata attributes like itemscope, itemtype, itemprop, itemref, itemid through JavaScript. Also we have added support for HTMLPropertiesCollection, PropertyNodeList interfaces to intract with microdata item-properties. As of now, WebKit EFL and Blackberry port has already enabled MICRODATA by default. Mozilla and Opera has also enabled the support for Microdata DOM API. Please let me know your thoughts on the same. Thanks and Regards, Arko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable MICRODATA feature by default
On Mon, Jul 30, 2012 at 11:51 PM, Arko Saha ngh...@motorola.com wrote: I have tested the test : http://w3c-test.org/html/tests/submission/Opera/microdata/001.html 255 Pass 82 Fail Most of the failed cases are specific to their implementation and for others, I need to check. What do you mean by specific to their implementation? I would expect any test submitted to the W3C test suite to be cross browser. Tests shouldn't include vendor prefixes for example. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: perf-o-matic is usable again
Hi, I've fixed a bunch of bugs in perf-o-matic; in particular, I've determined the culprit of the performance issue of perf-o-matic and fixed it. Dashboard, custom graphs, etc... should load almost instantly now. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: perf-o-matic is usable again
For those of you who didn't see the original announcement of perf-o-matic, it's located at: webkit-perf.appspot.com. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable MICRODATA feature by default
For an example :
test(function () {
assert_equals( makeEl('div',{itemtype:' '}).itemType[0],
window.undefined );
}, 'itemType[index] must be undefined for out-of-range index');
makeEl method creates an element div with empty itemtype(0 tokens). Test
expects itemTpye[0] should return undefined, in our case it returns null.
According to the spec itemtpye attribute is a space-separated list.
http://www.whatwg.org/specs/web-apps/current-work/#attr-itemtype
We have defined itemtype attribute as :
readonly attribute [Conditional=MICRODATA] DOMSettableTokenList itemType;
DOMSettableTokenList returns null for out-of-range index.
So I thought it is specific to DOMSettableTokenList implementation. Or is
this the bug in our DOMSettableTokenList implementation? There are many
tests failing because of this.
Do you think, we should first resolve all these test issues and then think
of enabling feature by default? In that case I will raise a new bug and we
can then discuss the failed tests there.
Regards,
Arko
On Tue, Jul 31, 2012 at 12:51 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jul 30, 2012 at 11:51 PM, Arko Saha ngh...@motorola.com wrote:
I have tested the test :
http://w3c-test.org/html/tests/submission/Opera/microdata/001.html
255 Pass
82 Fail
Most of the failed cases are specific to their implementation and for
others, I need to check.
What do you mean by specific to their implementation? I would expect any
test submitted to the W3C test suite to be cross browser. Tests shouldn't
include vendor prefixes for example.
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable MICRODATA feature by default
On Tue, Jul 31, 2012 at 12:55 AM, Arko Saha ngh...@motorola.com wrote:
For an example :
test(function () {
assert_equals( makeEl('div',{itemtype:' '}).itemType[0],
window.undefined );
}, 'itemType[index] must be undefined for out-of-range index');
makeEl method creates an element div with empty itemtype(0 tokens). Test
expects itemTpye[0] should return undefined, in our case it returns null.
According to the spec itemtpye attribute is a space-separated list.
http://www.whatwg.org/specs/web-apps/current-work#attr-itemtypehttp://www.whatwg.org/specs/web-apps/current-work/#attr-itemtype
We have defined itemtype attribute as :
readonly attribute [Conditional=MICRODATA] DOMSettableTokenList itemType;
DOMSettableTokenList returns null for out-of-range index.
So I thought it is specific to DOMSettableTokenList implementation. Or is
this the bug in our DOMSettableTokenList implementation? There are many
tests failing because of this.
Either that the spec is out of date or that the test is wrong. It's
possible that the spec has recently changed after they had submitted the
test case.
Do you think, we should first resolve all these test issues and then think
of enabling feature by default? In that case I will raise a new bug and we
can then discuss the failed tests there.
It seems like this particular problem isn't specific to micro data so it's
probably okay. But we should investigate other failures and make sure our
implementation interoperate with Opera and Firefox.
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove webkit prefix from Battery Status API and from Vibration API?
On Tue, Jul 31, 2012 at 3:02 AM, Kihong Kwon kihong.k...@samsung.comwrote: Hi, webkit-dev ** ** As you can see with these links, http://www.w3.org/TR/battery-status/ http://www.w3.org/TR/vibration/ the status of Battery Status API and Vibration API have been changed to the CR quite ago and specs are almost stable now. Therefore, I think we can remove webkit prefix from webkitBattery and from webkitvibrate. If someone has objection or other opinion please let me know. Has a test suite been published we can test against? Are there any other implementations of the APIs? Besides the time-based requirement of dropping vendor prefixes when a specification goes to Candidate Recommendation status, unprefixing also implies operability with both the specification and other implementations. It'll be good to confirm that. Peter BR, Kihong. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://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] is platform/mac baselined for ML (mountain lion)?
NRWT is producing a large number of apparent regressions on ML. A build/test run I performed last night shows 294 unexpected fails on WK1 tests [1] and 150 unexpected fails on WK2 tests [2]. My question is whether platform/mac has been rebaselined for ML or not? If not, then are there plans to do so? [1] http://people.apache.org/~gadams/webkit/test.wk1.log [2] http://people.apache.org/~gadams/webkit/test.wk2.log ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable MICRODATA feature by default
Has anything been done to verify security and stability of the feature, for example, fuzz testing? I'd like to request that before enabling for Apple's ports. - Maciej On Jul 30, 2012, at 11:35 PM, Arko Saha ngh...@motorola.com wrote: I am planning to enable MICRODATA feature by default in WebKit. Microdata master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Microdata spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html Currently we have support for Microdata DOM API's to interacting with microdata using microdata attributes like itemscope, itemtype, itemprop, itemref, itemid through JavaScript. Also we have added support for HTMLPropertiesCollection, PropertyNodeList interfaces to intract with microdata item-properties. As of now, WebKit EFL and Blackberry port has already enabled MICRODATA by default. Mozilla and Opera has also enabled the support for Microdata DOM API. Please let me know your thoughts on the same. Thanks and Regards, Arko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] trac.webkit.org timeline broken
It looks like the timeline has once again stopped updating. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] trac.webkit.org timeline broken
Fixed again. I'm still trying to debug the locking thats getting stuck. I appreciate everyone letting me know when it happens. -Bill On Jul 31, 2012, at 1:03 PM, Peter Kasting pkast...@google.com wrote: It looks like the timeline has once again stopped updating. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] webkit for windows x64
I've been working on WebKit for 64-bit windows. I've gotten the whole thing to compile using my repository ( https://github.com/achristensen07/webkit64prep.git) and Brent Fulgham's repository (https://github.com/bfulgham/WinCairoRequirements.git). Javascript and Cairo work and WinLauncher opens, but doesn't draw. I could use some help finding out why and possibly including my work into Webkit. Any feedback would be appreciated. Thanks. -- Alex Christensen FlexSim Software Products, Inc. *1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097* *Voice: 801-224-6914 | Fax: 801-224-6984* *Email:* al...@flexsim.com k...@flexsim.com *URL:* www.flexsim.com This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enable performance.webkitNow on all ports?
Hi, Can we enable performance.webkitNow on all ports? The last time performance feature was discussed, there were some privacy concerns about performance.navigation, etc... but webkitNow doesn't seem to pose any significant privacy concerns and is quite useful for benchmark purposes. e.g. in our own performance tests. Note that Firefox and Chrome have already shipped with a prefixed version and Microsoft is going to ship it in IE10. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
Hi all, I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. In theory this shouldn't break anything (I tried to keep the output basically the same on the bots, which have all been updated to pass --verbose --verbose as necessary), but if you do have other scripts that will break, either please update them or let me know that I might need to change things. Thanks! -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
On Tue, Jul 31, 2012 at 6:36 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? I'm not sure if I understand your suggestion. Are you suggesting we call --details --debug instead? or have --verbose --verbose be replaced by --debug? We definitely don't want --details to be enabled by default either interactively or on the bots; it logs way too much if you're running a lot of tests. I also personally would not want to have to slog through the debug output to extract the stuff that --details will print. I would be fine with changing '--verbose --verbose' to '--debug', but I'm not sure if that's either much of an improvement or enough to make you happy? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
On Tue, Jul 31, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 6:36 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? I'm not sure if I understand your suggestion. Are you suggesting we call --details --debug instead? or have --verbose --verbose be replaced by --debug? My suggestion is to merge --verbose --verbose and --details into one option: --debug. We definitely don't want --details to be enabled by default either interactively or on the bots; it logs way too much if you're running a lot of tests. I also personally would not want to have to slog through the debug output to extract the stuff that --details will print. I would be fine with changing '--verbose --verbose' to '--debug', but I'm not sure if that's either much of an improvement or enough to make you happy? So we need to have --verbose --verbose separately from --verbose and --details to be used on bots? Why don't we get rid of single --verbose then? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
On Tue, Jul 31, 2012 at 7:02 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 6:36 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? I'm not sure if I understand your suggestion. Are you suggesting we call --details --debug instead? or have --verbose --verbose be replaced by --debug? My suggestion is to merge --verbose --verbose and --details into one option: --debug. Right, I wouldn't want to do that; it would make the already-too-big bot output 6x bigger, I'm guessing. We definitely don't want --details to be enabled by default either interactively or on the bots; it logs way too much if you're running a lot of tests. I also personally would not want to have to slog through the debug output to extract the stuff that --details will print. I would be fine with changing '--verbose --verbose' to '--debug', but I'm not sure if that's either much of an improvement or enough to make you happy? So we need to have --verbose --verbose separately from --verbose and --details to be used on bots? Why don't we get rid of single --verbose then? ap@ and others have requested a single --verbose that is closer to what ORWT used to do (bug 88702); something more than what we get by default, but less verbose than either what --details or --verbose/--debug would be. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
Let's rename --verbose --verbose to --debug at least. I'd also prefer renaming --details to --trace or something because --details sounds less detailed than --debug but I'm not strongly opinionated about this. - Ryosuke On Tue, Jul 31, 2012 at 7:09 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 7:02 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 6:36 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432 . To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? I'm not sure if I understand your suggestion. Are you suggesting we call --details --debug instead? or have --verbose --verbose be replaced by --debug? My suggestion is to merge --verbose --verbose and --details into one option: --debug. Right, I wouldn't want to do that; it would make the already-too-big bot output 6x bigger, I'm guessing. We definitely don't want --details to be enabled by default either interactively or on the bots; it logs way too much if you're running a lot of tests. I also personally would not want to have to slog through the debug output to extract the stuff that --details will print. I would be fine with changing '--verbose --verbose' to '--debug', but I'm not sure if that's either much of an improvement or enough to make you happy? So we need to have --verbose --verbose separately from --verbose and --details to be used on bots? Why don't we get rid of single --verbose then? ap@ and others have requested a single --verbose that is closer to what ORWT used to do (bug 88702); something more than what we get by default, but less verbose than either what --details or --verbose/--debug would be. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Add support for CSS3 text-decoration* properties
Hi all :) As suggested by Ojan, I am writing a mail to you about my intention to implement all updated and missing text-decoration* properties from CSS3 spec (currently in development), named below: -webkit-text-decoration ( https://bugs.webkit.org/show_bug.cgi?id=92000 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration Status: Proposed patch / pending review -webkit-text-decoration-line ( https://bugs.webkit.org/show_bug.cgi?id=90959 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-line Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration-line Status: Proposed patch / pending review -webkit-text-decoration-style ( https://bugs.webkit.org/show_bug.cgi?id=90958 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-style Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration-style Status: Proposed patch / pending review -webkit-text-decoration-color ( https://bugs.webkit.org/show_bug.cgi?id=91638 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-color Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration-color Status: Proposed patch / pending review -webkit-text-decoration-skip ( https://bugs.webkit.org/show_bug.cgi?id=92801 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-skip Status: Work in progress As each patch touches similar places and sometimes requires previous work, this patch series requires the patches to be reviewed / commited in the same order as described above ( 92000, 90959, 90958, 91638 and 92801 ). The decision to use -webkit- prefix was suggested by Alexis on https://bugs.webkit.org/show_bug.cgi?id=90959#c13 . There is also a suggestion to use a specific flag to enable this feature at compile time, however other CSS3 properties such as text-emphasis, for example, do not use such flags, so I am a bit uncertain about it still. I am really looking forward for comments and review on the proposed patches :) Best regards, -- Bruno de Oliveira Abinader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Add support for CSS3 text-decoration* properties
Please make sure the new text decoration values don't break editing (rich text editing execCommand). In particular, we probably need to update ApplyStyleCommand/EditingStyle to handle -webkit-text-decoration*. On Tue, Jul 31, 2012 at 7:35 PM, Bruno Abinader brunoabina...@gmail.comwrote: Hi all :) As suggested by Ojan, I am writing a mail to you about my intention to implement all updated and missing text-decoration* properties from CSS3 spec (currently in development), named below: -webkit-text-decoration ( https://bugs.webkit.org/show_bug.cgi?id=92000 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration Status: Proposed patch / pending review -webkit-text-decoration-line ( https://bugs.webkit.org/show_bug.cgi?id=90959 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-line Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration-line Status: Proposed patch / pending review -webkit-text-decoration-style ( https://bugs.webkit.org/show_bug.cgi?id=90958 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-style Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration-style Status: Proposed patch / pending review -webkit-text-decoration-color ( https://bugs.webkit.org/show_bug.cgi?id=91638 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-color Mozilla ref: https://developer.mozilla.org/en/CSS/text-decoration-color Status: Proposed patch / pending review -webkit-text-decoration-skip ( https://bugs.webkit.org/show_bug.cgi?id=92801 ) CSS3 dev spec: http://dev.w3.org/csswg/css3-text/#text-decoration-skip Status: Work in progress As each patch touches similar places and sometimes requires previous work, this patch series requires the patches to be reviewed / commited in the same order as described above ( 92000, 90959, 90958, 91638 and 92801 ). The decision to use -webkit- prefix was suggested by Alexis on https://bugs.webkit.org/show_bug.cgi?id=90959#c13 . There is also a suggestion to use a specific flag to enable this feature at compile time, however other CSS3 properties such as text-emphasis, for example, do not use such flags, so I am a bit uncertain about it still. I am really looking forward for comments and review on the proposed patches :) Best regards, -- Bruno de Oliveira Abinader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
Another possibility is --extraverbose. That is more verbose (!), but perhaps more obviously related to --verbose than --debug is. John On Jul 31, 2012, at 7:28 PM, Ryosuke Niwa wrote: Let's rename --verbose --verbose to --debug at least. I'd also prefer renaming --details to --trace or something because --details sounds less detailed than --debug but I'm not strongly opinionated about this. - Ryosuke On Tue, Jul 31, 2012 at 7:09 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 7:02 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 6:36 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? I'm not sure if I understand your suggestion. Are you suggesting we call --details --debug instead? or have --verbose --verbose be replaced by --debug? My suggestion is to merge --verbose --verbose and --details into one option: --debug. Right, I wouldn't want to do that; it would make the already-too-big bot output 6x bigger, I'm guessing. We definitely don't want --details to be enabled by default either interactively or on the bots; it logs way too much if you're running a lot of tests. I also personally would not want to have to slog through the debug output to extract the stuff that --details will print. I would be fine with changing '--verbose --verbose' to '--debug', but I'm not sure if that's either much of an improvement or enough to make you happy? So we need to have --verbose --verbose separately from --verbose and --details to be used on bots? Why don't we get rid of single --verbose then? ap@ and others have requested a single --verbose that is closer to what ORWT used to do (bug 88702); something more than what we get by default, but less verbose than either what --details or --verbose/--debug would be. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://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] Adding Proximity Events
Hello, webkit-dev I would like to let you know, I am planning to add Proximity Events to WebCore. This feature will be behind the ENABLE_PROXIMITY_EVENTS. Please see : http://www.w3.org/TR/proximity/ https://bugs.webkit.org/show_bug.cgi?id=92837 If you have any comments, please let me know. BR, Kihong. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove webkit prefix from Battery Status API and from Vibration API?
Has a test suite been published we can test against? I didn't see a test suite which is opened to everyone yet. Is this a problem for dropping prefix? Are there any other implementations of the APIs? Besides the time-based requirement of dropping vendor prefixes when a specification goes to Candidate Recommendation status, unprefixing also implies operability with both the specification and other implementations. It'll be good to confirm that. Firefox already implements these APIs. https://wiki.mozilla.org/WebAPI https://developer.mozilla.org/en/DOM/window.navigator.battery https://developer.mozilla.org/en/DOM/window.navigator.battery And these APIs have been entered CR as you know. BR, Kihong. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
