from:"\"Maciej Stachowiak\""



On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:




I think 80 columns is a waste of time and hurts readability.

Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.

The optparse code which was recently re-wrapped is one example of 80c
fail.  Impossible to tell in the wrapped version which arguments are
actually being listed (first argument to the function) because your
eye can't parse the start of each line.

That said.  I'd rather have you and Adam and Chris all working on the
Python than have folks lose interest due to code wrapping.  If the
consensus is 80c, I'll learn to deal. :)

The choice is either:
A. no wrapping rule to match the rest of WebKit
B. 80c to match the official PEP8 spec (and Google code).

I've chosen A. in the past.  Mostly to match my own personal bias  
I'm sure.


I haven't contributed to WebKit's Python code yet, but I will say that  
I agree with Eric's sentiments here. 80-column limit is archaic and  
pointless. No one is developing WebKit on a vt220.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake as a build system?



On Apr 16, 2010, at 2:45 PM, Adam Treat wrote:

Sure.  Having Bill's and Kitware's help will hopefully make it  
easier to

produce such a demo using CMake.  I pledge to help.

We can start with this:

http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853


Can CMake generate native Xcode and Visual Studio project files? There  
are some people who consider it important to be able to edit, build  
and debug in the IDE.

Can it handle generated sources well?

I think those are the two toughest problems for any candidate unified  
build system.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [webkit meeting notes] build systems



On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote:



Am 16.04.2010 um 16:44 schrieb Adam Treat:

I am very skeptical that it is feasible to write a gyp generator  
that would
output QMake files.  There is a log of magic in those QMake files.   
My sense is

that it would not be trivial by any means.

Plus, I don't like the idea of a meta-meta generators.  Seems way  
to mickey-

mouse to me.


Agreed to a certain degree. Using gyp/whatever to generate qmake  
files, to generate Makefile/Xcode files etc seems akward to me as  
well.


What we really need to resolve is adding/removing files from  
compilation, that's the most common

task that has to be done in 5+ build systems at the moment.


Besides adding, removing and renaming, the other thing that's really  
hard is adding a new generated source rule. Although this is not  
needed as frequently, I think anyone adding a new code generator  
script that has to work across all WebKit ports would have a hellish  
time of it right now.


If I had to do it myself, I would just skip any ports that don't use  
DerivedSources.make.




So I have a new proposal:

1) Maintain a list of headers/source files to be compiled for ALL  
platforms (ie. dom/Node.cpp, etc..)


2) Keep all existing Makefile.am, WebCore.pro etc files as  
"templates", ie. WebCore.pro.template, with a special
   variable somewhere marking the $$HEADER_LIST$$ and the $ 
$SOURCE_LIST$$


3) Use a script that generates individual build files (eg.  
WebCore.pro) from WebCore.pro.template, it only
   needs to insert the file list with the correct syntax in the  
correct places


4) Keep all platform specific files to be compiled in the individual  
build system files (eg. WebCore.pro.template)


I think we'll never find a consensus on a single build system, there  
are too many different needs. I only care
about the most repetitive work in order to keep the build system  
up2date: adding/removing cross-platform files.


I think the proposal above does not handle the derived sources  
problem. It also doesn't handle files that are shared between multiple  
ports but not all ports. It also doesn't provide project files that  
are directly usable by IDEs, on platforms where that is the standard  
way to do development.


Once we start solving problems like that, I suspect we end up with  
something closer in complexity to Gyp or CMake.


Regards,
Maciej


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake as a build system?



On Apr 16, 2010, at 3:25 PM, Adam Treat wrote:


On Friday 16 April 2010 06:21:39 pm Maciej Stachowiak wrote:

On Apr 16, 2010, at 2:45 PM, Adam Treat wrote:

Sure.  Having Bill's and Kitware's help will hopefully make it
easier to
produce such a demo using CMake.  I pledge to help.

We can start with this:

http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853


Can CMake generate native Xcode and Visual Studio project files?  
There

are some people who consider it important to be able to edit, build
and debug in the IDE.
Can it handle generated sources well?


It was designed to do precisely that :)  Bill can speak to this, but  
the

google tech talk gives a great overview.


I'm curious if the Chromium folks who created Gyp had any specific  
reason that they ruled out CMake as an option. (I have heard that it  
was considered and rejected.)


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake as a build system?



On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote:

On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting   
wrote:
On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak   
wrote:


I'm curious if the Chromium folks who created Gyp had any specific  
reason
that they ruled out CMake as an option. (I have heard that it was  
considered

and rejected.)




I belive I can answer that.  During my talk at google, I met with with
Mark Mentovai and talked to him about Gyp and CMake.  The main thing
that he was trying to avoid was the requirement that CMake be
installed for the build.  That is true, CMake does have to be
installed.  However, CMake is installed on more an more systems.   The
cmake.org site has about 2K downloads per day, and most linux distros
include CMake.   With KDE using CMake, it has become pretty easy to
get.   Apple is also using CMake for the LLVM project, so it should be
installed and accepted at Apple.  I worked with Doug Gregor of the
LLVM team to help him convince the Apple testing folks to allow for
CMake to be installed.


FWIW, I don't have CMake installed, and I have everything a typical  
Apple developer would have and then some. I'm running SnowLeopard and  
the latest Xcode. CMake is also not installed by default on Windows  
and I am not sure if it comes with the cygwin distribution we use.


When you say "installed", does that mean it *has* to be in some system  
location? Could it be "installed" somewhere in the WebKit build tree?  
Our scripts download certain needed tools and libraries by default, so  
at least from the WebKit POV this is not necessarily a showstopper.


Also: how hard is the dependency on being "installed"? Is this a  
solvable problem if it turns out to be a showstopper for some folks?



And finally, I'd still like to hear from the Chromium folks whether  
there were any other issues. This one seems fairly minor.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake as a build system?



On Apr 16, 2010, at 6:58 PM, Bill Hoffman wrote:

On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak   
wrote:
FWIW, I don't have CMake installed, and I have everything a typical  
Apple
developer would have and then some. I'm running SnowLeopard and the  
latest
Xcode. CMake is also not installed by default on Windows and I am  
not sure

if it comes with the cygwin distribution we use.



It can come with cygwin, and nothing is installed on Windows by
default, not even the compiler...   Macports has CMake, and of course
we have binaries at cmake.org.


We can make binaries available through a convenient download script  
(possibly one that gets a source drop and builds it) if we have to. In  
fact, when WebKit first switched to Subversion, for a while you had to  
get your own copy to even check out the tree.


All I'm saying is that it's not *currently* installed out of the box  
on Mac OS X.




When you say "installed", does that mean it *has* to be in some  
system
location? Could it be "installed" somewhere in the WebKit build  
tree? Our
scripts download certain needed tools and libraries by default, so  
at least

from the WebKit POV this is not necessarily a showstopper.



It can be "installed" anywhere.   There are binaries for all marjor
OS's on www.cmake.org.  It is setup to run from any directory, so you
don't need root or anything to install.

http://www.cmake.org/cmake/resources/software.html


So by "installed" we're just talking about the fact that it's an  
executable, not a script?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] CMake as a build system?



On Apr 16, 2010, at 7:17 PM, Bill Hoffman wrote:

On Fri, Apr 16, 2010 at 10:10 PM, Marc-Antoine Ruel > wrote:

Thanks Nico for digging up the archive.
As I said in the other thread, the people at the session mostly  
looked about
reducing the number of build system, not forcing anyone to use any  
tool. If
some teams wants to switch to CMake, prefect as long as the number  
of build
tool reduces. Nobody seemed willing to switch to qtmake. Nobody at  
the

meeting advocated for CMake.
I don't have first-hand experience about CMake but from I only  
heard midly
negative comments. The generated xcodeproj and vcproj are far from  
'native'
and from f2f discussion, at least one llvm guy isn't happy about  
CMake and

would rather move it off. The 'native' IDE feel was very high in our
priority list, especially in XCode in fact.



It is as native as we can make it.   However, we do call cmake during
the build at some points, to overcome shortfalls of the build tool.
Also, to re-run cmake if any of the input files change. Also, basic
system commands like cp can be done with cmake -E copy_file so it is
portable.


Calling cmake during the build would likely be a showstopper for the  
Mac port. As far as I know, Apple's build farm does not have CMake  
installed (at least not on older build trains). And it's not easy to  
convince the build engineers to install custom build tools.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [webkit meeting notes] build systems

2010-04-17 Thread Maciej Stachowiak



On Apr 17, 2010, at 11:11 AM, Kevin Ollivier wrote:



True, but I think the real problem that we're not addressing in this  
discussion is that different ports have different sets of  
requirements, meaning their own evaluation process would lead them  
to choose different tools. If we want a 'one size fits all' build  
system, the first step is getting each port to come together and  
consolidate the requirements, and there will most likely need to be  
some compromises involved as some ports may have to agree to move to  
a tool that's not really as well suited for their project as the one  
they're using now.


It's true that different ports have different requirements. So far,  
this has resulted in every port choosing a different build system.  
While in some ways this may be convenient for individual ports, it  
creates negative externalities for the project as a whole.


That being said, we're not trying to convert to one true build system  
right now, merely seeing if we can reduce the number by having more  
ports share a build system.


We're even considering changing the build system for Apple's ports (in  
fact the Apple Windows port may be one of the first experiments).


For example, a primary reason tools like Gyp and Bakefile exist is  
that for some people, lack of a 100% native IDE-based build system  
is a deal breaker. For others, like myself, I want low maintenance,  
completely cross-platform, highly automated and highly scriptable,  
which are actually features the IDE projects don't fare very well  
in. So one man's feature is another man's drawback.


There are also factors besides features that are important as well.  
I think it's also important to remember that from each port's  
perspective, one potentially big factor in build system choice is  
also making users comfortable with contributing. For GTK, for  
example, that may mean that using autotools, the build system most  
likely to be familiar to potential contributors, is in part a way of  
making contributing a little less intimidating on a big project like  
WebKit. Similar with qmake, XCode, etc. I think that a big part of  
build system decision making is based not necessarily around  
features, but around being in the developers' comfort zones. So my  
gut impression is that it's going to be very difficult to find an  
existing tool that solves all the issues like this for most / all  
ports in a way that makes everyone happy.


As the saying goes, sometimes the perfect is indeed the enemy of the  
good. I personally think a quick and simple solution along the lines  
of what Nikolas and I were talking about maybe the only short term  
improvement that is viable. Everything else is looking more long- 
term, and requires both a lot of effort and a lot of collaboration  
among ports. To the point that, as a practical matter, I'm not sure  
if the system would save more time than it would take to develop.  
That's not to say such a system won't be developed, but absent some  
sponsorship of the project or some highly motivated hackers, I don't  
know how we plan on getting there.


I just think this subject has come up numerous times, and each time  
the discussion ended without any improvements being made, so I worry  
that so long as we wait for the perfect system to come along, we're  
not going to build the good system that can make life better today.


I would put that the other way around. Gyp exists today and knows how  
to generate an Xcode project. The templating solution that can  
generate an Xcode project while seeming less intrusive to Bakefile and  
Automake users is completely hypothetical. Anyone who wants to is  
welcome to try to code it, but my expectation going in is that it  
would evolve to be as complex as Gyp.


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Loader diagram from yesterday's session

2010-04-17 Thread Maciej Stachowiak



On Apr 17, 2010, at 5:22 PM, Adam Barth wrote:


I took the liberty of cleaning up this diagram in sketchy:

http://webblaze.org/abarth/webkit-loader.html

If folks find this diagram useful, we can add it to the web site.



Looks good, throw it on the wiki maybe? (You can include images on a  
wiki page by making them attachments first, that's what I did for the  
diagrams on ).


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

2010-04-18 Thread Maciej Stachowiak



On Apr 18, 2010, at 12:33 PM, Chris Jerdonek wrote:


I wanted to add a couple comments and a question to this discussion.

On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak   
wrote:


I haven't contributed to WebKit's Python code yet, but I will say  
that I
agree with Eric's sentiments here. 80-column limit is archaic and  
pointless.

No one is developing WebKit on a vt220.


Note that there are contexts where the limit does come into play  
that the
user might not have as much control over, for example pasting into  
the body

of an e-mail or into the comment box in bugs.webkit.org.


That reminds me, we should turn off the 80-column limit on bugs.webkit.org 
 - there's no need for it to hard-wrap your text. That being said,  
we've lived for years with the fact that C++ code may get wrapped  
badly in these contexts and it hasn't really been an issue.




Take a look at these two comments for example (which, incidentally,  
are

about crash logs rather than code):

https://bugs.webkit.org/show_bug.cgi?id=23558#c4
https://bugs.webkit.org/show_bug.cgi?id=36707#c1

So non-Python developers know, one argument for treating Python  
differently
(aside from PEP8) is that the language supports a syntax for  
continuing
lines to the next line that other languages don't (implied line  
continuation).


Finally, just to clarify, which parts of PEP8 are we discussing  
ignoring?
PEP8 has more specific guidelines for docstrings and how they should  
be
formatted.  For instance, it also contains this guideline in  
addition to
the blanket 79-character limit:  "For flowing long blocks of text  
(docstrings

or comments), limiting the length to 72 characters is recommended."


I'm happy to let the people who hack on Python most decide whether a  
column limit is appropriate and if so which ones.


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Update: new-run-webkit-tests migration

2010-04-19 Thread Maciej Stachowiak



On Apr 18, 2010, at 11:57 PM, Eric Seidel wrote:


new-run-webkit-tests is getting closer for general project-wide use.
If you're on a Mac and would like to experience sub-3-minute layout
test runs and are willing to deal with a few bugs, try
new-run-webkit-tests instead of run-webkit-tests next time you run the
tests.  We'd love to see questions/comments/complaints you have.

Additionally, run-webkit-tests was renamed to old-run-webkit-tests and
run-webkit-tests is now a perl script which automatically choses
old-run-webkit-tests or new-run-webkit-tests depending on your
platform/config. [1]  Right now it always uses old-run-webkit-tests.

We will be running trial conversions of a few of the builders later
this week. [2]  These conversions will happen outside of normal work
hours and should be invisible to the end users and bot administrators.


Thanks for the heads-up. A few questions:

- Will these be permanent or temporary conversions?
- Which trains will be converted?
- Is there anyone to contact besides you if anything goes wrong?

Regards,
Maciej


P.S. I would personally prefer to see at least the following bugs  
fixed before any bot is permanently converted to using new-run-webkit- 
tests:


https://bugs.webkit.org/show_bug.cgi?id=37736
https://bugs.webkit.org/show_bug.cgi?id=37738
https://bugs.webkit.org/show_bug.cgi?id=37739



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Update: new-run-webkit-tests migration

2010-04-19 Thread Maciej Stachowiak





On Apr 19, 2010, at 1:26 AM, Eric Seidel wrote:





[snip answers to questions, which sound good to me]

P.S. I would personally prefer to see at least the following bugs  
fixed
before any bot is permanently converted to using new-run-webkit- 
tests:


https://bugs.webkit.org/show_bug.cgi?id=37736
https://bugs.webkit.org/show_bug.cgi?id=37738
https://bugs.webkit.org/show_bug.cgi?id=37739


Those are all good bugs.  Dirk, Adam, Chris and I are all continuing
to improve new-run-webkit-tests.  Others should feel encouraged to
hack on it as well.


I'm starting out with filing bugs, if any turn out to be within the  
scope of my meager Python skills, I may attempt fixing as well.


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Experimental new code reviews

2010-04-19 Thread Maciej Stachowiak

I heard another group coded up a different approach to improving
reviews - does anyone have a URL for that, so we can compare?

Cheers,
Maciej

On Apr 19, 2010, at 3:35 PM, Ojan Vafai wrote:

At the hackathon last Tuesday, a few of us put together mashup style
rietveld integration with bugs.webkit.org. It currently requires a
chrome extension. We'll integrate properly with bugzilla based on
feedback if this seems to be a value add for the project.

http://webkit-rietveld.googlecode.com/svn/trunk/chrome-extension/webkit-cr.crx

You can try it out on the *last* attachment on https://bugs.webkit.org/show_bug.cgi?id=37531
.

You'll see another link next to each attachment labelled "Fancy
Review". This loads a page much like the current review page, but
with wkrietveld.appspot.com in the top frame (wkrietveld is our fork
of rietveld). You can then make comments in rietveld. When you click
the submit button, the comments are published *both* in Reitveld and
to bugs.webkit.org.

We do not intend to remove the old code review system for people who
prefer to stick to that.

Known issues:
-Currently, only works with patches that are uploaded using "webkit-
patch upload --fancy-review".
-Due to using a chrome extension rather than a tighter integration,
some things are a bit janky (e.g. the initial load).
-Each time a patch is uploaded, it currently creates a new rietveld
issue.

Ojan ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5



On Apr 19, 2010, at 11:58 PM, Aaron Boodman wrote:

On Mon, Apr 19, 2010 at 5:53 PM, Peter Kasting   
wrote:
On Thu, Apr 15, 2010 at 3:41 PM, Aaron Boodman   
wrote:


I'm not sure what the path is for fetching favicons today. Does
WebCore just implicitly do it, or does it expose the information to
the host, who later may or may not make the request?


Answering this is complicated by the fact that Chromium mostly uses a
different codepath for all of this stuff than, say, Safari -- e.g. it
bypasses the IconDatabase and pretty much all other classes/files  
called

"IconXXX" entirely.


Yeah, I looked into this over the weekend, and -- shock! -- it turned
out to be a bigger change than I initially imagined. Since Chromium
has a different backend, that would mean implementing two sets of
changes.

Also, I think it would be wasteful to have WebKit download all linked
icons, even if the hosting browser has no intention of every using
some of them. So I'd want to add code to allow the browser to tell
WebKit which sizes it is interested in.

I still want to do this, but I'm going to have to reduce the priority
a little bit for now. I may come back to it in a month or so.


