Xianzhu Wang | 1 Aug 02:33 2010
Picon

Re: About fixing "old" layout bugs

Hi,


Now the status of the three old bugs are:
* white space preceding <br> (https://bugs.webkit.org/show_bug.cgi?id=37261): New patches uploaded
* relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413): New patches uploaded
* line breaking around some punctuations (https://bugs.webkit.org/show_bug.cgi?id=37698): Fixed

For the <br> bug, I still split the patch into following parts to ease review:
1. A patch containing only the changed code and the added test;
2. A patch containing all affected text-only layout tests that differ only about trailing spaces;
3. A patch containing all affected DRT layout tests that differ only about trailing spaces of text rendering nodes;
4. A patch containing other layout tests that have been manually adjusted;
5. A patch containing changed Skipped files of other platforms.

The above 2 and 3 were auto generated by scripts. And instead of rebaslining tests of other platforms, I simply (temporarily) added the affected tests into Skipped files. I used the similar method to generate the patch for the second bug but didn't split it because the patch is much smaller. The patches also don't contain pixel tests to reduce the scope and size.

Because of rapid changes of affected layout tests, the patches had already been out-dated even before I uploaded them. It seems to me that the normal process of review queue and commit queue doesn't work for such patches. Would any committer please help review and maybe commit the patches?

Thanks,
Xianzhu

2010/6/2 Xianzhu Wang <phnixwxz <at> gmail.com>
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)
  * 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 <br>s 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? Are these bugs worth fixing?

2. What's the best practice to deal with a patche containing many updated layout test expectations? Is there a good way to rebaseline the effected tests on all platforms?

Thanks,
Xianzhu


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Alexey Proskuryakov | 2 Aug 13:28 2010

Re: Name nitpick: "layout tests"


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.

- WBR, Alexey Proskuryakov

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Steve Block | 2 Aug 13:35 2010
Picon

Re: Sharing WebKit mocks across platforms

I'd be happy to help where I can too, and can migrate the existing
Geolocation/DeviceOrientation/SpeechInput mocks to use the new
pattern. Please CC me on any bugs you create.

Steve
Alexey Proskuryakov | 2 Aug 13:38 2010

Re: Sharing WebKit mocks across platforms


29.07.2010, в 8:16, Adam Barth написал(а):

> Plumbing this mock API all the way through WebKit for each port seems like a waste.

One benefit of this is that it makes us test the API layer. Another one is that it gives WebKit developers
better familiarity with APIs - that's not as minor as it sounds, as some of us (including myself) have
limited knowledge of WebKit APIs, even for their favorite platform.

It certainly seems like a waste when private methods are added just for DumpRenderTree support. But maybe
it has prompted an API introduction a few times before, I just don't know.

This is all getting much better with WebKit2's cross-platform API, although of course we'll need to
support current APIs for a long time.

- WBR, Alexey Proskuryakov

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Shinichiro Hamaji | 2 Aug 14:40 2010

Re: Printer font is different from screen font

Thanks for your feedbacks!

