[webkit-dev] Running webkit tests on windows
I've been trying to get the webkit tests running on windows...I'm pretty close
and a lot of the tests are passing however, it looks like I have a problem with
several at the moment because of what I think may be an issue with fonts.
I've followed the directions for getting fonts at
http://trac.webkit.org/wiki/BuildingOnWindows (which seems to have an issue
because the ttc files don't quite decompress the Lucida Grande mac ttc file for
me; so I had to get it from somewhere else). I'm not sure if this is my
problem though; but I do have Lucida Grande and Lucida Grande Bold fonts (just
not the ones from my mac). I've stepped through the DumpRenderTree code and
I've seen it register all the fonts successfully in
WebTextRenderer::registerPrivateFont and it seems to be ok.
However, when I run the tests it seems to fail for the sans-serif font areas.
Here's one of my failures below. Does someone know which font this test uses
for sans-serif and where I can get it from since I'm guessing I have the wrong
one.
Is there some way to know which fonts are used in text runs or is there a good
breakpoint I can set somewhere to figure this out?
e.g. this line shows a different width for the text run:
- text run at (0,3) width 348: This element should be in a sans-serif
font.
+ text run at (0,3) width 375: This element should be in a sans-serif
font.
Here's my full test failure for css1/font_properties/font.html
--- /tmp/layout-test-results/css1/font_properties/font-expected.txt
2010-04-07 17:31:03.720919800 -0700
+++ /tmp/layout-test-results/css1/font_properties/font-actual.txt 2010-04-07
17:31:03.720919800 -0700
@@ -48,12 +48,12 @@
text run at (423,29) width 297: Extra text is included for the
purposes of
text run at (0,56) width 208: testing this more effectively.
RenderBlock {P} at (0,388) size 769x81
-RenderText {#text} at (0,3) size 760x75
- text run at (0,3) width 348: This element should be in a sans-serif
font.
- text run at (348,3) width 412: Its font-size should be 150% the
base font size, and
- text run at (0,30) width 568: its line-height should 150% of that
value (18px and 27px, respectively).
- text run at (568,30) width 192: Extra text is included for
- text run at (0,57) width 351: the purposes of testing this more
effectively.
+RenderText {#text} at (0,3) size 734x75
+ text run at (0,3) width 375: This element should be in a sans-serif
font.
+ text run at (375,3) width 358: Its font-size should be 150% the
base font
+ text run at (0,30) width 689: size, and its line-height should 150%
of that value (18px and 27px, respectively).
+ text run at (689,30) width 45: Extra
+ text run at (0,57) width 548: text is included for the purposes of
testing this more effectively.
RenderBlock {P} at (0,487) size 769x78
RenderText {#text} at (0,2) size 762x47
text run at (0,2) width 628: This element should be in a cursive
font, 'small' in size, with a line-height 200% the height of the text's actual
size.
@@ -106,10 +106,11 @@
text run at (176,79) width 500: Extra text is included for the
purposes of testing this more
text run at (0,115) width 93: effectively.
RenderBlock {P} at (0,1519) size 769x50
-RenderText {#text} at (0,6) size 751x37
- text run at (0,6) width 301: This element should be in a sans-serif
font, with a weight of 400.
- text run at (301,6) width 450: Its font-size should be 80% of 12px,
or 10px, and its line-height shoud be 2.5 times that, or 25px.
- text run at (0,31) width 318: Extra text is included for the
purposes of testing this more effectively.
+RenderText {#text} at (0,6) size 756x37
+ text run at (0,6) width 317: This element should be in a sans-serif
font, with a weight of 400.
+ text run at (317,6) width 439: Its font-size should be 80% of 12px,
or 10px, and its line-height shoud be 2.5 times that, or
+ text run at (0,31) width 30: 25px.
+ text run at (30,31) width 341: Extra text is included for the
purposes of testing this more effectively.
RenderBlock {P} at (0,1587) size 769x216
RenderInline {SPAN} at (0,0) size 765x183 [bgcolor=#C0C0C0]
RenderText {#text} at (0,16) size 765x183
@@ -148,13 +149,13 @@
text run at (138,76) width 563: Extra text is included for
the purposes of testing this more
text run at (0,112) width 111: effectively.
RenderBlock {P} at (4,269) size 747x144
-RenderText {#text} at (0,4) size 733x136
- text run at (0,4) width 461: This element should be in a
sans-serif font.
- text run at (461,4) width 232: Its font-size should be
-
Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore
On 08.04.2010, at 1:16, o...@webkit.org wrote: +// [Qt]r57240 broke Qt build (might be a gcc bug) +// FIXME! See: https://bugs.webkit.org/show_bug.cgi?id=37253 FIXME! is different from FIXME: in that Xcode doesn't recognize it. I'm surprised that style guide doesn't say anything about FIXME vs. TODO. But I'm not sure if a comment was even needed here - the ugliness of nested #ifs shouts the same. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore
On Thu, Apr 8, 2010 at 5:59 PM, Alexey Proskuryakov a...@webkit.org wrote: On 08.04.2010, at 1:16, o...@webkit.org wrote: + // [Qt]r57240 broke Qt build (might be a gcc bug) + // FIXME! See: https://bugs.webkit.org/show_bug.cgi?id=37253 FIXME! is different from FIXME: in that Xcode doesn't recognize it. I wasn't even aware that Xcode did recognize it or that we used that convention because it does. We should probably document this somewhere. I'm surprised that style guide doesn't say anything about FIXME vs. TODO. What do you mean? Are you suggesting that we should be using both and for different purposes? But I'm not sure if a comment was even needed here - the ugliness of nested #ifs shouts the same. - WBR, Alexey Proskuryakov ___ 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] Let's get the Windows test bots green!
I filed an umbrella bug to track all known issues with the Windows test bots: https://bugs.webkit.org/show_bug.cgi?id=37284. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore
On 08.04.2010, at 10:21, Jeremy Orlow wrote: I wasn't even aware that Xcode did recognize it or that we used that convention because it does. We should probably document this somewhere. I don't know if that's the original or only reason. Just something I noticed on my own at some point, and thought it was a sufficiently good explanation. I'm surprised that style guide doesn't say anything about FIXME vs. TODO. What do you mean? Are you suggesting that we should be using both and for different purposes? Sorry for being unclear. I meant that coding style guidelines should document always using FIXME. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore
On Apr 8, 2010, at 11:18 AM, Alexey Proskuryakov wrote: On 08.04.2010, at 10:21, Jeremy Orlow wrote: I wasn't even aware that Xcode did recognize it or that we used that convention because it does. We should probably document this somewhere. I don't know if that's the original or only reason. Just something I noticed on my own at some point, and thought it was a sufficiently good explanation. I'm surprised that style guide doesn't say anything about FIXME vs. TODO. What do you mean? Are you suggesting that we should be using both and for different purposes? Sorry for being unclear. I meant that coding style guidelines should document always using FIXME. That seems like a good change to the guidelines. Specifically FIXME: as a prefix, with discouragement of TODO or XXX or other such formats. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Announcing WebKit2
Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Thu, Apr 8, 2010 at 3:01 PM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Please, please consider making every call non-block, particularly those that requires interaction with user, avoiding nested main loops and bugs that come from these[1]. For instance, these could call user that is later responsible to call another function, providing the continuation based on some shared token/context. [1] https://lists.webkit.org/pipermail/webkit-dev/2010-March/011845.html -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Thu, Apr 8, 2010 at 4:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Apr 8, 2010 at 3:01 PM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Please, please consider making every call non-block, particularly those that requires interaction with user, avoiding nested main loops and bugs that come from these[1]. For instance, these could call user that is later responsible to call another function, providing the continuation based on some shared token/context. As noted in the linked Wiki document, the intent is to create a completely non-blocking API. That is one of our biggest motivations in pursuing this project. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 1:01 AM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? Cheers, Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. As I understand it, the goal is to have a C API that is suitable and works well cross platform for all the many platform independent operations; it is indeed analogous the one for JavaScriptCore in that respect. When you refer to a “selling point” of WebKit ports, I assume you are referring to how those ports integrate with the surrounding OS and frameworks. For example, the Mac OS X port provides an Objective-C API that fits in well with the rest of Cocoa. The goal would be that such API can be cleanly built on top of the C-based API and should offer a simple way to “drop down” to the platform independent C one and vice versa. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. It will be available as a public API, but as Darin explained, it's up to individual ports whether to wrap this API, expose it directly, or do some combination. For the Mac OS X API, we will be doing a combination. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? No WebCore changes are required - it works with the existing WebCore. - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? I think that would be up to the individual ports. We expect that on Mac OS X, we will have to support the classic WebKit API for a long time, perhaps indefinitely, in parallel with the new WebKit2-based API. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 2:52 AM, Darin Adler da...@apple.com wrote: As I understand it, the goal is to have a C API that is suitable and works well cross platform for all the many platform independent operations; it is indeed analogous the one for JavaScriptCore in that respect. When you refer to a “selling point” of WebKit ports, I assume you are referring to how those ports integrate with the surrounding OS and frameworks. For example, the Mac OS X port provides an Objective-C API that fits in well with the rest of Cocoa. The goal would be that such API can be cleanly built on top of the C-based API and should offer a simple way to “drop down” to the platform independent C one and vice versa. I see, so the answer is both, kinda. Interesting. Having a stable API for embedders to use to build their native APIs on top would certainly ease the lives of port maintainers, and using those stable APIs in the situations where it makes sense to use them can certainly be a good idea. Interesting choices for all of us ahead :) Xan -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
If its in a separate process, does Accessibility still work as expected? On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ 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] Announcing WebKit2
Hi, Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? Cheers, Adam On Thursday 08 April 2010 08:58:22 pm Maciej Stachowiak wrote: On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. It will be available as a public API, but as Darin explained, it's up to individual ports whether to wrap this API, expose it directly, or do some combination. For the Mac OS X API, we will be doing a combination. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? No WebCore changes are required - it works with the existing WebCore. - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? I think that would be up to the individual ports. We expect that on Mac OS X, we will have to support the classic WebKit API for a long time, perhaps indefinitely, in parallel with the new WebKit2-based API. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 8, 2010, at 6:19 PM, Chris Fleizach wrote: If its in a separate process, does Accessibility still work as expected? It does not yet work in this rough initial version, but it's certainly our intent to make it work. Cheers, Maciej On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ 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] Announcing WebKit2
Great. I think Google chrome has taken a similar approach and have had trouble making accessibility work because of the inter-process separation, so when we come up with a solution, maybe they can adopt as well. On Apr 8, 2010, at 6:30 PM, Maciej Stachowiak wrote: On Apr 8, 2010, at 6:19 PM, Chris Fleizach wrote: If its in a separate process, does Accessibility still work as expected? It does not yet work in this rough initial version, but it's certainly our intent to make it work. Cheers, Maciej On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ 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] Announcing WebKit2
On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Hi, On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. Awesome! I can't wait to see the patches. Is there a top-level bug I can subscribe to to keep track? -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