You'd probably want an API that lets the embedding app request a  
particular icon size, and picks the best fit from the icon links  
available, taking into account size=any as well. Possible niceties -  
return windows-style .ico or mac-style .icns either if explicitly  
specified, or synthesized from available sizes. Not sure if there is a  
conventional multisize icon format on other platforms.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] CMake vs. Apple's build farm



On Apr 16, 2010, at 7:39 PM, Maciej Stachowiak wrote:



On Apr 16, 2010, at 7:17 PM, Bill Hoffman wrote:



It is as native as we can make it.   However, we do call cmake during
the build at some points, to overcome shortfalls of the build tool.
Also, to re-run cmake if any of the input files change. Also, basic
system commands like cp can be done with cmake -E copy_file so it is
portable.


Calling cmake during the build would likely be a showstopper for the  
Mac port. As far as I know, Apple's build farm does not have CMake  
installed (at least not on older build trains). And it's not easy to  
convince the build engineers to install custom build tools.


Here is what I have learned about this, and unfortunately it is bad  
news for CMake:


1) None of the Mac builders have CMake installed.
2) The organization that maintains the Mac builders is not willing to  
let teams use any build systems to build that do not come with the OS,  
or to install any custom binaries on the builders, because builds need  
to be reproducible.
3) CMake is not part of the standard Mac OS X install for any shipping  
version of Mac OS X.
4) LLVM compiles using a separate Makefile-based (and apparently  
autoconf and autogen based) build system in OS builds.

5) LLVM uses CMake to build on Windows.
6) The build organization is more willing to install custom tools on  
Windows builders.


I think this rules out using CMake to build the mac port. Even if we  
got it set up, we'd need to maintain some kind of parallel build  
system for production builds via the build farm, which would negate  
the benefit. It might be possible to use CMake for Apple's Windows  
port, but if we switch away from native project formats at all,  
ideally we'd like to switch both ports to the same build system.


Since gyp does not require any special software to be installed merely  
to build, it seems like a more plausible option at the moment.


Note: this is not to hate on CMake, I just don't want to end up in a  
position where we have to maintain two parallel build systems for the  
Mac port, or fight with other organizations about the operation of the  
build farm. Requiring CMake to be installed at build time seems like a  
showstopper from that point of view.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] MD5 in WebCore



On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

I'm implementing new protocol of WebSocket ( http://www.whatwg.org/specs/web-socket-protocol/ 
 ).
Since it now requires MD5 in handshake, I wonder how I could add MD5  
in WebCore.  For now, there is no MD5 in WebCore.  It is in  
WebKitTools/DumpRenderTree to get message digest of image file.


I'm thinking to add new header file as WebCore/platform/MD5.h, which  
provides the following functions.


  struct MD5_CTX;
  void MD5_Init(MD5_CTX*);
  void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
  void MD5_Final(unsigned char hash[16], MD5_CTX*);

In Windows platform, it is implemented using "Cryptdll.dll".   Is it  
ok to copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/ 
platform/win/MD5.cpp, or move?
In Mac platform, it is provided by   
with #define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy  
this in WebCore/platform/chromium, or add dependency to base from  
WebCore?
How about other ports?  is it ok to link openssl or some other  
library?  (or use implementation used in chromium?)


I'm also wonder I need to put these functions in namespace WebCore.


If you put this code in WebCore, it should go in the WebCore  
namespace. I think it would also be a good idea to turn the API into  
something more WebCore-ish, something like:


namespace WebCore {

class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was  
MD5_Update ; or maybe this should take a Vector?

Vector checksum(); // what was MD5_Final
};
}

(The key point being to match the coding style guidelines for names,  
but it also seems better to use a class here instead of a struct and  
functions that take a pointer to it.)


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] MD5 in WebCore



On Apr 20, 2010, at 11:48 AM, Michael Nordman wrote:

In webcore, should we use the same impl on all platforms rather than  
use cryptdll on windows and md5.cc elsewhere?


For chrome, I don't think we can have a dependency between WebKit/ 
WebKit/chromium and /src/base/, and 'base' depending on 'webkit'  
also doesn't work. How can we avoid replicating the code? I guess  
having webcore's MD5 be platform specific could help us along those  
lines?


I'd rather use a platform-independent MD5 implementation in WebCore if  
possible.


Since the MD5 code itself has (presumably) minimal dependencies,  
perhaps we could put it in WTF. I don't know if that would help  
Chromium's dependency issues.


Regards,
Maciej




On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak   
wrote:


On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

I'm implementing new protocol of WebSocket ( http://www.whatwg.org/specs/web-socket-protocol/ 
 ).
Since it now requires MD5 in handshake, I wonder how I could add  
MD5 in WebCore.  For now, there is no MD5 in WebCore.  It is in  
WebKitTools/DumpRenderTree to get message digest of image file.


I'm thinking to add new header file as WebCore/platform/MD5.h,  
which provides the following functions.


  struct MD5_CTX;
  void MD5_Init(MD5_CTX*);
  void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
  void MD5_Final(unsigned char hash[16], MD5_CTX*);

In Windows platform, it is implemented using "Cryptdll.dll".   Is  
it ok to copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/ 
platform/win/MD5.cpp, or move?
In Mac platform, it is provided by   
with #define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy  
this in WebCore/platform/chromium, or add dependency to base from  
WebCore?
How about other ports?  is it ok to link openssl or some other  
library?  (or use implementation used in chromium?)


I'm also wonder I need to put these functions in namespace WebCore.


If you put this code in WebCore, it should go in the WebCore  
namespace. I think it would also be a good idea to turn the API into  
something more WebCore-ish, something like:


namespace WebCore {

class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was  
MD5_Update ; or maybe this should take a Vector?

Vector checksum(); // what was MD5_Final
};
}

(The key point being to match the coding style guidelines for names,  
but it also seems better to use a class here instead of a struct and  
functions that take a pointer to it.)


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] MD5 in WebCore

On Apr 20, 2010, at 12:45 PM, Jeremy Orlow wrote:

Agreed.  Can you give us a pointer to the email thread this decision  
was made on?

Discussion was on the IETF hybi list (which is trying to standardize  
the WebSocket protocol). I encourage anyone in the WebKit community  
who is interested in WebSocket to join the hybi list: https://www.ietf.org/mailman/listinfo/hybi

On Tue, Apr 20, 2010 at 12:12 PM, Alex Russell  
 wrote:

Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.

In the case of WebSocket protocol, the hash doesn't need to be  
cryptographically secure. Forging the hash is not a consideration. To  
give a rough outline, the hash is used like this:

1) The browser sends a few pieces of information to the server  
(including the Origin, a string specifically identifying the WebSocket  
protocol, etc).

2) The server combines some of this info and computes a hash.
3) The hash is returned to the client, which verifies it.

Steps 2 and 3 are the ones that use MD5. The reason for this handshake  
is to defend against cross-protocol attacks. The server responds with  
information based on unique parts of the request, to avoid the  
likelihood that a response from a non-WebSocket server won't  
accidentally look like a valid handshake. A hash is used to reduce the  
risk that a server that just echoes back pieces of the response may  
look like a valid handshake respnse.

I don't believe a cryptographically secure hash is needed here, it  
could have been something as simple as CRC-32, for example. I think  
the reason to pick MD5 was that it's well known and widely available  
as a library for many popular programming languages.

Regards,
Maciej

On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman  
 wrote:
> In webcore, should we use the same impl on all platforms rather  
than use

> cryptdll on windows and md5.cc elsewhere?
> For chrome, I don't think we can have a dependency between
> WebKit/WebKit/chromium and /src/base/, and 'base' depending on  
'webkit' also

> doesn't work. How can we avoid replicating the code? I guess having
> webcore's MD5 be platform specific could help us along those lines?
>
> On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak   
wrote:

>>
>> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>>
>> I'm implementing new protocol of WebSocket
>> ( http://www.whatwg.org/specs/web-socket-protocol/ ).
>> Since it now requires MD5 in handshake, I wonder how I could add  
MD5 in

>> WebCore.  For now, there is no MD5 in WebCore.  It is in
>> WebKitTools/DumpRenderTree to get message digest of image file.
>> I'm thinking to add new header file as WebCore/platform/MD5.h,  
which

>> provides the following functions.
>>   struct MD5_CTX;
>>   void MD5_Init(MD5_CTX*);
>>   void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
>>   void MD5_Final(unsigned char hash[16], MD5_CTX*);
>> In Windows platform, it is implemented using "Cryptdll.dll".   Is  
it ok to
>> copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/ 
win/MD5.cpp,

>> or move?
>> In Mac platform, it is provided by   
with

>> #define COMMON_DIGEST_FOR_OPENSSL ?
>> In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy  
this in

>> WebCore/platform/chromium, or add dependency to base from WebCore?
>> How about other ports?  is it ok to link openssl or some other  
library?

>>  (or use implementation used in chromium?)
>> I'm also wonder I need to put these functions in namespace WebCore.
>>
>> If you put this code in WebCore, it should go in the WebCore  
namespace. I
>> think it would also be a good idea to turn the API into something  
more

>> WebCore-ish, something like:
>> namespace WebCore {
>> class MD5 {
>> MD5(); // what was MD5_Init
>> addBytes(uint8_t* input, size_t length); // what was  
MD5_Update ;

>> or maybe this should take a Vector?
>> Vector checksum(); // what was MD5_Final
>> };
>> }
>> (The key point being to match the coding style guidelines for  
names, but
>> it also seems better to use a class here instead of a struct and  
functions

>> that take a pointer to it.)
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/web

Re: [webkit-dev] Implementing HTML5 context menus

2010-04-21 Thread Maciej Stachowiak



On Apr 21, 2010, at 5:06 PM, Drew Wilson wrote:

Has anyone done any work/investigation towards implementing the  
context menu support in HTML5 (the "contextmenu" attribute and  
 elements with type="contextMenu") as described here: http://www.w3.org/TR/html5/interactive-elements.html#context-menus 
 ?


I didn't see anything from a quick browse through the source code,  
and also haven't seen much traffic on webkit-dev on the subject. The  
spec itself seems to be at "Last call for comments" so it seems like  
it should be stable enough to start implementation. One of the  
members of my team has expressed some interest in working on this if  
there's no implementation already underway.


No one has started on this yet. This part of the spec has never been  
implemented by anyone, so I suspect that if WebKit does the first  
implementation, we will likely need to give input to the relevant  
standards groups, and I suspect that we'll probably run into issues  
that require changes to the spec. That's not to say we shouldn't do  
it, but rather, whoever is working on this should be prepared to  
communicate with the standards groups on this feature.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JSC String re-factorings are hosing the tree.

2010-04-22 Thread Maciej Stachowiak



On Apr 21, 2010, at 3:35 PM, Ojan Vafai wrote:

On Wed, Apr 21, 2010 at 3:27 PM, Gavin Barraclough > wrote:
I believe a big problem that caused the extended periods of redness  
was the slowness of the Windows test queues.  These can lag badly  
behind the builds, making failures here very are easy to miss -  
having landed a large change, and waited to watch the waterfall stay  
green for an extended period of time, it was easy to be under the  
misapprehension that everything was okay.  Only later would I  
discover windows test had started to fail.  Clearly there is a  
lesson I've learned here, but maybe we can find some more hardware  
to throw at these queues, to help them avoid getting quite so far  
behind.


I also have had this problem many times. Throwing more hardware at  
it would be great.


Also, maybe we could use one of the Windows test bots for the  
initial trial of new-run-webkit-tests. Do we know how may cores are  
on those windows machines? The improvement in running the tests will  
be roughly proportional to the number of cores on the machine.


That will improve the time running the tests, but I think the slow  
thing on Windows bots is building, and I believe that is because they  
are not doing parallel builds that take advantage of their multiple  
cores. I suspect Windows builders fall behind whenever there is a  
sequence of changes that each requires a long rebuild.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trouble reviewing patches since the experimental commenting support went into bugs.webkit.org's action=review page

2010-04-22 Thread Maciej Stachowiak

Seems like the most critical issue is that old-style review is broken.  
Perhaps the comment field can be cleared with a button, or we could  
add a button to paste the full patch. Other issues seem like iterative  
refinements we could do over time.


 - Maciej



On Apr 22, 2010, at 1:09 PM, Adam Barth  wrote:


How would you like me to address this issue?

Adam


On Thu, Apr 22, 2010 at 1:01 PM, Darin Adler  wrote:
I’m having trouble reviewing patches with the action=review patch  
since the experimental commenting support was added. I now have to 
 do a lot of editing and copying and pasting when reviewing that w 
as not necessary before.


- The action=review JavaScript code now deletes the copy of the  
patch, so I can't cite things by hand. Before I would never need to  
copy and paste when reviewing, just delete things, but now if I do  
want to cite more than one line I need to open another window.


- The comments all cite only a single line of the patch and I  
almost never have a comment that's for a single line. So I have to  
do a lot of editing, pretending to comment on multiple lines.


(The action=review JavaScript  page still includes an entire copy  
of the patch, and then the script code deletes it. Inelegant, and  
easy to fix!)


   -- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Mozilla -moz-any() selectors extension

2010-04-24 Thread Maciej Stachowiak



Do we want a -webkit version of this?

http://dbaron.org/log/20100424-any

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Maciej Stachowiak



On Apr 29, 2010, at 10:54 AM, Adam Barth wrote:



It would be great to have a tool that generates a diff of derived  
sources
for inspection, but making it into a test for everyone to maintain  
feels
like unnecessary burden. I certainly would feel bad about having to  
maintain

a test that verifies source file content instead of behavior.


You should feel free to develop a better testing harness.  This one
certainly isn't best conceivable tool, but it's better than what we
had previously, which was essentially the C++ compiler.

The maintenance is super easy.  I've been doing a lot of development
work on the code generator in the past few days, and it amounts to
typing a single command:

./WebKitTools/Scripts/run-bindings-tests --reset-results

The harness has been super useful in working on the code generator
because the tests run in a few seconds.  That lets me iterate on the
script much more quickly compared to rebuilding the world every time I
want to try a tweak.


It also strikes me as odd to do testing by doing exact comparison of  
the generated source. But I can also see side benefits. I think the  
real issue here may be one of naming. If the use model is that you  
fully regenerate the results every time you make a change to the  
bindings generator, then it's not really a regression test. The  
purpose is not to catch unintentional changes but rather to be able to  
observe changes to generated code, and new kinds of generated code,  
while working on a change and when reviewing code. Perhaps the tool  
should have a name that reflects that, instead of implying that the  
purpose is to catch bugs accidentally introduced by changes. It  
doesn't seem like an efficient or effective way to do the latter.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Maciej Stachowiak



On Apr 29, 2010, at 11:38 AM, Ojan Vafai wrote:

I don't really follow the argument against supporting this test.  
What is the maintenance overhead? Isn't this just like having a  
layout test with expected results? It's a small isolated test  
instead of testing everything. That seems like a good thing.


More importantly, it lets you be sure that every feature of the code  
generator has some testing. In the real IDLs, a feature might stop  
getting used temporarily and then changes to the code generator  
would not be readily apparent.


I don't think your comments above are responsive to my paragraph below:



On Thu, Apr 29, 2010 at 11:05 AM, Maciej Stachowiak   
wrote:


It also strikes me as odd to do testing by doing exact comparison of  
the generated source. But I can also see side benefits. I think the  
real issue here may be one of naming. If the use model is that you  
fully regenerate the results every time you make a change to the  
bindings generator, then it's not really a regression test. The  
purpose is not to catch unintentional changes but rather to be able  
to observe changes to generated code, and new kinds of generated  
code, while working on a change and when reviewing code. Perhaps the  
tool should have a name that reflects that, instead of implying that  
the purpose is to catch bugs accidentally introduced by changes. It  
doesn't seem like an efficient or effective way to do the latter.




To repeat, I think this is a useful tool, but not necessarily as a test.

The mode of operation is that when you run this test, if the generated  
bindings for the text IDL file change in any way, it reports a  
failure. Then you must manually take the step of regenerating the  
golden master file. It doesn't seem like the failure report itself  
will result in a decision. It doesn't provide interesting information  
until you regenerate the test file and look at the diffs, except in  
the highly unusual case of changing the output of the codegen script  
unintentially. Most changes to the codegen script are to intentionally  
change the output.


It seems to me a better model would be to regenerate the bindings test  
file automatically as part of the build. Then the changes can still be  
reviewed by you, or as part of a diff, but there would be no extra  
manual steps involved. And people making behaviorally transparent  
changes to codegen output would perhaps feel a little less burdened.


That makes more sense to me than treating it as a regression test. It  
also seems like this model would still have all the benefits you cite  
above.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Testing changes to CodeGenerator*.pm

2010-04-29 Thread Maciej Stachowiak




On Apr 29, 2010, at 1:05 PM, Adam Barth wrote:

On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak   
wrote:


It seems to me a better model would be to regenerate the bindings  
test file
automatically as part of the build. Then the changes can still be  
reviewed
by you, or as part of a diff, but there would be no extra manual  
steps
involved. And people making behaviorally transparent changes to  
codegen

output would perhaps feel a little less burdened.


That sounds like a good improvement.  I think it would be fine to
regenerate the output as part of the build.  However, I think we
should still preserve the ability to run the script along it "test"
mode because that's about three orders of magnitude faster than
performing a build after touching CodeGeneratorJS.



Alexey (or others who don't like the new tests), do you think this  
change would address your concerns?


On Apr 29, 2010, at 1:05 PM, Adam Barth wrote:



What I hear from this conversation is the following:

1) A bunch of people who've used the tool saying that they've found  
it useful.
2) A bunch of people who haven't used the tool suggesting  
improvements.


This tool impacts the handful of people who work on
CodeGeneratorJS.pm.  Everyone else in the project can safely ignore
it.  I'm all for improvements, and I invite anyone interested to
either improve the tool or write a new tool that does the job better.


