Re: [webkit-dev] Adding ENABLE_CSS_DIRECTIONAL_FOCUS to WebCore.
On Fri, Jul 26, 2013 at 9:07 PM, Benjamin Poulain benja...@webkit.orgwrote: On Fri, Jul 26, 2013 at 1:57 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote: Ah, When I made a new patch, had doubts about the file name Deprecated. So, I have to wait the StyleBuilder Class to have a clear form. On this regard, some input from Dirk Schulze could probably be very useful as guidance here, as he was the original author of the commit where this class got deprecated[1]. It is a work in progress to clean the StyleBuilder. Also, I'm waiting for the community to conclude this discussion. Me too. Honestly, I am concerned that no one in favor of this feature is a regular contributor. The feature does not seem very invasive so if some people really invest time in maturing this, it could be worth experimenting with this and provide feedback to the W3C working group. I think everything should be behind a feature flag, and have the -webkit- prefix. As usual with experimental features, you will have to remove it if it turns out the experiment is not successful. I wouldn't characterize the nav-* properties as experimental, given their fairly widespread implementation among Television oriented profiles of HTML/CSS, going back at least to 1999 [1]. See also specifications from 2001 and 2003 [2][3]. As such, it seems somewhat questionable to use a -webkit- prefix. [1] http://www.arib.or.jp/english/html/overview/archives/br/ARIB_STD-B24-2_2of2_v5.1_E1.pdf [2] http://www.atsc.org/cms/standards/a100/a_100_2.pdf [3] http://my.safaribooksonline.com/book/digital-media/9780240806662/15-building-applications-with-html/s235_xhtml ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding ENABLE_CSS_DIRECTIONAL_FOCUS to WebCore.
On Tue, Jul 23, 2013 at 12:17 AM, Kyounga Ra kyounga...@gmail.com wrote: Hi webkit-dev! I'd like to add new feature for CSS nav-[dir] properties. https://bugs.webkit.org/show_bug.cgi?id=66027 This feature is for http://dev.w3.org/csswg/css3-ui/#nav-dir On recent discussion, these nav-* properties was dropped from level 3. http://lists.w3.org/Archives/Public/www-style/2013Apr/0428.html But, I need this feature. (I'm in the TV industry.) Honestly, already implemented and have used it. You can see my previous patch. At that time, I thought that this is W3C standard and we didn't need to develop it behind a defined feature name. Now, this property was dropped from CSS. Actually, it hasn't been dropped. It was decided to move from CSS3 Basic UI to a new level 4 version; however, that earlier decision was recently vacated after Opera and others supported its retention in level 3 (where it will continue to be marked as at risk pending the results of a CR phase). [1] http://dev.w3.org/csswg/css-ui/#nav-index0 [2] http://lists.w3.org/Archives/Public/www-style/2013Jul/0090.html So, is it okay implementing this feature behind ENABLE_CSS_DIRECTIONAL_FOCUS? I re-ported this feature whenever I rebase my webkit. It's troublesome job. how about you Adding ENABLE_CSS_DIRECTIONAL_FOCUS is not bad? Any comments are welcome. - Kyounga ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When should I use AtomicString vs String?
On Sun, Jun 2, 2013 at 2:48 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 1, 2013, at 8:54 PM, Glenn Adams gl...@skynav.com wrote: You guys obviously never wrote any Lisp code. Um, why do you think I suggested Symbol? On Jun 1, 2013, at 9:09 PM, Glenn Adams gl...@skynav.com wrote: Seriously, if Atomic isn't jargon, Intern isn't either. Both are jargon. Atom and Intern in various forms are both used elsewhere so will be relevant to people from some other technical communities. Neither is completely obvious to the novice. Overall, I don't think any of the names suggested on this thread are sufficiently better to be worth the transition cost (including my own suggestions of Symbol and Atom). Perhaps just adding a brief comment at the head of AtomicString.h to the effect: This class might have been named SymbolString, AtomString, or InternedString, but we're sticking with AtomicString for historical reasons, and since the former are not markedly superior to the latter. Further, the term Atomic is not intended to be read as meaning 'atomic' in the sense of synchronic. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When should I use AtomicString vs String?
You guys obviously never wrote any Lisp code. http://books.google.com/books?id=FYoOIWuoXUIClpg=PA267ots=ioaahFTKT0dq=intern%20special%20form%20maclisppg=PA266#v=onepageq=intern%20special%20form%20maclispf=false On Sat, Jun 1, 2013 at 6:01 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sat, Jun 1, 2013 at 4:45 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 1, 2013, at 3:58 PM, Darin Adler da...@apple.com wrote: On May 31, 2013, at 8:01 PM, Glenn Adams gl...@skynav.com wrote: One thing that always threw me was the term Atomic in the class name. I wonder if the term InternedString would make it usage more apparent. I personally love the name AtomicString (the string of tomorrow) and have been using that name for it for the past 10 years, but I see that InternedString is what this would be called in Java and .NET context so I guess we could change to help people familiar with those. If we were to change the name, I'd go with Symbol or Atom. But I think AtomicString is a fine name and I don't think InternedString is better. All plausible names I can think of are jargon that you have to learn the first time if you don't know it. I don't like InternedString either. In general, we should avoid using design pattern jargons like interning, mediator, flyweight, etc... when we can come up with a more descriptive name. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When should I use AtomicString vs String?
On Sat, Jun 1, 2013 at 9:56 PM, Darin Adler da...@apple.com wrote: On Jun 1, 2013, at 8:54 PM, Glenn Adams gl...@skynav.com wrote: You guys obviously never wrote any Lisp code. Lets not play this game. When I met Maciej he was the maintainer of one of the most popular Scheme implementations, if I remember correctly. Sorry, I forgot to add a smiley... :) Seriously, if Atomic isn't jargon, Intern isn't either. In any case, I don't particularly care either way. Once you learn its function, you forget about the name. But the name did throw me, since I asked myself what makes this more 'atomic' than String, synchronicity wise? I'm sure I'm not the only one who wondered about this. My reason for suggesting Interned... was simply because that was how Ryosuke chose to characterize it as being different from String. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] When should I use AtomicString vs String?
On Fri, May 31, 2013 at 6:14 PM, Rafael Brandao rafael.l...@openbossa.orgwrote: This thread contains really useful information, so I've created a new topic on https://trac.webkit.org/wiki/EfficientStrings and pointed to here. One thing that always threw me was the term Atomic in the class name. I wonder if the term InternedString would make it usage more apparent. Best regards, Rafael On Fri, May 31, 2013 at 8:32 PM, Ryosuke Niwa rn...@webkit.org wrote: We shouldn't use AtomicString if the string we're about to create doesn't get shared across multiple AtomicStrings. For example, if we had used AtomicString for the strings inside Text nodes, then we may end up filling up the atomic string table with all these really long strings that don't typically appear more than once. It also slows down the hash map look up for all other atomic strings. On Fri, May 31, 2013 at 3:00 PM, Brendan Long s...@brendanlong.comwrote: So should I just never use String and always use AtomicString? On 05/31/2013 03:14 PM, Daker Pinheiro wrote: It is faster to compare and hash AtomicString than regular Strings. On Fri, May 31, 2013 at 5:57 PM, Brendan Long s...@brendanlong.comwrote: I hope this isn't a stupid question, but I can't find any references to what the difference between AtomicString and String is. It looks like AtomicString is generally preferred, but I don't know why. Can someone fill me in on this? Is there any refences for the classes in WTF? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Rafael Brandao @ INdT ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Vertical Selections in Textareas
On Thu, May 16, 2013 at 12:06 PM, Darin Adler da...@apple.com wrote: I think it’s a neat idea. It’s a big, challenging project. The first step is probably to add the notion of a selection that is not a single DOM range. There are many, many functions that currently have that assumption. I don’t have a lot more specific feedback to add. In bidi and certain complex script contexts, support for visual order selection instead of logical order selection requires assuming that more than one underlying (i.e., DOM) range may be associated with the visual selection. Some word processors allow the user to select which selection mode is to be used. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] obtaining webkit.org address?
How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.orgor a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] obtaining webkit.org address?
And if one prefers to use a webkit.org address, like you are doing? On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.orgwrote: Previously people used to get SVN accounts associated to a @webkit.orgalias. Today it seems like it is preferable to get a company email as alias, and credential to write-access SVN. On Sunday, April 28, 2013, Glenn Adams wrote: How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.org or a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] obtaining webkit.org address?
On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams gl...@skynav.com wrote: And if one prefers to use a webkit.org address, like you are doing? A little follow-up: when I got my SVN account and credentials earlier this year as a committer, I expected to be given or at least asked if I wanted a webkit.org address, to which I would have said yes. However, I wasn't asked and the credentials went through with my company address. As my company is basically just me, I would prefer to use a webkit.org address in order to identify better with the community as such. So I'm just now following up on this inquiry about how to get a community address. On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.orgwrote: Previously people used to get SVN accounts associated to a @webkit.orgalias. Today it seems like it is preferable to get a company email as alias, and credential to write-access SVN. On Sunday, April 28, 2013, Glenn Adams wrote: How does a committer/reviewer obtain a webkit.org address? I notice that the majority of existing committers and reviewers have either a webkit.org or a chromium.org address listed in contributors.json. I think it an important part of being part of the WK community to be able to identify oneself as being in that community, and having a usable webkit.org address seems a good way to effect that. G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement ruby-overhang
On Wed, Apr 17, 2013 at 1:26 AM, Yuki Sekiguchi yuki.sekigu...@access-company.com wrote: Hi, I'd like to add support for ruby-overhang. The spec for this feature can be found here: http://www.w3.org/TR/css3-ruby/#rubyover I'm working it at this bug https://bugs.webkit.org/show_bug.cgi?id=114678 My concern is that this patch changes the default behavior of overhanging ruby text. CSS spec says that initial value is none, but current behavior is like auto. Firefox doesn't support this property. IE says it supports this property[1], but values don't match CSS spec, and the property doesn't affect layout. Any comments and suggestions are welcome. [1]: http://msdn.microsoft.com/ja-jp/library/ie/ms531151(v=vs.85).aspx -- Yuki Sekiguchiyuki.sekigu...@access-company.com ACCESS Co., Ltd. I see that the CSS Ruby draft is now almost two years old and that the CSS Drafts page [1] indicates it is Outdated and majorly [sic] undefined. Have you checked with the author or the CSS WG to determine if this work is moving forward as presently drafted? Have you checked with them on this specific issue? [1] http://www.w3.org/Style/CSS/current-work ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Wed, Apr 10, 2013 at 1:46 AM, Eric Seidel e...@webkit.org wrote: If we create an emeritus class in committers.py, we also have a whole bunch of old (long-webkit-retired) Apple committers/reviewers (ken, vicki, cblu, gramps, etc.) which should go there. :) Then the tools (including validate-committer-lists) would be less confused by their presence in ChangeLogs and commit messages. I like this. Shouldn't be hard to add a suggest-emeriti command to webkitpy. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Tools/BuildSlaveSupport/.../TestFailures/run-unittests.html
Does any bot (or person) run this? Regularly? I just noticed today it reports a number of failures (using r148074). Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.37+ (KHTML, like Gecko) Version/6.0.3 Safari/536.28.10 Tests completed in 705 milliseconds. 513 tests of 545 passed, 32 failed. May I assume there would be no objection if I attempt to fix those failures? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Tools/BuildSlaveSupport/.../TestFailures/run-unittests.html
On Tue, Apr 9, 2013 at 11:15 PM, Dirk Pranke dpra...@chromium.org wrote: TestFailures, as I understand it, provides a summarize view of current tree failures clustered by the changes that might have caused the failures, kind of like garden-o-matic's initial page. All the garden-o-matic UI is under TestFailures/garden-o-matic.html et al. I ran across this today (for the first time) when updating this UI ( http://trac.webkit.org/changeset/148075). Seems like it would be good to fix it :). I think aroben built it and it has been neglected since he stopped working on WebKit full time. Thanks, will do. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unmaintained feature list
On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 6:35 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze k...@webkit.org wrote: The recent request from Andreas to remove CSS Variables leads to the question if there are more features that are not maintained at the moment. I think it would be honest and transparent if we collect all features that are not maintained at the moment in a Wiki page. This would give us the chance to review each feature individually and we would still have the overview over all features in question. It also makes it a lot easier to plan with the available resources IMO. Sounds like a great idea: http://trac.webkit.org/wiki/UnmaintainedFeatureList This is awesome. In addition to features and ports enabling them, it might be useful to include an estimate of maintenance burden. In cases where organizations are comfortable saying so, it might also be useful to express short-term future interest in enabling the feature if they don't have it on already. I have taken the liberty to add a complementary list at http://trac.webkit.org/wiki/MaintainedFeatureList where contributors can register their commitment to maintaining features. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unmaintained feature list
On Mon, Apr 8, 2013 at 5:01 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Apr 8, 2013 at 3:59 PM, Glenn Adams gl...@skynav.com wrote: On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 6:35 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze k...@webkit.org wrote: The recent request from Andreas to remove CSS Variables leads to the question if there are more features that are not maintained at the moment. I think it would be honest and transparent if we collect all features that are not maintained at the moment in a Wiki page. This would give us the chance to review each feature individually and we would still have the overview over all features in question. It also makes it a lot easier to plan with the available resources IMO. Sounds like a great idea: http://trac.webkit.org/wiki/UnmaintainedFeatureList This is awesome. In addition to features and ports enabling them, it might be useful to include an estimate of maintenance burden. In cases where organizations are comfortable saying so, it might also be useful to express short-term future interest in enabling the feature if they don't have it on already. I have taken the liberty to add a complementary list at http://trac.webkit.org/wiki/MaintainedFeatureList where contributors can register their commitment to maintaining features. We should somehow merge these two lists into http://trac.webkit.org/wiki/FeatureFlags. +1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Sun, Apr 7, 2013 at 7:27 PM, Benjamin Poulain benja...@webkit.orgwrote: I don't really see the big deal with revoking reviewer rights. If you come back to the project, make a few good patches and show a good understanding of the code base, you just get the rights back. This seems rather subjective criteria. What is a good understanding of the code base? Does that mean one module, a collection of modules in some namespace, or the entire breadth of the source tree? What constitutes a good patch? It might be interesting to learn which and how many reviewers would be withdrawn if a 6 month window were invoked now. For example, how many Apple reviewers would go away? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham bfulg...@gmail.com wrote: I'd also suggest purging the chromium layout tests ASAP so we can enjoy the much-reduced archive sync costs. We really need to get the Mac or Win EWS performing tests by default and reliably before doing this. At present, only the chromium-linux EWS bot has been consistently running tests. When Mac/Win tests were turned on recently, it resulted in huge backups on those EWS bots, and eventually having tests disabled. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 1:44 PM, Filip Pizlo fpi...@apple.com wrote: Sent from my PDP-11 11/20? 11/40? RSX-11? RT-11? Love the split I/D memory on 11/70s. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 1:50 PM, Geoffrey Garen gga...@apple.com wrote: To clarify: (1) The EWS bots are still running. (2) The mac and mac-wk2 EWS bots are running tests, and passing. (3) The cr-linux bots are running tests, and failing. If we're OK with item (3), we can go ahead with cleaning house, and break the cr-* EWS bots entirely, while we work on making the mac and mac-wk2 EWS bots faster. +1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Upcoming Contributors Meeting
Any update on the upcoming contributors meeting [1]? Logistics? Agenda? [1] http://trac.webkit.org/wiki/May%202013%20Meeting ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Web VHS API
On Mon, Apr 1, 2013 at 10:39 AM, Michael Saboff msab...@apple.com wrote: I had heard that there is some disagreement among browser vendors as to video formats being supported with the Web VHS API. Safari will only support the Not Too Saturated Colors (NTSC) format to improve clarity, while Chrome has agreed to the Paint As Lines (PAL) vectorizing format. Opera will only support See Every Color As Magenta (SECAM) format to reduce bandwidth. I also heard plug-ins are being developed to bridge the formats. correction... NTSC = Never The Same Color (twice) ... will we add VCR+ support as well to schedule recordings? ;) ___ 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
On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, I've made a change to NRWT in http://trac.webkit.org/changeset/146657 so that it always generate pixel results in retries even when pixel tests are disabled by default (on all but Chromium ports). We now enable pixel tests while we're retrying tests and generate -expected.png results. This change has two important implications: - We can now grab -expected.png results from build.webkit.org builders for those tests that have resulted in non-image-only failures. - Chromium and Mac EWS bots will now upload ZIP archives with those images (recall http://trac.webkit.org/changeset/146443) This will allow us to rebaseline BOTH test and image expected results PRIOR to landing patches. Now that layout-test-results are being attached to their related bugs, I wonder if there is a way to delete these attachments (in BZ) so as not to choke disk space on the BZ server. Otherwise, I have a feeling disk usage will increase rapidly. For example, after one has reviewed and extracted the useful results from the attachments, it would be useful to delete (and not just make obsolete) those (large) attachments. I also notice that when an EWS has multiple fails on the same patch, that multiple layout-test-results get attached. It might also be useful to have a cron job on the BZ server go through and delete obsoleted layout-test-result attachments (in case it is not straightforward to permit attachment deletion). At least, then the dev could obsolete result attachments after extracting the useful data and the cron job could do the rest of the work of deleting the attachments. ___ 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
On Wed, Mar 27, 2013 at 9:16 AM, Glenn Adams gl...@skynav.com wrote: On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, I've made a change to NRWT in http://trac.webkit.org/changeset/146657 so that it always generate pixel results in retries even when pixel tests are disabled by default (on all but Chromium ports). We now enable pixel tests while we're retrying tests and generate -expected.png results. This change has two important implications: - We can now grab -expected.png results from build.webkit.orgbuilders for those tests that have resulted in non-image-only failures. - Chromium and Mac EWS bots will now upload ZIP archives with those images (recall http://trac.webkit.org/changeset/146443) This will allow us to rebaseline BOTH test and image expected results PRIOR to landing patches. Now that layout-test-results are being attached to their related bugs, I wonder if there is a way to delete these attachments (in BZ) so as not to choke disk space on the BZ server. Otherwise, I have a feeling disk usage will increase rapidly. For example, after one has reviewed and extracted the useful results from the attachments, it would be useful to delete (and not just make obsolete) those (large) attachments. I also notice that when an EWS has multiple fails on the same patch, that multiple layout-test-results get attached. It might also be useful to have a cron job on the BZ server go through and delete obsoleted layout-test-result attachments (in case it is not straightforward to permit attachment deletion). At least, then the dev could obsolete result attachments after extracting the useful data and the cron job could do the rest of the work of deleting the attachments. Perhaps adding a DeleteObsoleteLayoutResults keyword would make automating deletion a viable process. It could either be added by default when the first layout results are attached (letting the dev decide whether to remove the keyword and keeping obsolete layout results) or the dev could explicitly add the keyword. I would suggest the former (add it by default), forcing an explicit action by the dev to retain obsolete layout results. ___ 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
On Wed, Mar 27, 2013 at 11:46 AM, Glenn Adams gl...@skynav.com wrote: On Wed, Mar 27, 2013 at 9:16 AM, Glenn Adams gl...@skynav.com wrote: On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, I've made a change to NRWT in http://trac.webkit.org/changeset/146657so that it always generate pixel results in retries even when pixel tests are disabled by default (on all but Chromium ports). We now enable pixel tests while we're retrying tests and generate -expected.png results. This change has two important implications: - We can now grab -expected.png results from build.webkit.orgbuilders for those tests that have resulted in non-image-only failures. - Chromium and Mac EWS bots will now upload ZIP archives with those images (recall http://trac.webkit.org/changeset/146443) This will allow us to rebaseline BOTH test and image expected results PRIOR to landing patches. Now that layout-test-results are being attached to their related bugs, I wonder if there is a way to delete these attachments (in BZ) so as not to choke disk space on the BZ server. Otherwise, I have a feeling disk usage will increase rapidly. For example, after one has reviewed and extracted the useful results from the attachments, it would be useful to delete (and not just make obsolete) those (large) attachments. I also notice that when an EWS has multiple fails on the same patch, that multiple layout-test-results get attached. It might also be useful to have a cron job on the BZ server go through and delete obsoleted layout-test-result attachments (in case it is not straightforward to permit attachment deletion). At least, then the dev could obsolete result attachments after extracting the useful data and the cron job could do the rest of the work of deleting the attachments. Perhaps adding a DeleteObsoleteLayoutResults keyword would make automating deletion a viable process. It could either be added by default when the first layout results are attached (letting the dev decide whether to remove the keyword and keeping obsolete layout results) or the dev could explicitly add the keyword. I would suggest the former (add it by default), forcing an explicit action by the dev to retain obsolete layout results. I've filed a bug suggesting this enhancement: https://bugs.webkit.org/show_bug.cgi?id=113428 ___ 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 Fri, Mar 22, 2013 at 3:07 PM, Ryosuke Niwa rn...@webkit.org wrote: Landed it in http://trac.webkit.org/changeset/146657. Once EWS bots catch up, we can start grabbing both text and pixel results off of Chromium and Mac EWS bots. Thanks, this will be very useful! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.org wrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.org wrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Of course I am verifying that tests are still passing and that new tests are generating results as expected. I do this by running NRWT without the patch, running it with the patch, then comparing results. This generally allows me to see new failures, which I manually review to determine the nature of the difference. If the difference is simply minor pixel positioning deltas (in text or image output), then I operate on the tentative hypothesis that a rebaseline is needed for the given test, unless I happen to be making a change that could be attributed to cause the delta. I'm also relying upon EWS to catch a regression before asking for a review. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. But EWS is only testing on a couple of platform/ports yes? Presumably this will still impact qt/gtk/efl and perhaps others where EWS is just building and not testing? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:40 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:36 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.orgwrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Of course I am verifying that tests are still passing and that new tests are generating results as expected. I do this by running NRWT without the patch, running it with the patch, then comparing results. This generally allows me to see new failures, which I manually review to determine the nature of the difference. If the difference is simply minor pixel positioning deltas (in text or image output), then I operate on the tentative hypothesis that a rebaseline is needed for the given test, unless I happen to be making a change that could be attributed to cause the delta. That sounds like a dangerous assumption to make. Due to the DPI differences, things like anti-aliasing will behave quite differently on Retina MBP. A hypothesis is not an assumption. It needs to be tested further. Be sure I am not making any unwarranted assumption. In general, I don't recommend people running and relying on layout tests on Retina MBP especially if you work on the rendering engine at this time. That's my platform, so I have to manage with it. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. But EWS is only testing on a couple of platform/ports yes? Presumably this will still impact qt/gtk/efl and perhaps others where EWS is just building and not testing? That's fine. I'm asking that you include rebaselines for at least one platform in the case that wasn't clear. I will if possible, but I'm just saying it may not be possible on the initial landing in all cases. If it isn't then I expect to have to add rebaseline expectations and then take responsibility for following up on them ASAP. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. Oh, please point out a case of without appropriate rebaseline. Please point out in the documentation where appropriate rebaseline is defined. I think you are making unwarranted assumptions here. If you can't define or understand a process where I can contribute using a MBP Retina, then I think you are imposing an arbitrary, unwarranted restriction on the community. I have been contributing successfully, ergo, it is working. Many are contributing WebCore layout and rendering patches using a wide variety of platforms, not all of which match your platform assumptions. It is not reasonable to claim they aren't contributing positively or that their contributions don't work. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
On Mon, Feb 25, 2013 at 3:53 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 25, 2013 at 2:48 PM, Dirk Pranke dpra...@google.com wrote: On Mon, Feb 25, 2013 at 2:05 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 25, 2013 at 1:39 PM, Dirk Pranke dpra...@google.com wrote: Are you suggesting we should land a failling baseline in the meantime? No. I'm suggesting patch authors perform their due diligence and either ask port maintainers to rebaseline or rebaseline tests themselves. I think either you misunderstood my question, or I am misunderstanding your answer. I'm not asking who, I'm asking what ... If we know some tests are failing, and when we fix a bug the tests will start passing again (but that patch might not land for quite some time), what should we (anyone) do in the meantime? Leave the tree red, land incorrect -expected baselines so that we can catch changes in behavior, or add lines to TestExpectations? Many of the lines you cited fell into the last category. Either one of those two solutions would work (although I strictly advice we do the latter) when there are failing tests and we need a fix in order for those tests to pass but I'm not interested in discussing that matter at the moment. I'm specifically opposed to adding new entries to TestExpectations for the sole purpose of rebaselining them later. One of the modes that the new generic TE file permits is to specify a generic Skip and overriding this with per-port Pass. This provides (IMO) a more manageable way to land a patch that you expect will require per-port mods to fully get the patch working on the primary ports. It also allows one to land a patch containing tests where a subsequent patch will provide the functionality to be tested. I recently used both of these modes to sub-divide a large patch and to incrementally verify (landing individual per-port fixes as needed) individual ports. Personally, I prefer this over the just turn bots red mode. I suspect the turn bots red approach results in greater churn, due to rollouts and re-landing, than the finer grain approach I outlined above. I agree it requires the committer to follow through on other ports and eventually remove the generic Skip and Pass rules (once it works everywhere), but we have to assume here (IMO) that committers will do the right thing and take responsibility for the process. [And if not, then remind them.] So I for one, would vote against the turn the bots red approach. Overall, I think that approach produces a higher interrupt load on our limited committer and reviewer resources. I think it would be useful to give other procedures an opportunity to be tried out so we can have more data for choosing between alternative approaches. Regards, Glenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
On Mon, Feb 25, 2013 at 5:27 PM, Ryosuke Niwa rn...@webkit.org wrote: Quite frankly, I don't want it to be my (or anyone but patch author's) job to take care of all these stale entries people add. I agree, but I think that sloppy follow-up doesn't mean the approach is necessarily bad. We have to police our own work and others all the time. I don't see that going away. In any case, it wouldn't be hard to add a command to webkitpy that reports extraneous/questionable entries in TE files. [Or perhaps there is already a tool that I haven't ran across.] ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
On Mon, Feb 25, 2013 at 6:17 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 25, 2013 at 5:06 PM, Glenn Adams gl...@skynav.com wrote: On Mon, Feb 25, 2013 at 5:27 PM, Ryosuke Niwa rn...@webkit.org wrote: Quite frankly, I don't want it to be my (or anyone but patch author's) job to take care of all these stale entries people add. I agree, but I think that sloppy follow-up doesn't mean the approach is necessarily bad. We have to police our own work and others all the time. If we need to constantly remind people to do X, then X needs to be removed from the list of things we need to remember to do. Or, we need to automate it in the process, like having style bot serve as a gatekeeper for people that forget to run check-webkit-style on their own. I'm sure that most of us have forgotten to run it ourselves, but that doesn't mean we should remove the tool or the style bot. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched
On Mon, Feb 25, 2013 at 12:24 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, We've replaced webkit-perf.appspot.com by perf.webkit.org. webkit-perf.appspot.com will be phased-out in the coming weeks. I'm going to check in the source code of perf.webkit.org into WebKit repository in coming months. Very nice! It also would be nice to have a smoothing function checkbox on the charts to allow visualizing trends a bit better. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
On Sun, Feb 10, 2013 at 10:03 AM, Balazs Kelemen kbal...@webkit.org wrote: On 02/07/2013 01:48 AM, Maciej Stachowiak wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. I agree with that, but I still don't see why should LChar be unsigned since it is a character and not a raw byte. It would be somewhat more convenient when dealing with string literals or traditional C libraries. I you agree I could investigate in the refactoring work. Because LChar is often (always?) UTF-8 encoded, the individual encoding units of which are 0x00 through 0xFF. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
On Sun, Feb 10, 2013 at 11:38 AM, Darin Adler da...@apple.com wrote: Short answer, yes. On Feb 10, 2013, at 9:14 AM, Glenn Adams gl...@skynav.com wrote: Because LChar is often (always?) UTF-8 encoded, the individual encoding units of which are 0x00 through 0xFF. Close. LChar is always Latin-1 encoded. That’s what the L is for. That’s the same thing as the first 256 code points in Unicode. thanks for that correction If LChar could possibly be a signed byte, then we’d have to cast to an unsigned byte at every call site where we are storing an LChar in a UChar; very easy to get that wrong. Since LChar is an unsigned type we can simply do a normal assignment and we get correct behavior. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
On Wed, Feb 6, 2013 at 5:35 PM, Alec Flett alecfl...@chromium.org wrote: Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. I've been coding in C since around 1972, and I admit that in the early days, char was used as a synonym for byte, however, that convention has long been dropped in favor of unsigned char. See [1] for a nice discussion, especially the second answer. [1] http://stackoverflow.com/questions/653336/should-a-buffer-of-bytes-be-signed-or-unsigned-char-buffer So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? I personally alway use unsigned char/uint8_t for raw byte strings. However, I don't have any dependency on SerializedScriptValue. Given Maciej and Adam's comments, you had best stay with unsigned char/uint_8 and convert any non-conforming usage to this pattern when needed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
On Mon, Feb 4, 2013 at 4:51 PM, Alec Flett alecfl...@chromium.org wrote: At the moment, SerializedScriptValue uses Vectoruint8_t (aka Vectorunsigned char) for both it's API (createFromWireBytes, toWireBytes) as well as its internal representation. (for both v8 and jsc implementations) The two largest consumers of this aspect of SerializedScriptValue seems to be IndexedDB and postMessage(). I'm jumping through some small hoops (i.e. reinterpret_cast and whatnot) in IndexedDB to convert between Vectoruint8_t and Vectorchar and a 'const char*' buffer in order to write out to LevelDB, who likes 'char' as opposed to unsigned char. postMessage() seems to be pretty agnostic to char vs unsigned char, since it uses SerializedScriptValue to both produce and consume the buffers it sends between windows. Before I did a code cleanup and just fixed up all the implementations to use Vectorchar I wanted to see if anyone had any objections here, on both the V8 and the JSC sides. The ultimate compiled code is going to be identical, but I'll be able to avoid all sorts of reinterpret_cast's at various points in the code. If you are suggesting to change IndexedDB to use Vectorchar in order to accommodate the LevelDB interfaces, then I would suggest you not do that. Vectoruint8_t is more clear than Vectorchar (or Vectorunsigned char) at expressing the intended usage (binary versus character data). ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)
On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth aba...@webkit.org wrote:
There's no experiment that you can run using web content to detect
whether we implement WebIDL. All you can detect is whether we
implement particular specifications that use WebIDL. We can just
simply not implement the specifications that require COM-like
implementations and we can continue to lead a happy life.
Speaking of implementing WebIDL (in the context of a spec that normatively
requires its support, e.g., CSSOM), what is your position on whether WK
will/should support the following? In the test at [1], neither of these are
currently supported, or at least don't yield expected results.
WebIDL 4.4.1 [2] states:
The interface object for a given non-callback
interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface is
a function objecthttp://dev.w3.org/2006/webapi/WebIDL/#dfn-function-object
.
WebIDL 4.4.3 [3] states:
If the
[NoInterfaceObject]http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject
extended
attribute was not specified on the interface, then the interface prototype
object must also have a property named “constructor” with attributes
{ [[Writable]]:true, [[Enumerable]]: false, [[Configurable]]: true } whose
value is a reference to the interface object for the interface.
[1]
http://hg.csswg.org/test/raw-file/3d8f9c12b1c8/contributors/gadams/incoming/cssom/cssstylerule-interface.xht
[2] http://dev.w3.org/2006/webapi/WebIDL/#interface-object
[3] http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object
Regards,
Glenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.orgwrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=103547 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.orgwrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 11:05 PM, Rafael Weinstein rafa...@chromium.orgwrote: On Thu, Nov 29, 2012 at 9:55 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 29, 2012 at 9:23 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org wrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? The spec is currently in the WebApps: http://www.w3.org/2008/webapps/wiki/PubStatus My assumption is that unless someone objects to it being there (rather than HTML), it will stay. Microsoft co-edited the spec, and made a public statement of support here: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0336.html Mozilla indicated they are looking at implementing here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930#c3 There is an test suite included in this bug which adds to the existing html5lib test suite, which can later be merged back to w3c. Thanks for the additional detail. It looks like this has sufficient support to move forward. We might want to determine whether or not any vendor specific prefixing is needed before moving into wider exposure, but I trust that reviewers will take this into account. We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. Our intention is to move these this spec through the W3C REC process and update the implementation as the spec evolves. As Maciej says, there has already been a good deal of discussion about this spec in the WebApps working group. It's not clear to me whether it's more appropriate for the WebApps working group (where much if the other web components work is taking place) or the HTML working group (where HTML parsing is defined). I'm sure that's something we'll need to discuss with the chairs and the W3C team at the appropriate time. Adam ___ 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] generic test expectations?
Just checking, but I don't see a way to add test expectations that apply generically (to all ports). It would be nice to have something like LayoutTests/platform/generic/TestExpectations to which one could add new tests that are known to fail everywhere (e.g., because the code that implements a feature that is tested by those tests is not yet committed), but which will (at some point in the near future) not fail (when the code that is to be tested is committed). At present, it seems that if one wishes to do this, then it is necessary to add entries to the each base port expectations (i.e., chromium, mac, win, etc), which is rather annoying. If there is no objection to adding such a generic platform expectations file, then I will undertake to do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
That would seem to work only if the test(s) fail the same way on all ports. In the case that I'm working from, I'm using reftests, where I know the correct expectations, but the actual behavior will (does) differ on different ports (when the corresponding feature is committed). I would like to be able to (independently) commit new reftests *and* their known good expectation counterparts (that should apply on all ports), and then subsequently commit an independent patch that implements the expected behavior (on some but not all ports), and the comment further follow-on patches that fix the failing ports (possibly by writing new expectations for those specific ports). On Tue, Nov 13, 2012 at 11:52 AM, Ryosuke Niwa rn...@webkit.org wrote: It is customary to add a failing test expectation (i.e. *-expected.txt file that contains the said failure) in such cases. On Tue, Nov 13, 2012 at 10:49 AM, Glenn Adams gl...@skynav.com wrote: Just checking, but I don't see a way to add test expectations that apply generically (to all ports). It would be nice to have something like LayoutTests/platform/generic/TestExpectations to which one could add new tests that are known to fail everywhere (e.g., because the code that implements a feature that is tested by those tests is not yet committed), but which will (at some point in the near future) not fail (when the code that is to be tested is committed). At present, it seems that if one wishes to do this, then it is necessary to add entries to the each base port expectations (i.e., chromium, mac, win, etc), which is rather annoying. If there is no objection to adding such a generic platform expectations file, then I will undertake to do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:02 PM, Glenn Adams gl...@skynav.com wrote: implements the expected behavior (on some but not all ports), and the comment further follow-on s/the comment further/then commit further/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke dpra...@chromium.org wrote: We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working. [1] http://trac.webkit.org/changeset/133529 At any rate, we encourage people these days to check in expected failures rather than suppressing them using the TestExpectations files. The problem is essentially a chicken and egg problem. I don't know what the per-port failures will be ahead of time, but I do know the set of correct expectations. Since I am (independently) unable to build/test all ports run by build bots, I would like to commit the set of tests plus known good expectations as a preliminary step (with a generic skip all tests for all ports), and then subsequently commit the feature itself, and then subsequently override the generic skip on a port specific basis, effectively re-enabling the tests on a port by port basis as I refine the feature patch (as needed) to handle port specific behavioral differences. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Wed, Oct 10, 2012 at 3:50 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Hi, I still don't get it. CE-HTML is a closed standard and not something we ever want in WebKit as we are pushing HTML5/Living Standard. Just to provide some additional input. CE-HMTL, more formally known as CEA-2014, is *not* a closed standard. It is available to anyone who wishes to pay CEA for a copy. In that respect, it is no different from ISO/ITU standards that sometimes cost money to obtain a copy. I understand that you need some execution and security model, but apart from that I don't see why you don't aim at supporting HTML5 instead of some custom dialect that is moving in another direction that they rest of the industry. Even with the System Applications working group [1], which Samsung is co-chairing, the execution and security model will get solved with proper participation. Also the need for using XHTML isn't that big anymore, now that HTML5 defines how to actually parse the document. Rather than delving deeper into this proposal, I would suggest the original commenter should make some very specific technical proposals (accompanied by actual patches) that may satisfy his requirements, instead of simply propose support for the higher level notion of this profile. The merit of such individual technical proposals (patches) can be evaluated on a case by case basis, as is the case with other features proposed for addition to WK. Regards, Glenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Remove support for -webkit-auto as a specifiable value for CSS text-align property?
Now that the initial value returned for text-align is 'start' instead of '-webkit-auto' (see [1]), would there be any objection to removing support for the ability to specify -webkit-auto as a legacy synonym for 'start'? If not, I will proceed with a new bug I just filed [2] to do this. Otherwise, I'll move it to RESOLVED LATER. [1] https://bugs.webkit.org/show_bug.cgi?id=79914 [2] https://bugs.webkit.org/show_bug.cgi?id=98126 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove support for -webkit-auto as a specifiable value for CSS text-align property?
On Tue, Oct 2, 2012 at 11:06 PM, Ryosuke Niwa rn...@webkit.org wrote: We can't. There are web contents that depend on this value. Also, -webkit-auto behaves slightly differently from start (it may well as be a bug). I wonder if it is possible to quantify this potential dependency. Features in WK have been deprecated and removed before, so this would not be a precedent. Certainly this usage is not a matter for Web interoperability, e.g., see http://www.browsersupport.net/CSS/text-align%3A-webkit-auto. Is WK destined to support -webkit-* syntactic features forever? Given the recent renewed interest in the CSS WG to unprefix certain features (with the recommendation that prefixed features be removed at time of unprefixing), how will WK accommodate this recommendation going forward? In any case, I will further investigate the possible issue of -webkit-auto not behaving as start. Also, I would think that, if this possible difference is eliminated, then we should be able to at least remove the use of -webkit-auto in html.css, etc. On Tue, Oct 2, 2012 at 1:44 AM, Glenn Adams gl...@skynav.com wrote: Now that the initial value returned for text-align is 'start' instead of '-webkit-auto' (see [1]), would there be any objection to removing support for the ability to specify -webkit-auto as a legacy synonym for 'start'? If not, I will proceed with a new bug I just filed [2] to do this. Otherwise, I'll move it to RESOLVED LATER. [1] https://bugs.webkit.org/show_bug.cgi?id=79914 [2] https://bugs.webkit.org/show_bug.cgi?id=98126 ___ 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] Remove support for -webkit-auto as a specifiable value for CSS text-align property?
On Wed, Oct 3, 2012 at 1:20 AM, Maciej Stachowiak m...@apple.com wrote:
Our recent practice and policy has been that the person asking for removal
has to present information to show that it's likely safe.For example by
gathering usage statistics. See:
https://trac.webkit.org/wiki/DeprecatingFeatures
Thanks for the pointer.
Note that 'text-align: -webkit-auto' can have an effect even if it
behaves identically to the initial value of 'start'; authors might use it
to reset when the text-align value has been set to something else, and I
believe this would not work if '-webkit-auto' was an unknown value.
BTW, the correct way to handle this in CSS would be to set text-align to
the value 'initial', or, alternatively, removing the style property.
As far as I can tell, the following all have identical effect in WK. That
is, each of these result in a computed value returned of 'start'.
elt.style.textAlign = '-webkit-auto';
elt.style.textAlign = 'start';
elt.style.textAlign = 'initial';
elt.style.textAlign = '';
elt.style.textAlign = null;
elt.style.cssText = '';
elt.style.removeProperty('text-align');
It is true, however, that elt.style.textAlign = '-webkit-auto' results in
elt.style.textAlign returning '-webkit-auto', so the fact that the author
originally set to '-webkit-auto' rather than 'start' is visible to content
when querying the specified (not computed) style, although it doesn't
produce any formatting difference (with computed styles being both 'start').
On the other hand, it is possible that there's some sites that use the
value but would still work fine. Gathering data on usage frequency might
still be a good first step.
Thanks, I will see if it is possible to gather any usage data on
-webkit-auto.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WKCreateCTLineWithUniCharProvider
Where can I find the source for WKCreateCTLineWithUniCharProvider? I'm working on a bug [1] in which I will need to at least understand and perhaps modify its behavior. Basically, to fix this bug, I need to pass character context from adjacent text runs (or adjacent inline text nodes) that will be used to affect the shaping substitutions but not otherwise participate in width or drawing behavior. Or is this functionality only exposed to Apple staffers? [If so, then I will instead approach doing a trial fix on one of the platforms that uses harfbuzz.] Regards, Glenn [1] https://bugs.webkit.org/show_bug.cgi?id=6148 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
On Sat, Sep 22, 2012 at 7:30 AM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote: That seems like a reasonable approach to gathering usage data indirectly, so I'd say that type of information satisfies the policy as written. If you wanted to take that type of approach to other prefixed features, I doubt I would object in most cases. As I understand the policy, it's just asking for a reasonable effort to gather data relative to what we know about the feature. Perhaps you and other readers of the policy see it as demanding an unreasonable level of work, but I don't think it does. Maybe it's just the tone of the wiki page. It speaks about arguing extensively and proofs. Maybe after this discussion I'll make an editing pass trying to tone down the language and reflect some of this discussion. As discussed, I've updated https://trac.webkit.org/wiki/DeprecatingFeatures to be a bit more friendly and to incorporate some of the recent discussion we had on this mailing list. The intro para seems odd in that it starts talking about adding features, then it immediately says it is going to discuss how to remove a feature. Regarding when to unprefix, I'm not sure the CSS WG has recommended removal of prefixes upon entrance of CR. It has recommended the implementation of the unprefixed flavor (of CSS syntactic features), but it has not gone any further than saying ideally, when you implement the unprefixed version [should you drop the prefixed version]. Also, it is worth noting that these CSS WG recommendations have not necessarily been accepted, applied to, or promulgated by other W3C WGs. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] adding support for css3 line-break property to -webkit-line-break
Bug 89235 [1] notes lack of support for the CSS3 Text module's line-break
property. I have prepared a patch to add support for the values expressed
by this property to the existing -webkit-line-break property, as a
preliminary step before the CSSWG agrees to unprefixed usage of CSS3 Text
properties.
I have prepared two wiki pages [2][3] describing the approach I took in
this patch, as well as discussing the current implementation of the
property and the effects of supporting the new CSS3 keywords.
The basic approach taken by the patch is to make use of customized ICU
rules in WebCore/platform/text/TextBreakIteratorICU.cpp, where the employed
rule set is tailored according to the author supplied line break mode. If
the author does not specify -webkit-line-break that is not 'auto' or
'after-white-space' or if the locale (i.e., @lang) is not a CJK language,
then the new logic is bypassed so no performance impact or semantic change
applies relative to current usage.
A number of new reftests (128) are provided in the patch to fully test this
new functionality. At present. EWS reports passes on all platforms except
cr-linux, which apparently uses a modified copy of ICU. I have added 27
IMAGE results to LayoutTests/platform/chromium/TestExpectations as a
temporary work around until a fix is put in place.
The only significant backwards compatibility issue in accepting this patch
is that -webkit-line-break will use 'auto' as its initial (default) value,
rather than the prior 'normal' value, which has slightly different
semantics in CSS3 Text. This change could affect pages that expect
getComputedStyle('-webkit-line-break') to return 'normal' in the absence of
an explicit property. See the discussion in [4] for further info.
Comments?
Regards,
Glenn
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
[2] https://trac.webkit.org/wiki/LineBreaking
[3] https://trac.webkit.org/wiki/LineBreakingCSS3Mapping
[4]
https://trac.webkit.org/wiki/LineBreaking#Theformer-webkit-line-breakproperty
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] testing strategy? - CJK line breaking tests
What is the recommended approach to test cases when one needs to use a CJK font that covers the test data? I could use DRT text results as expected but given lack of common font across platforms, that doesn't seem to be effective. From my somewhat limited (i.e., newbie) exposure to WK, I gather one can take one of the following approaches: (1) put font (and thus platform) dependent test cases in non-platform test directory, then add entries to Skipped for other platforms; this seems the current approach with many platform/font dependent tests, especially related to I18N features; (2) put font (and thus platform) dependent test cases in platform test directory, possibly ending up with separate tests per platform; (3) what would be nice is to not generate rendering dump from DRT but instead use script only; since I'm testing line-breaking logic, what would do nicely is a set of internal styles available via getComputedStyle() on a block element: - -webkit-line-count - numeric value indicating number of formatted lines produced from rendering a block - -webkit-line-chars-1 through -N, which returns the chars of line N as formatted when rendering a block That is, with these properties, I could use script to determine which line breaks occurred and where. I don't care about geometries or pixels in these particular tests, just whether breaks occur in specific contexts. Any recommendations on whether to pursue one of (1) or (2) above, or try the more ambitious (but more platform independent) third approach? I suppose I could start with (1) or (2) and then pursue (3) as a subsequent task. Regards, Glenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] testing strategy? - CJK line breaking tests
On Tue, Sep 4, 2012 at 8:30 PM, Ryosuke Niwa rn...@webkit.org wrote:
Can we use ref tests?
I'll try this first.
Alternatively, you can compute the with of each character with script
(without adding any new feature to WebKit).
Unfortunately, that won't work since I can't access the width of individual
lines produced by formatting a block. For example, p
style=width:2emXYZ/p:, where XYZ are certain CJK line break sensitive
chars, may format to
line-break: loose
line1: XY
lline2: Z
line-break: strict
line1: X
line2: YZ
The getComputedValue('width'|'height'| of the two results doesn't vary
since one can't access the resulting lines.
If neither is possible, then you should use (1) unless the test tests a
platform specific feature; I.e. the feature isnt available on other
platforms.
The feature is not platform specific (other than the fact different
platforms may use different versions of ICU and support different fonts).
If reftest doesn't work, I'll try (1).
(3) seems like a terrible idea as it means that we'll be either exposing
the WebKit internals to the Web without standardizing those properties or
we'll be adding yet-another DRT-specific behavior
Certainly it is not be the intent to expose such props to web content in
general. But I could fathom exposing this to WK test content (without
necessarily being dependent on DRT framework).
On Tuesday, September 4, 2012, Glenn Adams wrote:
What is the recommended approach to test cases when one needs to use a
CJK font that covers the test data? I could use DRT text results as
expected but given lack of common font across platforms, that doesn't seem
to be effective.
From my somewhat limited (i.e., newbie) exposure to WK, I gather one can
take one of the following approaches:
(1) put font (and thus platform) dependent test cases in non-platform
test directory, then add entries to Skipped for other platforms; this seems
the current approach with many platform/font dependent tests, especially
related to I18N features;
(2) put font (and thus platform) dependent test cases in platform test
directory, possibly ending up with separate tests per platform;
(3) what would be nice is to not generate rendering dump from DRT but
instead use script only; since I'm testing line-breaking logic, what would
do nicely is a set of internal styles available via getComputedStyle() on a
block element:
- -webkit-line-count - numeric value indicating number of formatted
lines produced from rendering a block
- -webkit-line-chars-1 through -N, which returns the chars of line N
as formatted when rendering a block
That is, with these properties, I could use script to determine which
line breaks occurred and where. I don't care about geometries or pixels in
these particular tests, just whether breaks occur in specific contexts.
Any recommendations on whether to pursue one of (1) or (2) above, or try
the more ambitious (but more platform independent) third approach?
I suppose I could start with (1) or (2) and then pursue (3) as a
subsequent task.
Regards,
Glenn
--
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] testing strategy? - CJK line breaking tests
On Tue, Sep 4, 2012 at 11:26 PM, Dan Bernstein m...@apple.com wrote: On Sep 4, 2012, at 5:50 AM, Glenn Adams gl...@skynav.com wrote: Alternatively, you can compute the with of each character with script (without adding any new feature to WebKit). Unfortunately, that won't work since I can't access the width of individual lines produced by formatting a block. You can use Range’s getClientRects to get the widths of individual characters and to determine where a line breaks occur. Thanks for that pointer. I wasn't aware of that feature. In any case, it looks like the reftest approach is going to work. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Passing null or undefined object as input url for XMLHttpRequest open()
On Wed, Sep 5, 2012 at 12:10 AM, Joshua Bell jsb...@chromium.org wrote: On Tue, Sep 4, 2012 at 8:32 AM, Alexey Proskuryakov a...@webkit.org wrote: 04.09.2012, в 07:43, Pozdnyakov, Mikhail написал(а): req = new XMLHttpRequest(); req.open(“GET”, null); ** ** the implementation of XMLHttpRequest will try to open URL: “base URL/null“. The similar behaviour is with an undefined object given as input url (will try to open “base URL/undefined“). ** ** It does not seem to be correct behaviour and I would raise SYNTAX_ERR exception in such cases, but I would like to hear other opinions on that before creating bug and uploading patch. This is an unlikely situation to occur in real web pages, so there is neither much risk nor much benefit to this change. One way this could break a page is if it calculates a URL and erroneously ends up with a null. In this case, raising an exception would further break page logic - instead of getting error and loaded events, it will likely be stuck waiting for these forever. Could you elaborate on why this seems incorrect to you? Generally speaking, special casing just null and undefined to bypass toString conversion would be unusual and surprising. Indeed - the WebIDL for the open method is in: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#interface-xmlhttprequest The spec doesn't special case null, so coercing the |url| argument via ToString() to the DOMString null is correct. There are several places in the platform where there are special cases for null/undefined/etc for backwards compatibility with the Web, but it appears this isn't one of them. Has the original poster compared behavior in other browsers? If other browsers handle this differently than WebKit and the spec, then it should be raised on public-webapps as a spec issue. A spec change could fix this easily by adding [TreatNullAs=EmptyString] to the url parameter. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] RenderStyleConstants.h - enum naming conventions?
I'm implementing a patch for [1], namely to support the CSS3 line-break
property.
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
There is an older -{khtml,webkit}-line-break enum EKHTMLLineBreak defined
in RenderStyleConstants.h. I see that some enums use a 'E' prefix, while
others do not, e.g.,
enum ELineClampType { LineClampLineCount, LineClampPercentage };
vs
enum LineAlign { LineAlignNone, LineAlignEdges };
plus, there appears to be a different convention for enum member names,
e.g.,
enum EKHTMLLineBreak { LBNORMAL, AFTER_WHITE_SPACE };
Would it be better to have:
enum LineBreak { LineBreakNormal, LineBreakAfterWhiteSpace };
or, with the new keywords from CSS3 Text line-break, write this as:
enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
LineBreakStrict, LineBreakAfterWhiteSpace };
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderStyleConstants.h - enum naming conventions?
On Fri, Aug 24, 2012 at 3:06 PM, Glenn Adams gl...@skynav.com wrote: [or if there is a name conflict on LineBreak, then will use LineBreakType] (whether the suffice 'Type' is included also seems somewhat irregular) s/suffice/suffix/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] EditBugs permission request
Could I be enabled for EditBugs permission? I'm starting to submit patches and actively work bugs, e.g., https://bugs.webkit.org/show_bug.cgi?id=94633 https://bugs.webkit.org/show_bug.cgi?id=6148 Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EditBugs permission request
On Wed, Aug 22, 2012 at 6:42 AM, Adam Barth aba...@webkit.org wrote: On Tue, Aug 21, 2012 at 2:41 PM, Glenn Adams gl...@skynav.com wrote: Could I be enabled for EditBugs permission? I'm starting to submit patches and actively work bugs, e.g., Done. In the future, folks should feel free to ask folks (including me) on #webkit rather than emailing webkit-dev, which has many subscribers. Thanks. I did ask there first, but was referred to this ML. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.comwrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. keep in mind that you need this or something much like it to handle correct selection in some complex scripts (e.g., indic scripts) as well as bidi contexts for example, a single displayed ligature glyph may map to multiple *disjoint* characters in the original unicode text ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 1:14 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig shezbaig...@gmail.comwrote: We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. I don't think we should implement general multi-range selection. It causes all sorts of hell in editing. keep in mind that you need this or something much like it to handle correct selection in some complex scripts (e.g., indic scripts) as well as bidi contexts What do you mean by correct? I mean understandable and repeatable. Selection in bidirectional text follow logical order on all major browsers although Gecko supports a non-default option to use visual-order selection. I've talked with many native RTL speakers who have a lot of experience working with bidirectional text but they almost unanimously agreed that selecting text in visual order is a bad idea. In my experience working with middle eastern and indic display and editing systems, both (logical and visual selection) modes have legitimate uses, and one mode should not be eliminated simply because there may be a majority (of a random sample) that prefers one mode. Personally, I use both modes for different reasons. Also, when you copy the text selected by visual order and pasting it to somewhere else, we need to somehow serialize the text and the algorithm by which to do this is not well defined. Agreed. Existing specs covering browser behavior do not define this very well. My point in bringing it up was simply that there are legitimate use cases for supporting disjoint, multi-range selection. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 3:36 PM, Ryosuke Niwa rn...@webkit.org wrote: I have to admit there are some valid use cases for supporting multi-range selection but the complexity it adds to our codebase is unjustifiable. Gecko has tried this for a decade but they're now trying to get rid of it. See https://bugzilla.mozilla.org/show_bug.cgi?id=753718. One could make the same (complexity) argument (and many have) against supporting complex scripts in the first place. That is a pretty subjective argument, when certain minorities have no choice but dealing with things that many of us would find complex [look how long it took to support Tibetan|Dzongkha]. For example, one might argue that Japanese should start writing in romaji because kanji|kana is too complex. But that argument never works. Personally, I have implemented and supported disjoint, multi-range selections in a number of high-end editing products (for the preprint industry). I found this quite implementable, though admittedly not straightforward. Anyway, that's my 2 cents worth on this thread... Regards, Glenn ___ 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
[webkit-dev] mac-mountainlion port?
anyone planning to add a mac-mountainlion port/baseline soon? at present, NRWT defaults to mac-future on 10.8 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] build time - lion vs mountain lion - 200% slowdown
Just upgraded from Lion to Mountain Lion (and XCode 4.4). Clean build time went from 29mins to 1h 29mins on a new 2.6GHz 16GB MacBook Pro 15 Retina. You might want to hold off on an upgrade unless you enjoy waiting for builds. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build time - lion vs mountain lion - 200% slowdown
On Fri, Jul 27, 2012 at 2:40 PM, Mark Rowe mr...@apple.com wrote: On 2012-07-27, at 13:33, Glenn Adams gl...@skynav.com wrote: Just upgraded from Lion to Mountain Lion (and XCode 4.4). Clean build time went from 29mins to 1h 29mins on a new 2.6GHz 16GB MacBook Pro 15 Retina. You might want to hold off on an upgrade unless you enjoy waiting for builds. You didn't mention what port of WebKit you're building, but I'm going to assume you're building the Mac port. I suspect there's something isolated to your system that's caused this problem (low disk space? Spotlight indexing / Time Machine backup after the upgrade?) as I'm able to do a clean build on Mountain Lion on a MacBook Air in less time than what you're seeing. My Mac Pro's also show no obvious showdown in building relative to their days running Lion. false alarm; after doing a selfupdate/upgrade on macports, build time returned to normal; not sure what the dependency was though... [spotlight was disabled, not running time machine, and 30% disk capacity, so those weren't a factor] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
