Re: [webkit-dev] Faster run-webkit-tests?

[Dan Bernstein]

On Jul 10, 2008, at 5:11 PM, Refstrup, Jacob Grundtvig wrote:

 Hi,

 Has anyone looked into making run-webkit-tests run faster by taking  
 advantage of multiple CPUs? E.g. my workstation is 8gb, with 2 x  
 dual core and I think it'd do just fine in running 4-8 tests  
 simultaneously.

 If there's no such work then I might start poking around.

I am not aware of any current work. See 
https://bugs.webkit.org/show_bug.cgi?id=10906 
 .
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore cleanup

[Dan Bernstein]

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

Re: [webkit-dev] 答复: About the layout test r esult.

[Dan Bernstein]

On Oct 6, 2008, at 7:55 PM, Bely wrote:




Hi Mark,

Thanks for your reply!



I am running the tests on windows, with cygwin installed. After  
build it in VC8 using “debug”


configuration, I execute the tests by invoking run-webkit-tests in  
cygwin console like:




./run-webkit-tests



First time it says WebKitGUID.lib is missing, I rename  
WebKitGUID_debug.lib to WebKitGUID.lib,


And later it says WTF_debug.lib is missing, again I rename  
WTF_debug.lib to WTF.lib, then I began to run the tests and


Got the result.



Is there anything wrong with my process?


Hi Bely,

Many layout tests’ results are  
dependent on the fonts that are available on the system. When you run  
the tests on Windows, the results for most tests are compared against  
the expected results in LayoutTests/platform/mac, so it is expected  
that the results will mismatch, because a typical installation of  
Windows is missing many fonts that are available on Mac OS X.


Thanks,
-- Dan





Thanks!



- Bely



-邮件原件-
发件人: Mark Rowe [mailto:[EMAIL PROTECTED]
发送时间: 2008年10月7日 10:07
收件人: Bely
抄送: webkit-dev@lists.webkit.org
主题: Re: [webkit-dev] About the layout test result.





On 2008-10-05, at 23:16, Bely wrote:



 Hi all,

  I am new to webkit. Recently I run the layout test and got

 the following result :

  [table]

 Test Feature

 Total

 passed/ incorrect/timedout/crashed/stderr

 Pass rate

 Layout Testing

 9085

 4853

 4198

 15

 5

 14

 53.4%

















  [text]

  Total:9085

  Passed: 4853

  Incorrect:  4198

  Timedout:  15

  Crashed:  5

  Stderr:   14



 Why the pass rate is so low?  Is this result reasonable? Or I

 wrongly executed the test?  Can someone help me?



Which platform did you run tests on?  Which port of WebKit did you

use?  The buildbot at http://build.webkit.org/waterfall shows that

WebKit on Mac is currently passing 100% of the regression tests.

Results for ports other than Mac and Windows are likely to be

significantly worse as the developers of other ports have not spent

much time focussing on passing the layout tests.



- Mark

___
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] 答复: 答复: About the layout test result.

[Dan Bernstein]

On Oct 6, 2008, at 10:56 PM, Bely wrote:


Thanks Dan!

But what fonts should I install on windows to run the tests and  
where can I get them?


The initialize() function in WebKitTools/DumpRenderTree/win/ 
DumpRenderTree.cpp lists all of them, alongside other fonts (Ahem and  
the WebKit* fonts) that are in the WebKit source tree. The Times  
family alone would probably suffice for the majority of the tests. I  
do not know how or even whether any or all of the required fonts are  
available for installation on Windows.


-- Dan



Thanks!


-- Bely
发件人: Dan Bernstein [mailto:[EMAIL PROTECTED]
发送时间: 2008年10月7日 11:36
收件人: Bely
抄送: 'Mark Rowe'; webkit-dev@lists.webkit.org
主题: Re: [webkit-dev] 答复: About the layout test result.


On Oct 6, 2008, at 7:55 PM, Bely wrote:




Hi Mark,

Thanks for your reply!



I am running the tests on windows, with cygwin installed. After  
build it in VC8 using “debug”


configuration, I execute the tests by invoking run-webkit-tests in  
cygwin console like:




./run-webkit-tests



First time it says WebKitGUID.lib is missing, I rename  
WebKitGUID_debug.lib to WebKitGUID.lib,


And later it says WTF_debug.lib is missing, again I rename  
WTF_debug.lib to WTF.lib, then I began to run the tests and


Got the result.



Is there anything wrong with my process?

Hi Bely,

Many layout tests’ results are  
dependent on the fonts that are available on the system. When you  
run the tests on Windows, the results for most tests are compared  
against the expected results in LayoutTests/platform/mac, so it is  
expected that the results will mismatch, because a typical  
installation of Windows is missing many fonts that are available on  
Mac OS X.


Thanks,
-- Dan





Thanks!



- Bely



-邮件原件-
发件人: Mark Rowe [mailto:[EMAIL PROTECTED]
发送时间: 2008年10月7日 10:07
收件人: Bely
抄送: webkit-dev@lists.webkit.org
主题: Re: [webkit-dev] About the layout test result.





On 2008-10-05, at 23:16, Bely wrote:



 Hi all,

  I am new to webkit. Recently I run the layout test and got

 the following result :

  [table]

 Test Feature

 Total

 passed/ incorrect/timedout/crashed/stderr

 Pass rate

 Layout Testing

 9085

 4853

 4198

 15

 5

 14

 53.4%

















  [text]

  Total:9085

  Passed: 4853

  Incorrect:  4198

  Timedout:  15

  Crashed:  5

  Stderr:   14



 Why the pass rate is so low?  Is this result reasonable? Or I

 wrongly executed the test?  Can someone help me?



Which platform did you run tests on?  Which port of WebKit did you

use?  The buildbot at http://build.webkit.org/waterfall shows that

WebKit on Mac is currently passing 100% of the regression tests.

Results for ports other than Mac and Windows are likely to be

significantly worse as the developers of other ports have not spent

much time focussing on passing the layout tests.



- Mark

___
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] Font cache cleaning

[Dan Bernstein]

On Oct 10, 2008, at 6:29 AM, Frederic Marmond wrote:


Hi people,
I just wonder how to clear the font cache, arbitrary.
For example, when leaving a site, clear all cached font data, to  
start loading the new page in a 'clean' environment.

I know it may slow down things :)  old memory vs speed debate...
I tried to call the FontCache::invalidate(); in my  
WebFrameLoaderClient::postProgressFinishedNotification(), but it  
doesn't do anything in my testcase.

I use valgrind to see what goes on.
my testcase is very simple:
first.html:
span style=font-family: arial;1234512345/span
a href=second.html2/a
second.html:
span style=font-family: verdana;a/span
If I load first.html and then the second.html by clicking the link,  
then exit, I would expect memory be less used than if I only load  
first.html and exit.
That's not the case, arial font datas are not cleared despite my  
invalidate() call.
I'm a bit lost in the Font Cache, is there any guru that may kindly  
point me where to look?
I tried to modify cTargetInactiveFontData and related parameters,  
without success, I can't manage to limit the font cache size... it  
grows and grows :(

Thanks in advance,
best regards
Fred


Hi Fred,

The way to clear the WebCore font cache is to invoke  
FontCache::purgeInactiveFontData(). This will remove all unreferenced  
font data from the cache. There is an amount of font data that is  
never released from the cache and therefore leaks, namely font data  
created in FontCache::getFontDataForCharacters. The call to  
invalidate() should release all other font data, but also re-create  
and re-cache font data for all active fonts. Perhaps by the time you  
call invalidate(), the render tree for the page has not been destroyed  
yet, so the fonts are referenced. I don’t know what valgrind measures,  
but in your simple test case you should be able to use the debugger to  
track all font data allocations and deallocations and specifically see  
whether and why purgeInactiveFontData() does not deallocate anything.


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

Re: [webkit-dev] calcPrefWidths, SimpleFontData, and text fields (oh my!)

[Dan Bernstein]

On Nov 19, 2008, at 1:17 PM, Mike Pinkerton wrote:


In tracking down something for Mac Chromium, I came across something
in WebCore that I can't explain, and hopefully someone on this list
can vend me a clue.

RenderTextControl::calcPrefWidths() checks the average character width
of the primary font if the width isn't explicitly set.


I don’t see such code in TOT WebKit. Are you by any chance looking at  
a version of the source that has a patch similar to the one from https://bugs.webkit.org/show_bug.cgi?id=15312 
 applied to it?

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

Re: [webkit-dev] Need help in understanding web kit

[Dan Bernstein]

On Dec 9, 2008, at 10:19 PM, ying lcs wrote:


Hi,

Can you please point me to the part of Webkit rendering code where it
does text wrapping?
for example , how does it determine when to break a paragraph into
multiple lines of text?

Thank you.


Line layout is implemented in WebCore/rendering/bidi.cpp. The method  
RenderBlock::findNextLineBreak() advances through the render tree,  
measuring text runs as necessary, and returns the line break position.

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

Re: [webkit-dev] FontCache refactoring proposal

[Dan Bernstein]

Hi Julien,

On Dec 11, 2008, at 2:14 AM, Julien Chaffraix wrote:


Hi everyone,

while working on memory leaks inside WebCore, the Pleyo team has found
that the FontCache was responsible for a few of them.


It would be good to have a bug filed about each leak.


In order to
solve those leaks and prevent future ones, we have done a refactoring
of the FontCache and its internal working (mainly making the
SimpleFontData Refcounted and change several sites inside WebCore to
hold RefPtr). The modification are done and they are too big for
integration right now so we would like to split them and contribute
them back to WebKit. You will find below the different parts that we
have worked on (this will follow more or less the order in which they
will be contributed back):

- initial clean-up
   * share some methods that are the same in all implementations
   * add a 'platform' suffix for those that should be implemented  
per platform
   * avoid using FontPlatformData ouside the few font files inside  
platform
   * make FontCache a singleton and remove all the current static  
methods


- Add leaks probe using RefCountedLeakCounter to track our progress as
well as see where the leaks occurs.

- Make the FontCache mechanism use smart pointers
   * have SimpleFontData derive from RefCounted
   * use internally RefPtr
   * use RefPtr for external reference to SimpleFontData all over  
WebCore


- FontCache HashMap refactoring: currently some HashMaps return
FontPlatformData internally and there is a mapping between those and
SimpleFontData so it should be better to use the SimpleFontData
instead.


How do you plan to maintain the constructor
Font::Font(const FontPlatformData fontData, bool isPrinterFont)
without a mapping from FontPlatformData to FontData?

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

Re: [webkit-dev] Getting more buildbots green

[Dan Bernstein]

On Jan 3, 2009, at 11:41 AM, Darin Adler wrote:

editing/selection/move-left-right.html — The failure here is  
curious. The actual test output seems to be unchanged, but all the  
WARNING lines mentioning moving in the wrong direction seem to be  
missing. Mitz, can you help?


I never understood what had caused those warnings, and I don’t  
understand what made them go away. I think it’s okay to just update  
the results.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Build error when source tree on alternate volume

[Dan Bernstein]

Unfortunately, WebKit cannot be built when there are spaces in the  
path to the source tree. See https://bugs.webkit.org/show_bug.cgi?id=10758 
.


On Jan 7, 2009, at 1:14 PM, Ross Lillie wrote:

I'm getting build errors when building WebKit on OS X (10.5.6, Xcode  
3.1.1) when the source tree is located on an alternate volume.  In  
my configuration, the source tree is located on a secondary volume (/ 
Volumes/Project HD/webkit).  Examining the terminal log you see the  
following errors:


setenv XCODE_VERSION_ACTUAL 0310
setenv XCODE_VERSION_MAJOR 0300
setenv YACC /Developer/usr/bin/yacc
/bin/sh -c \/Volumes/Project HD/webkit/WebKitBuild/ 
WebCore.build/Debug/Derived Sources.build/Script- 
DD041FBD09D9DDBE0010AF2A.sh\
i686-apple-darwin9-gcc-4.0.1: HD/webkit/WebKitBuild/Debug: No such  
file or directory
WebCore/ForwardingHeaders/wtf/Platform.h:1:37: error: JavaScriptCore/ 
Platform.h: No such file or directory
i686-apple-darwin9-gcc-4.0.1: HD/webkit/WebKitBuild/Debug: No such  
file or directory
WebCore/ForwardingHeaders/wtf/Platform.h:1:37: error: JavaScriptCore/ 
Platform.h: No such file or directory
i686-apple-darwin9-gcc-4.0.1: HD/webkit/WebKitBuild/Debug: No such  
file or directory
WebCore/ForwardingHeaders/wtf/Platform.h:1:37: error: JavaScriptCore/ 
Platform.h: No such file or directory


The build later halts with the following message:

_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT  
ENABLE_SVG_USE ENABLE_VIDEO ENABLE_WORKERS ENABLE_XPATH ENABLE_XSLT  
LANGUAGE_JAVASCRIPT --generator JS WebCore/xml/XSLTProcessor.idl
make: *** No rule to make target `JSDOMWindowBase.lut.h', needed by  
`all'.  Stop.

make: *** Waiting for unfinished jobs
** BUILD FAILED **

The following build commands failed:
Derived Sources:
PhaseScriptExecution /Volumes/Project HD/webkit/WebKitBuild/ 
WebCore.build/Debug/Derived Sources.build/Script- 
DD041FBD09D9DDBE0010AF2A.sh

(1 failure)

If the source tree is rooted in my Mac home directory (e.g. /Users/ 
xx/projects/webkit), everything builds fine.


This error results in numerous generated files not being created  
(e.g. HTMLNames.h, etc.)  As I’m fairly new to Xcode as well as the  
webkit build process I’m floundering to trace down the exact error.   
Any suggestions would be helpful.


thanks
/ross
___
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] currently failing regression tests on Mac OS X Leopard

[Dan Bernstein]

On Mar 6, 2009, at 7:47 AM, Darin Adler da...@apple.com wrote:

After fixing the test I could easily deal with myself, the following  
tests are failing for me:


   fast/block/float/t0905-c414-flt-fit-01-d-g.html
   fast/block/float/t0905-c5525-fltblck-00-d-ag.html
   fast/block/float/t0905-c5526-flthw-00-c-g.html

It looks like the check-in to deal with the YinYang character  
included some incorrect test results, or at least results that don't  
work on my computer. We need to correct the test results.


   fast/repaint/transform-absolute-in-positioned-container.html


This was caused by Hyatt's continuations patch. I filed a bug in  
Bugzilla and copied him.





Simon, you added this test originally so maybe you can figure out  
why it's giving me a result with an element 20 pixels wide instead  
of 40 now.


   -- 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] Need help in understanding Webkit text wrapping