If everyone has to use the tool for the tool to be useful, then  
ideally we want a system where the people who change the bindings  
frequently mostly buy into. Here is the list of people with more than  
5 all-time commits in the WebCore/bindings/scripts directory. Ideally  
I'd like to hear from more of these what they think would be helpful  
and not burdensome.


  59  wei...@apple.com
  46  e...@webkit.org
  35  da...@apple.com
  32  jap...@chromium.org
  29  oli...@apple.com
  26  gga...@apple.com
  26  dglaz...@chromium.org
  16  aba...@webkit.org
  14  zimmerm...@webkit.org
  12  a...@webkit.org
  10  aro...@apple.com
   8  le...@chromium.org
   7  m...@apple.com
   7  da...@chromium.org
   6  timo...@apple.com
   6  s...@chromium.org
   6  jia...@chromium.org
   6  ddkil...@apple.com
   6  cwzwar...@webkit.org

Here is the command anyone can run to see the full list (assuming you  
have an SVN checkout):
$ svn log WebCore/bindings/scripts | grep '|.*@' | sed -e 's/^[^|]* |// 
g; s/ | .*$//g;' | sort | uniq -c | sort -rn


The long tail of people who have made only a few bindings changes is  
rather large, so I suspect this tool affects more than a handful  
people, if it becomes a mandatory part of the process.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

2010-05-10 Thread Maciej Stachowiak



On May 7, 2010, at 9:10 PM, Eric Seidel wrote:


2.  Additionally, Tiger seems mostly ignored by WebKit (note examples
like https://bugs.webkit.org/show_bug.cgi?id=38743).  No one develops
on Tiger to my knowledge (note mjs last night in #webkit noting how he
had no access to a Tiger machine, I certainly don't have access to
one).


I do have access to one at work, just not at home (I can only fit so  
many OS partitions on one laptop.)




I'm happy to add a brief note to the tools.html page noting that
python 2.5 is required and linking to a page.

Our scripts already print:
webkitpy.python24.versioning: [WARNING] WebKit Python scripts do not
support your current Python version (2.4.6).  The minimum supported
version is 2.5.

I'm happy to augment that warning to provide a download URL.

In short, I don't think Tiger (which appears legacy and
maintenance-mode only at this point) should hold hostage our script
development on all platforms.  We should simply update the bot and be
done with things. :)


My feeling about requiring a higher Python version for Tiger remains  
this:


"I'd prefer that we provide an easy means to do the install of Python  
2.6 (ideally a single script you can run, and ideally without  
affecting the system copy), rather than making every Tiger developer  
figure it out on their own."

http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

For those of us who still need to support Tiger, it would be a huge  
hassle to have to figure out how to update Python manually to even run  
the layout tests. The fact that it's not a primary development  
platform doesn't mean that it's ok to add stumbling blocks to the  
development process. In fact, it kinda makes it less ok, because then  
it takes more work to shift gears when fixing a Tiger-specific bug.


At minimum, there should be instructions here, and ideally the install  
should be one step:

http://webkit.org/building/tools.html

I understand that Google is not interested in supporting Tiger, but  
please be kind to those of us who do have to support it (for now  
anyway).


Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Yet another bug-less change hosed the tree.

2010-05-10 Thread Maciej Stachowiak



On May 10, 2010, at 2:05 PM, Adam Barth wrote:



That's part of what motivated us to create webkit-patch, which makes
creating and managing bugs and patches quite easy.



Personally, I find "webkit-patch upload" to be an easier way to  
prepare a patch for review than approaches you might expect to be  
lighter-weight, like creating a patch and posting it to a pastebot.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

2010-05-10 Thread Maciej Stachowiak



On May 10, 2010, at 11:01 PM, Eric Seidel wrote:

On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak   
wrote:
My feeling about requiring a higher Python version for Tiger  
remains this:


"I'd prefer that we provide an easy means to do the install of  
Python 2.6
(ideally a single script you can run, and ideally without affecting  
the
system copy), rather than making every Tiger developer figure it  
out on

their own."
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

For those of us who still need to support Tiger, it would be a huge  
hassle
to have to figure out how to update Python manually to even run the  
layout
tests. The fact that it's not a primary development platform  
doesn't mean
that it's ok to add stumbling blocks to the development process. In  
fact, it
kinda makes it less ok, because then it takes more work to shift  
gears when

fixing a Tiger-specific bug.


Provided:
https://bugs.webkit.org/show_bug.cgi?id=38886

At minimum, there should be instructions here, and ideally the  
install

should be one step:
http://webkit.org/building/tools.html


Provided:
https://bugs.webkit.org/show_bug.cgi?id=38822


Yay thanks! (Will try to review these later if no one beats me.)

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Yet another bug-less change hosed the tree.

2010-05-11 Thread Maciej Stachowiak



On May 10, 2010, at 11:45 PM, Eric Seidel wrote:



As Maciej states, webkit-patch upload is pretty quick (at least for
git users).


I'm not a git user but I still find it more convenient than any other  
approach because it has fewer steps and it helps me avoid some common  
mistakes.


I do think making it capable of handling subdirectories would be an  
improvement for SVN users. Also, I suspect it doesn't work as well as  
it could for people who prefer to edit ChangeLogs in a non-command- 
line editor, and for people who are very much in the habit of running  
prepare-ChangeLog before they even think about uploading a patch. Even  
with those limitations, I personally find it very useful, and I am a  
grumpy curmudgeon about tools.


On a tangential note, I think another thing that would help in these  
particular cases is enabling more of our JS-only tests to run as part  
of run-javascriptcore-tests, so it's easier for JS hackers to run them  
without having to wait on a WebCore world rebuild.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Yet another bug-less change hosed the tree.

2010-05-11 Thread Maciej Stachowiak



On May 11, 2010, at 9:51 AM, Alexey Proskuryakov wrote:



11.05.2010, в 0:56, Maciej Stachowiak написал(а):

I do think making it capable of handling subdirectories would be an  
improvement for SVN users. Also, I suspect it doesn't work as well  
as it could for people who prefer to edit ChangeLogs in a non- 
command-line editor, and for people who are very much in the habit  
of running prepare-ChangeLog before they even think about uploading  
a patch. Even with those limitations, I personally find it very  
useful, and I am a grumpy curmudgeon about tools.


FWIW, I'm unwilling to use a command line tool to deal with  
Bugzilla, no matter how refined. I don't work on a browser engine to  
run away from the experience it provides.


It would be interesting to know if I'm alone in feeling this way.


I like the command-line tool as a way to upload patches for two basic  
reasons:


1) The bugzilla Web-based process for filing a bug and uploading a  
patch sucks. Too many steps and too many fields to fill in. We could  
definitely streamline this if we cared to.


2) It requires a command-line tool to create a patch in the first  
place. Thus, no matter how much we streamline the Web experience for  
uploading a patch, using it will result in an extra step. I don't  
foresee the Web interface being able to create a patch in the  
foreseeable future.


I do use the bugzilla Web interface for commenting on bugs, reading  
patches, reviewing patches, etc.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Yet another bug-less change hosed the tree.

2010-05-11 Thread Maciej Stachowiak



On May 11, 2010, at 2:30 PM, Geoffrey Garen wrote:

Maybe I would use webkit-patch if it really were quite easy. I  
tried it in earnest for a while, but I had to give it up because:
* I couldn't find a ChangeLog workflow that fit its demands, so  
using it was actually more complicated than doing everything by hand


Can you explain this in more detail?


I don't know how to do either of these steps in an easy way:

1. Once I have a patch with a ChangeLog, say, "File a new bug and  
upload this patch for review." (Bonus points if the tool  
automatically made the first line of the ChangeLog the title of the  
bug.)


In the case where you don't have a ChangeLog, you can use "webkit- 
patch upload" to do all these things. But I believe the step where it  
lets you edit the ChangeLog may not work great if you use a non- 
command-line text editor. I think if you set the EDITOR enviornment  
variable to "open -t -W", it may do what you want - the ChangeLog will  
be opened in Xcode and the webkit-patch script will wait until you quit.


It also doesn't modify an existing ChangeLog entry if you already made  
one.




2. Once the patch has been reviewed, say, "Add bug # and reviewer  
information from Bugzilla, commit, and close the bug." (Bonus points  
if the commit happens via the bugzilla patch, so I can move on to  
working on another patch.)


This one is easy:

A) webkit-patch land
(if the patch is already in your tree)

B) webkit-patch land-from-bug BUGID
(to pull it from bugzilla)

It will fill in the reviewer in the ChangeLog, commit the patch, and  
mark the bugzilla bug closed.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] converting by constructor

2010-05-17 Thread Maciej Stachowiak

On May 17, 2010, at 12:39 PM, Chris Jerdonek wrote:

> Hi, I have a basic question.  What has been WebKit's stance on the use of the
> explicit keyword (for higher-level objects in particular)?  Do we prefer the
> looser API's that conversion by constructor affords, or do we more often
> discourage relying on conversion by constructor?
> 
> For comparison, the Google C++ style guide says the explicit keyword should
> almost always be used.  Note that I'm not suggesting that this be added to
> our style guide.

We like to use implicit conversion where it makes sense. We only use the 
"explicit" keyword to prevent specifically undesired implicit conversions.

As an example, the implicit conversions between String and AtomicString are 
very useful. They let the bindings generator write code from IDL without having 
to know whether the underlying C++ method takes a String or an AtomicString.

An example of a bad implicit conversion would be the Vector constructor that 
takes just a size_t. We don't want numbers passed as parameters to magically 
turn into Vectors, not only is that confusing but it would lead to ambiguous 
overloads. So we mark it explicit.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkit-patch requests

2010-05-19 Thread Maciej Stachowiak


On May 19, 2010, at 11:04 AM, Darin Adler wrote:

> On May 19, 2010, at 10:52 AM, Adam Barth wrote:
> 
>> Thanks for the feedback. Webkit-patch already respects the EDITOR 
>> environment variable. It should be a simple change to support the 
>> CHANGE_LOG_EDIT_APPLICATION environment variable also. The function that 
>> needs to change is:
>> 
>> http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/system/user.py#L73
> 
> When I created the prepare-ChangeLog and commit-log-editor scripts 8 years 
> ago I did the following:
> 
>- Had a separate CVS_LOG_EDITOR (later SVN_LOG_EDITOR) environment 
> variable in case someone wanted a different editor for this purpose than the 
> general case.
> 
>- Added CHANGE_LOG_EDIT_APPLICATION to adapt the work flow better to a Mac 
> OS X application where you would not quit after editing the files. But I had 
> to come up with a different way to indicate “I’m done” in such cases. 
> Probably could do something similar to what we do after launching Safari to 
> browse the diff.
> 
> There’s also a tool called xed that I could probably use as an EDITOR. The 
> xed command has an option "--wait" that can make it behave more like modal 
> vi. The xed tool was created many years after I wrote those scripts.

The Mac OS X "open" command also has a -W option which can wait for quit.

I believe setting EDITOR="open -W -a Xcode" would probably do it.

Regards,
Maciej
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] More webkit-patch requests

2010-05-22 Thread Maciej Stachowiak

On May 21, 2010, at 9:10 PM, David Hyatt wrote:

> I like webkit-patch.  My one complaint with it would be that I'd like to be 
> able to specify the subdirectories that it uses to generate the patch.  
> Running over the entire LayoutTests directory takes so long that I think 
> right now it would take me less time to just fire up my web browser and 
> upload the patch myself.

Besides the slowness of walking the full tree, webkit-patch once had a bug 
where it would do a full-tree SVN command multiple times, compounding the 
slowness, and I believe that bug has recurred.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?


On Jun 4, 2010, at 1:32 PM, Darin Fisher wrote:

> On Fri, Jun 4, 2010 at 11:15 AM, Peter Kasting  wrote:
> On Fri, Jun 4, 2010 at 11:11 AM, Darin Adler  wrote:
> If the two enum types are identical except for their names, then this doesn’t 
> firewall the types at all.
> 
> It doesn't firewall the concepts (but then, it's hard for an embedding layer 
> to not transmit any concepts, as that's basically the point).  It does 
> firewall the actual #includes, and thus provides source independence for the 
> embedder/a point where the WebKit side can be built as its own independent 
> DLL (if we want to).
> 
> PK
> 
> 
> Right.  Insulating the embedder from WebCore headers is very important.  It 
> helps avoid accidental dependencies on more of WebCore than just simple 
> constant values.
> 
> I can imagine a tool that would parse a WebCore enum and convert it to a 
> WebKit API equivalent, but that seems dangerous as it would mean that a 
> WebCore change could change the API.  I think it is better for API changes to 
> be more explicit.
> 
> I also agree with Peter that a case-switch translation would be no less work 
> to maintain.  Our use of compile-time asserts catches any drift between the 
> enum values (with the exception of newly appended WebCore enum values).  
> However, a case-switch translation may become necessary if a WebCore enum 
> value were deleted.  Then we'd need to make a decision between either 
> deleting the corresponding API enum value or providing compatible support for 
> it somehow.  If we chose the latter, then the API enum and the WebCore enum 
> would no longer be 1-1, so we'd need a case-switch translation to cope.

With a case-switch transition, the compiler can also help you detect cases 
where a new enum value was added at the core level but not the API level.

Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] free functions


On Jun 3, 2010, at 1:36 AM, Chris Jerdonek wrote:

> On Tue, May 25, 2010 at 10:01 AM, Darin Adler  wrote:
>> On May 25, 2010, at 7:54 AM, Chris Jerdonek wrote:
>> 
>>> I sometimes come across public member functions whose implementations do 
>>> not depend on private data.
>>> 
>>> There is a school of thought that such functions are better non-member 
>>> because it reduces the number of functions coupled to private data. On the 
>>> other hand, I've heard the argument that making such functions free creates 
>>> naming issues -- it's not clear to the caller in which header file to find 
>>> the free function.
>>> 
>>> My question for WebKit is whether naming considerations outweigh 
>>> encapsulation considerations.  And if so, is there a naming convention or 
>>> otherwise that we can use to make finding free functions easier?
>> 
>> We do need our classes to be smaller so we can understand the structure of 
>> the code. The encapsulation benefits of having a much smaller number of 
>> members in a class are well worth some cost. But there are at least two 
>> considerations that come into play when replacing a member function with a 
>> free function:
>> 
>>1) Free functions still have to go in some header/source file. The usual 
>> rule for finding a function is to look for a file named based on the class. 
>> Without a class name we have to do something to make it practical to find 
>> the functions in the source tree without a lot of searching.
>> 
>>2) Free functions need names that are clear and unambiguous with no 
>> context other than the WebCore namespace. We try to keep member function 
>> names short, and we can do so in part because they have a class name 
>> context. The same function as a free function will almost certainly need a 
>> longer name. Each time we create a free function we have to think about what 
>> an appropriate name is; it’s a mistake to leave the same short name that was 
>> previously used for a class member.
>> 
>> Another possible way to get encapsulation benefits with fewer of the other 
>> problems is to group functions into classes or namespaces that have no data 
>> and nothing else private. This may be helpful if the class or namespace name 
>> has a good name with a clear concept.
> 
> 
> Would the following simple convention be an acceptable option?  A free
> function in a header file could go in a nested namespace whose name is
> the name of the header file followed by "Functions" (as in "free
> functions").  An example in Chrome.h might be--
> 
> WebCore::ChromeFunctions::applyWindowFeatures(Chrome*, const WindowFeatures&);
> 
> Would adding such a non-member function be preferable to adding to the
> Chrome class a public member function that didn't depend on private
> Chrome data?  The encapsulation discussion above suggests it would.
> 
> I'm just trying to think of a simple alternative so the default need
> not always be to add another member function.
> 
> For comparison, we have essentially 8 files whose file name ends in 
> "Functions":
> 
> JavaScriptCore/API/JSCallbackObjectFunctions.h
> JavaScriptCore/runtime/JSGlobalObjectFunctions.*
> JavaScriptCore/wtf/HashFunctions.h
> JavaScriptCore/wtf/StringHashFunctions.h
> WebCore/bindings/js/JSPluginElementFunctions.*
> WebCore/dom/PositionCreationFunctions.h
> WebCore/xml/XPathFunctions.*
> WebKit/mac/Plugins/WebNetscapeDeprecatedFunctions.*

I just discussed this topic with Darin briefly in person. We both agreed that, 
in general, free functions do not need a special namespace, an overly specific 
name, or a separate header. Free functions that are closely related to a class 
can be thought of as part of the interface exposed by that class - it's just a 
part that's not necessarily core functionality, and that doesn't need access to 
class internals. Going back to your specific example,

I would just do:

namespace WebCore {
void applyWindowFeatures(Chrome*, const WindowFeatures&);
}

Due to C++ overloading, it doesn't matter much if some other class has an 
applyWindowFeatures function. C++ will resolve the namespace collision. The 
main question to consider is whether it's still clear at the call site:

chrome->applyWindowFeatures(feature);

would change to:

applyWindowFeatures(chrome, feature);

That's likely to still be understandable. And in this particular case, the 
function name is unlikely to be ambiguous.

I would also suggest that in most cases, free functions closely related to a 
specific class should generally go in the same header. Exceptions would be:

(a) Sets of functions that are related to each other but aren't closely related 
to a single specific class (for example hash functions for a bunch of different 
types).
(b) Functions that comprise clearly separate subsystem, and are not truly about 
the main class they work with. For example, a set of functions to parse email 
addresses might operate mainly on strings, but they are not conceptually part 
of the interface of

Re: [webkit-dev] sick of forgetting bugzilla email addresses?


On Jun 7, 2010, at 2:30 PM, Julie Parent wrote:

> Thank you thank you thank you!
> 
> I'm happy using this as a Chrome extension, but if there is enough interest 
> to have it added to Bugzilla directly, I can do it (I already have a local 
> bugzilla running for the Rietveld work).

I think this would be a good addition to bugzilla itself.

Cheers,
Maciej

> 
> Julie
> 
> On Mon, Jun 7, 2010 at 1:44 PM, Jeremy Orlow  wrote:
> This will save me so many iterations of trying a name into gmail and then 
> copying it over to bugzilla.  :-)
> 
> Thanks Ojan!
> 
> 
> On Mon, Jun 7, 2010 at 9:28 PM, Adam Barth  wrote:
> Wow, that's pretty awesome.  Thanks Ojan.
> 
> Adam
> 
> 
> On Mon, Jun 7, 2010 at 1:25 PM, Ojan Vafai  wrote:
> > I sure am.
> > I wrote a Chrome extension that adds autocomplete to bugzilla email input
> > boxes based off the data
> > in 
> > http://svn.webkit.org/repository/webkit/trunk/WebKitTools/Scripts/webkitpy/common/config/committers.py.
> > It will autocomplete based on first name, last name, irc nick or email
> > address.
> > https://chrome.google.com/extensions/detail/olaabhcgdogcbcoiolomlcodkngnemfb
> > Please let me know if I missed any email input boxes. The only ones I saw
> > were on the advanced search page and the individual bug page.
> > If anyone would like to integrate this directly into bugzilla, it's ~250
> > lines of JS to do the autocomplete, which you're welcome to use or modify.
> > You'll just need to write code to generate the list of email addresses. You
> > can't just use my JS code for that if you want to use committers.py since
> > it's on a different domain.
> > Ojan
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?


