Re: [webkit-dev] Adding ENABLE_CSS_DIRECTIONAL_FOCUS to WebCore.

[Glenn Adams]

On Fri, Jul 26, 2013 at 9:07 PM, Benjamin Poulain wrote:

> 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.

[Glenn Adams]

On Tue, Jul 23, 2013 at 12:17 AM, Kyounga Ra  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] compact ICU unicode

[Glenn Adams]

On Sat, Jun 8, 2013 at 3:15 AM, Salisbury, Mark wrote:

> Hello,
>
> What would people think about including specific ICU data tables in WTF in
> order to provide a lightweight (but functional) unicode implementation?
>

FWIW, I'd suggest you port ICU to your platform or if the size is too
large, port the portion of it that WK uses, and then use that portion.
However, I think the ICU library or even a subset should NOT be added to
WTF.


>
> On embedded systems the size of ICU is prohibitive.  Determining the right
> way to package it to make it small enough isn't simple either.
>
> A patch was reviewed once that attempted to add ICU data tables directly
> in WTF and there were two concerns:
> 1) Checking in generated files (
> https://bugs.webkit.org/show_bug.cgi?id=27305#c8)
> 2) Questions concerning if the ICU license is compatible with WebCore (
> https://bugs.webkit.org/show_bug.cgi?id=27305#c9)
>
> I believe the patch could be done differently as to not check in generated
> files.  Regarding the second concern, ICU has a very permissive license (
> http://www.icu-project.org/repos/icu/icu/trunk/license.html).  There are
> three requirements, basically that the copyright and permission notice has
> to appear with copies of the software.  I believe that is already a
> requirement for distributions of webkit that use ICU.  Except for WChar
> unicode, I believe all webkit builds now use ICU Unicode.
>
> This Unicode path could replace WCHAR_UNICODE or be introduced as a third
> option, call it what you like - BASIC_ICU_UNICODE, ICU_LITE_UNICODE,
> COMPACT_ICU_UNICODE, etc..  I think it might be valuable for other ports
> that are size conscious - the up and coming NIX port comes to mind.
>
> Thanks,
> Mark
>
> Background:
> After rebasing my WinCE port of webkit, I ran into an ASSERT in
> WebCore/platform/text/wchar/TextBreakIteratorWchar.cpp,
> acquireLineBreakIterator().  I thought I'd be able to easily fix this,
> since I had already modified how LineBreakIterator works to take prior
> context into account (on my own branch) and find line break in a stream of
> non-ASCII characters.
>
> However, the WCHAR Unicode implementation is very bare bones and does not
> even support returning the Unicode character category (
> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/unicode/wchar/UnicodeWchar.cpp#L35).
>  WCHAR Unicode was originally called WinCE Unicode, then it was properly
> renamed as it had nothing to do with WinCE.
>
> WinCE Unicode originally came in here:
> https://bugs.webkit.org/show_bug.cgi?id=27305.  The reason it was
> introduced was to save space (filesystem and RAM).  ICU, if not packaged
> very carefully (http://userguide.icu-project.org/packaging), is actually
> larger than webkit itself.  On embedded systems, this is a big deal.  The
> original plan with the bug above was to include specific ICU data tables in
> webkit.
>
> I've been compiling WTF with Unicode tables embedded for some time now.  I
> don't believe I've seen many layout test regressions due to using a
> simplified ICU implementation.
>
>
> ___
> 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?

[Glenn Adams]

On Sun, Jun 2, 2013 at 2:48 AM, Maciej Stachowiak  wrote:

>
> On Jun 1, 2013, at 8:54 PM, Glenn Adams  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  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?

[Glenn Adams]

On Sat, Jun 1, 2013 at 9:56 PM, Darin Adler  wrote:

> On Jun 1, 2013, at 8:54 PM, Glenn Adams  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?

[Glenn Adams]

You guys obviously never wrote any Lisp code.

http://books.google.com/books?id=FYoOIWuoXUIC&lpg=PA267&ots=ioaahFTKT0&dq=intern%20special%20form%20maclisp&pg=PA266#v=onepage&q=intern%20special%20form%20maclisp&f=false


On Sat, Jun 1, 2013 at 6:01 PM, Ryosuke Niwa  wrote:

> On Sat, Jun 1, 2013 at 4:45 PM, Maciej Stachowiak  wrote:
>
>>
>> On Jun 1, 2013, at 3:58 PM, Darin Adler  wrote:
>>
>> On May 31, 2013, at 8:01 PM, Glenn Adams  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?

[Glenn Adams]

On Fri, May 31, 2013 at 6:14 PM, Rafael Brandao
wrote:

> 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  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 wrote:
>>
>>>  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 wrote:
>>>
 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

[Glenn Adams]

On Thu, May 16, 2013 at 12:06 PM, Darin Adler  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

Re: [webkit-dev] obtaining webkit.org address?

[Glenn Adams]

On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams  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 wrote:
>
>> 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?

[Glenn Adams]

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 wrote:

> 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

[webkit-dev] obtaining webkit.org address?

[Glenn Adams]

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] Implement ruby-overhang

[Glenn Adams]

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 Sekiguchi
> 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

[Glenn Adams]

On Wed, Apr 10, 2013 at 1:46 AM, Eric Seidel  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

Re: [webkit-dev] Tools/BuildSlaveSupport/.../TestFailures/run-unittests.html

[Glenn Adams]

On Tue, Apr 9, 2013 at 11:15 PM, Dirk Pranke  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

[webkit-dev] Tools/BuildSlaveSupport/.../TestFailures/run-unittests.html

[Glenn Adams]

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] Unmaintained feature list

[Glenn Adams]

On Mon, Apr 8, 2013 at 5:01 PM, Ryosuke Niwa  wrote:

> On Mon, Apr 8, 2013 at 3:59 PM, Glenn Adams  wrote:
>
>>
>> On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:
>>
>>>
>>> On Apr 7, 2013, at 6:35 PM, Benjamin Poulain 
>>> wrote:
>>>
>>> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  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] Unmaintained feature list

[Glenn Adams]

On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:

>
> On Apr 7, 2013, at 6:35 PM, Benjamin Poulain  wrote:
>
> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  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] Sunsetting committership and reviewership