I did a few experiments before my email post but I forgot to mention about it. Sorry that my first post was not so specific :( Now I've done a few more experiments. Let me explain what I've seen so far.

* The issue

The example HTML in question is


Here is a screenshot for this HTML on my Mac OSX 10.5:


And this is the printed image for this HTML:


Though this screenshot was taken from its print preview, I confirmed that this result agrees with the paper my HP printer produced.

You can see line wrappings are inconsistent between them. On the screen, the first line wraps after the word "tempor", but with the printer, the first line wraps after "eiusmod".

* Experiments

I created a super simple patch with which we always uses the screen font even for printing. The patch is

diff --git a/WebCore/platform/graphics/FontDescription.h b/WebCore/platform/grap
hics/FontDescription.h
index 86a4349..3ef4e85 100644
--- a/WebCore/platform/graphics/FontDescription.h
+++ b/WebCore/platform/graphics/FontDescription.h
<at> <at> -84,7 +84,8 <at> <at> public:
     FontWeight lighterWeight() const;
     FontWeight bolderWeight() const;
     GenericFamilyType genericFamily() const { return static_cast<GenericFamilyType>(m_genericFamily); }
-    bool usePrinterFont() const { return m_usePrinterFont; }
+    //bool usePrinterFont() const { return m_usePrinterFont; }
+    bool usePrinterFont() const { return false; }
     // only use fixed default size when there is only one font family, and that family is "monospace"
     bool useFixedDefaultSize() const { return genericFamily() == MonospaceFamily && !family().next() && family().family() == "-webkit-monospace"; }
     FontRenderingMode renderingMode() const { return static_cast<FontRenderingMode>(m_renderingMode); }

I printed the example HTML with this modification using my HP printer and this time the print result agreed with the screen. I also printed the document, changing scale smaller and bigger. The results of both attempts were OK. I also printed Apple's top page and again the result was fine. I did these experiments just with one printer so other printers would stop working with this change.

I also created another simple patch with which WebKit always uses printer fonts. I checked a dozen of random websites and didn't see something broken. I printed the example HTML and of course the printed result agreed with the screen.

Please let me know if there are something I should check.

Thanks!

On Sat, Jul 31, 2010 at 3:27 AM, Darin Adler <darin <at> apple.com> wrote:
On Jul 30, 2010, at 2:10 AM, Shinichiro Hamaji wrote:

> I've noticed WebKit uses slightly different font size for printing on Mac.

We should discuss specifics instead of this broad issue. There’s a good chance this is something that has been misdiagnosed.

> My colleague told me Mac's font API has a feature to select the best font for printing.

Your colleague may be talking about the -[NSFont printerFont] method. That method is used to select a font that is supported for printing. It is not optimizing for printing, but rather must be used to guarantee that WebKit doesn’t try to use a font for printing that is incompatible with the printing machinery.

The documentation for this is at <http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/instm/NSFont/printerFont>.

> This feature isn't good for a team in Google because they want exactly same results between screen and printing.

We’ll have to discuss a specific example.

You could test this by modifying your copy of WebKit to turn bypass the calls to the printerFont method in FontCacheMac.mm, FontMac.mm, and SimpleFontDataMac.mm. If you get your improved results from that we can continue the discussion. I think it’s more likely you will find that printing doesn’t work any more.

Before we start discussing adding features and modes to control this behavior you should do the experiment to see if this would do something helpful.

   -- Darin


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Dan Bernstein | 2 Aug 16:33 2010
Picon

Re: Name nitpick: "layout tests"


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 <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Darin Fisher | 2 Aug 18:40 2010

Re: Name nitpick: "layout tests"

On Mon, Aug 2, 2010 at 7:33 AM, Dan Bernstein <mitz <at> apple.com> wrote:

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

That sounds like a vote for RegressionTests

-Darin
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Eric Seidel | 2 Aug 19:46 2010

commit-queue switching to Snow Leopard this week

- CQ will block on the SL Release builder
- CQ will test on SL Release before committing.

Most users shouldn't notice or care.

Email me if you have questions.

-eric
Adam Roben | 2 Aug 20:12 2010
Picon

Safari for Windows symbol server updated

The Safari for Windows symbol server has been updated with symbols for all releases through Safari 5.0.1.

You can find instructions for using the symbol server at <http://developer.apple.com/internet/safari/windows_symbols_agree.html>.

-Adam
Tony Gentilcore | 2 Aug 20:56 2010

Updating the tradition for new reviewer blog posts

The Surfin' Safari blog seems to have fairly wide readership in the web dev community. Google Reader reports 35k Reader subscribers. For comparison: blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last post with descriptive content was back on April 18th. Since that post, we've written 8 "X is a now a WebKit reviewer" posts. One recent commenter said:


"I don’t suppose there’s anything more interesting going on in WebKit land worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t nearly as interesting as whatever new hotness is coming down the pipe. And I know I’m not the only one who thinks so… Feel like blogging about WebKit awesomeness?"

I propose we increase the amount of blogging about WebKit awesomeness by changing the tradition for new reviewer posts.

Instead of defaulting to:

  So-and-so is now a WebKit reviewer
  Posted by Someone-else
  So-and-so has worked on awesome-feature or awesome-infrastructure...

We encourage (or just allow?) a format more like:

  How awesome-infrastructure works
  Posted by So-and-so, the latest WebKit reviewer
  Here's my description of how awesome-infrastructure works in WebKit...

  -OR-

  Awesome-feature is the new hotness
  Posted by So-and-so, the latest WebKit reviewer
  Web developers can now use awesome-feature. Here's how it works...

Thoughts?

-Tony
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Gmane