[Dan Bernstein]

On Mar 9, 2009, at 6:48 PM, Meryl Silverburgh silverburgh.me...@gmail.com 
 wrote:



Hi,

Can you please tell me where is the Webkit code which does text  
wrapping?

For example, I have a paragraph of text. How does Webkit decide where
to break into multiple lines?


RenderBlock::findNextLineBreak() in bidi.cpp.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] what's important in layouttests?

[Dan Bernstein]

On Jun 25, 2009, at 7:54 PM, David Jones wrote:


I am confused about webkit's layouttests.
1.What's the layouttess used for?


The layout tests are used to detect unintended changes in engine  
behavior, which are typically regressions.


Are they provided only for developers who want to create a browser  
with webkit to test if their browser behaves right?


No. They do not test browsers, they only test the WebKit engine. They  
are used by everyone who makes code changes to WebKit to ensure that  
the changes do not introduce regressions. Adding new tests when fixing  
bugs makes it almost impossible for the bug to come back undetected.



2.The layouttests use Safari to run all the tests, right?


No. The DumpRenderTree tool, which is part of the WebKit source tree,  
is used to run all of them. A script called run-webkit-tests drives  
DumpRenderTree.



3.I noticed some tests need an app server, how do they start one?


Some tests use a local HTTP server. run-webkit-tests sets it up, but  
you can also use run-webkit-httpd to start the server independently.



4.Is layouttest only for Leopard?


No. They are cross-platform. In some cases, the results differ  
depending on the platform. The LayoutTests directory includes expected  
test results for all tests. If a test has platform-specific results,  
they can appear in subdirectories of LayoutTests/platform. Cross- 
platform results live alongside the test.



If I want to take it into my project, what should I do?


I do not understand this question.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Dan Bernstein]

On Jul 1, 2009, at 10:44 PM, Eric Seidel wrote:


   prepare-ChangeLog should have a --bug= argument and use it for
url autofill
   https://bugs.webkit.org/show_bug.cgi?id=26383


I would much prefer if the bug URL came first. I believe that this is  
the prevailing style.


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

Re: [webkit-dev] About Word wrap in DumpRendertree

[Dan Bernstein]

On Jul 7, 2009, at 12:05 AM, bircov wrote:



I have this question about the output of Dumprendertree:-

If a simple html with a div with fixed width (300px or something) is  
given

as input to dumprendertree, the word wrap shown by the output of
dumprendertree differs from the word wrap observed when html is  
viewed in

the browser.  I have attached an image illustrating the issue below.
http://www.nabble.com/file/p24368173/dumprendertree.jpg

Could someone please educate me why this might be happening.

Thanks,
Bir.


This can be the result of DumpRenderTree and the browser using  
different fonts, which have different horizontal metrics.

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

Re: [webkit-dev] Patch process - let's make it better

[Dan Bernstein]

On Jul 10, 2009, at 4:17 PM, Chris Marrin wrote:

The annoying part is the fact that I ALWAYS get conflicts in at  
least one Changelog file when I try to check in. I have to fix these  
by hand, do svn resolved, and try to check in again.


No you don’t. You can just use WebKitTools/Scripts/resolve-ChangeLogs;  
if you use WebKitTools/Scripts/update-webkit instead of just “svn up”,  
it will do it for you.

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

[webkit-dev] WinCE Font work

[Dan Bernstein]

Hi,

Today while looking at the patch at https://bugs.webkit.org/show_bug.cgi?id=28021 
 I noticed that the WinCE version of FontCustomPlatformData includes  
CachedFont.h and uses CachedFont.


It is incorrect for classes in the platform layer to have any  
knowledge of higher WebCore layers (essentially, anything outside the  
platform hierarchy). In this case, it also necessitated a platform  
difference in the createFontCustomPlatformData call site in  
CachedFont::ensureCustomFontData(), which is how I noticed it.


I think once you should correct this and any other layering violations  
in the WinCE platform layer, and only then submit patches with changes  
to cross-platform code, if any such changes are still deemed  
necessary. I don’t think https://bugs.webkit.org/show_bug.cgi? 
id=27734 and https://bugs.webkit.org/show_bug.cgi?id=28021 should  
be reviewed until then.


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

Re: [webkit-dev] LayoutTest results choose from which folder?

[Dan Bernstein]

On Aug 25, 2009, at 4:38 PM, Dirk Pranke wrote:


On Sun, Aug 23, 2009 at 12:23 PM, Dan Bernsteinm...@apple.com wrote:


On Aug 23, 2009, at 11:28 AM, Dirk Pranke wrote:


Hi Chris,
In layout test results, we make the latest Mac OS X version the  
rule, and
earlier versions the exception. Tiger will look for results in  
mac-tiger
first, then in mac-leopard, then in mac-snowleopard, then in mac,  
then

finally in cross-platform results. Leopard will begin the search in
mac-leopard, continue to mac-snowleopard, then mac, the cross- 
platform.
As you can see, there are no expected results in mac-snowleopard  
(other

than
the ones you just added), because it’s the latest Mac OS X  
version. We

will
only start putting expected results in mac-snowleopard when the  
“latest”
version (for which we put results in mac) will be something  
different.
You should put the expected results for Snow Leopard in platform/ 
mac (or,

if
they are cross-platform, alongside the test), and you should put  
the

results
for Leopard and earlier in platform/mac-leopard.
—Dan


Does this imply that if you've moved results from 'platform/mac' to
'platform/mac-leopard' when you switched from 10.5 to 10.6? (Since,
presumable, some results that were in platform/mac were actually
specific to 10.5?)


Yes, when the expected results of an existing test change under a new
version of Mac OS X, legacy expected results are moved from  
platform/mac to

platform/mac-last version with legacy behavior and current expected
results are put in platform/mac. http://trac.webkit.org/changeset/47052 
 is

an example.



Hi Dan,

Thanks for the explanation, that definitely helps. Out of curiosity,
when do you make the
platform switch? For example, when did mac stop equalling leopard and
start equaling snowleopard?


The platform/mac-snowleopard directory was created in r41710 on  
2009-03-14, and the required changes to the expected result search  
order were made in r41956 on 2009-03-24.



It looks like we will adopt the same convention as you, for
consistency's sake, and so I'd like to mirror it as closely as
possible.

-- Dirk


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

Re: [webkit-dev] Whitespace changes

[Dan Bernstein]

On Aug 26, 2009, at 10:35 PM, Oliver Hunt wrote:

Adam just landed a fairly substantial patch that did nothing but  
remove whitespace from the ends of lines.  While we had a thread  
about style changes earlier, it was in the context of changes that  
actually bring code into line with style guidelines in a way that  
actually effects the visible layout of code.


I do not believe that patches such as r47808 should be considered  
valuable as the changes have no visible effect on code layout, but  
do impact our ability to effectively use tools like svn or git  
blame, however the situation is slightly ambiguous on this matter so  
i thought i should bring it up on the mailing list.


Does anyone else have thoughts on this?


While I do see value in cleaning up code, I think the cost of  
whitespace-only changes is higher than their benefit.

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

Re: [webkit-dev] map tag and zoom donot work ..?

[Dan Bernstein]

On Sep 18, 2009, at 8:09 AM, Simon Fraser wrote:


On Sep 17, 2009, at 11:08 PM, Purushottam Sholapur wrote:


Hi All,

Web pages with  map  tag do not behave as expected when page is  
zoomed.
Typically, map tag with coords property do not scale properly when  
page is zoomed.


E.g: http://24x7guru.com/joe/resolution.html , there is continue  
button. If page is zoomed then that button do not work.


This bug also occurs on Mac OS X, so it's likely to be cross-platform.

You should first search http://bugs.webkit.org to see whether  
someone has reported it already. If not, please file it with a  
simple testcase.


I can reproduce the bug in Safari 4.0.3, but not in TOT WebKit. It  
sounds like the bug that was fixed in http://trac.webkit.org/changeset/46825 
.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Purging as much memory as possible

[Dan Bernstein]

On Oct 1, 2009, at 6:24 PM, Peter Kasting wrote:

* Does anyone already know the likely footprint of the Glyph cache,  
or how to clear it?


FontCache::purgeInactiveFontData().

If you’re using Safari then you can see Font and Glyph Caches  
statistics in its Caches window, which also includes a Purge Inactive  
Font Data button that calls through to purgeInactiveFontData().

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

Re: [webkit-dev] How does Zooming Work?

[Dan Bernstein]

On Oct 6, 2009, at 8:49 PM, Alex Milowski wrote:


What exactly happens during a zoom (command +/-) ?


Depends on the flavor of zoom (“full-page” zoom vs. text-only zoom),  
but in both cases, a full style recalculation for the document is  
forced.



I have code that works well but layout doesn't seem to happen after
a zoom in/out operation.  If I then resize the window, that forces a
layout for the zoomed size and things adjust themselves
appropriately (because layout() eventually gets called).

So, what sequence of events happens after a zoom?


Frame::setZoomFactor() calls Document::recalcStyle(Force). If after  
that the document has a renderer (which would be a RenderView) and  
that renderer is marked for layout, then FrameView::layout() is  
called, which will call RenderView::layout() and recursively lay out  
every render tree object marked as needing layout.


One explanation for what you’re seeing would be that as your objects’  
style changes, they fail to call setNeedsLayout() (or  
setNeedsLayoutAndPerfWidthsRecalc()), and therefore layout doesn’t  
occur at that time. An alternative, less likely, explanation is that  
your objects have anonymous children, but they don’t propagate the  
style changes correctly to those children.


Also, if I need layout() to be called for things to be handled  
properly, is

something out of place?


No, layout() is the correct way to update the layout after a style  
change. To ensure that it happens, objects should mark themselves for  
layout in response to the style change when necessary.  
RenderObject::styleDidChange() is an example, and most render objects  
that override styleDidChange() invoke their base class’s  
implementation, so they get marked for layout as needed.


This all relates to the stretchy operator code in the MathML  
rendering.  The
operator's box stretches correctly after layout but after a zoom, it  
doesn't

stretch until layout happens again.


I hope the above helps you debug the problem. You may want to  
experiment with more localized style changes (such that should affect  
only your object of interest) and see whether they work and if not,  
why not.

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

Re: [webkit-dev] adding script type to webcore

[Dan Bernstein]

On Oct 17, 2009, at 1:47 PM, Alexander Cohen wrote:


Hello,

Forgive me if this is a very vague question, but where should i  
start in webkit to view how it implements the script tag and how it  
starts evaluating JS. I'm looking into adding a new script type and  
having it evaluated and run.


You can start by looking at the implementation of the ScriptElement  
class, which handles script evaluation for HTML script and SVG  
script.

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

Re: [webkit-dev] Why are some layout tests renamed with a suffix of -disabled?

[Dan Bernstein]

On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote:

 Why are some layout tests renamed with a suffix of -disabled?  Why aren't 
 such tests simply added to the skipped list?  Is -disabled simply the old way?

Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug 
makes it impossible to run the test (e.g. it crashes DumpRenderTree) or makes 
the test produce different results on each run (this can also be a bug in the 
test). The skipped lists are platform-specific, so they are not a good way to 
deal with such situations.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Platform API for Uniscribe/ComplexTextController?

[Dan Bernstein]