[Glenn Adams]

On Sun, Apr 7, 2013 at 7:27 PM, Benjamin Poulain wrote:

> 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

[webkit-dev] Upcoming Contributors Meeting

[Glenn Adams]

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] Cleaning House

[Glenn Adams]

On Thu, Apr 4, 2013 at 1:50 PM, Geoffrey Garen  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

Re: [webkit-dev] Cleaning House

[Glenn Adams]

On Thu, Apr 4, 2013 at 1:44 PM, Filip Pizlo  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

[Glenn Adams]

On Thu, Apr 4, 2013 at 12:56 PM, Geoffrey Garen  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.
>
>
> If committers are willing to do their own regression testing and
> committing, we can move forward with cleaning house. (For what it's worth,
> that's how I've always worked.)
>

I always run my own regression testing as well, but I'm using a MBP Retina,
so that makes filtering real regressions tough since images are all
non-Retina. Also, I can't regress test other platforms/ports without EWS,
so I've made good use of the chromium-linux testing in the up until now.

However, I'm not suggesting delays to house cleaning. Just pointing out
that absence of the chromium-linux EWS will have its negatives as well
until we have reliable testing (with pixel testing) on a few of the Apple
ports.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Cleaning House

[Glenn Adams]

On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham  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] Feature announcement: Web VHS API

[Glenn Adams]

On Mon, Apr 1, 2013 at 10:39 AM, Michael Saboff  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

[Glenn Adams]

On Wed, Mar 27, 2013 at 11:46 AM, Glenn Adams  wrote:

>
> On Wed, Mar 27, 2013 at 9:16 AM, Glenn Adams  wrote:
>
>>
>> On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa  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] PSA: run-webkit-tests now generates pixel results in retry

[Glenn Adams]

On Wed, Mar 27, 2013 at 9:16 AM, Glenn Adams  wrote:

>
> On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa  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

[Glenn Adams]

On Fri, Mar 22, 2013 at 3:24 PM, Ryosuke Niwa  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] Please don't leave entries for rebaseline in TestExpectation files

[Glenn Adams]

On Fri, Mar 22, 2013 at 3:07 PM, Ryosuke Niwa  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

[Glenn Adams]

On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa  wrote:

> On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams  wrote:
>
>>
>> On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa  wrote:
>>
>>>  On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams  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] Please don't land patches without rebaselining tests for at least one platform

[Glenn Adams]

On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa  wrote:

> On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams  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

[Glenn Adams]

On Thu, Mar 21, 2013 at 5:40 PM, Ryosuke Niwa  wrote:

> On Thu, Mar 21, 2013 at 4:36 PM, Glenn Adams  wrote:
>
>>
>> On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa  wrote:
>>
>>> On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams  wrote:
>>>
>>>> On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa 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.
>>
>
> 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

[Glenn Adams]

On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa  wrote:

> On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams  wrote:
>
>> On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa  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

[Glenn Adams]

On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa  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] Best practices for landing new/changed layout test expectations?

[Glenn Adams]

On Mon, Feb 25, 2013 at 6:17 PM, Ryosuke Niwa  wrote:

> On Mon, Feb 25, 2013 at 5:06 PM, Glenn Adams  wrote:
>
>>
>> On Mon, Feb 25, 2013 at 5:27 PM, Ryosuke Niwa  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] Best practices for landing new/changed layout test expectations?

[Glenn Adams]

On Mon, Feb 25, 2013 at 5:27 PM, Ryosuke Niwa  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?

[Glenn Adams]

On Mon, Feb 25, 2013 at 3:53 PM, Ryosuke Niwa  wrote:

> On Mon, Feb 25, 2013 at 2:48 PM, Dirk Pranke  wrote:
>
>> On Mon, Feb 25, 2013 at 2:05 PM, Ryosuke Niwa  wrote:
>> > On Mon, Feb 25, 2013 at 1:39 PM, Dirk Pranke 
>> 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] WebKit Perf Monitor (perf.webkit.org) has been launched

[Glenn Adams]

On Mon, Feb 25, 2013 at 12:24 PM, Ryosuke Niwa  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)

[Glenn Adams]

On Sun, Feb 10, 2013 at 11:38 AM, Darin Adler  wrote:

> Short answer, yes.
>
> On Feb 10, 2013, at 9:14 AM, Glenn Adams  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] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)

[Glenn Adams]

On Sun, Feb 10, 2013 at 10:03 AM, Balazs Kelemen  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] SerializedScriptValue: signed vs unsigned char

[Glenn Adams]

On Wed, Feb 6, 2013 at 5:35 PM, Alec Flett  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

[Glenn Adams]

On Mon, Feb 4, 2013 at 4:51 PM, Alec Flett  wrote:

> At the moment, SerializedScriptValue uses Vector (aka
> Vector) 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 Vector and Vector 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 Vector 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 Vector in order to
accommodate the LevelDB interfaces, then I would suggest you not do that.
Vector is more clear than Vector (or Vector)
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)

[Glenn Adams]

On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth  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
interface is
a function object
.

WebIDL 4.4.3 [3] states:

If the 
[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

[Glenn Adams]

On Thu, Nov 29, 2012 at 11:05 PM, Rafael Weinstein wrote:

> On Thu, Nov 29, 2012 at 9:55 PM, Adam Barth  wrote:
> > On Thu, Nov 29, 2012 at 9:23 PM, Glenn Adams  wrote:
> >> On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa 
> wrote:
> >>> On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams  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

Re: [webkit-dev] Feature announcement: HTMLTemplateElement

[Glenn Adams]

On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa  wrote:

> On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams  wrote:
>
>> On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein 
>> 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?
>>
>
> 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

[Glenn Adams]

On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein 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 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] generic test expectations?

[Glenn Adams]

On Tue, Nov 13, 2012 at 1:02 PM, Tony Chang  wrote:

> On Tue, Nov 13, 2012 at 11:35 AM, Dirk Pranke wrote:
>
>> On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams  wrote:
>> >
>> > On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke 
>> 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
>> >
>>
>> I expect it'll sort of work, but it won't be robust; you may hit weird
>> behavior and/or bugs. We really haven't beaten on this aspect of
>> things, and I don't know yet how much we want to.
>
>
> I don't think we should support port specific ref test results.  That kind
> of misses the point of using a ref test in the first place.  I mean, you
> may as well check in port specific pixel results which are easier to review
> for correctness.
>
> It may be the case that a ref test is not appropriate for what you're
> trying to test.
>

In the case of line break behavior, using reftests seem better than pixel
tests, since there is less need for port-specific expectations. If I can
come up with a text based approach (perhaps using range boundary rects),
then I'll do so, but in the mean time, reftests seem a better option,
especially for defining correctness based expectations (instead of merely
regression based expectations). But we are straying from the original topic
of this thread.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] generic test expectations?

[Glenn Adams]

On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke  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] generic test expectations?

[Glenn Adams]

On Tue, Nov 13, 2012 at 12:02 PM, Glenn Adams  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?

[Glenn Adams]

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  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  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

[webkit-dev] generic test expectations?

[Glenn Adams]

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] HbbTV support within Webkit

[Glenn Adams]

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

Re: [webkit-dev] Remove support for -webkit-auto as a specifiable value for CSS text-align property?

[Glenn Adams]