On Jun 10, 2010, at 12:04 AM, Eric Seidel wrote:

> This causes a huge header dependency cascade, bloating object files
> and slowing down builds.  I can't imagine avoiding the pointer
> indirection is actually a measurable runtime savings (at least in most
> cases).

Can you give a specific example of a data member where you think OwnPtr would 
be better?

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience


On Jun 2, 2010, at 1:22 PM, David Hyatt wrote:

> 
> I really don't think hit testing needs to be modified to get what you want.  
> You can do a scattershot sampling using multiple candidate points within the 
> rect and apply whatever heuristics you want to choose a node.  I'm also not 
> convinced that we should be complicating core hit testing code in this way, 
> since I suspect this is one of those areas where mobile platforms will each 
> want to do their own slightly different thing anyway.

I suspect hit testing a rect against the render tree could be done more 
efficiently than scattershot sampling.

Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

2010-06-11 Thread Maciej Stachowiak

On Jun 10, 2010, at 4:22 PM, Eric Seidel wrote:

> Example.  Use of a mutable member for AnimationController:
> https://trac.webkit.org/browser/trunk/WebCore/page/Frame.h#L346
> 
> Causes us to pull in AnimationController.h:
> https://trac.webkit.org/browser/trunk/WebCore/page/Frame.h#L31
> 
> Which pulls in additional headers of its own.

I think what requires including the additional headers is the fact that it's a 
data member of class type instead of a pointer; the mutable declaration is 
unrelated.

> 
> Frame.h is included by lots and lots of cpp files, most of which never
> need AnimationController.h.  Thus all of those intermediate files
> (preprocessor output, assembler output, .o file, etc.) are larger than
> necessary, causing longer builds.  Also any time someone edits an
> AnimationController.h (or a dependent .h) we end up re-building every
> file which includes Frame.h (hundreds of files).

Making the helper classes of Frame into separately allocated objects could 
certainly help compile time. It used to be they were all held in a separate 
FramePrivateData class. I'm not sure when that changed. I don't know of any 
considerations besides performance and memory use that would favor the current 
approach. Testing would show whether it actually matters. It might also be 
worthwhile to find the checkin that removed the separate private data struct 
for Frame, to see if that was done for a particular reason.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

2010-06-11 Thread Maciej Stachowiak

On Jun 11, 2010, at 6:17 PM, Eric Seidel wrote:

> I'm all for PLT speedups (despite it running too fast on modern
> hardware to be useful, it's all we got).  But I'm very against
> build-time explosion. :(
> 
> I bet we don't need to inline all of these.  Would be nice to know which ones.
> 
> Inlines requiring additional headers (especially for Frame.h) increase
> the .o size of most WebCore .cpp files and increase overall build
> time.  I need to write some sort of scripts to help us check for
> header includes we don't need.

I'd be happy to see any build time speedups that don't cause a measurable speed 
hit. It should be easy to find through testing whether some of these data 
members can be changed to smart pointers without a speed hit.

Note: inlining methods that access these is still possible even if they are in 
separate headers, the methods just need to go into that separate header. So the 
main costs at issue are extra allocations and extra indirection.

If it's a tradeoff between page load speed and faster compile time though, I 
think page load speed wins.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Style question: static, protected, or public members

2010-06-12 Thread Maciej Stachowiak

On Jun 4, 2010, at 3:54 PM, Joe Mason wrote:

> I'm strongly in favour of g_.  It seems weird and ugly to me to have
> prefixes for some non-local scopes but not all.  And it's very helpful
> to be able to look at a variable reference and immediately know that
> it's a global, and not a local whose definition you skimmed over.

I think file-scope static globals don't need a prefix. In the few cases of 
globals with extern linkage, I think a prefix would make them needlessly 
unpleasant to use. HTMLNames.h is one of the most prominent examples. I don't 
think we'd want to write g_divTag and g_widthAttr instead of divTag and 
widthAttr.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 tokenizer landing soon

2010-06-14 Thread Maciej Stachowiak


On Jun 14, 2010, at 8:18 AM, Simon Fraser wrote:

> On Jun 13, 2010, at 10:21 PM, Adam Barth wrote:
> 
>> People of WebKit,
>> 
>> As mentioned recently on webkit-dev, Eric, Tonyg, and I have been
>> working on implementing the HTML5 parsing algorithm in WebKit:
>> 
>> http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11472.html
>> 
>> We're now ready to turn the new tokenization algorithm on by default
>> (probably early this week).  The new code passes all the existing
>> LayoutTests, with the exception of roughly 40 tests that "expect"
>> behavior that violates the HTML5 specification [1].
> 
> Does the HTML5 tokenizer kick in for all HTML documents, or is there
> some switching based on DOCTYPE?

There definitely shouldn't be switching based on doctype. The HTML5 parsing 
algorithm is specifically designed to handle existing Web content.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 tokenizer landing soon

2010-06-14 Thread Maciej Stachowiak

On Jun 14, 2010, at 12:47 PM, Oliver Hunt wrote:

> We have historically not taken patches that "will certainly be faster" 
> without evidence that it will be faster -- Adam already said this will 
> regress performance which makes me sad :-(

Since the test was a parsing microbenchmark and the difference is very small, 
it's probably that the difference will be below the noise threshold on 
end-to-end benchmarks.

Of course, we can confirm this with PLT or HTML iBench results.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] increase the number of tests before bailing?

2010-06-16 Thread Maciej Stachowiak


On Jun 16, 2010, at 2:04 PM, Eric Seidel wrote:

> We could add a separate option to DumpRenderTree to disable
> ReportCrash (sign up for all the crashing signals and simply exit(2)
> or similar).  That would be useful in many instances besides the bots.
> 
> Yes, --exit-after-N-failures was designed to prevent crashers from
> eating the bots.

I think --exit-after-n-crashes is probably the most expedient solution to the 
problem.

I think when only a few tests crash, having the crash report is very useful, 
particularly if the developer of the patch cannot reproduce the crash off the 
bot. All we need to do is limit the number of crashes to prevent the bots 
falling way behind.

Regards,
Maciej

> 
> On Wed, Jun 16, 2010 at 1:59 PM, Geoffrey Garen  wrote:
>> Hi Ojan.
>> 
>> I wonder if it would help to distinguish --exit-after-n-failures from 
>> --exit-after-n-crashes.
>> 
>> I think that crashing tests are the biggest problem, since they can cause a 
>> bot to lag behind quite a bit.
>> 
>> Geoff
>> 
>> On Jun 16, 2010, at 1:57 PM, Ojan Vafai wrote:
>> 
>>> Currently, --exit-after-n-failures on the bots is set to 20. I like the 
>>> idea of exiting early, but I think 20 is too low. We should up it to 100. 
>>> Is anyone opposed to that?
>>> 
>>> There are some straightforward, mechanical patches that cause more than 20 
>>> tests to fail where they just need new expected results (e.g. changing form 
>>> control or scrollbar metrics). Right now, to make such a change you need 
>>> access to every platform so you can create new results or you need to get 
>>> someone who has access to that platform to pull in your change and create 
>>> new results.
>>> 
>>> The problem that confounds this is that many people have trouble ever 
>>> getting all the tests to pass on Windows. I've never succeeded. There are 
>>> always ~50 tests that fail for me and it's not due to lack of trying. So, 
>>> even though I have access to Windows, it's hard for me to get new expected 
>>> results for Windows changes.
>>> 
>>> Long-term we really need a solution that lets you get expected results for 
>>> a platform you don't have access to without committing code, e.g., the EWS 
>>> archiving results for failing tests.
>>> 
>>> Ojan
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] A proposal for "Platform Mechanisms"

2010-06-17 Thread Maciej Stachowiak

On Jun 17, 2010, at 11:26 AM, Geoffrey Garen wrote:

>> I propose that we create an abstract class, "PlatformMechanism" which acts 
>> as the starting point for accessing such functionality, something like:
>> 
>> class PlatformMechanism {
>>  virtual ClipboardMechanism* clipboardMechanism() = 0;
>>  virtual FileAccessMechanism* fileAccessMechanism() = 0;
>>  virtual PluginMechanism* pluginMechanism() = 0;
>> };
> 
> I think this would read better if you just got rid of the "Mechanism" suffix. 
> It's such an abstract word that it's maybe meaningless.
> 
> You might still need something to distinguish this kind of clipboard from, 
> say, the WebCore clipboard. For that, I suggest using the word "platform."

I agree that Mechanism is a very vague word. Platform is an interesting idea, 
but I believe it is potentially confusing in some ways. We have normally used 
platform/ to refer to stuff in the Platform directory. In fact we already have 
a Clipboard class in WebCore/platform, the role of which is platform 
abstraction of the underlying implementation. The proposed PlatformClipboard 
object would not primarily be providing platform abstraction, rather its main 
role is to provide runtime switchability among different implementations, one 
of which is a cross-process proxy and the other of which implements clipboard 
functionality directly. I don't think the name PlatformClipboard clearly 
identifies how the role is different from Clipboard, given the context of the 
project.

Cracking my Design Patterns book (or at least my memory of it), another idea 
that comes up is "Strategy". Strategy is a design pattern where you have a 
runtime switchable object that provides alternative approaches to providing the 
same functionality. Then we would have:

ClipboardStrategy --> abstract class
ClipboardProxyStrategy (or ProxyClipboardStrategy) --> class that provides the 
details of clipboard functionality by proxying to a privileged process
ClipboardDirectStrategy --> class that implements clipboard functionality 
directly.

Then Clipboard makes use of an abstract ClipboardStrategy, without having to 
know which implementation it is using under the covers. And 
ClipboardProxyStrategy could even be implemented using ClipboardDirectStrategy 
on the other side of the proxy.

I'm not sure if that is the best naming, but I often find the Design Patterns 
book helpful for naming classes that have an abstract role which is hard to 
describe succinctly.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] strategy for evaluating performance issues related to memory.

2010-06-21 Thread Maciej Stachowiak

On Jun 21, 2010, at 11:59 AM, Mike Marchywka wrote:

> 
> I was hardly worried about who does anything as much as what would make sense 
> to do. I have interest, motivation,
> and multiple copies of the code but not a lot of time to waste of bad 
> approaches. There was a prior discussion
> about coding conventions that should be applicable even to those 
> contemplating a contribution of just browsing
> the code, I fail to see how this discussion is less relevant to current and 
> possible future development concerns.
> 
> If there was some piece of this or a related effort that could be aided by 
> certain code features that
> would seem to be of interest to everyone and it isn't clear which people 
> would have important thoughts
> to contribute ( or I would take it some other place). 
> 
> So I take it that now you just have factories and smart pointers and just 
> make stuff and have it
> allocated wherever without further thought?  I guess I could do some 
> profiling my self and empirically
> find problems and just assume that no one has specific comments on suspects 
> or things they have observed
> as possible problems. 

In my experience with performance work, and specifically in the context of 
WebKit, I believe the following are useful approaches to reducing memory use:

1) Find and fix memory leaks. There are good tools for this, and memory leaks 
contribute considerably to memory growth over a long browsing session. 
Long-term memory growth is a bigger concern than one-time costs or per-page 
memory that is properly returned to the system.

2) Run memory profiling tools under a significant and realistic workload, such 
as Mozilla's "membuster" test. We have had great success with this and in 
particular you can find some good recent memory use improvements from Sam 
Weinig and Anders Carlsson, among others, if you look at the ChangeLog.

3) Track memory benchmarks regularly, and identify and fix regressions.

4) Run long automated page loads to verify that memory growth stabilizes 
eventually, rather than continuing to grow without bound.

5) Investigate memory held by caches, and figure out ways to get the same speed 
benefits with less overall memory use, for example by discarding redundant data 
or better tuning the cache to hold the items most likely to be reused.

6) Find reproducible cases of non-leak repeatable memory growth, and determine 
where the extra memory is going.

If you are interested in improving WebKit's memory use, I encourage you to 
consider one or more of the above approaches.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Maciej Stachowiak


I like this idea. Addressing some of the side comments:

- Yes, we should get rid of auto_ptr.
- I can imagine a leakPtr function being more self-documenting than 
adoptPtr(...).releasePtr() when it appears in code, but on the other hand the 
greater convenience may lead to using it carelessly. On the third hand, it will 
definitely stand out if it appears in a patch.

Regards,
Maciej

On Jun 28, 2010, at 1:39 PM, Darin Adler wrote:

> Hi folks.
> 
> I’d like to use our smart pointers more consistently to decrease the chances 
> of memory leaks or other similar problems.
> 
> My proposal is that we have a rule that all calls to "new" are immediately 
> followed by putting the object into a smart pointer. The main types of smart 
> pointer that matter for these purposes are:
> 
>RefPtr
>OwnPtr
>OwnArrayPtr
> 
> Today, we put a new reference counted object into a RefPtr by calling 
> adoptRef. The code looks something like this:
> 
>PassRefPtr createSharedObject()
>{
>return adoptRef(new SharedObject);
>}
> 
> I propose we do the same thing with single ownership objects. It would look 
> like this:
> 
>PassOwnPtr createSingleOwnerObject()
>{
>return adoptPtr(new SingleOwnerObject);
>}
> 
> Then it would be a programming mistake to call new without immediately 
> calling adoptPtr or adoptRef. As part of this effort I plan to do the 
> following:
> 
>1) Add a debugging mode where we assert at runtime if we ref, deref, or 
> destroy a RefCounted object before doing adoptRef. Tracked in 
> .
> 
>2) Add an adoptPtr function that returns a PassOwnPtr, and a releasePtr 
> function that returns a raw pointer to the PassOwnPtr class.
> 
>3) Add a PassOwnArrayPtr with similar adoptArrayPtr and releaseArrayPtr 
> functions.
> 
>4) Add a strict mode to PassOwnPtr and OwnPtr which removes OwnPtr::set 
> entirely and removes the ability to construct a PassOwnPtr or OwnPtr from a 
> raw pointer directly, making it a compile time error to forget to use 
> adoptPtr.
> 
>5) Once everything compiles with the strict mode, make the strict mode the 
> only mode.
> 
>6) Add validator rules that make invocation of the "new" operator legal 
> only inside adoptRef and adoptPtr function calls.
> 
> Code that used to say this:
> 
>OwnPtr m_otherObject;
>...
>m_otherObject.set(new OtherObject);
> 
> Will now say this:
> 
>OwnPtr m_otherObject;
>...
>m_otherObject = adoptPtr(new OtherObject);
> 
> And one thing that’s cool about that is it is quite natural for this to 
> become:
> 
>OwnPtr m_otherObject;
>...
>m_otherObject = OtherObject::create();
> 
> I thought I’d mention this to everyone on the list before getting doing 
> significantly more work on this. I think it’s going to work well. Any 
> questions or comments?
> 
>-- Darin
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Should Table Cell (TD) children inherit height?

2010-06-28 Thread Maciej Stachowiak


On Jun 28, 2010, at 6:32 PM, David Kilzer wrote:

> How do Firefox and MSIE render the test case?

Our rendering on this content matches Firefox in both quirks and standards 
mode. I also do not know if a reason per spec for the div to get 100% height. 
Height does not inherit.

 - Maciej

> 
> Dave
> --
> Sent from my iPhone 3GS
> 
> On Jun 28, 2010, at 11:42 AM, Fady Samuel  wrote:
> 
>> My understanding is that in quirks mode,  causes the 
>> table to fill the entire client window. Now, I believe the height attribute 
>> should trickle down to the TR and TD tags, correct? What about children of a 
>> TD tag? If you add an empty div child to a table, should it fit the whole 
>> cell, or should it have a size of 0?
>> 
>> 
>> 
>>
>>
>>  
>>
>>
>> 
>> 
>> 
>> WebKit will show you red instead of green because the div does not have a 
>> height of 100%.
>> 
>> Now if you make the div's height 100%, you get green. 
>> 
>> Should a cell's child inherit height?
>> 
>> Thanks,
>> 
>> Fady Samuel
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior


Thank you for fixing the problem.

Did you try talking to Alexey directly about this? Or to someone else who may 
be familiar with the situation? It's usually better to try steps like that 
before calling someone out on the mailing list. And if you do need to bring 
something to wider attention, perhaps you could consider a less strident tone. 
In the WebKit project, we prefer to resolve disputes calmly and respectfully, 
especially among longtime valued contributors such as Alexey and yourself. I 
realize that at times, contributors can feel frustrated, but let's try to keep 
the project mailing list a happy place.

Sincerely,
Maciej

On Jul 7, 2010, at 12:47 AM, Adam Barth wrote:

> If you're tired of my complaining about the tree being red, you can
> skip this message.
> 
> Today Alexey checked in ,
> which broke two tests on every port.  12 hours later, these failures
> remained in the tree until I cleaned them up.  This mess could have
> been avoided in a number of ways:
> 
> 1) He could have run-webkit-tests before committing his change.
> 2) If he didn't have time to run the tests locally, he could have used
> the commit-queue to run-webkit-tests before it landed his patch.
> 3) He could have looked at the tree when sheriff-bot informed him that
> he might have broken Leopard Intel Debug by pinging him in #webkit and
> commenting on his bug:
> .
> 
> Is this acceptable behavior?
> 
> http://webkit.org/coding/contributing.html clearly says to "run the
> layout tests using the run-webkit-tests script and make sure they all
> pass."  That page also says:
> 
> [[
> In either case, your responsibility for the patch does not end with
> the patch landing in the tree. There may be regressions from your
> change or additional feedback from reviewers after the patch has
> landed. You can watch the tree at build.webkit.org to make sure your
> patch builds and passes tests on all platforms. It is your
> responsibility to be available should regressions arise and to respond
> to additional feedback that happens after a check-in.
> ]]
> 
> Are there consequences for breaking these rules?
> 
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

On Jul 7, 2010, at 9:45 AM, Alexey Proskuryakov wrote:

> 
>> I think we can improve this by having sheriff-bot say which tests
>> broke.  I bet if you saw these tests listed, you'd have realized what
>> was going one.
> 
> 
> That would be very useful indeed! It currently takes some effort to find out 
> what exactly the bot complains about.

Another possibility is for it to link to the test results page when it reports 
a failure - not as obvious as reporting the failing tests inline, but this 
would make it very convenient to look into the details of the failure.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit2 process model

On Jul 7, 2010, at 4:41 AM, ARaj wrote:

> Hi,
> The latest WebKit2 Windows port creates a single process for any
> number of tabs that are opened.
> Will this be changed to something like a one-process-per-tab mode?

Our short-term plans are to make the threaded and single-web-process modes of 
WebKit2 work really well - there's still significant work to make the port 
feature-complete. Once that is done, we plan to work on multiple-web-process 
mode. That mode will have some unique additional challenges.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

On Jul 7, 2010, at 7:22 PM, James Robinson wrote:

> 
> 
> On Wed, Jul 7, 2010 at 7:19 PM, Oliver Hunt  wrote:
> 
> On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
> 
>> 
>> 
>> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
>> Maybe I should complain this in a different threads, but recently the commit 
>> bot waiting time is way too long.  Several times a patch of mine got the r+ 
>> and cq+ and it landed two days later.  This is really frustrating.
>> 
>> I am very tempted to use svn directly to commit patches, but that means the 
>> patch only gets tested in my local environments. Like one time my patch 
>> breaks the leopard bot, turns out the failed test is skipped on leopard, 
>> which is exactly my OS.  If I land it through the commit bots, I could 
>> identify the issue earlier.
>> 
>> I agree they are closely related. A greener tree means a faster commit queue 
>> and a faster commit queue means less people subvert it and break the tree. 
>> The hard problem is figuring out how to fix the incentives so subverting the 
>> queue isn't so desirable.
> 
> What do you mean by subvert the queue?  The commit queue is a tool to 
> streamline commits from contributors who do not have commit access to the 
> repository.  If you have the ability to commit you should not be using the 
> commit queue to land your patches.
> 
>  
> That's not my understanding of the commit queue.  I use the commit queue to 
> land my patches when possible so that the patch receives further testing 
> before it hits the tree and potentially affects a large number of 
> contributors.  Why do you think this is a bad idea?  Is this preference 
> codified somewhere (formally or informally)?

Previously the commit queue had a problem whereby it would show incorrect 
committer information (every patch committed by Eric). Now that is fixed - 
every patch submitted by a committer will show the proper committer, and those 
submitted by a non-committer will show up as committed by commit-queue. I think 
it's a choice of which approach to use.

In addition to the obvious benefit of testing your patch for you, I think one 
positive externality of the commit queue is that people who use it are more 
motivated to keep the tree green. One negative externality is that it sometimes 
makes people excessively upset about tree redness, and sometimes makes them 
want to fix redness in a way that papers over problems (e.g. by adding to the 
skipped list).

On the whole, I suspect the benefits of automated testing before landing 
probably outweigh these concerns.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

On Jul 7, 2010, at 7:32 PM, Oliver Hunt wrote:

> 
> webkit-patch land-safely does the job of running the tests automatically, 
> that said if you have commit privileges you should be running the tests 
> yourself otherwise you're wasting the reviewers time.
> 
> Pushing a patch through the normal review path will have it built on multiple 
> platforms (though it is annoying that once you get r+ those builders don't 
> run).
> 
> The only benefit of the commit-queue (as i see it) is that it will make sure 
> that the patch still applies in the many hours between it being reviewed and 
> it being landed.

You can roll out the patch and work on something else, which might be a benefit 
to some.

Also, the track record of the commit queue seems to be that people using it are 
less likely to break the tree in practice. I'm not naturally enthusiastic about 
the commit queue approach (I like to be around when my patch actually lands), 
but you can't argue with results. The only remaining downside (in my opinion) 
is sometimes making people overly frustrated when it's blocked, and 
occasionally leading to inelegant fixes for tree redness.

> My opinion is that if people want to use the commit-queue to land patches 
> they should be happy to drop their commit privileges thus mooting this entire 
> issue.

That would probably make things worse on net, since the commit queue would then 
not mark the person as the committer in SVN.

Personally, I don't think we need to either mandate or discourage use of the 
commit queue at this time.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 & MathML3 entities

2010-07-10 Thread Maciej Stachowiak


On Jul 10, 2010, at 3:47 AM, Sausset François wrote:

> I'm currently working on the MathML3 implementation and I noticed that new 
> XML entities have been defined by the W3C:
> http://www.w3.org/TR/xml-entity-names/
> 
> They are supposed to be used by both HTML 5 & MathML 3.
> 
> I would like to include them in WebCore/html/HTMLEntityNames.gperf.
> However there is one conflict with the existing XHTML 1.0 entities: \rangle 
> (and \langle) doesn't point to the same Unicode character in XHTML 1.0 and 
> HTML 5 entity definitions.
> For instance, U+27E9 ("⟩") instead of U+3009 ("〉").
> 
> There are two possibilities:
> - either update WebCore/html/HTMLEntityNames.gperf and overwrite the two 
> conflicting cases with the new standard, but it won't respect the XHTML 1.0 
> specification anymore.
> - or use two sets of HTML entities depending on the DTD of the document. It 
> would be the cleanest way, but I don't know how to make WebCore handle two 
> such sets.
> 
> I think the best solution is the second one, but I'll need help to make 
> WebCore handle two entity sets and switch depending on the DTD. It is outside 
> of my present skills.

Go with the HTML5 / MathML 3 definitions for everything. Our XHTML 
implementation targets XHTML5, not XHTML 1.0.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 & MathML3 entities

2010-07-10 Thread Maciej Stachowiak

On Jul 10, 2010, at 9:36 AM, Alexey Proskuryakov wrote:

> 
> 10.07.2010, в 04:49, Maciej Stachowiak написал(а):
> 
>> Go with the HTML5 / MathML 3 definitions for everything. Our XHTML 
>> implementation targets XHTML5, not XHTML 1.0.
> 
> 
> I think that xml-entity-names and HTML5 made a poor choice changing the 
> semantics of ⟩ and ⟨ (they used to be CJK punctuation, and now they 
> are suddenly math). These are rendered differently. We should probably take a 
> pragmatic approach, and avoid rushing to be the first to implement this 
> aspect of the specs.

I agree we shouldn't rush on potential compatibility-breaking changes, if we 
can get someone else to do some testing for us first. However I believe Firefox 
dev builds have the new meanings of ⟩ and ⟨. They haven't discovered 
a problem yet, as far as I know.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 & MathML3 entities

2010-07-10 Thread Maciej Stachowiak

On Jul 10, 2010, at 11:10 AM, Sausset François wrote:

> I just saw that when looking at the code by myself.
> What do you exactly mean by a prefix tree?

The data structure commonly called a "Trie" is a prefix tree:
http://en.wikipedia.org/wiki/Trie

This data structure not only lets you tell if a particular key is present, but 
it also lets you check if a string you have could possibly be the prefix of any 
valid key.

I think it is challenging, though, to make a trie structure that can be a 
compile-time constant, and building one dynamically will cost runtime memory 
per-process (whereas constant data would be in the data segment and shared).

Another possibility is to make an array of all the entity names in sorted 
order. Then lookup can use a binary search, and on a failed lookup, looking to 
either side of the last key checked should determine whether it is a valid 
prefix.

I expect binary search would be slower than Trie lookup, though I don't know by 
how much.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes


The reason for these is historical. Originally, we didn't use a separate vendor 
prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we 
realized WebKit would not be an Apple-specific project forever, so we switched 
to -webkit. The main risk to removing the old prefixes is that some older 
WebKit-specific content authored against them will break. I'm not sure the code 
cleanup benefits outweigh the risk of breaking content.

If we want to phase out support for these older prefixes, what I'd propose as a 
first step is supporting the legacy prefixes for old properties but not for any 
new ones.

Regards,
Maciej

On Jul 12, 2010, at 1:53 AM, Peter Beverloo wrote:

> Good day,
> 
> While going through WebCore for some CSS research I'm currently doing,
> I came across a piece of code[1] which translates all "-khtml-" and
> "-apple-" vendor-prefixes to "-webkit-". This effectively means
> "-apple-transform" and "-khtml-transform" can both be used instead of
> "-webkit-transform". I am unaware of the rationales behind the apple
> vendor-prefix, but I'd like to propose removing support for the
> KHTML-prefix.
> 
> My main argument for this is that WebKit and KHTML are, in my opinion,
> two separate engines by two separate vendors. The port occurred eight
> years ago, and code in both projects has changed significantly ever
> since. When Microsoft announced support for "-webkit-text-size-adjust"
> in IE Mobile it was argued that browsers should not implement
> properties with prefixes "belonging" to other vendors, which seems to
> be exactly what WebKit is doing with the KHTML prefix.
> 
> I understand the history of supporting -khtml-, and have heard from
> the KHTML project that they implement the -webkit- prefix as well.
> However, considering that WebKit has grown significantly in the past
> few years and that all code changes basically made KHTML and WebKit
> two individual rendering engines, with individual CSS support, I
> believe it would be appropriate for support to be dropped.
> 
> Regards,
> Peter Beverloo
> http://peter.sh/
> 
> [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
> [2] 
> http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

On Jul 12, 2010, at 10:44 AM, Peter Beverloo wrote:

> Right now WebKit has by far the most prefixed elements[1], a
> significant part of which have not been standardized/drafted yet.
> Keeping the translation for all properties active practically triples
> the amount of supported vendor-specific CSS extensions, which cannot
> be desirable.
> 
> I'm not opposed to the idea of limiting the supported properties for
> these prefixes to a certain subset, but my preference would be to only
> support behavioral properties as "-webkit-binding",
> "-webkit-font-smoothing", "-webkit-highlight" and
> "-webkit-user-(drag|modify|select)". In the same piece of code,
> prefixed versions of border-radixes and opacity are still supported as
> well. Although I think the latter of which could be removed as well,
> considering Safari 1.1 got released in 2003.

WebKit really uses vendor-prefixed properties for a few different purposes:

1) Properties that are only intended to be used internal to the engine, to 
implement particular effects.
2) Properties that are future CSS standards but not yet mature enough to remove 
the prefix.
3) Experimental properties that may be proposed as standards in the future.
4) Proprietary properties that we don't intend to standardize, but which can be 
used by content.
5) Properties that were once prefixed for one of the above reasons, and we keep 
the prefixed version in addition to the unprefixed one.

One beneficial exercise would be to classify prefixed properties into the above 
buckets. For categories (3) and (4), we should consider whether the properties 
in question can actually be proposed as standards, and therefore move to 
category (2). For category (5), we should assess the compatibility impact of 
removing the prefixed version.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?


On Jul 12, 2010, at 11:01 AM, Beth Dakin wrote:

> 
> On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote:
> 
>> I would think we'd close it when we've actually completely implemented
>> MathML.  
> 
> If this is what you want the bug to represent, then it does make sense to 
> keep all feature-implementation bugs related to this master bug, but none of 
> the bug bugs…if that makes any sense.The bug bugs should be in the MathML 
> component, but they shouldn't block the feature-complete bug.
> 
>> Just
>> enabling it seems like something we could do now but our implementation is
>> quite impoverished with respect to MathML 3.0.
> 
> I think we should consider enabling MathML. Just because we don't have MathML 
> 3.0 implemented yet doesn't mean we need to keep it off; there was a time 
> when we didn't have any CSS 3 implemented, but that didn't mean our CSS 
> implementation had to be turned off! I have been playing around with a 
> MathML-enabled build, and I feel like we do a pretty good job getting a lot 
> of MathML on the web right, and I haven't experienced any crashes in the 
> MathML code either. And if we turn it on, more people will test it, and that 
> is just plain helpful. Just my opinion!

I think it's fine to enable MathML soon, as long as we make sure of the 
following:

1) Using a MathML-enabled build shouldn't cause stability problems or 
functional or performance regressions when browsing ordinary non-MathML content.
2) We should try to do some fuzz testing to verify that MathML doesn't create 
security risks.

#2 can happen after we enable MathML, but should probably happen before anyone 
ships it.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

On Jul 12, 2010, at 4:06 PM, Alex Milowski wrote:

> On Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak  wrote:
>> 
>> I think it's fine to enable MathML soon, as long as we make sure of the 
>> following:
>> 
>> 1) Using a MathML-enabled build shouldn't cause stability problems or 
>> functional or performance regressions when browsing ordinary non-MathML 
>> content.
> 
> Some of tis is testable by passing all our test cases, right?  Or did you have
> something else in mind?

That plus browsing around some, or using the Safari "stress test" feature, wuld 
be enough to show basic stability.

> 
> Do we have anything that measures "performance" for regressions?

The Safari team has some internal tests we could run, once you have a patch 
ready.

> 
> I suspect that the performance on MathML with complicated row structures
> isn't going to be good at the moment.  There are two many multiple
> rendering passes for operator and content stretching and that can probably
> be optimized.  On the other hand, it seems to do quite well on "reasonable"
> MathML.

At this point, what I'm concerned about is that turning MathML on doesn't 
regress performance of other things (such as page load speed of normal HTML 
pages, or memory use when not using MathML). I would not expect it to, but 
there's always the possibility of unexpected interactions.

Optimizing MathML rendering itself is something that can be done after it gets 
turned on/

> 
>> 2) We should try to do some fuzz testing to verify that MathML doesn't 
>> create security risks.
>> 
>> #2 can happen after we enable MathML, but should probably happen before 
>> anyone ships it.
> 
> What is involved in (2) ?
> 
> I'm happy to try to beat on the code to make sure it works well
> enough for people to feel comfortable turning it on.

I'm not an expert on making fuzzers, so maybe some of the security people here 
can chime in or perhaps even help out.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application

2010-07-13 Thread Maciej Stachowiak

On Jul 13, 2010, at 8:14 AM, Lianghui Chen wrote:

> Hi, I have asked this same question in (wha...@lists.whatwg.org), but haven't 
> got many responses, so I want to ask here again.
> 
> In spec HTML5 for offline web application 
> (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter 6.6.6, 
> item 3, 4, 5 state that for resources that is in online whitelist (or has 
> wildcard whitelist), or fallback list, it should be fetched “normally”.
> 
> I would like to know does it mean the user agent (browser) should bypass its 
> own caches (besides html5 appcache), like the WebKit cache and browser http 
> stack cache?

As the spec is currently written, I think the browser should not bypass its own 
caches. Other caches should have their normal behavior, and will revalidate 
once the freshness lifetime of the resource expires.

> 
> If we don't, like WebKit (and Opera) doing now, once browser starts with 
> network connection, it won't detect network connection loss, which happened 
> not that common for a PC but common for a mobile device. And it will 
> effectively defeat the intention of "fallback" resources in a offline web 
> application, as the content for a "fallback namespace" from cache will be 
> used, instead of the content of its mapping "fallback entry".

Clients have other ways to detect loss of connection:
(a) platform-specific APIs that track the state of network interfaces.
(b) Revalidating cached items once their freshness lifetime expires.

That being said, if you think there is a problem with the spec, you should 
report it to the W3C Web Apps WG or the WHATWG.

Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SIL Open Font License and WebKit

2010-07-19 Thread Maciej Stachowiak


Apple's legal department would strongly prefer for WebKit's license terms to 
remain simple. We prefer everything to be licensed under LGPL or BSD terms, or 
at the very least a license which is clearly compatible with LGPL and BSD. Is 
this license LGPL-compatible for cases where the fonts are embedded as data in 
software?

For support material that has unusual license terms, another possibility is to 
have WebKit's support scripts automatically download it, rather than checking 
it directly into the repository.

Regards,
Maciej

On Jul 16, 2010, at 8:05 AM, Eric Seidel wrote:

> A little web searching produced:
> 
> It's OSI approved:
> http://www.opensource.org/licenses/openfont.html
> 
> GNU thinks it's OK, albeit having an "unusual requirement":
> http://www.gnu.org/licenses/license-list.html#Fonts
> 
> Fedora recommended:
> https://fedoraproject.org/wiki/Licensing#Font_Licenses
> 
> It would appear to be "the font license".
> 
> -eric
> 
> On Fri, Jul 16, 2010 at 5:05 AM, Alex Milowski  wrote:
>> We have a licensing issue we need to address for MathML.  We need the STIX
>> fonts as they will provide consistent rendering for Mathematics.  I highly
>> suspect these fonts will find themselves on our desktops somewhere down
>> the road.  Meanwhile, we need them for our testing infrastructure to
>> actually work across all the platforms.
>> 
>> The STIX Fonts are available under the SIL Open Font License:
>> 
>>   http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=OFL_web
>> 
>> You can see the patch that adds these fonts here:
>> 
>>   https://bugs.webkit.org/show_bug.cgi?id=41961
>> 
>> I think we need to adjust our licensing policy to include font licenses
>> like the above.  It is unlikely that the STIX consortium will change their
>> font licensing.  In reality, they don't need to do so.  The font license is
>> intended to support "open source" fonts.
>> 
>> --
>> --Alex Milowski
>> "The excellence of grammar as a guide is proportional to the paucity of the
>> inflexions, i.e. to the degree of analysis effected by the language
>> considered."
>> 
>> Bertrand Russell in a footnote of Principles of Mathematics
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SIL Open Font License and WebKit

2010-07-19 Thread Maciej Stachowiak


On Jul 19, 2010, at 11:45 AM, Sausset François wrote:

> 
> Le 19 juil. 2010 à 21:04, Maciej Stachowiak a écrit :
> 
>> 
>> Apple's legal department would strongly prefer for WebKit's license terms to 
>> remain simple. We prefer everything to be licensed under LGPL or BSD terms, 
>> or at the very least a license which is clearly compatible with LGPL and 
>> BSD. Is this license LGPL-compatible for cases where the fonts are embedded 
>> as data in software?
> 
> See answers 1.4 to 1.7 in the following official FAQ of the license:
> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=OFL-FAQ_web
> It is compatible.

I don't see a claim that the font is LGPL-compatible when embedded in a 
program. The FSF discussion of this license doesn't say, unfortunately.

> And as the font is only used by DumpRenderTree for tests, the WebKit API by 
> itself does not need it at all.
> So, Safari, Chrome/Chromium, etc need to include neither the font, nor the 
> license.

Good point. However, at least some versions of DumpRenderTree build with test 
fonts embedded directly into the binary. 

> 
>> 
>> For support material that has unusual license terms, another possibility is 
>> to have WebKit's support scripts automatically download it, rather than 
>> checking it directly into the repository.
> 
> CSS font-face could be a workaround but a persistent location should be found 
> (and I suppose WebKit website has the same licensing issues?). And with that 
> solution MathML layout tests could not be run without a network connection.

I'm not suggesting WebFonts. Rather, the fonts could be downloaded on demand 
when running the tests if not present, the way we do with some Python modules.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding window.layoutTestInspector

2010-07-19 Thread Maciej Stachowiak

Darin and I discussed this proposal, and we had a few thoughts to share:

(1) It seems a little odd that we'll end up with two different objects that 
have similar names and a very similar purpose, but just differ in how they are 
implemented. Maybe there's a way to define layoutTestController in WebCore and 
have DumpRenderTree extend it.

(2) It does seem like for some test-specific methods, implementing then in 
WebCore would be simpler and would save the work of plumbing them through the 
WebKit layers.

(3) On the other hand, LayoutTestController seems like it has too much stuff in 
it. Originally DumpRenderTree exposed a very modest set of functionality, 
mostly to control output (dumpAsText) or to emulate things that you could do by 
hand when running the test in the browser (waitUntilDone, eventSender). 
Nowadays, there are dozens of methods. A lot of them are used in only one or 
two tests. And in many cases, the methods have no interactive equivalent, so a 
lot of our tests are not runnable in the browser at all. Those seem like bad 
trends. Maybe instead of making it easier to add to LayoutTestController, we 
should look at whether we can consolidate functionality, factor it into more 
objects, and find ways to test things that don't require quite so much custom 
functionality.

I'll add on my own behalf that "layoutTestInspector" doesn't seem like a great 
name and doesn't express the relationship to layoutTestController. It's not 
used to examine layout tests.

Regards,
Maciej

On Jul 14, 2010, at 10:16 PM, Hajime Morita wrote:

> Hi WebKit folks,
> 
> I'm planning to add "window.layoutTestInspector" or something like that to 
> DRT.
> And I'd like to hear your opinions.
> 
> Background:
> 
> Adding new method to LayoutTestController is hard. It
> - requires to add new WebKit API to each ports, when the method is to
> access WebCore.
> - requires to export extra WebCore symbols to access it from WebKit
> API implementation.
> - cannot use WebIDL so we need to write binding code manually.
> 
> In some case, these steps are unavoidable.
> But in some other case, especially when we just want to access WebCore
> from the test, we might be able to skip these steps.
> 
> A concrete example (my first motivation) is to test DocumentMarker
> for http://webkit.org/b/41423.
> DocumentMarker is WebCore's internal state and cannot access neither
> from DOM nor LayoutTestController.
> 
> To test it,
> - the first idea is to use a pixel test.
>  But it has some shortcomings as you know well.
> - The second idea is to extend render tree's dump format to
>  include markers. But it is also platform-specific,
>  and hard to interpret for humans.
> - The third idea is to add an API to LayoutTestController.
>  But it is hard as I mentioned above.
> 
> Is there another way? DocumentMarker is
> - WebCore's internal state,
> - so we don't need to inspect it except for testing purpose,
> - so it's better to avoid an extra WebKit API for that.
> 
> I think there are similar demands other than for DocumentMarker,
> and it might be worth to invest a common way to handle them.
> 
> Plans:
> 
> To deal with such cases, we can add a test-specific object named
> LayoutTestInspector to window object. (The name is tentative.)
> With this object, We'll be able to write a LayoutTest like:
> 
> if (window.layoutTestInspector) {
>   var target = document.getElementById("target")
>   var markerStr = layoutTestInspector.nodeMarkerString(target);
>   if (markerStr == "Spelling:0:6")
>  log("PASS");
>   else
>  log("FAIL");
> }
> 
> Here is a plan to do this:
> 
> - LayoutTestInspector will be defined in WebCore,
>  and implemented as a usual DOM object using WebIDL.
>  (placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
> - window object will expose a non-enumerable
> windows.layoutTestInspector property
>  for that.
> - Settings::m_enableLayoutTestInspector will control 
> windows.layoutTestInspector
>  availability. This flag should be true only on DRT.
> 
> Tests with LayoutTestInspector would have several advantages:
> 
> - Compared to LayoutTestController,
>  we don't need to add new APIs to WebKit layer for test purpose.
> - Compared to LayoutTestController,
>  we don't need to export extra WebCore APIs to WebKit layer.
> - Compared to Render-tree dump,
>  the test can be more portable, focused and understandable.
> 
> But there are some concerns:
> 
> - WebCore need to have a test-specific code, that might be a waste of space.
>  Test-specific WebKit APIs would have a same problem, though.
> - LayoutTestInspector may introduce some potential security risks.
>  I have no idea about this area.
> 
> Do you have any other use-cases or better approaches?
> Are there concerns I've missed? Do we have similar discussions in the past?
> Any ideas/suggestions are welcome.
> If there are no strong objections, I'll start to work on this.
> 
> Regards.
> 
> --
> morita
> __

Re: [webkit-dev] review queue crazy idea

2010-07-21 Thread Maciej Stachowiak


On Jul 21, 2010, at 2:40 PM, Ojan Vafai wrote:

> There are currently 38 (of 171 total) patches in the review queue where the 
> bugs have not been modified in over 1 month old. I propose we have a bot that 
> educates people about writing easy to review patches and auto-rejects any 
> patches in bugs that haven't been touched in over a month. For people new-ish 
> to the WebKit project, it is often confusing both degree of responsibility 
> that lies with the contributor to make the patch easy to review and the need 
> to get reviewers' attention for a given patch.
> 
> This is just an initial proposal. I'm not wed to any of the details of how 
> this would work. I do think that auto-rejecting old patches is valuable to 
> the project as a whole. Having the review queue be so large makes it daunting 
> for any reviewer to try and tackle it. On the other hand, knowing that 
> patches will magically fall off the end of the queue might encourage 
> reviewers to just ignore some patches.
> 
> An alternative to auto-rejecting patches would be to send a nag email once a 
> week to webkit-reviewers@ with the list of patches that are over a month old.

I think we should try the nag email first. I like the idea of advice on how to 
get a review. I think automatic rejection is kind of unfriendly, so I'd like to 
try other steps first.

 - Maciej

> 
> Here are my initial thoughts on what a review bot would do.
> 
> After a patch turns a week old, send the following email:
> Patch 12345 of bug 6789 is a week old. It may just be because no reviewer has 
> found time to review it. But there may be steps you can take to help get your 
> patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a few 
> suggestions.
> 
> -WebKit review bot
> 
> After the patch is three weeks old:
> Patch 12345 of bug 6789 is three weeks old. If it is still unreviewed in a 
> week, it will automatically be rejected. It may just be because no reviewer 
> has found time to review it. But there may be steps you can take to help get 
> your patch reviewed. See http://trac.webkit.org/wiki/CodeReview for a few 
> suggestions.
> 
> -WebKit review bot
> 
> After the patch is a month old:
> Patch 12345 of bug 6789 has been rejected because it is too old. This is 
> likely because no webkit reviewer has been able to review it. If you would 
> still like the patch reviewed, then please do the following:
> Make sure your patch still applies to tip of tree.
> Do as many of the suggestions at http://trac.webkit.org/wiki/CodeReview as 
> possible.
> Upload your patch for review again.
> -Webkit Review Bot
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

2010-07-22 Thread Maciej Stachowiak

On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote:

> Wow.  I really like this idea of helping contributors better
> understand what's going wrong.
> 
> But, I think that even better would be to build a better front-end for
> reviews.  Or a bot which knew how to suggest reviewers (based on
> annotate information from lines changed).

I think a better UI for reviews, plus some better attempts at active 
notification of potential reviewers, could go a long way. I'm a strong believer 
in trying nudges and positive incentives before implementing harsher policies.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

2010-07-24 Thread Maciej Stachowiak

On Jul 23, 2010, at 1:10 PM, Dirk Pranke wrote:

> I have been thinking along these lines as well. I'm not sure how
> relevant touching existing lines of code is versus just other people
> who have hacked on the file at all or who have hacked on other files
> in the same directory (i.e., you'd need to address new code and new
> files, too). I think some empirical testing and tweaking would be the
> way to evaluate this, though.

To find a reviewer, what you want to find is people who understand the relevant 
subsystems well, and perhaps also people who are good reviewers in general 
(have a high likelihood of spotting avoidable problems). Making lots of commits 
to (or touching lots of lines in) the same file or the same directory are at 
best proxies for that kind of information. They may be better proxies for that 
kind of information than self-identification, but that has yet to be 
demonstrated. While an algorithm is a good starting point, I think 
self-identification and/or peer identification can capture nuances that an 
algorithm will not.

I think the main problems with  are 
that (a) people don't know to look there; and (b) people don't know or don't 
bother to update it. I don't think the accuracy of the information is a problem 
(other than possibly being out of date). I don't see how it is helpful to refer 
to this information as "bragging".

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

2010-07-25 Thread Maciej Stachowiak

On Jul 25, 2010, at 1:03 AM, Ryosuke Niwa wrote:

> Are there Apple or third-party products that heavily rely on the current 
> implementation of RemoveFormatCommand?
> If not, I want to completely re-implement RemoveFormat to match the behavior 
> of other browsers.
> 
> In MSDN, RemoveFormat is described as:
> Removes the font and character formatting from the current selection.
> The following code removes all formatting from the selected text.
> 
> ActiveDocument.execCommand "removeformat
> 
> In MDC, it's described as:
> Removes all formatting from the current selection.
> 
> However, our current implementation deletes all selected contents and type 
> them back in,
> losing all sorts of elements such as input, img, hyper links, tables, lists, 
> and etc...
> 
> There are two options to resolve this problem:
> Store all elements deleted and their positions and insert (restore) them back.
> Remove format more gracefully by walking through the DOM and removing 
> stylesheets and presentational elements.
> I want to re-implement RemoveFormat because I don't think option 1 really is 
> an option.

I think the key question here is what counts as as "formatting". That needs to 
be determined empirically by testing other browsers, not just by reading their 
docs.

Here are some tricky questions:

- Does font-weight: bold count as "formatting"?
- Does the  element's default bold style count as "formatting"?
- Does the  element itself count as "formatting"?
- Does display: block count as "formatting"?
- Does the  element's display: block style count as "formatting"?
- Does the  element itself count as formatting?

You could make a rule that only non-default styles count as "formatting", but 
it would seem weird if "RemoveFormat" allowed the selection to retain bold or 
italic text, so I wonder if other browsers actually do that.

You could ask similar questions about tables and lists. In particular, do we 
preserve table and list elements with their default styles, but CSS table or 
list layout properties are not allowed?

I think with information based on testing other browsers, and test cases 
demonstrating this behavior, we could make a more informed decision.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.


On Jul 26, 2010, at 11:46 AM, Ryosuke Niwa wrote:

> Thanks a lot for the feedback!
> 
> On Sun, Jul 25, 2010 at 5:07 PM, Maciej Stachowiak  wrote:
> I think the key question here is what counts as as "formatting". That needs 
> to be determined empirically by testing other browsers, not just by reading 
> their docs.
> 
> I agree, it's crucial that we carefully decide on what to preserve and what 
> to not.
> 
> But MSDN explicitly say "character formatting" and bugs such as 
> Bug 13125 - removeformat execCommand loses input elements
> Bug 20216 - execCommand RemoveFormat removes links
> indicates that there is a demand to correct WebKit's behavior.

If our goal is to match other browsers, we need to test them, not read the 
docs. MSDN often bears little relation to IE's actual behavior.

> 
> I agree.  We should test and see what other browsers do in various cases.
> 
> But since it's impossible for us to enumerate every possible formatting, I 
> propose to just remove text-decoration, font-weight, etc... and the 
> corresponding presentational elements probably using ApplyStyleCommand as a 
> starting point.  We can then file a separate bug or so to uncover edge cases 
> and polish the behavior.

Sure it's possible. We can test every CSS property and every HTML element. It 
should be easy to write a test case that checks every case exhaustively. I 
don't think it makes sense to change our behavior based on a guess of what 
other browsers do.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Introducing dumpAsMarkup

On Jul 26, 2010, at 3:06 PM, Ryosuke Niwa wrote:

> If tests you write only require comparing DOMs, you want to read this.
> 
> We've recently added dump-as-markup. It allows your tests to be platform 
> independent and gives output that is easier to read than render tree dumps. 
> For example, if I have:
> 
> This is a dumpAsMarkup test.
> window.getSelection().selectAllChildren(foo);
> 
> Then I get:
> 
> 
> 
> 
> <#text>
> 
> 
> 
> 
> <#text>This is a dumpAsMarkup test.
> 
> <#text>
> 
>  window.getSelection().selectAllChildren(foo); 
> <#text>
> 
> 
> 
> 
> See Writing DumpAsMarkup Tests for more ways you can use dump-as-markup.js

Very cool! I suggest adding # signs to the selection pseudo-elements, just to 
avoid the tiny risk of conflicting with an actual element in a test. Also, 
perhaps it would be better to show tag names in lowercase - that can be 
achieved by using localName instead of nodeName or tagName.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.


On Jul 26, 2010, at 4:27 PM, Ryosuke Niwa wrote:

> 
> On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak  wrote:
>> I agree.  We should test and see what other browsers do in various cases.
>> 
>> But since it's impossible for us to enumerate every possible formatting, I 
>> propose to just remove text-decoration, font-weight, etc... and the 
>> corresponding presentational elements probably using ApplyStyleCommand as a 
>> starting point.  We can then file a separate bug or so to uncover edge cases 
>> and polish the behavior.
> 
> Sure it's possible. We can test every CSS property and every HTML element. It 
> should be easy to write a test case that checks every case exhaustively. I 
> don't think it makes sense to change our behavior based on a guess of what 
> other browsers do.
> 
> I don't think that captures all possible formatting because CSS in particular 
> has interesting effects when combined with other styles. What I meant is that 
> we can't test every combination of all CSS properties & HTML elements (i.e. 
> enumerating every possible DOM with every possible combinations of CSS 
> properties applied every possible way on each DOM) simply because there are 
> infinitely many of them. Although I'd guess that some of them are reputations 
> so we might be able to find a finite subset that suffice the purpose. anyhow, 
> I agree that testing every CSS property and every HTML element will be a good 
> idea.  That'll at least give us a starting point.

I doubt any other browser behaves differently for a combination of CSS 
properties than for individual CSS properties. I guess it's possible but it 
seems unlikely.

I would note though that there is a finite set of possible combinations of CSS 
properties, if you pick a finite set of possible values to try for each, but it 
might be too large a set for the test to complete in a reasonable time frame.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Introducing dumpAsMarkup

On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote:

> You can see many more examples of dom2string in the non-html5 results
> (where there are a zillion failure cases):
> http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt
> 
> dom2string.js came from http://code.google.com/p/html5lib I thought,
> but I couldn't find the source for it there.
> 
> I'm not wedded in any way to dom2string.  But I do like the output it
> produces slightly more than the current dumpAsMarkup.  I agree,
> standardization might be nice.
> 
> dom2string uses " for <#text> and .  newlines return you to
> the start of the line as you would expect.  (see the
> runner-expected.txt above).
> 
> -eric
> 
> p.s. Would be nice if we could just inject certain javascript into
> every page.  Sorta like how v8 allows you to define engine-level
> functions in javascript.  Would be nice to just make dumpAsMarkup()
> part of DRT, but write it in javascript. :)

That's easy to do, DRT could just force loading of the JS file that implements 
dumpAsMarkup() (or whatever we end up calling it). But I'm not sure that is 
better than including a JS file in the test explicitly. For one thing, most of 
the logic to dumpAsMarkup() (other than forcing a text dump) should work in any 
other browser, so it would make it easier to try our tests in other browsers if 
the JS code implementing it is included explicitly instead of magically. It 
would also make the tests more useful to try in a WebKit-based browser like 
Safari or Chrome, for that matter - you wouldn't need DRT to see the output.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)