On Nov 29, 2009, at 10:27 AM, Kevin Ollivier wrote:

 Hi all,
 
 The wx port is starting to look at getting proper support for complex text, 
 and one of the first places I started looking at was the Win and Mac port 
 implementations. I noticed that the complex text code in FontWin.cpp and 
 FontComplexTextMac.cpp is largely the same, passing the heavy lifting down to 
 their respective complex text controllers, and I actually wondered if they 
 could be merged if there were some tweaks to the APIs to make them compatible.
 
 That led me to wonder if we couldn't make ComplexTextController one of our 
 platform classes and have USE() defines to determine the implementation. Then 
 we could move the drawComplexText, floatWidthForComplexText, and 
 offsetForPositionForComplexText into Font.cpp guarded by that USE() define. 
 The wx port can provide the native font handles the Win/Mac controllers need, 
 so it'd really be great if we could just add these into our build to get 
 complex text support working without having to implement the complex text 
 methods differently for each platform. 
 
 BTW, I actually already did get UniscribeController compiling, actually, but 
 on Windows I had to have the build script copy it to platform/graphics/wx 
 because MSVC implicitly puts the current directory first on the path, which 
 was causing it to pick up platform/graphics/win/FontPlatformData.h instead of 
 the wx one when compiling that file. :( So that's something else that would 
 need to be addressed if ports can start sharing these files.
 
 Thanks,
 
 Kevin

Hi Kevin,

This sounds like a generally good idea. ComplextTextController is already using 
USE() macros to select between Core Text and ATSUI. I am not entirely sure how 
the the *ComplexText() methods will be guarded in Font.cpp in your proposal. 
Are you suggesting something like
#if USE(ATSUI) || USE(CORE_TEXT) || USE(UNISCRIBE) || …
?

There are still some differences in behavior between ComplexTextController and 
UniscribeController, so you’d need to find a way to accommodate them or 
eliminate them.

I look forward to seeing a patch!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

[Dan Bernstein]

On Dec 2, 2009, at 9:46 PM, Peter Kasting wrote:

 On Wed, Dec 2, 2009 at 9:19 PM, Mark Rowe mr...@apple.com wrote:
 On 2009-12-02, at 21:00, Peter Kasting wrote:
 
  I find this tricky to read and error-prone.  I propose that the rule be 
  modified to be:
 
  * When all arms of a conditional or loop are one physical line, do not use 
  braces.  If any arms are more than one physical line (even if they are one 
  logical line), use braces on all arms.
 
 I do not agree that this would be an improvement.
 
 Are you satisfied with the existing rule, then?  If so, you would be the 
 first developer I have asked who is.

I am satisfied with the existing rule.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Platform API for Uniscribe/ComplexTextController?

[Dan Bernstein]

On Dec 2, 2009, at 10:52 AM, Kevin Ollivier wrote:

 Hi Dan,
 
 On Dec 1, 2009, at 8:29 AM, Dan Bernstein wrote:
 
 
 On Nov 29, 2009, at 10:27 AM, Kevin Ollivier wrote:
 
 Hi all,
 
 The wx port is starting to look at getting proper support for complex text, 
 and one of the first places I started looking at was the Win and Mac port 
 implementations. I noticed that the complex text code in FontWin.cpp and 
 FontComplexTextMac.cpp is largely the same, passing the heavy lifting down 
 to their respective complex text controllers, and I actually wondered if 
 they could be merged if there were some tweaks to the APIs to make them 
 compatible.
 
 That led me to wonder if we couldn't make ComplexTextController one of our 
 platform classes and have USE() defines to determine the implementation. 
 Then we could move the drawComplexText, floatWidthForComplexText, and 
 offsetForPositionForComplexText into Font.cpp guarded by that USE() define. 
 The wx port can provide the native font handles the Win/Mac controllers 
 need, so it'd really be great if we could just add these into our build to 
 get complex text support working without having to implement the complex 
 text methods differently for each platform. 
 
 BTW, I actually already did get UniscribeController compiling, actually, 
 but on Windows I had to have the build script copy it to 
 platform/graphics/wx because MSVC implicitly puts the current directory 
 first on the path, which was causing it to pick up 
 platform/graphics/win/FontPlatformData.h instead of the wx one when 
 compiling that file. :( So that's something else that would need to be 
 addressed if ports can start sharing these files.
 
 Thanks,
 
 Kevin
 
 Hi Kevin,
 
 This sounds like a generally good idea. ComplextTextController is already 
 using USE() macros to select between Core Text and ATSUI. I am not entirely 
 sure how the the *ComplexText() methods will be guarded in Font.cpp in your 
 proposal. Are you suggesting something like
 #if USE(ATSUI) || USE(CORE_TEXT) || USE(UNISCRIBE) || …
 ?
 
 I was thinking we'd create some WTF_USE_COMPLEX_TEXT_CONTROLLER so that it 
 would be easier to opt out of using it, since a port may define / use 
 WTF_USE_ATSUI or WTF_USE_CORE_TEXT for purposes other than supporting complex 
 text. 

The USE() macros are intended for specifying platform technologies, not parts 
of the engine. I think it would be more appropriate to use ENABLE(COMPLEX_TEXT) 
to control the feature.

 
 There are still some differences in behavior between ComplexTextController 
 and UniscribeController, so you’d need to find a way to accommodate them or 
 eliminate them.
 
 In terms of public API, I think merging the changes shouldn't be too 
 difficult. IIUC finalRoundingWidth() can probably just remain 0 on Win, and 
 the ignore writing direction optimization on Mac can be put in the common 
 API but just be ignored under Windows.
 
 The only thing I'm not sure about is that Mac and Win get the run's width in 
 different ways, but I'm not quite sure why they do it differently00. Either 
 approach would seem to work for both platforms. Mac calculates the total 
 width when the ComplexTextController is created, while on Win to calculate it 
 you have to call advance(run.length()) then get the value using 
 runWidthSoFar().

Since the glyph used for the ith character—and the width of the glyph used for 
the ith character—may depend on the i+1th character, you have to generate 
glyphs and advances for the entire run before you can determine any widths, so 
ComplexTextController does it in its constructor. What UniscribeController 
leads to incorrect selection rects in some cases.

 The quick fix would seem to be to just have both platforms call 
 advance(run.length()) and then use runWidthSoFar(), but I suspect that would 
 hurt performance on Mac. Another way that might fix it would be to call 
 advance(run.length()) in UniscribeController::UniscribeController then set 
 m_totalWidth = m_runWidthSoFar and reset m_currentCharacter and 
 m_runWidthSoFar to 0. Lastly, we could take the guts of advance and put it 
 into something like a Win version of adjustGlyphsAndAdvances() that sets 
 total width. Do you have any suggestions / preferences for how to tackle this?

I would like UniscribeController to become more like ComplexTextController, not 
the other way around, but I wouldn’t like to make either one slower than. If 
the UniscribeController constructor advanced to the end, but then reset its 
current state, it would end up doing some amount of work twice in some cases, 
because the adjusted glyphs and advances it had produced in the first pass 
would be lost. Generally speaking, the way to fix this is to add “adjusted 
advances” and “adjusted glyphs” vectors to UniscribeController, like the ones 
ComplexTextController has. You’d probably also need a vector of runs 
(corresponding to Uniscribe “items”), but the differences between Uniscribe and 
the Mac complex text

Re: [webkit-dev] [webkit-changes] [52439] trunk/WebCore

[Dan Bernstein]

On Dec 21, 2009, at 3:00 AM, pfeld...@chromium.org wrote:

 Revision
 52439
 Author
 pfeld...@chromium.org
 Date
 2009-12-21 03:00:06 -0800 (Mon, 21 Dec 2009)
 Log Message
 
 2009-12-20  Pavel Feldman  pfeld...@chromium.org
 
 Reviewed by Eric Seidel.
 
 Web Inspector: extract syntax highlighters into separate files.
 
 https://bugs.webkit.org/show_bug.cgi?id=32803
 
 * WebCore.gypi:
 * WebCore.vcproj/WebCore.vcproj:
 * inspector/front-end/CSSSourceSyntaxHighlighter.js: Added.
 (WebInspector.CSSSourceSyntaxHighlighter):
 * inspector/front-end/JavaScriptSourceSyntaxHighlighter.js: Added.
 (WebInspector.JavaScriptSourceSyntaxHighlighter):
 (WebInspector.JavaScriptSourceSyntaxHighlighter.):
 * inspector/front-end/SourceFrame.js:
 * inspector/front-end/SourceSyntaxHighlighter.js: Added.
 (WebInspector.SourceSyntaxHighlighter):
 (WebInspector.SourceSyntaxHighlighter.prototype.createSpan):
 (WebInspector.SourceSyntaxHighlighter.prototype.process.processChunk):
 
 (WebInspector.SourceSyntaxHighlighter.prototype.process.moveToNextLine):
 (WebInspector.SourceSyntaxHighlighter.prototype.process):
 (WebInspector.SourceSyntaxHighlighter.prototype.lex):
 (WebInspector.SourceSyntaxHighlighter.prototype.appendNonToken):
 (WebInspector.SourceSyntaxHighlighter.prototype.syntaxHighlightNode):
 * inspector/front-end/WebKit.qrc:
 * inspector/front-end/inspector.html:
 Modified Paths
 
 trunk/WebCore/ChangeLog
 trunk/WebCore/WebCore.gypi
 trunk/WebCore/WebCore.vcproj/WebCore.vcproj
 trunk/WebCore/inspector/front-end/SourceFrame.js
 trunk/WebCore/inspector/front-end/WebKit.qrc
 trunk/WebCore/inspector/front-end/inspector.html
 Added Paths
 
 trunk/WebCore/inspector/front-end/CSSSourceSyntaxHighlighter.js
 trunk/WebCore/inspector/front-end/JavaScriptSourceSyntaxHighlighter.js
 trunk/WebCore/inspector/front-end/SourceSyntaxHighlighter.js
The preferred way to make this sort of change is to use 'svn copy' in order to 
preserve the history of the code being moved.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Commit queue blocked because of failing tests

[Dan Bernstein]

On Feb 24, 2010, at 3:50 PM, Eric Seidel wrote:

 I find http://build.webkit.org/console more useful.
 
 In this case, looks like mitz's patch changed the test:
 http://trac.webkit.org/changeset/55203

Sorry about the inconvenience. I will try to fix this shortly.

 
 I'm glad to see more folks are watching the bots!
 
 -eric
 
 On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote:
 1. It looks like you are a committer, so you don't need to wait for the
 commit queue to do this for you :)
 2. But it still would be good to have this fixed. If you'd like to help move
 this along, you can go to http://build.webkit.org/waterfall and find which
 patch caused the test to start failing. Then ping the relevant person.
 
 On Wed, Feb 24, 2010 at 3:41 PM, Kenneth Russell k...@google.com wrote:
 
 On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov a...@webkit.org
 wrote:
 
 On 24.02.2010, at 11:47, David Levin wrote:
 
 Actually, it doesn't appear to be do to recent changes in this
 area. They
 started failing after r55177
 (http://build.webkit.org/waterfall?last_time=1266975298), but that
 change is
 unrelated to these test as far as I can tell.
 
 It looks unrelated, but it somehow broke these editing tests
 nonetheless.
 I'm investigating now.
 
 Thanks. Our patch (from https://bugs.webkit.org/show_bug.cgi?id=34459)
 was about to be landed by the bot when the tree went red again. The
 test now failing is:
 
 fast/dom/prototype-inheritance-2.html - failed
 
 Could someone please look?
 
 Thanks,
 
 -Ken
 
 
 ___
 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] Antialiasing GraphicsContext::drawLine

[Dan Bernstein]

On Mar 13, 2010, at 9:06 AM, Sausset François wrote:

 I recently began to work on the square root implementation in MatML and I'm 
 near to submit a patch.
 But as I'm new to WebKit development, I have a beginner question:
 
 To draw the square root, the GraphicsContext::drawLine method is called but 
 it is written (in comments) to use it only for borders.
 Moreover this method enforces to turn antialiasing off.
 I have two possibilities:
 - modify that method to allow (optional) antialising
 - use other methods. It should be better but I don't know which one is 
 adapted.
 Ideally, a polyline method should be great. Is there such a method? Probably 
 yes, as SVG  Canvas need advanced drawing.
 Any help is welcome!

You can construct a Path object, use the path methods to add a line (or lines) 
and then use GraphicsContext::beginPath(), GraphicsContext::addPath() and 
GraphicsContext::strokePath().___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Determining platform in LayoutTests

[Dan Bernstein]

On Mar 28, 2010, at 7:08 PM, Sam Weinig wrote:

 I am not sure which tests you are referring to that use the user-agent to 
 change behavior, but that is not the way it is supposed to be done. Instead, 
 tests that test a platform specific behavior should go in the 
 LayoutTest/YOURPLATFORM directory. If it is just a platform specific result, 
 the results should go in LayoutTest/YOURPLATFORM.

This works for some tests, but is not ideal for tests that encode expected 
behavior (in particular, “script tests”) and output some sort of PASS/FAIL 
result. In such cases, unless the test has a way to adapt to platform 
conventions, FAIL could end up being the platform-specific result for some 
platforms, which isn’t so great.

 
 -Sam
 
 On Sun, Mar 28, 2010 at 1:11 PM, Martin Robinson mrobin...@webkit.org wrote:
 Apologies in advance if this has been hashed out before, but a
 cursory search of the list history didn't turn anything up.
 
 It seems that in LayoutTests platform specific behavior is generally handled 
 by
 examining the user agent. I'm currently in the process of fixing
 editing/selection/extend-selection-after-double-click.html for GTK+. This
 test will have different results for GTK+ and Qt (it's currently
 skipped on both)
 because the selection behavior is different between the toolkits. This
 will become even
 more of an issue as we try to bring selection behavior in line with
 standard GTK+
 behavior (see bug https://bugs.webkit.org/show_bug.cgi?id=36627 ).
 
 I'm not sure that you can tell Qt and GTK+ apart via  the user agent,
 so does it make
 sense for LayoutTestController to expose this information somehow or
 just fix the user
 agent? Is there an alternative?
 
 Martin
 ___
 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] About fixing old layout bugs

[Dan Bernstein]

Hi Xianzhu,

On Jun 1, 2010, at 9:37 PM, Xianzhu Wang wrote:

 Hi,
 
 I'm new to webkit development, and I'd like to hear opinions about the 
 problems I met.
 
 Now I'm trying to fix some old layout bugs, for example:
   * white space preceding br (https://bugs.webkit.org/show_bug.cgi?id=37261)
   * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
   * line breaking around some punctuations 
 (https://bugs.webkit.org/show_bug.cgi?id=37698)
 
 Some people have warned me about the difficulty of fixing these bugs, and now 
 I have realized it. Fixing the bugs themselves is not very difficult, for 
 example, only 2 functional lines change can fix the first bug. However, the 
 change will break more than 4000 existing layout tests mostly because 
 trailing spaces preceding brs in current expectations of the tests (for 
 example, PASS  vs PASS). I tried to rebaseline all effected layout tests 
 (for now on mac only), and the patch is about 6MB (Sorry I overlooked the 
 Bigfile option when I submitted the patch, so I split it into 4 parts).
 
 My questions are:
 
 1. The bugs violate the standards and cause some site compatibility issues. 
 However, because the bugs are old, some web developers might treat them as 
 features and depend on them, so fixing them might break some existing pages. 
 Is there any existing policy about this problem?

Not sure. I think WebKit should not make a policy decision to diverge from the 
standard (quirks mode withstanding) unless WebKit developers are actively 
advocating a change to the relevant standard.

 Are these bugs worth fixing?

  * white space preceding br (https://bugs.webkit.org/show_bug.cgi?id=37261)

Unless I’m missing something, there is no known downside to fixing this bug. 
Seems worthwhile.

  * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)

Is this really a standards compliance issue or just compatibility with Firefox? 
If there is a standards issue, is there a subset of the change that’s 
sufficient for standards compliance? Unless WebKit is in violation of a 
standard here, I personally don’t consider this important, but I know that 
other contributors have agreed to this change in principle, and it’s just that 
the patch has been abandoned by the original author.

  * line breaking around some punctuations 
(https://bugs.webkit.org/show_bug.cgi?id=37698)

Seems worthwhile if it aligns WebKit with Firefox and IE. If moves away from IE 
compatibility, I wouldn’t do it. The main issue here is efficiency.

Personally, I think it’s good that you’re looking into such long-standing 
standards/compatibility issues!

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

Re: [webkit-dev] How to convert character offset into VisiblePosition?

[Dan Bernstein]

On Jun 1, 2010, at 10:48 PM, Xiaomei Ji wrote:

 
 Given a DOM Node and an InlineBox, is there a way to convert the character 
 offset within this InlineBox to a VisiblePosition? considering bidi/RTL.

Not sure how being given a DOM node helps here…

 
 Using span node in the following example as an example:
 div contenteditable dir=rtlabc ששש def span dir=ltrשנב abc סטז/span uvw 
 זזז xyz/div 
 Assume the span node is node A, using (node, offset)a to represent the 
 node and offset information of Position when caret is before character a, 
 the position information are:
 .. (A, 4)a(A, 5)b(A, 6)c(A, 7) (A, 0xb)ז(A, 0xa)ט(A, 9)ס(A, 8).
   
 Given the span node, the InlineBox representing  abc (with surrounding 
 spaces), and character offset 5 within the InlineBox, is there a way to 
 convert offset 5 into VisiblePosition (A, 0xb) (not (A, 8))? which means when 
 caret is placed after the 2nd space in  abc , the visible position is (A, 
 0xb).

I don’t think there’s code to do this—hit testing code will just choose the DOM 
offset that corresponds to the line box you hit—but how about something like 
this?

If the offset is not at the edge of the text box, then just map it to that 
box’s text node
Otherwise, if there is an adjacent text box on that edge, and it has the same 
direction as the first text box, just map to the first text box’s text node 
(or, perhaps you should look at the bidi levels of both boxes and choose the 
one with the higher level?)
Otherwise, of the two adjacent text boxes, choose the one whose direction is 
equal to the block direction, and return an offset into the chosen box’s text 
node, corresponding to the edge

Does this cover all cases?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] STIX Fonts and MathML Tests

[Dan Bernstein]

On Jul 7, 2010, at 3:48 AM, Alex Milowski wrote:

 Is there any precedence for this or default policy for tests requiring
 fonts?

Yes. Some tests require the Ahem font, so the font is checked into the 
repository and—at least on Mac OS X and Windows—DumpRenderTree activates the 
font while running the tests.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] STIX Fonts and MathML Tests

[Dan Bernstein]

On Jul 7, 2010, at 9:57 AM, Alex Milowski wrote:

 The STIX fonts are relatively small (2.6MB for the full download) and
 we probably don't need all of them.  Would it be acceptable to check these in 
 like the Ahem font?

Subject to WebKit’s licensing requirements, yes.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] STIX Fonts and MathML Tests

[Dan Bernstein]

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

 If every is OK with licenses, how DumpRenderTree needs to be modified to use 
 custom fonts?

This is where the Mac version activates test fonts:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L218

and this is where the Windows version does it:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L275

You will also need to modify the build system to copy the additional fonts to 
the right places.

 And where the fonts have to be stored?

Most are here:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/fonts

Ahem is currently in
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/fonts
but had better be moved to the cross-platform location.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Crash in RenderLayer related to setStyle() - Questions

[Dan Bernstein]

On Jul 23, 2010, at 3:48 PM, Alex Milowski wrote:

 I've identified a crash with the MathML implementation related to use of
 CSS style rules that cause a RenderLayer instance to be created.  In the
 MathML code's various createRenderer() methods, they always call
 RenderObject::setStyle() on the object they've just created.
 
 When the setStyle() method is called, a style difference is calculated
 and propagated.  If you call setStyle() inside your createRenderer()
 method, you're calling it on an unattached RenderObject instance.
 
 Further, if there happens to be a rule like:
 
 math {
   overflow: auto;
 }
 
 you'll get a layer created by RenderBoxModelObject.  That layer
 will get the style change.
 
 Right now, as the code stands, you'll get an exception and crash
 due to the fact that the RenderLayer code makes some assumptions
 about the RenderObject instance being attached to the tree.
 
 The fix is trivial but my question is basically: what's the right thing
 to do here?  Should the setStyle() be called in createRenderer() ?  It
 seems like the answer is no because the style gets associated
 somewhere else.  If I remove the call, the crash is also fixed (without
 any change to RenderLayer) and the tests still all pass for MathML.
 
 Further, should RenderLayer be made more safe?  Should it check
 for zero pointer values in a couple places and avoid this?
 
 If we shouldn't be calling setStyle() in createRenderer(), then fixing
 RenderLayer would just hide that fact.  While an ASSERT wouldn't
 hide things, it would still only arise when a layer is created.
 
 I know how to fix the MathML code and I just want to make
 sure I understand why calling setStyle() is bad.
 
 I'm not sure what should be done about RenderLayer or otherwise.
 
 Suggestions?

Do not call setStyle() from createRenderer(). Node::createRendererIfNeeded() 
calls setAnimatableStyle() on the renderer after setting it as the node’s 
renderer, so there is no need for createRenderer() to call setStyle(); and as 
you saw, calling it before setting the node’s renderer violates the assumption 
that the pointers between node and renderer are in a consistent state (which is 
not to say that renderer-node-renderer is always the original renderer).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Name nitpick: layout tests

[Dan Bernstein]

On Aug 2, 2010, at 4:28 AM, Alexey Proskuryakov wrote:

 
 29.07.2010, в 10:59, Darin Adler написал(а):
 
 The directory should be eventually be named Tests or WebKitTests or 
 RegressionTests. 
 
 
 Ideally, the directory will have a unique first letter for better tab 
 completion - so WebKitTests is a poor option from that point of view. I like 
 the other two.

Tests collides with Tools (which is what WebKitTools should be renamed to).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] What is XBL?

[Dan Bernstein]

On Aug 25, 2010, at 9:11 AM, Julien Chaffraix wrote:

 http://en.wikipedia.org/wiki/XBL , I guess?
 
 FYI XBL has been superseded by XBL 2.0 that is not backward compatible
 with the first version [1]. Thus our code is just obsolete.

All XBL-related code in WebKit is for XBL2. It seems as if WebKit had working 
XBL2 support, most of the form controls added over the last couple of years 
could have been defined declaratively in markup rather than requiring the 
significant amount of C++ code that they currently do.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] RenderStyle inheritance