On Wed, Oct 3, 2012 at 1:20 AM, Maciej Stachowiak  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

Re: [webkit-dev] Remove support for -webkit-auto as a specifiable value for CSS text-align property?

[Glenn Adams]

On Tue, Oct 2, 2012 at 11:06 PM, Ryosuke Niwa  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  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

[webkit-dev] Remove support for -webkit-auto as a specifiable value for CSS text-align property?

[Glenn Adams]

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] WKCreateCTLineWithUniCharProvider

[Glenn Adams]

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)

[Glenn Adams]

On Sat, Sep 22, 2012 at 7:30 AM, Adam Barth  wrote:

> On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth  wrote:
> > On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak 
> 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

[Glenn Adams]

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

Re: [webkit-dev] Passing null or undefined object as input url for XMLHttpRequest open()

[Glenn Adams]

On Wed, Sep 5, 2012 at 12:10 AM, Joshua Bell  wrote:

>
> On Tue, Sep 4, 2012 at 8:32 AM, Alexey Proskuryakov  wrote:
>
>>
>> 04.09.2012, в 07:43, Pozdnyakov, Mikhail написал(а):
>>
>> req = new XMLHttpRequest();
>> req.open(“GET”, null);  
>> ** **
>> the implementation of XMLHttpRequest  will try to open URL:
>> “/null“. The similar behaviour is with an undefined object given
>> 
>> as input url (will try to open “/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

Re: [webkit-dev] testing strategy? - CJK line breaking tests

[Glenn Adams]

On Tue, Sep 4, 2012 at 11:26 PM, Dan Bernstein  wrote:

> On Sep 4, 2012, at 5:50 AM, Glenn Adams  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] testing strategy? - CJK line breaking tests

[Glenn Adams]

On Tue, Sep 4, 2012 at 8:30 PM, Ryosuke Niwa  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, XYZ, 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

[webkit-dev] testing strategy? - CJK line breaking tests

[Glenn Adams]

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] RenderStyleConstants.h - enum naming conventions?

[Glenn Adams]

On Fri, Aug 24, 2012 at 3:06 PM, Glenn Adams  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

Re: [webkit-dev] RenderStyleConstants.h - enum naming conventions?

[Glenn Adams]

On Fri, Aug 24, 2012 at 2:58 PM, Eric Seidel  wrote:

> Sorry, I was unclear.  I haven't seen someone create a new enum using
> E in years.  LineBreakType or similar would be better than
> ELineBreakType.
>
> > On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams  wrote:
> >> enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
> >> LineBreakStrict, LineBreakAfterWhiteSpace };
>

Thanks, I will take that as a +1 to go with changing EKHTMLLineBreak to:

enum LineBreak { LineBreakAuto, LineBreakLoose,
LineBreakNormal, LineBreakStrict, LineBreakAfterWhiteSpace };

[or if there is a name conflict on LineBreak, then will use LineBreakType]
(whether the suffice 'Type' is included also seems somewhat irregular)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] RenderStyleConstants.h - enum naming conventions?

[Glenn Adams]

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] EditBugs permission request

[Glenn Adams]

On Wed, Aug 22, 2012 at 6:42 AM, Adam Barth  wrote:

> On Tue, Aug 21, 2012 at 2:41 PM, Glenn Adams  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

[webkit-dev] EditBugs permission request

[Glenn Adams]

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] Disjointed selection ranges

[Glenn Adams]

On Tue, Aug 14, 2012 at 3:36 PM, Ryosuke Niwa  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

Re: [webkit-dev] Disjointed selection ranges

[Glenn Adams]

On Tue, Aug 14, 2012 at 1:43 PM, Ryosuke Niwa  wrote:

> On Tue, Aug 14, 2012 at 1:14 PM, Glenn Adams  wrote:
>
>>
>> On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa  wrote:
>>
>>> On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig wrote:
>>>>
>>>> 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

[Glenn Adams]

On Tue, Aug 14, 2012 at 12:25 PM, Ryosuke Niwa  wrote:

> On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig wrote:
>>
>> 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

[webkit-dev] is platform/mac baselined for ML (mountain lion)?

[Glenn Adams]

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?

[Glenn Adams]

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

Re: [webkit-dev] build time - lion vs mountain lion - 200% slowdown

[Glenn Adams]

On Fri, Jul 27, 2012 at 2:40 PM, Mark Rowe  wrote:

>
> On 2012-07-27, at 13:33, Glenn Adams  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

[webkit-dev] build time - lion vs mountain lion - 200% slowdown

[Glenn Adams]

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