On Jul 26, 2010, at 5:46 PM, Ojan Vafai wrote:

> Then again it should be possible to re-write our script-test support
> so that this is all you need to write:
> 
> 
> 
> description("foo");
> shouldBe("foo", "bar");
> 
> 
> 
> Instead of the current (cumbersome) templating system.  Should be
> possible to even get rid of the final "end-script-test.js" tag if
> we're smart.
> 
> Yes! The templating system is just too much overhead, not to mention that it 
> creates too many files. There's a few minor issues with the above though:
> 1. What if you want to include multiple js files? For example, then 
> editing/selection tests include two JS files. Maybe we should just move all 
> our JS code into one file?
> 2. The src will need to be relative, so you'll need some "../.." action. But 
> that seems OK to me. Unless we had a script that put the JS files in every 
> directory (or maybe in the resources subdirectory of every directory).

The template in fast/js is currently this:















We could reduce it to this by having the test script document.write the 
skeleton content and the stylesheet (as an inline

Re: [webkit-dev] Enabling the HTML5 tree builder soon

2010-07-27 Thread Maciej Stachowiak

On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:

> I measure it as a 1% win on the PLT.

Might be a good idea to test HTML iBench as well.

 - Maciej

> 
> -- Stephanie
> 
> On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote:
> 
>> I can do this.
>> 
>> -- Stephanie Lewis
>> 
>> On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
>> 
>>> Would someone from Apple be willing to run the patch below though the
>>> PLT?  We're doing well on our parsing benchmark (4% speedup), but the
>>> PLT might have a different mix of HTML.
>>> 
>>> Thanks,
>>> Adam
>>> 
>>> 
>>> diff --git a/WebCore/html/HTMLTreeBuilder.cpp 
>>> b/WebCore/html/HTMLTreeBuilder.cpp
>>> index 7a9c295..5b89c37 100644
>>> --- a/WebCore/html/HTMLTreeBuilder.cpp
>>> +++ b/WebCore/html/HTMLTreeBuilder.cpp
>>> @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer*
>>> tokenizer, HTMLDocument* documen
>>>   , m_originalInsertionMode(InitialMode)
>>>   , m_secondaryInsertionMode(InitialMode)
>>>   , m_tokenizer(tokenizer)
>>> -, m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new
>>> LegacyHTMLTreeBuilder(document, reportErrors) : 0)
>>> +, m_legacyTreeBuilder(0)
>>>   , m_lastScriptElementStartLine(uninitializedLineNumberValue)
>>>   , m_scriptToProcessStartLine(uninitializedLineNumberValue)
>>>   , m_fragmentScriptingPermission(FragmentScriptingAllowed)
>>> 
>>> 
>>> On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth  wrote:
 We're getting close to enabling the HTML5 tree builder on trunk.  Once
 we do that, we'll have the core of the HTML5 parsing algorithm turned
 on, including SVG-in-HTML.  There are still a bunch of details left to
 finish (such as fragment parsing, MathML entities, and better error
 reporting), but this marks a significant milestone for this work.

 The tree builder is markedly more complicated than the tokenizer, and
 I'm sure we're going to have some bad regressions.  I'd like to ask
 your patience and your help to spot and triage these regressions.
 We've gotten about as much mileage as we can out of the HTML5lib test
 suite and the LayoutTests.  The next step for is to see how the
 algorithm works in the real world.

 There are about 84 tests that will require new expectations, mostly
 due to invisible differences in render tree dumps (e.g., one more or
 fewer 0x0 render text).  In about half the cases, we've manually
 verified that our new results agree with the Firefox nightly builds,
 which is great from a compliance and interoperability point of view.
 The other half involve things like the exact text for the ,
 which we've chosen to match the spec exactly, or the  element,
 which needs some shadow DOM love to hide its implementation details
 from web content.

 As for performance, last time we ran our parser benchmark, the new
 tree builder was 1% faster than the old tree builder.  There's still a
 bunch of low-hanging performance work we can do, such as atomizing
 strings and inlining functions.  If you're interested in performance,
 let me or Eric know and we can point you in the right direction.

 I don't have an exact timeline for when we're going to throw the
 switch, but sometime in the next few days.  If you'd like us to hold
 off for any reason, please let Eric or me know.

 Adam

 P.S., you can follow along by CCing yourself on the master bug,
 , or by looking at our
 LayoutTest failure triage spreadsheet,
 .

>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Enabling the HTML5 tree builder soon

2010-07-28 Thread Maciej Stachowiak


For future reference, iBench can be found here:

ftp://ftp.pcmag.com/Benchmarks/i-bench/ib50.exe

However, it requires a Windows system with IIS to set up the server, and is 
generally a hassle to set up as Stephanie said.

Cheers,
Maciej


On Jul 28, 2010, at 10:09 PM, Adam Barth wrote:

> slewis++
> 
> On Thu, Jul 29, 2010 at 3:15 AM, Stephanie Lewis  wrote:
>> I believe it is somewhere, but the setup is a hassle, so I'll run it 
>> tomorrow for you.
>> 
>> -- Stephanie
>> 
>> On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
>> 
>>> On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak  wrote:
>>>> On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
>>>>> I measure it as a 1% win on the PLT.
>>>> 
>>>> Might be a good idea to test HTML iBench as well.
>>> 
>>> Sure.  I'd be happy to.  Is that benchmark available publicly?
>>> 
>>> Adam
>> 
>> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Updating the tradition for new reviewer blog posts

2010-08-02 Thread Maciej Stachowiak


On Aug 2, 2010, at 1:56 PM, Adam Barth wrote:

> I'd be happy to write more posts for Surfin' Safari, but I don't know
> if I need approval, etc.

You don't need approval.

 - Maciej

> 
> Adam
> 
> 
> On Mon, Aug 2, 2010 at 1:31 PM, Eric Seidel  wrote:
>> Woh.  I think that's an awesome idea. :)
>> 
>> Would also make sure that all reviewers are blog-enabled.
>> 
>> Might be a bit to ask of new reviewers though.
>> 
>> -eric
>> 
>> On Mon, Aug 2, 2010 at 11:56 AM, Tony Gentilcore  wrote:
>>> The Surfin' Safari blog seems to have fairly wide readership in the web dev
>>> community. Google Reader reports 35k Reader subscribers. For comparison:
>>> blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last
>>> post with descriptive content was back on April 18th. Since that post, we've
>>> written 8 "X is a now a WebKit reviewer" posts. One recent commenter said:
>>> "I don’t suppose there’s anything more interesting going on in WebKit land
>>> worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t
>>> nearly as interesting as whatever new hotness is coming down the pipe. And I
>>> know I’m not the only one who thinks so… Feel like blogging about WebKit
>>> awesomeness?"
>>> 
>>> I propose we increase the amount of blogging about WebKit awesomeness by
>>> changing the tradition for new reviewer posts.
>>> 
>>> Instead of defaulting to:
>>> 
>>>   So-and-so is now a WebKit reviewer
>>>   Posted by Someone-else
>>>   So-and-so has worked on awesome-feature or awesome-infrastructure...
>>> 
>>> We encourage (or just allow?) a format more like:
>>> 
>>>   How awesome-infrastructure works
>>>   Posted by So-and-so, the latest WebKit reviewer
>>>   Here's my description of how awesome-infrastructure works in WebKit...
>>>   -OR-
>>> 
>>>   Awesome-feature is the new hotness
>>>   Posted by So-and-so, the latest WebKit reviewer
>>>   Web developers can now use awesome-feature. Here's how it works...
>>> 
>>> Thoughts?
>>> -Tony
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Updating the tradition for new reviewer blog posts

2010-08-02 Thread Maciej Stachowiak


I agree that it would be good to have more useful and interesting content. I 
don't think it's good to do this by forcing the task on new reviewers. Not 
everyone enjoys a writing exercise and it shouldn't be required to become a 
reviewer. However, I encourage people to post about cool WebKitty stuff!

 - Maciej

On Aug 2, 2010, at 11:56 AM, Tony Gentilcore wrote:

> The Surfin' Safari blog seems to have fairly wide readership in the web dev 
> community. Google Reader reports 35k Reader subscribers. For comparison: 
> blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last 
> post with descriptive content was back on April 18th. Since that post, we've 
> written 8 "X is a now a WebKit reviewer" posts. One recent commenter said:
> 
> "I don’t suppose there’s anything more interesting going on in WebKit land 
> worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t 
> nearly as interesting as whatever new hotness is coming down the pipe. And I 
> know I’m not the only one who thinks so… Feel like blogging about WebKit 
> awesomeness?"
> 
> I propose we increase the amount of blogging about WebKit awesomeness by 
> changing the tradition for new reviewer posts.
> 
> Instead of defaulting to:
> 
>   So-and-so is now a WebKit reviewer
>   Posted by Someone-else
>   So-and-so has worked on awesome-feature or awesome-infrastructure...
> 
> We encourage (or just allow?) a format more like:
> 
>   How awesome-infrastructure works
>   Posted by So-and-so, the latest WebKit reviewer
>   Here's my description of how awesome-infrastructure works in WebKit...
> 
>   -OR-
> 
>   Awesome-feature is the new hotness
>   Posted by So-and-so, the latest WebKit reviewer
>   Web developers can now use awesome-feature. Here's how it works...
> 
> Thoughts?
> 
> -Tony
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkit editing rewrite?

2010-08-04 Thread Maciej Stachowiak

On Aug 3, 2010, at 4:38 PM, Darin Adler wrote:

> Inventing a new layer to rebuild editing on top could well be good. Exposing 
> that layer itself to webpages seems like it makes the job even harder rather 
> than easier! Hidden implementation details can be changed more easily than 
> exposed APIs.
> 
> I personally don’t think a complete rewrite is a great idea, nor do I think 
> that using JavaScript is how I’d do it.

I strongly agree with these points.

In addition I'd add, there seem to be multiple large changes proposed under the 
"complete rewrite" heading:

(1) A new editing API exposed to Web content.
(2) A new set of fundamental abstractions to build editing on top of (which 
maybe has to be the same as #1?)
(3) A change in implementation language for much of the editing code from C++ 
to JavaScript.
(4) A from-scratch rewrite of the whole editing subsystem, rather than an 
incremental refactoring.

Each of these seems like a very high-risk project. Doing all four at once seems 
to put the risk into the red zone. My idea of how to make these kinds of 
changes would be to do one at a time, and probably not do #3 or #4 at all. 
Rewriting is almost never a better option than refactoring.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Some new coding style rules

2010-08-04 Thread Maciej Stachowiak


On Aug 4, 2010, at 10:43 AM, Darin Adler wrote:

> On Aug 4, 2010, at 1:29 AM, Nikolas Zimmermann wrote:
> 
>> 1. namespace closing brace
>> It was discussed in 
>> http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563, but with no 
>> real result.
>> 
>> When writing headers, do we need the "// namespace Foo" comment after the 
>> namespace closing brace? I think it's visual noise and would like to see a 
>> style rule that forbids it.
>> (A rule that says we need this would also be fine with me, as long as we 
>> write it down. But I'd vote for removing those comments, I don't trust them 
>> anyways, if I'm unsure.)
>> 
>> namespace WebCore {
>> ...
>> } // namespace WebCore
> 
> My personal preference: We should omit it.
> 
>> 2. ENABLE(FOO) #endif comments
>> 
>> #if ENABLE(FOO)
>> ..
>> #endif // ENABLE(FOO)
>> 
>> Shall we remove the comment, or require it explicitely in the style rules?
> 
> My personal preference: We should omit it.

Comments at the end of an #if block can help code readability if the #ifs are 
nested. 

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Fwd: webkit editing rewrite?

2010-08-05 Thread Maciej Stachowiak

On Aug 4, 2010, at 6:12 PM, Ojan Vafai wrote:

> 
> On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen  wrote:
>>> -Ensures that the APIs we expose to the web are at least good enough for 
>>> our own editing code
>> 
>> I don't think this necessarily follows. Not everything exposed to the 
>> internal editing implementation would necessarily be exposed to the web. If 
>> we required that everything exposed to the internal editing implementation 
>> be exposed to the web, that would substantially slow development, since 
>> every new API would need to be vetted and possibly standardized. So this is 
>> either not true or a substantial con.
> 
> This would have been a fine point without the last sentence here. I'm
> not sure how to read that sentence without the implication that I'm
> either being stupid or manipulative. FWIW, I do think that everything
> exposed to the internal editing implementation should eventually be
> exposed to the web. I'll expand on that below.

I think Geoff is not saying that you are stupid or manipulative, just that he 
disagrees with your conclusion. There are many reasons someone could be wrong, 
for example that they are honestly mistaken. When I think someone is wrong, I 
usually assume they are honestly mistaken  and can probably be persuaded 
through logic. Or else, perhaps I am mistaken and will learn that through 
discussion. When someone else disagrees with me and says I am wrong, I try to 
assume they thought I made an honest mistake. Sometimes people actually do 
think I am stupid or are stupid themselves, but I find it makes technical 
discussions go better if I don't focus on those possibilities.

Short version: let's all try to assume good faith on the part of our fellow 
webkit-dev posters.

(That being said, I think a few parts of Geoff's message were a little too 
snarky, but I think the point you cited here is a reasonable one and not stated 
in an overly combative way.)

> On Tue, Aug 3, 2010 at 4:38 PM, Darin Adler  wrote:
>> Inventing a new layer to rebuild editing on top could well be good. Exposing 
>> that layer itself to webpages seems like it makes the job even harder rather 
>> than easier! Hidden implementation details can be changed more easily than 
>> exposed APIs.
> 
> I agree that these can be separated out. 1 and 2 are the ones I really
> care about. 3 and 4 were just an idea of one way to get there. I'm not
> attached to them.
> 
> I was picturing that we would first implement all or most of our
> editing code on top of the editing API and then, once we were
> confident with it, expose it as a webkit prefixed set of APIs that we
> propose to the appropriate standards body. I'd like to see an approach
> to this where we move (incrementally) in the direction of a clearly
> defined editing API that the editing code uses that we can eventually
> expose to the web.
> 
> I'll try and make some concrete proposals in the coming days.

I think this carries an assumption that the right internal abstractions are 
necessarily also a sensible public API. I don't know if that is a good 
assumption. 

First: It is tempting to argue along the lines of "the pieces needed to 
implement API X must be powerful primitives which should be exposed as API in 
their own right". But at some level, there has to be a next layer of 
implementation down that is not exposed, so clearly this line of argument has 
limits. It can't be API turtles all the way down.

Second, often the right internal implementation strategy bears very little 
relation to the proper public API. For example, CSS is a reasonable 
constraint-based system to express layout and style rules. Web designers seem 
to get along ok with it. But internally it's implemented via the render tree, 
which is a very different abstraction, though it relates to CSS concepts. 
Exposing the render tree in every detail would greatly constrain our ability to 
change implementation strategy in the future. So this is one clear-cut case 
where the implementation abstractions do not necessarily make sense as API. To 
give a simpler and more pervasive example, we use refcounting throughout many 
pieces of WebCore, but it would not be appropriate to expose to Web content 
because it's too low-level. I could cite endless examples where the public API 
exposed to Web content ends up very different from internal abstractions. The 
DOM is probably the one major subsystem where there is a lot of similarity, and 
even then, many critical implementation interfaces are not exposed, nor should 
they be.

Third, in the case of editing specifically, much of the existing behavior, in 
response to user actions and things like the execCommand API, has *really* 
weird quirks. And some of its behavior is probably wrong in light of what other 
browsers do. It may be that the pieces needed to build all those quirky 
behaviors are not really sane as a public API.

Overall, I think the API design process should work in the opposite direction. 
You do

Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-11 Thread Maciej Stachowiak

On Aug 9, 2010, at 8:21 PM, Timothy Hatcher wrote:

> On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:
> 
>> I am very, very tempted to just get rid of them. As Ojan indicated,
>> the use cases for DOM Mutation events are extremely limited and to me,
>> most of them feel like we should be solving them differently anyway.
>> 
>> However, with the introduction of extensions into Chromium and Safari,
>> DOM Mutation events experience a sort of renaissance, being used to
>> sense the DOM changes to re-apply modifications (rewrite URLs, text,
>> etc.).
>> 
>> So I think we will upset a bunch of extensions developers if we just
>> go cold turkey, which is probably not the right thing -- regardless of
>> whether techniques they employ are sound or not.
>> 
>> With this in mind, I think we should do #1 and #3, then #2 after some
>> time and loud over-communication (like Inspector warnings, blog posts,
>> billboards on Hwy 101 etc.).
> 
> 
> Adding input/beforeinput events (#3) wont solve the need of most extension 
> developers that use mutation events today (the examples you cite). So that 
> makes it hard to remove them, especially over time, no matter how much 
> warning you give.

Would it satisfy extension use cases if DOM mutation events got batched and 
dispatched asynchronously as the generic DOMSubtreeModified?[1] Do extensions 
need detailed change notification, or is a general "something changed" 
notification good enough?

I think reducing mutation event support down to just DOMSubtreeModified, and 
firing it only at the very end of operations that should be atomic, would 
greatly reduce the risk of mutation-event-induced crashing, but would probably 
still serve the key use cases.

For performance reasons, it would be even better to have a type of notification 
that doesn't have to allocate an event object, as that is a large part of the 
performance hit from mutation events. I gather that is what the fancier new 
mutation events proposal does.

Regards,
Maciej

[1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMSubtreeModified
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are we running Sputnik?

2010-08-11 Thread Maciej Stachowiak

On Aug 10, 2010, at 2:26 PM, Alexey Proskuryakov wrote:

> 
> 10.08.2010, в 14:00, Adam Barth написал(а):
> 
>> A better long-term fix might be to finish new-run-webkit-tests so we
>> can run the tests in parallel.
> 
> 
> One reason to move the tests to run-javascriptcore-tests is that people 
> working on JS run these more often (sometimes not even building WebCore until 
> ready to submit a patch).

If these tests can catch regressions from non-JS-engine changes (and according 
to Adam's message, they have done so at least once), then we need to run them 
in the full browser engine context, even if we also have a version that runs in 
a JS-only command-line tool.

As another data point, some of the Sputnik tests are currently failing in 
WebKit2 on Mac, so they are detecting a problem that they wouldn't be able to 
if they ran JS-only.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build system complexity


On Aug 12, 2010, at 2:53 AM, Jeremy Orlow wrote:

> Are there currently any plans for simplifying the situation regarding build 
> systems?  I haven't seen any threads for a while, which I assume means no.
> 
> Is there any low hanging fruit out there?  Since many of the build systems 
> are little more than lists of files, it really seems like we should be able 
> to do some sort of consolidation.  Or reduce the process down to updating one 
> file and then running a script that updates/generates the rest.  Currently, I 
> cringe every time I find out I need to add a new file.
> 
> In addition, has anyone ever looked at simplifying the mac port's xcode 
> project?  It's _by far_ the heaviest burden on the project given that you 
> pretty much need to use xcode (which is mac only...no other port requires 
> this), exported linker symbols are in a separate file, extra effort to expose 
> a new file in WTF to WebCore, extra effort to expose a new file in WebCore to 
> WebKit, etc.  Has anyone recently looked at how the mac build could be 
> simplified--especially from the perspective of contributors whose main 
> development platform isn't a mac?

I think we should switch over to export control specified in the headers and 
not use .exp files any more. WebKit2.framework builds on all its target 
platforms with no external export control file. The hardest case for this is 
probably WebCore, though, and I'm not sure how practical it is to do 
incrementally.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:

> I was wondering if it would be a reasonable change to make accessing 
> location.href (and other location properties) throw SECURITY_ERR when 
> accessed across origins (https://webkit.org/b/43504). This initially was 
> reported on the Chrome side (giv), but it looks like neither the JSC nor V8 
> bindings do this, so fixing it across the board seemed reasonable.
> 
> From my investigations, it looks like IE and Gecko both throw an exception in 
> this case, and the HTML5 spec mentions it too 
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location).
> 
> I realize that we're cautious around the access checks for security reasons 
> (based on changes like https://trac.webkit.org/changeset/48619), but this 
> seems safe since 1) we were returning control to the script at that point 
> anyway 2) we already throw exceptions in some cases in that code: 
> https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219

I think what we do is better than what HTML5 specifies for this:

1) It means the access control goes in fewer places - we don't have to have 
access control on every document property, only window properties.

2) If access is denied for security reasons, it seems like it gives the 
attacker less information and less potential attack surface to just give them 
an undefined value instead of raising a security exception. Security errors 
make it easier to probe.

So in general I'm not in a rush to change this. However, if the original bug 
involved a compatibility problem on a real site (it doesn't really say), then 
maybe that would be a stronger reason to change.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] js binding: function argument type checking


I think doing type checks in the bindings makes sense as a long-term strategy. 
Only the bindings level can tell actually detect wrong type errors; the C++ 
layer can't distinguish wrong type from a validly passed null. WebGL interfaces 
are not the only ones that have this problem. Here is a DOM Core example of the 
bug:

document.body.insertBefore(document.createElement("div"), "foo")

This will append a div to the body, when it should throw.

As far as tactics go:

1) I think it's much better to deploy this gradually than to all bindings at 
once; if a pervasive change causes a regression, then the regression becomes 
much harder to track down.

2) In many cases, this *will* change behavior. When deploying the new approach 
to methods where it changes behavior, we should create regression tests showing 
the behavior change.