[Dan Bernstein]

On Sep 18, 2010, at 12:39 PM, François Sausset wrote:

 If, in a RenderObject method (let's say addChild() or layout()), I change a 
 style property that should be inherited (for instance style()-setColor()), 
 the corresponding style property of the children is not updated.

As a rule, you shouldn’t mutate RenderStyle objects (unless you are 
CSSStyleSelector or you created the RenderStyle yourself). For all you know, 
the style may be shared with other nodes.

 What should I do to propagate the style change?
 I tried unsuccessfully setNeedsStyleRecalc().

What are you trying to do?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] X-Purpose, again!

[Dan Bernstein]

On Oct 8, 2010, at 6:26 AM, Gavin Peters (蓋文彼德斯) wrote:

 In particular, Safari sends X-Purpose: preview headers on requests for 
 resources and subresources motivated by the previw feature of Safari.

That’s incorrect. The header is only present in the request for the main 
resource.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] X-Purpose, again!

[Dan Bernstein]

On Oct 9, 2010, at 7:11 AM, Gavin Peters (蓋文彼德斯) wrote:

 On 8 October 2010 12:02, Dan Bernstein m...@apple.com wrote:
 
 On Oct 8, 2010, at 6:26 AM, Gavin Peters (蓋文彼德斯) wrote:
 
 In particular, Safari sends X-Purpose: preview headers on requests for 
 resources and subresources motivated by the previw feature of Safari.
 
 That’s incorrect. The header is only present in the request for the main 
 resource.
 
 Thanks for the correction.
 
 Can you tell me why that decision was made?

This enables cached subresources to be shared between normal loading of pages 
and loading for preview purposes.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] disable selection of text and images

[Dan Bernstein]

On Oct 19, 2010, at 10:07 AM, Efan... wrote:

 Hi All unfortunately I can not use JAVA script or any thing like that cause 
 my application is totally c++ , QT based.
 I need to make the change in webkit src code I guess.

Note that this is already supported (with no source changes) on Mac OS X via 
the editing delegate method 
-webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting:. 
Perhaps Qt WebKit is missing an equivalent to that delegate interface (a 
cursory look in EditorClientQt.cpp suggest that it is).

 
 On Tue, Oct 19, 2010 at 8:39 AM, Simon Fraser simon.fra...@apple.com wrote:
 Put
 * {
  -webkit-user-select: none;
 }
 
 in your user-agent stylesheet?
 
 Simon
 
 On Oct 18, 2010, at 10:12 PM, Efan... wrote:
 
  Hi
  I am totally new to this group.
 
  I want to disable selection of Text and graphics in my QWebView, it seems 
  that there is no way via Qt i can do this , so only option I am left with 
  is to modify webkit code.
  I am new to webkit code too, but I am willing to put my time and effort to 
  do this, Can any one please suggest what file/function should I be 
  modifying in webkit?? Or does any one has any other solution other than 
  modifying webkit?
 
  I will highly appreciate any input on this.
 
 
 
 
 -- 
 Efan Harris
 ___
 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] Can the build bot trigger be limited to trunk?

[Dan Bernstein]

As far as I can tell, all of the builders and testers use trunk, so changes to 
branches and tags should not trigger a build. Can the build bot be configured 
accordingly?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] WebKitTools is changing to Tools

[Dan Bernstein]

WebKit developers,

I am going to commit the patch from 
https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools 
directory to Tools and updating all internal references. If you update your 
tree after that, you might need to adjust any personal scripts or tools that 
refer to the old name.

I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST).

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

Re: [webkit-dev] Build Errors on Mac OS

[Dan Bernstein]

On Nov 29, 2010, at 1:18 PM, Eric Mader wrote:

 Hi,
 
 I'm trying to build TOT (as of an hour or so ago) on Mac OS. I'm getting a 
 bunch of compile errors in WebKit2Shared/mac/SandboxExtensionMac.mm. The 
 compiler can't find any of the WKSandBoxExtensionXXX symbols (e.g. 
 WKSandboxExtensionInvalidate). What do I need to do to fix this?

I’ve responded to Eric off-list, as this is something that only pertains to 
people who work at Apple.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Rebaselining render tree dumps

[Dan Bernstein]

On Dec 6, 2010, at 12:30 PM, David Hyatt wrote:

 RenderTreeAsTetxt has a large number of hacks in it that have been put in 
 over time to keep the dumps from changing too dramatically.  Some of these 
 include:
 
 (1) Table cells dump incorrect dimensions and positions.
 (2) Text nodes dump an incorrect bounding box position.
 (3) RenderInlines don't dump their position at all.
 (4) The root layer incorporates overflow when it shouldn't.
 (5) The root element has a RenderLayer when there has been no need for it to 
 have a RenderLayer for years.  It only has one in order to not change all the 
 layout tests.

Not a RenderTreeAsText hack per se, but

(6) There’s something called RenderBody ;-)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Pixel tests and displaying text

[Dan Bernstein]

On Dec 8, 2010, at 12:13 PM, Peter Kasting wrote:

 If you never write layout tests, you can stop reading.
 
 Right now few ports run pixel tests (a shame).  One reason is because we 
 frequently need different reference images for each port, and creating 
 hundreds or thousands of these is a hassle.  Maintenance burden also 
 increases.
 
 We could greatly decrease the number of these baselines by following a simple 
 rule: don't display text unless you need to.  For example, let's say I have a 
 test that is supposed to display a green square.  If the test output is:
 
 A green square means this test passes.  If there is any red below, fail.
 [green square here]
 
 ...then for each platform that has different font rendering, whether that be 
 subpixel AA differences, font size differences, or anything else, we'll need 
 new baselines.  By contrast, if that explanation was in an HTML comment 
 inside the test code, and the output was a simple green square, one baseline 
 would serve for all ports.
 
 I think this doesn't really hinder tracking down test failures, for a couple 
 of reasons:
 * Most tests are green = pass, red = failure by convention, so frequently a 
 pixel result that differs from the baseline is easily classifiable at a quick 
 glance.
 * When this isn't the case, one of the first steps in understanding the test 
 output is to read the test, at which point the HTML comment will explain 
 things.
 
 Obviously, some tests need to display text, but this seems to me to be a good 
 rule of thumb.

Tests that involve text can still have cross-platform results if they use the 
Ahem font. See for example 
http://trac.webkit.org/browser/trunk/LayoutTests/fast/css/first-letter-set-text.html?rev=55196.

 
 Am I missing anything?  If not, is anyone interested in helping to make this 
 change on existing tests where possible, to trim the number of baselines in 
 the tree and make it easier for new ports to bring up pixel tests?
 
 PK
 ___
 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] WebKitTools is changing to Tools

[Dan Bernstein]

On Dec 10, 2010, at 2:21 PM, Eric Seidel wrote:

 I suspect there will be a lot of follow-on cleanup.  I don't plan to
 be hacking much that evening, but it would be possible.
 
 grep -l -r WebKitTools * | grep -v pyc | grep -v ChangeLog
 
 Shows that at least 65 files in svn.webkit.org will need an update.

I don’t understand. Aren’t those files covered by my patch at  
https://bugs.webkit.org/show_bug.cgi?id=49861 ?

 I expect all of the queues.webkit.org bots will need restarts.  As
 well as possibly build.webkit.org bots as well.
 
 So that means at least the following people will need to perform restarts:
 - me (cq nodes, and ews)
 - Adam Barth (cq nodes, and ews)
 - Bill Siegrist (build.webkit.org)
 - Lucas Forschler (win ews nodes)
 - Lucas De Marchi (EFL ews)
 - Whoever runs the Qt ews
 
 I don't think the build slaves will need to be restarted, right Bill?
 
 I'm all for the change, but ideally we should come up with a list of
 who all will be affected (that may just be the list above?)
 
 Could we add a symlink before then?

Yes, unless that creates problems for some non-Unix platforms.

 Then it would be easy for most of
 those restarts to happen before the switch date.
 
 -eric
 
 On Fri, Dec 10, 2010 at 2:10 PM, Dan Bernstein m...@apple.com wrote:
 
 
 On Dec 10, 2010, at 1:58 PM, Adam Barth aba...@webkit.org wrote:
 
 Is it time to throw the switch now?
 
 How about next week, Dec 17 at around 4PM PST?
 
 
 Adam
 
 
 On Sun, Nov 21, 2010 at 9:55 AM, Dan Bernstein m...@apple.com wrote:
 
 On Nov 21, 2010, at 5:41 AM, Eric Seidel wrote:
 
 That's likely to break all the ews and commit bots. Since I'm on vacation 
 at
 least the ones I run will remain broken until I return on 29th.
 
 Thanks for letting me know. I will make this change some other time.
 
 On Nov 21, 2010 2:31 AM, Dan Bernstein m...@apple.com wrote:
 WebKit developers,
 
 I am going to commit the patch from
 https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools
 directory to Tools and updating all internal references. If you update 
 your
 tree after that, you might need to adjust any personal scripts or tools 
 that
 refer to the old name.
 
 I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST).
 
 Regards,
 —Dan
 
 
 ___
 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] WebKitTools has changed to Tools

[Dan Bernstein]

Done in r74301.

On Nov 20, 2010, at 11:29 PM, Dan Bernstein wrote:

 WebKit developers,
 
 I am going to commit the patch from 
 https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools 
 directory to Tools and updating all internal references. If you update your 
 tree after that, you might need to adjust any personal scripts or tools that 
 refer to the old name.
 
 I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST).
 
 Regards,
 —Dan

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

[webkit-dev] Please set the svn:mime-type property on binary files before committing

[Dan Bernstein]

Please set the svn:mime-type property on binary files that you add to the tree, 
such as *-expected.png, before committing. Otherwise the resulting 
webkit-changes message will include those files as text, which is inconvenient.

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

[webkit-dev] Why does Ahem have different vertical metrics in Qt?

[Dan Bernstein]

In an attempt to give layout tests consistent results across platforms, I ofter 
use the Ahem font. However, I’ve noticed that Qt still requires 
platform-specific results when I do that. One recent example is 
fast/dynamic/unicode-bidi.html

$ diff -u LayoutTests/platform/qt/fast/dynamic/unicode-bidi-expected.txt  
LayoutTests/fast/dynamic/unicode-bidi-expected.txt 
--- LayoutTests/platform/qt/fast/dynamic/unicode-bidi-expected.txt  
2011-02-03 09:02:59.0 -0800
+++ LayoutTests/fast/dynamic/unicode-bidi-expected.txt  2011-01-28 
10:46:32.0 -0800
@@ -3,14 +3,14 @@
 layer at (0,0) size 800x600 layerType: background only
 layer at (8,8) size 100x50
   RenderBlock (positioned) zI: -1 {DIV} at (8,8) size 100x50 [color=#FF]
-RenderInline {SPAN} at (0,0) size 50x49 [color=#008000]
-  RenderText {#text} at (0,0) size 50x49
+RenderInline {SPAN} at (0,0) size 50x50 [color=#008000]
+  RenderText {#text} at (0,0) size 50x50
 text run at (0,0) width 50: x
-RenderText zI: -1 {#text} at (50,0) size 50x49
+RenderText zI: -1 {#text} at (50,0) size 50x50
   text run at (50,0) width 50: x
 layer at (0,0) size 800x600 layerType: foreground only
   RenderBlock {HTML} at (0,0) size 800x600
 RenderBody {BODY} at (8,8) size 784x584
   RenderBlock {DIV} at (0,0) size 784x50 [color=#008000]
-RenderText {#text} at (0,0) size 100x49
+RenderText {#text} at (0,0) size 100x50
   text run at (0,0) width 100 RTL override: xp

Here, all the 50px Ahem text has a height of 49 pixels on Qt. The pixel 
results, though, show it having the same height it does in Mac OS X (and 
presumably other platforms).

What is causing this difference? How does it affect other fonts and real 
websites? Is there a way to fix this?

Thanks,
—Dan___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] process for unreviewed commits

[Dan Bernstein]

On Mar 3, 2011, at 11:58 PM, Ojan Vafai wrote:

 This isn't a big deal either way, but I noticed that 
 http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit 
 lists the following as the process for unreviewed commits: Unreviewed 
 commits should include a line saying Unreviewed. in place of the Reviewed 
 By... line in each ChangeLog entry.
 
 The Unreviewed bit is news to me. I thought it was assumed that if there's 
 no Reviewed By... line then it was committed unreviewed and, in fact, that 
 was preferred to adding the Unreviewed line.

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

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Dan Bernstein]

On Mar 27, 2011, at 9:27 AM, Simon Fraser wrote:

 On Mar 27, 2011, at 9:07 AM, Eric Seidel wrote:
 
 Do we have any guidelines as to when we use -webkit- for new properties vs 
 not?
 
 For example, when implementing CSS3 properties (like we are this week
 for the BiDi sprint):
 https://bugs.webkit.org/show_bug.cgi?id=57181
 https://bugs.webkit.org/show_bug.cgi?id=50951
 
 It's unclear to me whether -webkit- is required (or even desired) in
 these cases.
 
 Since unicode-bidi is part of CSS 2.1 
 http://www.w3.org/TR/CSS2/visuren.html#direction,
 then it shouldn't need to be prefixed, as long as the implementation is 
 consistent with the 2.1 text.

I think Eric is not asking about the unicode-bidi property, but rather about 
the isolate value, which is not in CSS 2.1. I don’t know that there’s a 
guideline, but there is precedent for prefixing values (for example, display: 
box and display: inline-box), so I would recommend prefixing the new 
unicode-bidi value as well.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Why is gtest in the Source directory?

[Dan Bernstein]

Is gtest required to build any of the WebKit ports? If not, can it be moved out 
of Source and into Tools?

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

Re: [webkit-dev] Switching away from integers for layout

[Dan Bernstein]

On Jun 23, 2011, at 11:46 AM, Levi Weintraub wrote:

 We’ve been getting an increasing number of complaints lately about the 
 zooming support in webkit and how hard it is to correctly support zooming in 
 complex web applications.
 
 To address this we plan to convert the rendering tree to float to allow for 
 better zooming and scaling support. Furthermore this could be expanded to 
 support sub-pixel layout and positioning which in turn would allow higher 
 precision layout when zoomed. We’re the only rendering engine that hasn’t yet 
 made this change.
 
 Changing rendering (and hit testing) to use floats does not necessarily mean 
 that we need to expose floats through the dom api, however if we are to 
 support sub-pixel layout (i.e. style=”left: 12.3px”) this would be required. 
 Specifically we’d need to change the offsetLeft/Top/Width/Height properties 
 to return floating point values [2]. 
 
 We tried two strategies for building a proof of concept, one of which 
 involved accumulating error when laying out with an applied zoom, and the 
 other was a wholesale swap of integers for floats in the layout engine. 
 Ultimately, we discovered that our hopes of the former being a less-invasive 
 solution were lost when the patch grew to the size of the more-invasive 
 latter, and we decided to focus our efforts there.
 
 In the span of 10 days, we built a working prototype that passes over 90% of 
 our layout tests and renders most webpages correctly, including our original 
 zooming test cases. There are still numerous rounding errors, but tracking 
 these down and fixing them is beyond the scope of our proof of concept. We’ve 
 uploaded the resulting patch on the meta bug [1] tracking our work. It’s been 
 tested on the Mac and QT ports.
 
 To make this transition as painless as possible (read: to avoid landing one 
 massive patch), we plan on first moving our current int values to an 
 abstraction that will begin as a typedef to int and its progeny IntRect, 
 IntPoint, and IntSize. We’ll also implement requisite rounding functionality 
 behind a USE(FLOAT_OFFSETS) [or other name, pending discussion] flag. These 
 steps are transitional only, and this abstraction and USE flag will both be 
 removed once we successfully make the jump from int-float.

While compact, the 32-bit float type has poor precision and doesn’t match some 
platforms’ graphics layers’ underlying floating-point type (such as CGFloat in 
64-bit OS X). As long as you are using a typedef, it might be better to make 
the render tree floating-point type easily configurable, so that different 
ports can use (or at least experiment with) different types.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using inline-block divs for line breaking tests

[Dan Bernstein]

On Aug 24, 2011, at 1:08 PM, Alan Stearns wrote:

 I have an idea for writing LayoutTests where what's being tested are line
 breaks. Take the case of this recent bug fix:
 
 https://bugs.webkit.org/show_bug.cgi?id=2
 
 The problem here was that if you had a left float and text-indent combined,
 the text-indent was not being considered in the line break, so text was
 running outside of the container box. Checking this fix seems to require
 using text, and test results that contain text are notoriously
 platform-dependent (apparently even if you use Ahem, see
 https://lists.webkit.org/pipermail/webkit-dev/2011-June/016930.html). The
 patch for this fix had platform/mac/... txt and png expected files, and I
 assume there will be other platform files created and maintained for this
 test.
 
 If I could test the line break without using text, this test (and a class of
 other seemingly text-reliant tests) could be platform-independent. I think I
 have something that works, but I'd like to get feedback from people with
 more WebKit testing experience.
 
 The test currently looks like this:
 
 style
#container {
text-indent: 100px;
width: 200px;
border: 1px solid black;
}
#float {
float: left;
width: 50px;
height: 50px;
background: green;
}
 /style
 div id=container
div id=float/div
Some text that should not overlap the edge of the container.
 /div
 
 What's really being tested is whether the first line contains a short (up to
 50px) amount of text or a longer (50-150px) amount. If I change the text
 content to inline-block elements at a specific pixel width (and set
 line-height as well) the dump-render-tree output should be
 exactly the same on each platform. I can use that output to check for a
 regression as the positions of the RenderBlocks for the word divs will
 change based on whether the line breaks correctly.
 
 style
#container {
line-height:20px;
text-indent: 100px;
width: 200px;
border: 1px solid black;
}
#float {
float: left;
width: 50px;
height: 50px;
background: green;
}
.word{
display:inline-block;
background: blue;
height:12px;
}
.short {
width:40px;
}
.long {
width:90px;
}
 /style
 div id=container
div id=float/divdiv class=short word/divdiv class=long
 word/div
 /div
 
 With this version of the test you lose the self-documenting nature of the
 text, but this also happens if you use the Ahem font. I think this would be
 an OK tradeoff versus having to maintain platform-specific dumps and
 bitmaps. The test expectation could be added to the test source as a
 comment.
 
 If a test really does need to verify that text is being rendered correctly,
 this technique would not be applicable. But I think there are a number of
 tests that are only concerned with line length or height, where the text
 content is incidental.
 
 Does this seem like a good idea? Are there any refinements that can be made?

You can make a text-only test that uses Ahem (you can still rely on its 
horizontal metrics, at least) and DOM API such as Range’s getClientRects() to 
test that the first character after the line break is positioned where you 
expect it to be.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Hyphenation in webkit

[Dan Bernstein]

On Sep 7, 2011, at 2:28 AM, Sireesha Janakiraman wrote:

 Hello,
 
 I tried hyphenation test files in webkit. 
 a)'http://trac.webkit.org/browser/trunk/LayoutTests/fast/text/hyphens.html' 
 b) 
 http://trac.webkit.org/browser/trunk/LayoutTests/fast/text/hyphenate-character.html
   via GtkLauncher in webkitgtk1.5.2
 
 I don't see hyphenation results. I tried setting locale to english and 
 verified my system locale is same as set in -webkit-locale.
 
 Is hyphenation working in latest build?

The implementation of canHyphenate() in Hyphenation.cpp returns false. A port 
needs to provide alternate implementations of canHyphenate() and 
lastHyphenLocation() for hyphenation to work.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Chromium PLT regression

[Dan Bernstein]

On Oct 4, 2011, at 10:37 PM, Adam Barth wrote:

 About a week ago, the Chromium project measured a PLT regression on
 Windows, Mac, and Linux:
 
 https://bugs.webkit.org/show_bug.cgi?id=69238
 
 I don't know whether the regression affects any other ports, but
 according to the Chromium performance bots, the regression occurred in
 this range:
 
 http://trac.webkit.org/log/trunk/Source?rev=96091stop_rev=96066verbose=on
 
 Normally, the Chromium project has a bot continuously running the PLT
 against WebKit trunk, but, due to a configuration error, that bot was
 been offline for about 10 days, which, unfortunately, includes the
 time period in question.  The bot is now back online:
 
 http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/intl1/report.html?history=150rev=-1
 
 I'm not able to reproduce the regression locally.  Sometime in the
 next couple days, when the tree is quiet (which probably means at
 night PST), I'd like to try to hunt down which revision in that range
 caused the regression by rolling out the patches.  If I roll out your
 patch as part of this process, do not worry.  I'll roll it back in
 shortly thereafter.  My hope is that this experiment will allow us to
 isolate the exact revision that caused the regression.
 
 If anyone is able to reproduce the issue locally, that would certainly
 be better than me making a mess by rolling patches in and out of the
 main tree.

Hi Adam,

I think that configuring your bot to build and test old the revisions off trunk 
would be far better. Or, if for some reason that is impossible, then 
configuring it to work against a local repository. Or, if for some reason that 
is impossible, and you absolutely have to use svn.webkit.org for this purpose, 
then configuring it to build and test a branch that you will create for this 
purpose and on which you will run the experiment.

It is almost unbelievable that the only way for you to track down a performance 
regression is to make changes to the source tree.

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

[webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore

[Dan Bernstein]

On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:

 Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819)
 
 --- trunk/Source/WebCore/dom/ScriptElement.h  2011-10-06 16:37:35 UTC (rev 
 96818)
 +++ trunk/Source/WebCore/dom/ScriptElement.h  2011-10-06 16:40:47 UTC (rev 
 96819)
 @@ -113,6 +113,14 @@
ZeroedInStopLoadRequest,
ZeroedInNotifyFinished,
  } m_cachedScriptState;
 +
 +// We grab a backtrace when we zero m_cachedScript, so that at later 
 crashes
 +// we'll have a debuggable stack.
 +enum {
 +MaxBacktraceSize = 32
 +};
 +int m_backtraceSize;
 +void* m_backtrace[MaxBacktraceSize];
  };

This appears to increase the size of each ScriptElement instance by 256 bytes. 
I don’t know how bad a performance hit this is in real-world use, but it is 
most certainly not something all vendors would like to include in their 
releases. The way this change was made, however, it is almost inevitable that a 
vendor would end up unknowingly shipping this performance regression. This 
change was made on trunk, it is unconditionally compiled in, and there is 
nothing obvious tracking undoing this change.

I think this is the wrong way to incorporate diagnostic code into WebKit.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore

[Dan Bernstein]

On Oct 6, 2011, at 10:12 AM, Darin Fisher wrote:

 I agree that this seems like something to #ifdef.  Out of curiosity, did you 
 just stumble upon this, or did you actually notice a measurable performance 
 regression from this?

I just noticed the patch go by.

 
 -Darin
 
 
 On Thu, Oct 6, 2011 at 10:07 AM, Dan Bernstein m...@apple.com wrote:
 
 On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
 
 Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819)
 
 
 --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 
 96818)
 +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 
 96819)
 @@ -113,6 +113,14 @@
ZeroedInStopLoadRequest,
ZeroedInNotifyFinished,
  } m_cachedScriptState;
 +
 +// We grab a backtrace when we zero m_cachedScript, so that at later 
 crashes
 +// we'll have a debuggable stack.
 +enum {
 +MaxBacktraceSize = 32
 +};
 +int m_backtraceSize;
 +void* m_backtrace[MaxBacktraceSize];
  };
 
 This appears to increase the size of each ScriptElement instance by 256 
 bytes. I don’t know how bad a performance hit this is in real-world use, but 
 it is most certainly not something all vendors would like to include in their 
 releases. The way this change was made, however, it is almost inevitable that 
 a vendor would end up unknowingly shipping this performance regression. This 
 change was made on trunk, it is unconditionally compiled in, and there is 
 nothing obvious tracking undoing this change.
 
 I think this is the wrong way to incorporate diagnostic code into WebKit.
 
 ___
 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] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore

[Dan Bernstein]

On Oct 6, 2011, at 10:11 AM, Gavin Peters (蓋文彼德斯) wrote:

 Dan,
 
 You're right.  I'm adding #if PLATFORM(CHROMIUM) to this change shortly.