Regards,
Maciej


On Aug 12, 2010, at 7:11 PM, Sam Weinig wrote:

> As I mentioned, I am not necessarily against ever changing the behavior, but 
> if we do, we should make sure to remove all the existing checks, as they 
> become an unnecessary branch.  It just seems to me like that should be a 
> separate change than a bug due to ambiguity.
> 
> -Sam
> 
> On Thu, Aug 12, 2010 at 4:21 PM, Kenneth Russell  wrote:
> For what it's worth, I think this change should be made for all of the
> DOM bindings, not just those for WebGL. The IDL code generators'
> support for overloaded methods already generates TypeError when an
> incoming argument doesn't implement any of the interfaces required by
> the overloaded variants. The new behavior will be closer to the rules
> specified by Web IDL in
> http://dev.w3.org/2006/webapi/WebIDL/#es-interface and also, as I
> understand it, closer to what Firefox implements.
> 
> It would be possible to add support for another extended attribute to
> the code generators and annotate all of the methods in
> WebGLRenderingContext.idl, but I really think the default behavior
> should be changed.
> 
> -Ken
> 
> On Thu, Aug 12, 2010 at 1:15 PM, Mo, Zhenyao  wrote:
> > Hardly.  Right now we already do the type checking in the generated
> > toType(argument) functions.  Instead of casting to null, we throw a
> > TypeError, which adds no extra cost if the type is correct.
> >
> > Besides, where I looked, after toType(argument) call, exception is
> > checked.  Only that currently toType(argument) is not generating
> > exceptions.
> >
> > Mo
> >
> > On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig  wrote:
> >>
> >>
> >> On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher  wrote:
> >>>
> >>> On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig  wrote:
> 
>  On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier 
>  wrote:
> >
> > On Thu, Aug 12, 2010 at 13:26, Sam Weinig  wrote:
> >>
> >> For this specific case, it seems like you could easily check for a null
> >> WebGLProgram* in WebGLRenderingContext::useProgram and set the
> >> ExceptionCode.
> >
> > Nope, null is a valid argument, it bounds to the initial program, which
> > means nothing will be drawn with WebGL.
> > Certainly not the expected behavior when one pass the wrong type to the
> > argument like Zhenyao pointed out, therefore throwing TypeError really 
> > makes
> > sense here (and elsewhere with WebGL API).
> 
>  Ok, in that case, it seems like you need to do it in the bindings for
>  this. I would prefer not making a sweeping change at this time, and 
>  instead
>  keeping the changes just to places where the extra checking is necessary 
>  due
>  to ambiguity (as in this useProgram case).
>  -Sam
> >>>
> >>> Out of curiosity, if we have the ability for code to be auto generated
> >>> from the IDL, why not use it universally?  I'm trying to guess to 
> >>> understand
> >>> your preference :)
> >>> -Darin
> >>
> >> My concern with doing it universally is the performance cost of doing the
> >> check twice in many places (once in the bindings and once in the
> >> implementation with a null check). We could certainly re-evaluate the way 
> >> we
> >> do these type checks, potentially even converting the existing null checks
> >> in the implementation to asserts, but I think that discussion shouldn't be
> >> conflated with this bug fix.
> >> -Sam
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >>
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses


On Aug 13, 2010, at 2:12 AM, Jeremy Orlow wrote:

> On Fri, Aug 13, 2010 at 8:42 AM, Maciej Stachowiak  wrote:
> 
> On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:
> 
>> I was wondering if it would be a reasonable change to make accessing 
>> location.href (and other location properties) throw SECURITY_ERR when 
>> accessed across origins (https://webkit.org/b/43504). This initially was 
>> reported on the Chrome side (giv), but it looks like neither the JSC nor V8 
>> bindings do this, so fixing it across the board seemed reasonable.
>> 
>> From my investigations, it looks like IE and Gecko both throw an exception 
>> in this case, and the HTML5 spec mentions it too 
>> (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location).
>> 
>> I realize that we're cautious around the access checks for security reasons 
>> (based on changes like https://trac.webkit.org/changeset/48619), but this 
>> seems safe since 1) we were returning control to the script at that point 
>> anyway 2) we already throw exceptions in some cases in that code: 
>> https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219
> 
> I think what we do is better than what HTML5 specifies for this:
> 
> 1) It means the access control goes in fewer places - we don't have to have 
> access control on every document property, only window properties.
> 
> 2) If access is denied for security reasons, it seems like it gives the 
> attacker less information and less potential attack surface to just give them 
> an undefined value instead of raising a security exception. Security errors 
> make it easier to probe.
> 
> So in general I'm not in a rush to change this. However, if the original bug 
> involved a compatibility problem on a real site (it doesn't really say), then 
> maybe that would be a stronger reason to change.
> 
> Regards,
> Maciej
> 
> If we're willfully going against the spec because we think our solution is 
> better, should this be brought up on WhatWG or in the HTML WG?  (Or has it 
> already?)

It might be, but before taking that step, I'm really curious if the bug that 
sparked this discussion was based on a real compat issue that the author ran 
into.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tests that separate JS and HTML

2010-08-16 Thread Maciej Stachowiak

On Aug 16, 2010, at 12:44 PM, Ojan Vafai wrote:

> I agree that dealing with the script to generate tests and having the actual 
> test content be in a different file is a significant maintenance overhead. 
> But I also think that having standard testing code across many tests reduces 
> the amount of effort it takes to understand a test.
> 
> We discussed this at 
> https://lists.webkit.org/pipermail/webkit-dev/2010-July/013673.html. I think 
> Maciej's solution sounds ideal, although I'm not convinced it's worth 
> including doctype for news tests.

I think it is. Tests should be in strict mode by default, unless you 
specifically have a goal of testing quirks mode behavior. Quirks more is more 
likely to have weird pitfalls or to change in unexpected ways over time. No 
doctype == quirksmode, for HTML anyway. XML-based tests (including XHTML, 
MathML and SVG) don't need a doctype. And really, "" is hardly a 
burden on either the reader or the writer. The short, memorable doctype is one 
of my favorite things about HTML5.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

2010-08-16 Thread Maciej Stachowiak

On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote:

> On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak  wrote:
>> 1) It means the access control goes in fewer places - we don't have to have
>> access control on every document property, only window properties.
> 
> I'm not quite sure I understand this. At least for the location
> object, I see an explicit check in JSLocationCustom.cpp:
> http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71.
> Throwing the exception would happen there too (it won't require custom
> getters for each property).

Yes, a small handful of objects that hang off of Window are accessible 
cross-origin and have their own security checks. However, one property of 
Window is handled very differently between WebKit-based browsers and what the 
spec calls for. someCrossOriginWindow.document returns undefined in 
WebKit-based browsers, but it returns a document object per the spec which then 
does its own security check on every property access. This is unfortunate 
because the attack surface is increased and performance suffers. And it's not 
Web-compatible to just throw on access to the document property - Web apps 
expect they can always ask for the document, and it's the *next* property 
access that throws, which is fulfilled by returning undefined since accessing a 
property of the undefined value throws in JS. For cases like the location 
object, it doesn't matter much either way.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ANGLE

2010-08-16 Thread Maciej Stachowiak

On Aug 16, 2010, at 4:26 PM, Darin Fisher wrote:

> On Mon, Aug 16, 2010 at 2:43 PM, Chris Marrin  wrote:
> 
> 
> I'm not familiar with what update-webkit does. But the only reason ANGLE is 
> in the root is because a couple of people here said that was the best way to 
> do it. ANGLE is a pretty new project and it doesn't look to me like they are 
> producing .zip files yet. I'd hate to use TOT because that could introduce 
> instability at random times. We were originally going to just put a .a in the 
> tree but someone (maybe Maciej?) thought that was a bad idea.
> 
> There are many things we can do:
> 
> 1) Leave it as is
> 2) Move the source to a better subdir
> 3) Check angle.a into WebKit and get rid of the source
> 4) Checkout ANGLE from its source repo and build it
> 
> I don't have any preference, except that if we choose option 4 we make sure 
> to get a known rev to avoid instability
> 
> 
> #4 is what Chromium does for numerous dependencies (including WebKit).
> 
> It seems like it would be fairly easy to extend update-webkit to checkout 
> ANGLE at the right revision for ports that require it.

For purposes of Apple internal process, if we eventually want to ship a version 
of WebKit that relies on ANGLE, we need to submit it as source, from an 
Apple-managed repository (both for purposes of continuity and so we can add our 
own branches and tags etc). This is done for a number of open source projects 
that are developed completely external to Apple and minimally modified, if at 
all.

We could, if we wanted to, have a completely separate copy of ANGLE source 
that's checked into a separate Apple-internal repository, and provide a version 
of ANGLE for use when building WebKit in some completely different way, such as 
by checking in a binary, or by pulling from the upstream repository live. 
However, this would create busywork to keep multiple version in sync, and a 
risk of version skew if our internal copy ever gets out of sync with whatever 
the webkit.org tree uses.

Granted, this mostly affects Apple (and potentially users of software we ship, 
if we accidentally ship a different version than what was tested). I'm willing 
to consider that we should change our approach if it would create a greater 
benefit for other WebKit contributors. But before we do that, I'd like to 
understand the tangible benefits to others, if any.

(Note, this only applies to #3 and #4 above; there's no material difference 
between #1 and #2 for us.)

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page

On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:

> Where-ever it goes, please don't put it on Document directly. :)
> (Feel free to tie it to Document's lifetime, just don't add to
> Document's 300+ methods.)
> 
> The madness must stop...  Document is long overdue for some weightloss...

I assume Dean is suggesting that Document would gain a new data member 
(DeviceMotionController?) which strikes me as a reasonable approach.

> 
> -eric
> 
> On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson  wrote:
>> Hi,
>> 
>> I've been looking into implementing the clients for DeviceOrientation/Motion 
>> Events. Currently, the controllers for these events are members of Page. I 
>> think they are better suited on Document.
>> 
>> Here are a few reasons:
>> 
>> - Page isn't tied to any actual web page or document. Would we want to share 
>> the same controller and client across multiple web pages? I don't think so.
>> - Document is already the place that is listening for these events
>> - It's easy to suspend and resume the client from the Document-level when 
>> the user navigates to another page, or the document enters the cache, or a 
>> platform needs to temporarily suspend events for some reason.
>> - When the API is on Page, it is hidden in the WebView, from where it is 
>> difficult to access.
>> - it would allow the client to live in WebCore. This avoids tweaking the 
>> WebView implementations for all platforms to pass messages back and forth
>> https://bugs.webkit.org/show_bug.cgi?id=41616
>> 
>> I assume one of the advantages of having them on Page is that it allows a 
>> Mock Controller to be easily created for testing from Dump Render Tree. Am I 
>> right? Is this that important?
>> 
>> FWIW, Geolocation seems to take both approaches. One implementation is down 
>> in Navigator/Document/DOMWindow, but the mock controller is on Page. I've 
>> found the low-level approach much easier to implement.
>> 
>> Thoughts?

For this sort of thing, it seems reasonable to me that there is a layer of the 
implementation that is a per-document controller, and then below that a 
singleton object in case we don't need things to happen multiple times per 
document. It doesn't seem especially helpful to have something happen at the 
Page level, in normal operation.

The reason it seems a singleton would be useful is that you only want to 
register with the OS service once, and then multicast the relevant 
notifications to all clients that are listening.

For purposes of substituting a mock controller:

(1) If there is a singleton beneath the per-document controllers, perhaps the 
mock object can insert itself at that level.
(2) Even if the mock controller is at the per-document level, it is likely 
still sufficient for most tests; it might mean a little extra work if we need 
to specifically test geolocation or device motion/orientation from a subframe.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why does isLocationChange() return false for redirection?


On Aug 16, 2010, at 10:58 PM, Eric Zhou wrote:

> Hi all, 
> 
> following is the related code. My question is why it returns false when 
> ScheduledRedirection.type is redirection.
> From the name of the function, I think if the url changes, it should return 
> true. Thus, for most of redirection, it should return true.

For these functions, I wouldn't assume that the name is necessarily logical. In 
any case it looks like you are looking at old-ish code - this code has been 
refactored on current trunk.

Regards,
Maciej

> 
> //FrameLoader.cpp
> bool FrameLoader::isLocationChange(const ScheduledRedirection& redirection)
> {
> switch (redirection.type) {
> case ScheduledRedirection::redirection:
> return false;
> case ScheduledRedirection::historyNavigation:
> case ScheduledRedirection::locationChange:
> case ScheduledRedirection::formSubmission:
> return true;
> }
> ASSERT_NOT_REACHED();
> return false;
> }
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page


On Aug 17, 2010, at 6:50 AM, Dean Jackson wrote:

> 
> On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
> 
>> 
>> On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
>> 
>>> Where-ever it goes, please don't put it on Document directly. :)
>>> (Feel free to tie it to Document's lifetime, just don't add to
>>> Document's 300+ methods.)
>>> 
>>> The madness must stop...  Document is long overdue for some weightloss...
>> 
>> I assume Dean is suggesting that Document would gain a new data member 
>> (DeviceMotionController?) which strikes me as a reasonable approach.
> 
> Right - either one or two (+DeviceOrientationController). I do think the 
> controllers of both events could be a single object - but that is another 
> discussion.
> 
> If it wasn't on Document, what do you suggest otherwise? DOMWindow? Putting 
> it on Frame but tying it to Document seems less than perfect.

My specific advice was in the rest of my reply - trimming quotes so you can see 
it:

>> For this sort of thing, it seems reasonable to me that there is a layer of 
>> the implementation that is a per-document controller, and then below that a 
>> singleton object in case we don't need things to happen multiple times per 
>> document. It doesn't seem especially helpful to have something happen at the 
>> Page level, in normal operation.
>> 
>> The reason it seems a singleton would be useful is that you only want to 
>> register with the OS service once, and then multicast the relevant 
>> notifications to all clients that are listening.
>> 
>> For purposes of substituting a mock controller:
>> 
>> (1) If there is a singleton beneath the per-document controllers, perhaps 
>> the mock object can insert itself at that level.
>> (2) Even if the mock controller is at the per-document level, it is likely 
>> still sufficient for most tests; it might mean a little extra work if we 
>> need to specifically test geolocation or device motion/orientation from a 
>> subframe.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cleaning up Document.* (was DeviceOrientation/Motion on Document rather than Page)