Thank you.

 
 - Gavin
 
 On 6 October 2011 13:07, Dan Bernstein m...@apple.com wrote:
 
 On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
 
 Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819)
 
 
 --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 
 96818)
 +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 
 96819)
 @@ -113,6 +113,14 @@
ZeroedInStopLoadRequest,
ZeroedInNotifyFinished,
  } m_cachedScriptState;
 +
 +// We grab a backtrace when we zero m_cachedScript, so that at later 
 crashes
 +// we'll have a debuggable stack.
 +enum {
 +MaxBacktraceSize = 32
 +};
 +int m_backtraceSize;
 +void* m_backtrace[MaxBacktraceSize];
  };
 
 This appears to increase the size of each ScriptElement instance by 256 
 bytes. I don’t know how bad a performance hit this is in real-world use, but 
 it is most certainly not something all vendors would like to include in their 
 releases. The way this change was made, however, it is almost inevitable that 
 a vendor would end up unknowingly shipping this performance regression. This 
 change was made on trunk, it is unconditionally compiled in, and there is 
 nothing obvious tracking undoing this change.
 
 I think this is the wrong way to incorporate diagnostic code into WebKit.
 

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

Re: [webkit-dev] For debugging in xcode - Breakpoint does not work.

[Dan Bernstein]

On Dec 6, 2011, at 11:01 PM, Kihong Kwon vim...@gmail.com wrote:

 Hello.
 
 I am a new to mac. Can anyone help me for debugging WebCore?
 
 I have a problem about breakpoint with xcode.
 What I want to say, I can't use a breakpoint with WebCore in the xcode.
 
 After finish to build webkit, I put a breakpoint to the DOMWindow.cpp
 (I  put a breakpoint to DOMWindow::alert and make a alert for testing)
 But breakpoint does work.
 
 I did googling for this...
 I found below solution. but It doesn't work too.
 
 1. Launch safari.

In order for the instance of Safari you're trying to debug to link against the 
WebCore framework you've built, rather than the system WebCore, you need to 
launch it in a way that sets the DYLD_FRAMEWORK_PATH environment variable to 
point to your build products directory. One easy way to do this is to use 
Tools/Scripts/run-safari. Another way is to add Safari as a custom executable 
to the Xcode project. Also, make sure that you are building all of the projects 
(JavaScriptCore, WebCore, WebKit and WebKit2) and that they're all building 
into the same directory. Again, the build-webkit script takes care of this for 
you.

 2. Run - attach to process - select WebProcess (My XCODE version is 3.2.6)
 3. Click debug in the WebCore project window.
 
 Did I make wrong? or have I to do anything else?
 
 Thanks in advance
 Kihong
 ___
 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] Load event for cached resources in DRT

[Dan Bernstein]

On Jan 6, 2012, at 8:18 AM, Alexandru Chiculita ach...@adobe.com wrote:

 I need to add more tests for CSS Shaders, but I couldn't find a nice way to 
 know that a cached resource is loaded. So the result is that in DRT the 
 screenshot is taken too early. Other tests use the onload event of the 
 associated tag (ie. img, iframe, script), but CSS Shaders have no such tag. 
 Do you know if there's any DRT method that forces a sync load or waits for a 
 specific resource?
 
 If not, I think a workaround would be to use a hidden iframe (or script tag) 
 and the onload event. Other ideas?

What triggers loading the shaders? If you can force them to start loading 
before the load event fires, then it shouldn't fire until they're finished 
loading. This is the case with custom fonts: the forced layout that happens 
when we finish parsing the main resource triggers the requests for @font-face 
sources, and thus holds up the load event.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Please set the svn:mime-type property on binary files before committing

[Dan Bernstein]

Please set the svn:mime-type property on binary files that you add to the tree, 
such as *-expected.png, before committing. Otherwise the resulting 
webkit-changes message will include those files as text, which is inconvenient.

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

[webkit-dev] Please set the svn:mime-type property on binary files before committing

[Dan Bernstein]

Please set the svn:mime-type property on binary files that you add to the tree, 
such as *-expected.png, before committing. Otherwise the resulting 
webkit-changes message will include those files as text, which is inconvenient.

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

Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing

[Dan Bernstein]

On Mar 8, 2012, at 12:05 PM, Ojan Vafai o...@chromium.org wrote:

 Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I 
 didn't have my subversion config set correctly.
 
 I went to fix up my commits from yesterday and realized that a very large 
 percentage of the pngs in the LayoutTests tree have the wrong svn:mime-type. 
 Is anyone opposed to me doing a bulk fix for all the pngs?

No. I have done this myself multiple times in the past.

 
 find LayoutTests | grep \.png$ | grep -v \.svn | xargs svn ps svn:mime-type 
 image/png

I tend to be more conservative and only set the property on PNGs that don’t 
already have it set to something.

 
 
 
 On Thu, Mar 8, 2012 at 1:52 AM, Ashod Nakashian ashodnakash...@yahoo.com 
 wrote:
 Please let's also enforce svn:eol-style to LF for all scripts as this is 
 breaking (at least) the bash scripts that are checked-out with native style 
 on Windows. Some bash versions don't like CR. Please see a (failed) attempt 
 at fixing this manually[1].
 
 I also believe we should mark all (Bash/Perl/Python) scripts as executable. 
 It's best to at least automate it, if not also check for violations via 
 check-webkit-style. (And for the loving of all that's good, would someone 
 please help with this bug[1]?)
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=79509
 
 -Ash
 
 From: Simon Fraser simon.fra...@apple.com
 To: Eric Seidel e...@webkit.org 
 Cc: WebKit Development webkit-dev@lists.webkit.org 
 Sent: Thursday, March 8, 2012 3:37 AM
 Subject: Re: [webkit-dev] Please set the svn:mime-type property on binary 
 files before committing
 
 The best way to enforce it would be with a pre-commit hook:
 https://bugs.webkit.org/show_bug.cgi?id=80548
 
 Simon
 
 On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote:
 
  Unless this is enforced by a tool, it's very likely to be forgotten.
  
  https://bugs.webkit.org/show_bug.cgi?id=75824
  https://bugs.webkit.org/show_bug.cgi?id=75825
  
  
  On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote:
  Please set the svn:mime-type property on binary files that you add to the
  tree, such as *-expected.png, before committing. Otherwise the resulting
  webkit-changes message will include those files as text, which is
  inconvenient.
  
  Thanks.
  
  ___
  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

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

Re: [webkit-dev] Debugging With Xcode

[Dan Bernstein]

On Apr 24, 2012, at 12:18 AM, Eric Seidel wrote:

 I have updated to the latest Xcode.
 
 My current hack for being able to build from the command line as well
 as within Xcode is that I've manually added symlinks from
 Source/WebCore/build - ../../WebKitBuild (since it no longer seems
 possible to set a global build directory).  It seems to be working
 mostly (it likes to re-link, but is at least not re-compiling when I
 switch between build-webkit and Xcode).
 
 I'm told that the Xcode4 way to share build directories is with
 Workspaces? [1] Has anyone set up a workspace file for WebKit that I
 could use?  I don't see one in the repository.

There’s one attached to
http://webkit.org/b/85739 Building and debugging WebKit in the Xcode IDE 
requires a lot of setup

 
 Thanks.
 
 -eric
 
 1. 
 http://developer.apple.com/library/ios/#featuredarticles/XcodeConcepts/Concept-Workspace.html#//apple_ref/doc/uid/TP40009328-CH7-SW1
 
 On Mon, Apr 23, 2012 at 7:30 PM, Ryosuke Niwa rniwa at webkit.org wrote:
 Has anyone successfully setup DRT as a debug target (a.k.a. Scheme) on XCode
 4 (so that we don't have to manually attach dbg)?

Yes. The All Tools scheme in the aforementioned patch has DumpRenderTree as its 
Executable, and is configured such that you can specify LayoutTests-relative 
paths to tests as arguments.

 
 - Ryosuke
 
 On Mon, Apr 23, 2012 at 7:07 PM, Jarred Nicholls jarred at webkit.org 
 wrote:
 
 On Apr 23, 2012, at 9:03 PM, Eric Seidel eric at webkit.org wrote:
 
 Does anyone still debug WebKit on Mac OS X with Xcode 4?
 
 
 1. ?I don't know how to actually set up Xcode to point to WebKitBuild
 like it used to.
 http://www.webkit.org/building/debug.html
 Mentions a Legacy option which does not exist for me.
 
 Simon Fraser helped me set up WebKitBuild on one of my machines, but I
 don't really know how to repeat that process.
 
 
 2. ?Xcode tries to Re-index WebCore, seemingly every time I open
 WebCore.xcodeproj. ?This is a hour+ process on my 12-core Mac Pro!
 
 The re-indexing takes a lot of processing power, and seems to render
 both my machine, and Xcode largely unusable.
 
 
 I understand that Xcode isn't really designed for projects as large as
 WebCore, but we've made it work in the past, and I'm curious if anyone
 is still making it work?
 
 
 If the Apple folks have any suggestions or updates to
 http://www.webkit.org/building/debug.html, they would be most
 appreciated. :)
 
 Thanks!
 
 -eric
 
 Xcode 4.2.1
 Build version 4D502
 ___
 webkit-dev mailing list
 webkit-dev at lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 I usually create an empty project, add the source files I care about, and
 then attach to the appropriate renderer process - but also use
 WebCore.xcodeproj directly on occasion. ?I run the same version as you and
 once ran into an infinite indexing cycle, but after a swift kick from
 Activity Monitor, I haven't seen it again. ?Xcode works great as a gdb front
 end for me.
 ___
 webkit-dev mailing list
 webkit-dev at 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] We should rename layoutTestController to testController

[Dan Bernstein]

On May 31, 2012, at 12:11 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote:
 I am thinking we should rename layoutTestController to testController. Or if 
 you don’t like that name, maybe testHarness or some even better name.
 
 testController seems like a misnomer since it doesn't really control the 
 test itself. I would prefer testRunnerController or simply testRunner since 
 it's quite self-evident that methods on testRunner would act on the test 
 runner itself.

I like the name testRunner.

 
 We could expose the object under the new name and the old one, and then over 
 time convert all the tests to the new name, then get rid of the old one.
 
 That sounds like a good idea.
 
 Can we also rename LayoutTests to RegressionTests? I know Dave (Hyatt) 
 suggested to cleanup the render tree dump format to get rid of all hacks and 
 tweaks we've added over years, and my preference is to combine all these 
 efforts and put new types of tests in trunk/RegressionTests. We'll move tests 
 from LayoutTests to RegressionTests as we convert. We'll get rid of 
 LayoutTests directory once all tests have been converted to use testRunner 
 and new render tree dump format.
 
 - Ryosuke
 
 ___
 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-changes] [119113] trunk/Source/WebKit/gtk

[Dan Bernstein]

On May 31, 2012, at 9:36 AM, commit-qu...@webkit.org wrote:

 Revision
 119113
 Author
 commit-qu...@webkit.org
 Date
 2012-05-31 09:36:29 -0700 (Thu, 31 May 2012)
 
 
 Modified: trunk/Source/WebKit/gtk/ChangeLog (119112 = 119113)
 
 --- trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:32:33 UTC (rev 119112)
 +++ trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:36:29 UTC (rev 119113)
 @@ -1,3 +1,35 @@
 +2012-05-31  commit-qu...@webkit.org  
 commit-qu...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc
Can whoever made this change fix the change log?

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

Re: [webkit-dev] are fuzzer tests appropriate layout tests?

[Dan Bernstein]

On Jun 12, 2012, at 5:17 PM, Ojan Vafai o...@chromium.org wrote:

 See https://bugs.webkit.org/show_bug.cgi?id=87772.
 
 It's great to use a fuzzer in order to find cases where we're broken and then 
 make reduced layout tests from those. The viewspec-parser tests are 
 themselves just a fuzzer though. Granted, they are deterministic by avoiding 
 using an actual random function, but I don't think throwing randomly 
 generated bits at a parser is appropriate for layout testing. If nothing else 
 it's very slow.
 
 These tests regularly timeout on the Chromium debug bots and occasionally 
 timeout on the Apple Lion bots. Even on the bots where they don't timeout, 
 they're slow. I don't it makes sense to spend 1+ minutes running these 5 
 tests when more targeted reductions could get the same effective coverage 
 much faster.
 
 Am I wrong? If not, does anyone object to moving these tests over to 
 ManualTests or just deleting them entirely?

I am not familiar with the viewspec-parser tests and their history, but I agree 
in principle that fuzzers and their raw output rarely make for the best way to 
regression test.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] editbugs permission

[Dan Bernstein]

On Jun 13, 2012, at 9:25 PM, Mike Lawther wrote:

 Hi there,
 
 I'd like to ask for EditBugs permission for dstockw...@chromium.org, who has 
 already landed a couple of patches and is helping us triage bugs.

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

Re: [webkit-dev] Compiling WebKit in 32 bit for Mac

[Dan Bernstein]

On Jun 17, 2012, at 11:12 AM, Mark Gilbert wrote:

 Hi There,
 
 Could anyone enlighten me on how to create a 'build-webkit' tool which 
 compiles the frameworks with 32-bit (and 64-bit perhaps).
 
 I need a 32-bit compatible set of frameworks to allow the WebKit app to 
 support 32-bit plug ins like the QuickTime plug in.
 
 Using the 'build-webkit' too appears to produce only 64-bit binaries in the 
 frameworks.
 
 I want to rebuild webkit as 32/64 bit, with some tiny code changes, then 
 insert these into the WebKit nightly application.  This is working fine with 
 the 64-bit only build I am creating with 'build-webkit' but it doesn't then 
 support the 32-bit plug ins (which the nightly build does when it arrives).
 
 Clearly the nightly build is not using 'build-webkit' for the frameworks  
 since it comes with universal 64/32 bit
 
 Any suggestions ?

build-webkit --32-bit
will build 32-bit-only products.

build-webkit ARCHS=i386 x86_64 ONLY_ACTIVE_ARCH=NO
will build universal products.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Please include function-level comments in change log entries

[Dan Bernstein]

It appears that lately most WebCore change log entires don’t include any 
comments on individual functions. An overall description of the change at the 
top of the change log entry is valuable, but it is no substitute for describing 
the changes to each function. Good function-level comments are useful both 
while reviewing a patch and while revisiting existing code. Personally, I find 
that writing the function-level comments helps me a lot in reviewing my own 
patches before I post them.

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

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

[Dan Bernstein]

On Sep 4, 2012, at 5:50 AM, Glenn Adams gl...@skynav.com wrote:

 
 Alternatively, you can compute the with of each character with script 
 (without adding any new feature to WebKit).
 
 Unfortunately, that won't work since I can't access the width of individual 
 lines produced by formatting a block.

You can use Range’s getClientRects to get the widths of individual characters 
and to determine where a line breaks occur.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] unsigned vs unsigned int

[Dan Bernstein]

On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen 
kenneth.christian...@gmail.com wrote:

 Hi there,
 
 I was telling people to use unsigned instead of unsigned int, as I
 have been told that was the preferred style before, but apparently
 that is not in the style guide.
 
 The question is, should it be?

Yes.

 
 A few greps in the code:
 
 unsigned - 18406 occurrences.
 unsigned int - 1721
 unsigned i = - 1548
 
 It does in fact seem to be the preferred style.
 
 Cheers
 Kenneth
 
 -- 
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org
 
 ﹆﹆﹆
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WKCreateCTLineWithUniCharProvider

[Dan Bernstein]

On Sep 26, 2012, at 2:34 AM, Glenn Adams gl...@skynav.com wrote:

 Where can I find the source for WKCreateCTLineWithUniCharProvider? I'm 
 working on a bug [1] in which I will need to at least understand and perhaps 
 modify its behavior.
 
 Basically, to fix this bug, I need to pass character context from adjacent 
 text runs (or adjacent inline text nodes) that will be used to affect the 
 shaping substitutions but not otherwise participate in width or drawing 
 behavior.
 
 Or is this functionality only exposed to Apple staffers? [If so, then I will 
 instead approach doing a trial fix on one of the platforms that uses 
 harfbuzz.]
 
 Regards,
 Glenn
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=6148

WKCreateCTLineWithUniCharProvider is a wrapper around Core Text private API. It 
does the same thing that the public function CTLineCreateWithAttributedString 
does, except that instead of taking an attributed string as a parameter, it 
takes a pointer to a callback function that returns runs of characters and 
attributes.

Core Text source code is not published.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] New web-exposed feature: ruby-position: {before, after}

[Dan Bernstein]

As specified in http://www.w3.org/TR/2011/WD-css3-ruby-20110630/#rubypos, the 
ruby-position property takes four values: before, after, inter-character, and 
inline. In http://trac.webkit.org/r136142 I added a -webkit-ruby-position 
property and support for the before and after values (the former, which is also 
the initial value of the property, corresponds to the existing behavior before 
the property was added).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVGStopElement.idl recompiling every time if you build twice in a row?

[Dan Bernstein]

On Mar 10, 2013, at 6:15 PM, Darin Adler da...@apple.com wrote:

 On Mac, SVGStopElement.idl keeps getting recompiled every time I build 
 WebCore, and then in turn everything that uses the headers generated. Anyone 
 know why this happens? Is this specific to Mac, or happening with other build 
 systems too?

I noticed this too and I knew which change had caused it, then someone told me 
that if I deleted my build directory (or maybe it was just my derived sources 
directory) it would stop, and it did. I don’t know what is broken in the Mac 
(or all) build systems that made this necessary.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Safari support for Web Speech API

[Dan Bernstein]

On May 15, 2013, at 4:46 PM, Randy Brown rbr...@madmobile.com wrote:

 I'm trying to ascertain if, and when, Apple is planning on supporting the Web 
 Speech API.  This email from Chris that was attached to this post earlier in 
 the year, is the ONLY thing I can find on the web regarding Apple's support 
 of the speech API, which is very surprising to me.  Does anyone have any 
 knowledge of whether or not Apple is planning to support this spec for 
 Safari, specifically on mobile, and if so, when?  Now that this is a W3C 
 spec, and Chrome has added support for it, Apple is seriously missing the 
 boat on this.  As a developer of mobile optimized sites for large retail 
 brands, we see speech to text as a game changer for the mobile web.  Very 
 interested to know if this is even on Apple's radar…and if not, why not?
 
 Thanks for any and all feed back on this topic.
 Randy

First of all, webkit-dev is not an appropriate forum for discussing any 
vendor’s product plans. In addition to that, Apple doesn’t comment on 
unannounced products and features.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

[Dan Bernstein]

On Jun 19, 2013, at 7:37 PM, Timothy Hatcher timo...@apple.com wrote:

 What about?
 
 StyleResolver* existingStyleResolver()
 StyleResolver styleResolver()

I like it.

 
 — Timothy Hatcher
 
 
 On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote:
 
 For me optional seems very misleading and generally different prefixes 
 suggests that those objects are not the same.
 Maybe IfExists does not sound nicely but at least it's clear. I would choose 
 to have a pointer version with IfExists and a reference version which is a 
 noun, like:
 
 StyleResolver* styleResolverIfExists()
 StyleResolver styleResolver()
 
 Br,
 -Balazs
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

[Dan Bernstein]

On Jul 1, 2013, at 7:31 PM, Brady Eidson beid...@apple.com wrote:

 
 On Jul 1, 2013, at 5:27 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Sun, Jun 30, 2013 at 9:39 PM, Filip Pizlo fpi...@apple.com wrote:
 On Jun 19, 2013, at 9:41 AM, Dan Bernstein m...@apple.com wrote:
 
 
 
  On Jun 19, 2013, at 7:37 PM, Timothy Hatcher timo...@apple.com wrote:
 
  What about?
 
  StyleResolver* existingStyleResolver()
  StyleResolver styleResolver()
 
  I like it.
 
 
  — Timothy Hatcher
 
 
  On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote:
 
  For me optional seems very misleading and generally different prefixes 
  suggests that those objects are not the same.
  Maybe IfExists does not sound nicely but at least it's clear. I would 
  choose to have a pointer version with IfExists and a reference version 
  which is a noun, like:
 
  StyleResolver* styleResolverIfExists()
 
 I like this more. I like that the use of 'if' in the name alerts me to the 
 fact that the function will return something conditionally.
 
 By contrast, existingFoo only makes sense to me if I'm already aware of 
 the idiom. And although I probably will *become* aware of the idiom it will 
 still nonetheless be one of many idioms that I have to be aware of, so I 
 fear that I'll forget why Foo is qualified with existing. That's why I 
 like fooIfExists - its super explicit about what is going on.
 
 I concur.  Maybe
 StyleResolver* styleResolverIfExists()
 StyleResolver styleResolver()
 ?
 
 I concur with this.
 
 For this entire discussion, this is where I was hoping it was headed.

On second and third thought, I do think these are better.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Dan Bernstein]

On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.
 
 Recently, I’ve seen patches go by using the C++11 “auto” keyword. For 
 example, let me pick on Andreas:
 
 http://trac.webkit.org/changeset/161143
 
 +auto newRenderer = textNode.createTextRenderer(style);
 +ASSERT(newRenderer);
 
 ….
 
 +parentRenderer-addChild(newRenderer.leakPtr(), nextRenderer);
 
 I think this use of “auto” is net harmful. 
 
 Upsides:
 
 - Less typing
 
 Downsides:
 
 - I don’t know the type of ’newRenderer’ at a glance
 - Navigating to newRenderer’s class definition is a two-step process: (1) Go 
 to the definition of createTextRenderer and see what it returns; (2) Go to 
 the definition of (1).
 
 I think the downsides outweigh the upsides here because reading code is more 
 common than writing code, and because it’s not *that* much typing to write 
 out RenderPtr RenderText”. In this particular code, I think it’s 
 especially bad to disguise the type of a pointer in the render tree, since 
 we’re in the middle of a transition to a new type of pointer, and so it’s 
 important to know if you’re looking at code that does the new thing or the 
 old thing.

We tend to avoid local write-once-read-once local variables, i.e. we tend to 
prefer

{
setSize(optimalSize());
}

to

{
CGSize newSize = optimalSize();
setSize(newSize);
}

But the up- and down-sides of this are the same as those of using auto. Do you 
think we should also encourage use of write-once-read-once locals for the same 
reasons?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Guideline for nullptr

[Dan Bernstein]

Sent from my iPad

 On Jan 6, 2014, at 11:55 AM, Darin Adler da...@apple.com wrote:
 
 I suggest we use nullptr, rather than of 0 or NULL, for all pointer nulls in 
 WebKit C++ sources. I don’t see any advantage to using 0 or NULL over 
 nullptr, and nullptr has multiple advantages. Three obvious ones: Compile 
 time error if accidentally passed to something expecting an integer, can be 
 distinguished from an integer in function overloading, can tell it’s a 
 pointer.
 
 Any objections?
 
 — Darin
 
 PS: Maybe even instead of nil in WebKit Objective-C++ code?

In Objective-C++, nil is nullptr, so I suggest that we stick with the language 
convention of writing it as nil.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

[Dan Bernstein]

On Jan 11, 2014, at 2:47 PM, Darin Adler da...@apple.com wrote:

 Hi folks.
 
 There is a lot of WebKit code that needs to be on for “the Mac and iOS 
 ports”. Some of it is guarded be conditionals with a higher level concept. 
 But most of it, now this is guarded by PLATFORM(MAC). I think that’s really 
 confusing and we need to rename PLATFORM(MAC) to something else. Perhaps 
 PLATFORM(COCOA)? Or maybe it’s SOMETHING_ELSE(COCOA)?
 
 Then we can use PLATFORM(MAC) for “the Mac port” rather than PLATFORM(MAC)  
 !PLATFORM(IOS).
 
 Later we can start renaming file names as well, but for now I just want to 
 fix the conditionals to be more readable. And of course, it’s even better in 
 cases where we can move away from platform conditionals to more logical 
 conditionals such as USE(CF) or USE(APPKIT).
 
 So, is PLATFORM(COCOA) an acceptable new name for what is currently named 
 PLATFORM(MAC)?

Yes.

 If not, what’s a better choice?
 
 Lets do this soon. It’s hard for me to remember that in WebKit, PLATFORM(MAC) 
 means “the Mac and iOS ports”.
 
 — Darin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

[Dan Bernstein]

On Jan 11, 2014, at 3:19 PM, Darin Adler da...@apple.com wrote:

 
 On Jan 11, 2014, at 3:12 PM, Anders Carlsson ander...@apple.com wrote:
 
 
 One downside is that we won’t be able to make PLATFORM(MAC) mean “the Mac 
 port” before all the uses have been audited and converted to 
 PLATFORM(COCOA). I don’t know a good solution to that problem.
 
 My proposal is:
 
 1) Add PLATFORM(COCOA).
 2) Change PLATFORM(MAC) to PLATFORM(COCOA) quickly and mechanically before 
 making other changes.
 3) Add a PLATFORM(MAC) that is false for iOS.
 
 Then we can change various PLATFORM(COCOA) back to PLATFORM(MAC) if they 
 really meant PLATFORM(MAC), but that can be done gradually over time.

How about this plan instead?

1) Add PLATFORM(COCOA)
2) Change all instances of PLATFORM(MAC) that are not in !PLATFORM(IOS) 
sections or combined with !PLATFORM(IOS) into PLATFORM(COCOA)
3) Make PLATFORM(MAC) be false in iOS.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EFL and GTK on Darwin

[Dan Bernstein]

Hi everyone, and especially EFL and GTK contributors!

In preparation for changing PLATFORM(MAC) to be false when building for iOS, I 
have been reviewing usage of PLATFORM(MAC) throughout our codebase. Some of 
these uses are really about targeting the Darwin OS. However, I could not 
simply replace PLATFORM(MAC) with OS(DARWIN), because the latter also 
encompasses the EFL and GTK platforms when building for Darwin (which the 
former does not). Therefore, thus far I have replaced relevant instances of 
PLATFORM(MAC) with (OS(DARWIN)  !PLATFORM(EFL)  !PLATFORM(GTK)).

This is ugly and seems like a waste of time, so I was wondering:

1. Is there a configuration of the EFL port that actually builds for Darwin?

2. Is there a configuration of the GTK port that actually builds for Darwin?

3. If such configuration(s) exist, would it be OK for them to use Darwin when 
building for Darwin?

If the answer to 1 and 2 is no, or if the answer to 3 is yes, then I will 
simply use OS(DARWIN) to replace PLATFORM(MAC) where that is the intent, and, 
depending on the answers to 1 and 2, update the EFL and GTK build systems to 
include the Darwin-based implementations where needed.

Thanks!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL and GTK on Darwin

[Dan Bernstein]

On Feb 11, 2014, at 12:29 AM, Žan Doberšek zandober...@gmail.com wrote:

 Hi.
 
 On Mon, Feb 10, 2014 at 6:30 PM, Dan Bernstein m...@apple.com wrote:
 Hi everyone, and especially EFL and GTK contributors!
 
 In preparation for changing PLATFORM(MAC) to be false when building for iOS, 
 I have been reviewing usage of PLATFORM(MAC) throughout our codebase. Some of 
 these uses are really about targeting the Darwin OS. However, I could not 
 simply replace PLATFORM(MAC) with OS(DARWIN), because the latter also 
 encompasses the EFL and GTK platforms when building for Darwin (which the 
 former does not). Therefore, thus far I have replaced relevant instances of 
 PLATFORM(MAC) with (OS(DARWIN)  !PLATFORM(EFL)  !PLATFORM(GTK)).
 
 Just to be clear, this is about code that's not appropriate to guard with 
 PLATFORM(COCOA)?

Yup.

 
 
 This is ugly and seems like a waste of time, so I was wondering:
 
 1. Is there a configuration of the EFL port that actually builds for Darwin?
 
 2. Is there a configuration of the GTK port that actually builds for Darwin?
 
 Yes, this configuration is supported by the GTK port through the MacPorts 
 project. Jeremy Huddleston regularly upstreams modifications to properly 
 support building the GTK port on Darwin.
  
 
 3. If such configuration(s) exist, would it be OK for them to use Darwin when 
 building for Darwin?
 
 This could be possible, but it depends really on the code in question. Jeremy 
 would probably be the best candidate to exactly tell you whether the new code 
 is viable to use for the GTK port on Darwin. 
  
 
 If the answer to 1 and 2 is no, or if the answer to 3 is yes, then I will 
 simply use OS(DARWIN) to replace PLATFORM(MAC) where that is the intent, and, 
 depending on the answers to 1 and 2, update the EFL and GTK build systems to 
 include the Darwin-based implementations where needed.
 
 Thanks!
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 

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

Re: [webkit-dev] Comment on the bug email author/reviewer before reverting a patch

[Dan Bernstein]

 On Jul 9, 2014, at 1:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 When the bug for a rollout is created, the original bug is automatically 
 reopened.

This is a long-standing bug in the bot. The original bug should not be reopened 
until the change that fixed it is reverted.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Port-specific OpenType support

[Dan Bernstein]

 On Sep 11, 2014, at 11:44 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 Hello, Webkittens!
 
 I have started work on an SVG font - OpenType converter [1] with the intent 
 of eventually getting rid of our code path which lays out and draws text 
 using SVG fonts. The motivation is fourfold:
 
 1) Performance: on OS X the native text libraries are over 1000x faster than 
 our SVG code path.
 2) Security: There have been numerous security bugs in the SVG font code path.
 3) Code clarity: This would greatly simplify the text rendering code.
 4) The next version of SVG is removing SVG fonts completely [2]. Chrome has 
 recently dropped support for SVG fonts [3] and Firefox/IE never had it [4] 
 [5].

5) Correctness: using an SVG font will no longer mean you don’t get subpixel 
antialiasing (and perhaps other text effects?)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for editbugs privilege on bugzilla

[Dan Bernstein]

 On Aug 20, 2015, at 11:39 AM, Andrunko andru...@gmail.com wrote:
 
 Hi all,
 
 I would like to request editbugs privilege on bugzilla (I went to
 close #124167 in favor of #148028 but dont have permission) - I am a
 committer.
 
 Please let me know if I should ask someplace else instead.
 
 BR,
 Andre

I’ve added andru...@gmail.com mailto:andru...@gmail.com to the cancofirm and 
editbugs groups.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] OSX: Linking to custom build resorts to system version...

[Dan Bernstein]

> On Nov 11, 2015, at 2:06 AM, Nikolay Tsenkov  wrote:
> 
> Hello,
> 
> First of all, thanks for the awesome OSS software that WebKit is!
> 
> I need some help with linking to a fresh build of WebKit.framework on OS X:
>  - I am building a modified version of WebKit.framework (my changes are in 
> WebCore and WebKit projects) on OS X 10.11, but I am not able to use that 
> framework in another project - somehow the project always resorts to the 
> default system WebKit.framework.
> 
> Setup:
>  - OS X 10.11.0 (just saw there is 10.11.1 available, but haven’t installed 
> it yet)
>  - System Integrity Protection (SIP) disabled (I couldn’t build when ON)
> 
> Changes:
>  - (Gist) I am making a version of the WebView (the legacy one, the 
> single-process model) which can be used in DAW plugin, exposing API for 
> rendering the audio, settings the sampling rate, not rendering to the audio 
> hardware directly, etc.
>  - (Specific)
>- (WebCore) -Replaced- AudioDestinationMac with AudioDestinationDaw;
>- (WebCore) -Add- DawStateSingleton which exposes the custom 
> destination node to the WebView;
>- (WebKit) -Modify- WebView to include a new constructor and couple of 
> new methods:
> - (instancetype)initWithFrame:(NSRect)frame samplingRate:(float)samplingRate 
> frameName:(NSString *)frameName groupName:(NSString *)groupName;
> - (void)setDawSamplingRate:(float)samplingRate;
> - (void)renderAudio:(int) numberOfFrames bufferList:(AudioBufferList*) 
> bufferList;
> 
> In a new project, I am trying to use the new WebView. If I don’t link to 
> WebKit.framework, of course, the build fails because it can’t find the 
> framework. But if I link to the custom build (the WebView header is the new 
> one, I’ve checked) in run time the app breaks with “-[WebView 
> initWithFrame:samplingRate:frameName:groupName:]: unrecognized selector sent 
> to instance” from which I infer it’s using the system version of the WebView.
> 
> I’ve tried to inspect how the MiniBrowser project correctly is referring to 
> the new build, but I don’t see how the linking is happening…
> 
> Could someone help me out with this?
> 
> Please, accept my apologies, if there is something simple that I’ve missed.

The most common way to get your executable to pick up your custom built WebKit 
instead of the system WebKit is to have your executable run with the 
DYLD_FRAMEWORK_PATH environment variable set to the the path where your built 
frameworks are. The run-webkit-app script in Tools/Scripts does this. Or if 
you’re running your up from within Xcode you can set the environment variable 
for the Run action in the scheme editor. There are a few other ways to get the 
environment variable set, and some other ways to get your program to pick up 
your framework, but I think the above should give you a good start.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] A recent change to how WebKit XPC services work for development

[Dan Bernstein]

The recent r195795  
changed how WebKit XPC services work for development.

I expect this change to not have any impact on most of your workflows, but read 
on for the details, and be on the lookout for any things that might have broken 
anyway.

The most noticeable effect of this change is that XPC services will no longer 
inherit all of the UI process’s environment variables automatically. To set an 
environment variable EXAMPLE to VALUE in the XPC services, you’ll need to set 
__XPC_EXAMPLE to VALUE in the UI process’s environment. In cases where our 
tools need to control the XPC services’ environment, the tools have been 
updated to do use the __XPC_ prefix. And setting __XPC_DYLD_FRAMEWORK_PATH or 
__XPC_DYLD_LIBRARY_PATH for the services isn’t necessary, since they know to 
look for frameworks and libraries relative to where they are.

Engineering builds will no longer contain both a normal variant and a 
.Development variant of each of the WebKit XPC services. Instead, they will 
contain only a normal variant of each service. However, the service name and 
bundle identifier will continue to have the .Development suffix.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for editbugs bit on Bugzilla

[Dan Bernstein]

I’ve added canconfirm and editbugs to web...@chrisrebert.com.

> On Feb 18, 2016, at 10:59 PM, Chris Rebert  wrote:
> 
> Hello,
> 
> I'd like to request the editbugs bit on Bugzilla, so as to be able to
> correct the Component field or (after testing) update the
> Version+Platform fields of bugs when trawling Bugzilla.
> 
> Here are some examples of bugs I've previously filed:
> https://bugs.webkit.org/show_bug.cgi?id=138162
> https://bugs.webkit.org/show_bug.cgi?id=138167
> https://bugs.webkit.org/show_bug.cgi?id=143527
> https://bugs.webkit.org/show_bug.cgi?id=146244
> https://bugs.webkit.org/show_bug.cgi?id=146896
> https://bugs.webkit.org/show_bug.cgi?id=147284
> https://bugs.webkit.org/show_bug.cgi?id=149587
> https://bugs.webkit.org/show_bug.cgi?id=149935
> https://bugs.webkit.org/show_bug.cgi?id=150271
> https://bugs.webkit.org/show_bug.cgi?id=153056
> 
> Cheers,
> Chris
> --
> https://github.com/cvrebert
> Browser  of the day: http://crbug.com/534750
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Dan Bernstein]

> On Sep 5, 2016, at 10:13 AM, Darin Adler  wrote:
> 
> Hi folks.
> 
> WebKit has some critical functions that involve asking an object to give up 
> ownership of something so the caller can take ownership.
> 
> In the C++ standard library itself, this is called move, as in std::move.
> 
> In WebKit smart pointers, we call this operation release, as in 
> RefPtr::releaseNonNull and String::releaseImpl.
> 
> In WebKit collections, we call this operation take, as in HashMap::take and 
> ExceptionOr::takeReturnValue.
> 
> The release vs. take terminology is distracting to my eyes. The verb “take" 
> states what the caller wishes to do, and the verb “release” states what the 
> caller wants the collection or smart pointer to do.

This can be addressed by renaming take to give (hey, it’s right there in the 
subject).

> My first thought was be to rename the take functions to use the word release 
> instead, but I fear it might make them harder to understand instead of easier 
> and clearly it would make them longer.
> 
> Does anyone have other ideas on how to collapse WebKit project terminology 
> down so we don’t have three different single words that are used to mean 
> almost the same thing?

Rename release to give, too?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Problems running WebKit/Safari in Sierra

[Dan Bernstein]

> On Nov 15, 2016, at 7:23 AM, Joanmarie Diggs  wrote:
> 
> Hey all.
> 
> WebKit/Safari builds just like it always does, but running it now fails
> for me in Safari (10.12.1):
> 
> $ ./Tools/Scripts/run-safari
> Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to
> point to built WebKit in /Users/jd/WebKit/WebKitBuild/Release.
> dyld: Symbol not found: _NSTouchBarDidExitCustomization
>  Referenced from:
> /Users/jd/WebKit/WebKitBuild/Release/WebKitLegacy.framework/Versions/A/WebKitLegacy
>  Expected in: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> in
> /Users/jd/WebKit/WebKitBuild/Release/WebKitLegacy.framework/Versions/A/WebKitLegacy
> 
> I'd be most grateful for a hint and/or a pointer to the doc my search
> failed to turn up.


Hi Joanmarie,

If you are building WebKit with Xcode 8.1, then to use it, you need to have 
macOS 10.12.1 build 16B2657. Your computer may have a different build, 16B2555, 
which was originally offered to computers without a Touch Bar. You can use the 
sw_vers command to see which build you have. The newer build is available from 
>.

Thanks!___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Dan Bernstein]

> On Jan 11, 2017, at 5:43 PM, Maciej Stachowiak  wrote:
> 
> 
> To be clear, I think PAL is a great move. Details like the namespace, 
> placement of the code, and how includes look are all things that can be 
> changed after the fact.
> 
> That said, I think we need to ultimately consider our porting layer to be the 
> combination of PAL and WTF, so it is good for the two to be consistent. I 
> hope revisions along these lines can be considered in due course.

Indeed, some considerations relating to the Apple production build process led 
me to suggest that we avoid adding another subdirectory under Source. I believe 
that at some point in the future, those considerations will no longer hold. 
Even before then, while still keeping the PAL source code inside 
Source/WebCore, we should be able to take advantage of Xcode’s support for 
cross-project references and create a separate Xcode project for PAL (in a 
subdirectory of Source/WebCore), which will allow for better—or at least 
simpler—enforcement of the separation (and for an easier move to a top-level 
Source subdirectory in the future).

> 
> Regards,
> Maciej
> 
>> On Jan 11, 2017, at 3:30 PM, Olmstead, Don > > wrote:
>> 
>> I was the one who did the WebCore::PAL namespace so I wanted to chime in on 
>> why I went that route. We at Sony are newcomers to pushing to trunk so my 
>> explanation might be entirely too idealistic but here goes.
>>  
>> I had thought of PAL as a library that is internal to WebCore that provides 
>> a clear porting layer. I would not expect anyone outside of WebCore to be 
>> linking to it. Because of that it was living inside Source/WebCore, and 
>> since it was setup that way having an internal namespace of WebCore::PAL 
>> made sense conceptually. Also in the future if PAL was successful I could 
>> see a WebKit2 equivalent.
>>  
>> Whatever the consensus is we’re looking forward to working on getting the 
>> PAL layer up and running. We’re working on rebooting our port so we’re in a 
>> good position to help build it out and do any refactoring to help create a 
>> clear layering. Having a clear porting layer, especially one with tests, is 
>> something we’re hoping will be beneficial to all the ports.
>>  
>> From: webkit-dev-boun...@lists.webkit.org 
>>  
>> [mailto:webkit-dev-boun...@lists.webkit.org 
>> ] On Behalf Of Maciej Stachowiak
>> Sent: Wednesday, January 11, 2017 2:05 PM
>> To: Antti Koivisto >
>> Cc: Webkit Development List > >; mrobin...@igalia.com 
>> 
>> Subject: Re: [webkit-dev] WebCore/platform standalone library
>>  
>>  
>> These both sound right to me. 
>>  
>> More generally, I would expect that over time, PAL would likely become a 
>> peer project to WebCore instead of being inside it, much the same way WTF 
>> started inside JavaScriptCore and eventually moved outside it in the source 
>> tree. In the WTF case, it always had a separate top-level namespace.
>>  
>> On Jan 11, 2017, at 12:27 PM, Antti Koivisto > > wrote:
>>  
>> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
>> top-level namespace (even if it currently happens to live in the WebCore 
>> project)?
>>  
>> #include  would be more consistent with existing headers than 
>> .
>>  
>>  
>>   antti
>>  
>> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield > > wrote:
>> After 18 months of no progress, Don Olmstead and I are getting the band back 
>> together!
>>  
>> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
>>  which incorporates feedback 
>> from many different stakeholders (and as such, the direction is a little 
>> different than where I was going with this in the beginning).
>>  
>> First of all, this isn’t a new project; instead, it’s a new target inside 
>> the WebCore project. The target creates a static library which gets linked 
>> into WebCore, which means that the enforcement mechanism can’t be done by 
>> the linker. Instead, the layering will be enforced by a Python script, 
>> triggered as an extra build step, which checks the symbol names inside the 
>> .a file as well as #include directives in source code.
>>  
>> We opted for WebCore to include files using “#include ” instead 
>> of just including Foo.h. Similarly, we are putting symbols inside the PAL 
>> namespace, which is a child of the WebCore namespace. Therefore, inside 
>> WebCore, you use PAL things by specifying “PAL::Foo”.
>>  
>> The first thing to move into PAL is the “crypto” subfolder, which is a good 
>> candidate because it’s small, simple, yet also has 

[webkit-dev] Unable to log in to bugs.webkit.org

[Dan Bernstein]

Can someone help me log in to by bugs.webkit.org  
account?

I logged out of bugs.webkit.org  and now when I try to 
log in with my email m...@webkit.org, an error message appears saying that I 
must request a new password. When I click the “request a new password” link, I 
receive two email messages in rapid succession. The first one includes a 
password change link. The second one says that the password change  has been 
canceled because I requested cancellation. After that, the link from the first 
email is useless.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] !!Tests for equality comparison

[Dan Bernstein]

> On Apr 27, 2017, at 4:36 PM, Geoffrey Garen  wrote:
> 
>>> On Apr 27, 2017, at 16:30, Geoffrey Garen >> > wrote:
>>> 
>>> I’ve never really liked this style rule, and I’ve always felt like it snuck 
>>> into the style document without much discussion.
>> 
>> It date from 2009: https://bugs.webkit.org/show_bug.cgi?id=27333 
>> 
> This is just a rote copy of the the pre-existing rule, which was recorded by 
> a website check-in. I don’t have enough svn foo to make it past our website 
> reorganization and find that check-in.

As far as I can tell, the guideline first appeared on the website here 

 in 2006, even though the change log claimed that it was only a layout change.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename LayoutTests

[Dan Bernstein]

> On May 9, 2017, at 10:23 PM, Maciej Stachowiak  wrote:
> 
>> JSTests, and
> 
> Could go under JavaScriptCore, since these by design don't test anything 
> outside of JavaScriptCore.

There is an advantage to Apple’s internal production build system in keeping 
large amounts of test content out of projects’ source directories (which is why 
we moved it out of JavaScriptCore in 
https://bugs.webkit.org/show_bug.cgi?id=160180 
), but if that’s the preferred 
directory layout, then we can make some project changes to accommodate the 
aforementioned build system.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev