Bug 75091

Summary: [SVG] Text does not show after scripted scaling.
Product: WebKit Reporter: Branimir Lambov <blambov>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: bashi, dbates, dglazkov, krit, macpherson, menard, pdr, thorton, tim_webkit, webkit.review.bot, zimmermann
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 81217    
Attachments:
Description Flags
Testcase
none
foreignObject test
none
Use CSS smart font minimums for SVG font minimums
zimmermann: review-, webkit.review.bot: commit-queue-
Rough cut at properly calculating font metrics when scale changes.
none
Updated patch per reviewer comments
webkit.review.bot: commit-queue-
Update per reviewer comments (fixed several bugs, added support for SVGViewportContainer)
none
Fix trivial mistake in previous patch.
none
Rebase for bot happiness
webkit.review.bot: commit-queue-
Patch
webkit.review.bot: commit-queue-
Add skipped tests that need to be rebaselined and add mac results
webkit.review.bot: commit-queue-
Update expectations for bot happiness
none
Remove spurious mac tests none

Description Branimir Lambov 2011-12-22 08:50:42 PST
Created attachment 120327 [details]
Testcase

In the attached SVG text is initially drawn with scale 0.0001, and then changed by a script to scale 1. The text does not show up. The same happens if the text is animated to zoom in, where the initial appearance is at invisibly small scale. If the scale is 0, the problem does not happen.

The text appears if one forces refresh manually (e.g. by zooming in/out).

The test works properly in Firefox 8 and Opera 11.6.
Comment 1 Branimir Lambov 2011-12-23 03:30:44 PST
Created attachment 120450 [details]
foreignObject test

The same happens with text in foreignObject.
Comment 2 Philip Rogers 2012-02-12 17:06:20 PST
Created attachment 126691 [details]
Use CSS smart font minimums for SVG font minimums
Comment 3 WebKit Review Bot 2012-02-12 18:46:22 PST
Comment on attachment 126691 [details]
Use CSS smart font minimums for SVG font minimums

Attachment 126691 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11506617

New failing tests:
svg/custom/text-tref-03-b-change-href-dom.svg
svg/custom/text-tref-03-b-tref-removal.svg
svg/custom/tref-own-content-removal.svg
svg/carto.net/window.svg
svg/text/scaled-font.svg
svg/zoom/page/zoom-svg-through-object-with-absolute-size.xhtml
svg/custom/text-tref-03-b-change-href.svg
svg/W3C-SVG-1.1/metadata-example-01-b.svg
svg/zoom/page/zoom-svg-through-object-with-absolute-size-2.xhtml
Comment 4 Nikolas Zimmermann 2012-02-13 08:56:44 PST
Comment on attachment 126691 [details]
Use CSS smart font minimums for SVG font minimums

View in context: https://bugs.webkit.org/attachment.cgi?id=126691&action=review

> Source/WebCore/ChangeLog:9
> +        computeNewScaledFontForStyle did not use smart minimums for fonts,
> +        resulting in fonts being rendered with very small sizes (eg, 0.001).

Can you elaborate a bit? I'm not sure I understand fully yet.
RenderSVGInlineText should always request "absolute, scaled-up font sizes" in the on screen coordinate system.
eg for <svg viewBox="0 0 1 1" width="400" height="400"><font size="0.5" it'll request a font-size with 200px, not with 0.5.

I'm trying to understand why we still get into the case where we request tiny font sizes like this.

> LayoutTests/svg/text/text-rescale.html:4
> +<!-- Test that a script can change the scale of text from very small to something visible -->
> +<!-- https://bugs.webkit.org/show_bug.cgi?id=75091 -->

You should include fast/repaint/resources/repaint.js here, and use

> LayoutTests/svg/text/text-rescale.html:6
> +<body>

<body onload="runRepaintTest()"> to guarantee the initial painting happened.

> LayoutTests/svg/text/text-rescale.html:13
> +    function rescale() {

rename this to function repaintTest() { it will then get called by runRepaintTest, once painting is done.

> LayoutTests/svg/text/text-rescale.html:23
> +        if (window.layoutTestController)
> +            layoutTestController.notifyDone();

This can be removed.

> LayoutTests/svg/text/text-rescale.html:31
> +        layoutTestController.waitUntilDone();
> +    }
> +
> +    setTimeout(function() { rescale(); }, 1);

Ditto.
Comment 5 Philip Rogers 2012-02-13 12:38:22 PST
(In reply to comment #4)
> (From update of attachment 126691 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=126691&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        computeNewScaledFontForStyle did not use smart minimums for fonts,
> > +        resulting in fonts being rendered with very small sizes (eg, 0.001).
> 
> Can you elaborate a bit? I'm not sure I understand fully yet.
> RenderSVGInlineText should always request "absolute, scaled-up font sizes" in the on screen coordinate system.
> eg for <svg viewBox="0 0 1 1" width="400" height="400"><font size="0.5" it'll request a font-size with 200px, not with 0.5.
> 
> I'm trying to understand why we still get into the case where we request tiny font sizes like this.

We get into this case in situations like the following:
<g id="scale" transform="scale(0.0001)" opacity="1">
  <text x="10" y="50" font-size="40">***</text>
</g>
This essentially has an "on-screen" font size of 0.0001*40 = 0.004. This patch avoids this degenerate case of a 0.004 font size. Instead of rendering with 0.004, this patch says to use some smart minimum (say, 5) and adjust the scale factor appropriately. I don't particularly like using the CSS smart font minimum, but checking if the font size is less than some constant doesn't seem like a good idea. Any ideas here?

It seems to me that almost any way it's implemented seems to be okay with the spec, which seems to imply to use CSS rules:
http://www.w3.org/TR/SVG/text.html#FontSizeProperty
Comment 6 Philip Rogers 2012-02-13 12:39:42 PST
I'm not happy with the FIXME on line 212 of this patch and I'm going to work on fixing that in this patch after all, as well as updating per Niko's other comments. Updated patch forthcoming!
Comment 7 Philip Rogers 2012-02-15 14:21:13 PST
Created attachment 127235 [details]
Rough cut at properly calculating font metrics when scale changes.

Note: I need at least another test, and this still contains a FIXME in RenderSVGInlineText that needs addressing.
Comment 8 Nikolas Zimmermann 2012-02-15 15:08:17 PST
Comment on attachment 127235 [details]
Rough cut at properly calculating font metrics when scale changes.

View in context: https://bugs.webkit.org/attachment.cgi?id=127235&action=review

Pre-review: Very interesting patch, looking forward to the next version :-)

> Source/WebCore/css/CSSStyleSelector.h:-38
> -enum ESmartMinimumForFontSize { DoNotUseSmartMinimumForFontSize, UseSmartMinimumForFontFize };

You could land this separated, but it's not a must :-)

> Source/WebCore/rendering/svg/RenderSVGTransformableContainer.cpp:42
>  
> +bool RenderSVGTransformableContainer::transformToRootChanged()
> +{
> +    RenderObject* ancestor = parent();

Interessting approach, though very differently from what we do for eg. setNeedsBoundariesUpdate.

void RenderObject::setNeedsBoundariesUpdate()
{
    if (RenderObject* renderer = parent())
        renderer->setNeedsBoundariesUpdate();
}

We could implement setTransformToRootChanged the same way. Default impl: pass to parent, and in RenderSVGTransformableContainer::setTransformToRootChanged, you can set it to true. Then just look at each place where we call setNeedsTransformUpdate, and also call setTransformToRootChanged, to make sure each ancestor is notified about the change. That would avoid the need to crawl the tree again when doing layout(), as it's already done eg. from SVGStyedTransformableElement::svgAttributeChanged, if 'transform' changed. (Of course there are more places, just an example).

What do you think?

> Source/WebCore/rendering/svg/SVGRenderSupport.cpp:249
> +static inline bool transformToRootChanged(RenderObject* start)

You probably want to share this in eg. SVGRenderSupport, or a more specific class.

> LayoutTests/svg/text/text-rescale.html:20
> +    function runRepaintTest() {

This function needs to be named repaintTest(), otherwise you're overriding the function from repaint.js.
You're currently not using layoutTestController.display() at all - you're not tracking repainting, thus no grey rect is painted over the view after the initial painting.
Using reftests together with repaint tests, thus doensn't make much sense, otherwise you'd need to paint the gray overlay rects and white highlight rects yourself in the expected.html file!

I'd advice to make this a pixel test using repaint.js only, and not make it a reftest. Whenever we want to test repainting reliable, this is the way to go.
For any static testcase reftests are the way to go in the future.

> LayoutTests/svg/text/text-rescale.html:22
> +        if (window.layoutTestController)
> +            layoutTestController.waitUntilDone();

This is not needed anymore, once you fix the repaintTest() name clash.

> LayoutTests/svg/text/text-rescale.html:30
> +            if (window.layoutTestController)
> +                layoutTestController.notifyDone();
> +        }, 1);

Ditto.
Comment 9 Philip Rogers 2012-02-16 06:55:37 PST
Created attachment 127371 [details]
Updated patch per reviewer comments
Comment 10 Philip Rogers 2012-02-16 07:12:24 PST
(In reply to comment #8)
> (From update of attachment 127235 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=127235&action=review
> 
> Pre-review: Very interesting patch, looking forward to the next version :-)
> 
> > Source/WebCore/css/CSSStyleSelector.h:-38
> > -enum ESmartMinimumForFontSize { DoNotUseSmartMinimumForFontSize, UseSmartMinimumForFontFize };
> 
> You could land this separated, but it's not a must :-)

Removed :)

> > Source/WebCore/rendering/svg/RenderSVGTransformableContainer.cpp:42
> >  
> > +bool RenderSVGTransformableContainer::transformToRootChanged()
> > +{
> > +    RenderObject* ancestor = parent();
> 
> Interessting approach, though very differently from what we do for eg. setNeedsBoundariesUpdate.
> 
> void RenderObject::setNeedsBoundariesUpdate()
> {
>     if (RenderObject* renderer = parent())
>         renderer->setNeedsBoundariesUpdate();
> }
> 
> We could implement setTransformToRootChanged the same way. Default impl: pass to parent, and in RenderSVGTransformableContainer::setTransformToRootChanged, you can set it to true. Then just look at each place where we call setNeedsTransformUpdate, and also call setTransformToRootChanged, to make sure each ancestor is notified about the change. That would avoid the need to crawl the tree again when doing layout(), as it's already done eg. from SVGStyedTransformableElement::svgAttributeChanged, if 'transform' changed. (Of course there are more places, just an example).
> 
> What do you think?

I think the transform case is sufficiently different because it is the case where the child nodes need to know information from their ancestors, whereas setBoundariesUpdate() is for notifying ancestors of changes in the children.

The core issue is that global transform changes do not currently propagate down to children, because for most children this does not matter. For text metrics though, it does. There is one other class of renderers that relies on calculateTransformationToOutermostSVGCoordinateSystem: filters/etc, and they handle this by always updating on layout via SVGResourcesCache::clientLayoutChanged().

I talked with schenney at some length about the approach I took here and we boiled the options down to:
1) When the outer transform changes, all children can be notified by adding a boolean to every container.
2) When the outer transform changes, we can store that in the transform container and children can query it by walking back up the tree.

I think it's somewhat of a toss-up in terms of performance between needlessly propagating this transform change notification down the tree versus having to crawl back up in some cases. In this patch I took approach #2 because I think it's likely that the unnecessary work in #1 is high, and I implemented a caching behavior at each transform container so that we only need to look at the text's parent in most cases.

What do you think?

> > Source/WebCore/rendering/svg/SVGRenderSupport.cpp:249
> > +static inline bool transformToRootChanged(RenderObject* start)
> 
> You probably want to share this in eg. SVGRenderSupport, or a more specific class.
D'Oh! Done :)

> > LayoutTests/svg/text/text-rescale.html:20
> > +    function runRepaintTest() {
> 
> This function needs to be named repaintTest(), otherwise you're overriding the function from repaint.js.
> You're currently not using layoutTestController.display() at all - you're not tracking repainting, thus no grey rect is painted over the view after the initial painting.
> Using reftests together with repaint tests, thus doensn't make much sense, otherwise you'd need to paint the gray overlay rects and white highlight rects yourself in the expected.html file!
> 
> I'd advice to make this a pixel test using repaint.js only, and not make it a reftest. Whenever we want to test repainting reliable, this is the way to go.
> For any static testcase reftests are the way to go in the future.
> 
> > LayoutTests/svg/text/text-rescale.html:22
> > +        if (window.layoutTestController)
> > +            layoutTestController.waitUntilDone();
> 
> This is not needed anymore, once you fix the repaintTest() name clash.
> 
> > LayoutTests/svg/text/text-rescale.html:30
> > +            if (window.layoutTestController)
> > +                layoutTestController.notifyDone();
> > +        }, 1);
> 
> Ditto.

I think I finally got this right, but can you check one more time? I also updated the test to test for the following:
1) Text in a transformed container
2) Tspan in text in a transformed container (as pointed out by Krit)
3) Text in a foreignobject
4) Text in a nested svg element
Comment 11 Nikolas Zimmermann 2012-02-16 08:11:01 PST
Comment on attachment 127371 [details]
Updated patch per reviewer comments

View in context: https://bugs.webkit.org/attachment.cgi?id=127371&action=review

> Source/WebCore/ChangeLog:7
> +

Needs a better ChangeLog! :-)

> Source/WebCore/rendering/svg/RenderSVGInlineText.cpp:255
> +

This can be omitted.

> Source/WebCore/rendering/svg/RenderSVGInlineText.cpp:272
> +    fontDescription.setComputedSize(CSSStyleSelector::getComputedSizeFromSpecifiedSize(document, scalingFactor, fontDescription.isAbsoluteSize(), fontDescription.computedSize(), DoNotUseSmartMinimumForFontSize));

Nothing changed here, why does it list it as change?

> Source/WebCore/rendering/svg/RenderSVGTransformableContainer.cpp:46
> +    m_didTransformToRootUpdate = m_needsTransformUpdate || SVGRenderSupport::transformToRootChanged(parent());

What if the viewBox of an inner <svg> changes? This viewBox transformation is handled in RenderSVGViewportContainer - which overrides calculateLocalTransform IIRC.
That would mean viewBox changes of inner <svg> elements, don't cause m_didTransformToRootUpdate to switch to true. Can you add/extend a test, and fix RenderSVGViewportContainer as well?

> Source/WebCore/rendering/svg/SVGRenderSupport.cpp:252
> +        if (ancestor->isSVGTransformableContainer()) {

Unneeded braces.

> Source/WebCore/rendering/svg/SVGRenderSupport.cpp:270
> +        if (transformChanged) {

You could add a small comment here, as it's done for layoutSizeChanged=true, as well.

> LayoutTests/svg/text/text-rescale.html:46
> +</svg>

I'd add another test that uses:
<svg> <svg id="inner" viewBox="0 0 100 100"><text y="0.3" x="0.3" font-size="0.1">Foo</text>.
And then script inner.viewBox to be 0 0 1 1 - that should lead to a recalculation of the text scaledFont, hopefully.
Comment 12 Nikolas Zimmermann 2012-02-16 08:11:06 PST
Comment on attachment 127371 [details]
Updated patch per reviewer comments

View in context: https://bugs.webkit.org/attachment.cgi?id=127371&action=review

> Source/WebCore/ChangeLog:7
> +

Needs a better ChangeLog! :-)

> Source/WebCore/rendering/svg/RenderSVGInlineText.cpp:255
> +

This can be omitted.

> Source/WebCore/rendering/svg/RenderSVGInlineText.cpp:272
> +    fontDescription.setComputedSize(CSSStyleSelector::getComputedSizeFromSpecifiedSize(document, scalingFactor, fontDescription.isAbsoluteSize(), fontDescription.computedSize(), DoNotUseSmartMinimumForFontSize));

Nothing changed here, why does it list it as change?

> Source/WebCore/rendering/svg/RenderSVGTransformableContainer.cpp:46
> +    m_didTransformToRootUpdate = m_needsTransformUpdate || SVGRenderSupport::transformToRootChanged(parent());

What if the viewBox of an inner <svg> changes? This viewBox transformation is handled in RenderSVGViewportContainer - which overrides calculateLocalTransform IIRC.
That would mean viewBox changes of inner <svg> elements, don't cause m_didTransformToRootUpdate to switch to true. Can you add/extend a test, and fix RenderSVGViewportContainer as well?

> Source/WebCore/rendering/svg/SVGRenderSupport.cpp:252
> +        if (ancestor->isSVGTransformableContainer()) {

Unneeded braces.

> Source/WebCore/rendering/svg/SVGRenderSupport.cpp:270
> +        if (transformChanged) {

You could add a small comment here, as it's done for layoutSizeChanged=true, as well.

> LayoutTests/svg/text/text-rescale.html:46
> +</svg>

I'd add another test that uses:
<svg> <svg id="inner" viewBox="0 0 100 100"><text y="0.3" x="0.3" font-size="0.1">Foo</text>.
And then script inner.viewBox to be 0 0 1 1 - that should lead to a recalculation of the text scaledFont, hopefully.
Comment 13 WebKit Review Bot 2012-02-16 08:37:17 PST
Comment on attachment 127371 [details]
Updated patch per reviewer comments

Attachment 127371 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11535214

New failing tests:
svg/carto.net/tabgroup.svg
svg/carto.net/window.svg
svg/custom/use-detach.svg
svg/custom/js-late-clipPath-and-object-creation.svg
svg/custom/js-late-gradient-and-object-creation.svg
svg/hixie/perf/003.xml
svg/custom/js-late-pattern-and-object-creation.svg
Comment 14 Philip Rogers 2012-02-16 12:47:29 PST
Created attachment 127430 [details]
Update per reviewer comments (fixed several bugs, added support for SVGViewportContainer)
Comment 15 Philip Rogers 2012-02-16 12:51:17 PST
(In reply to comment #12)
> (From update of attachment 127371 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=127371&action=review
> 
> > Source/WebCore/ChangeLog:7
> > +
> 
> Needs a better ChangeLog! :-)

Fixed

> 
> > Source/WebCore/rendering/svg/RenderSVGInlineText.cpp:255
> > +
> 
> This can be omitted.

Fixed

> 
> > Source/WebCore/rendering/svg/RenderSVGInlineText.cpp:272
> > +    fontDescription.setComputedSize(CSSStyleSelector::getComputedSizeFromSpecifiedSize(document, scalingFactor, fontDescription.isAbsoluteSize(), fontDescription.computedSize(), DoNotUseSmartMinimumForFontSize));
> 
> Nothing changed here, why does it list it as change?

Fixed (I think I had removed a tab)

> 
> > Source/WebCore/rendering/svg/RenderSVGTransformableContainer.cpp:46
> > +    m_didTransformToRootUpdate = m_needsTransformUpdate || SVGRenderSupport::transformToRootChanged(parent());
> 
> What if the viewBox of an inner <svg> changes? This viewBox transformation is handled in RenderSVGViewportContainer - which overrides calculateLocalTransform IIRC.
> That would mean viewBox changes of inner <svg> elements, don't cause m_didTransformToRootUpdate to switch to true. Can you add/extend a test, and fix RenderSVGViewportContainer as well?
> 
> > Source/WebCore/rendering/svg/SVGRenderSupport.cpp:252
> > +        if (ancestor->isSVGTransformableContainer()) {
> 
> Unneeded braces.

Fixed

> 
> > Source/WebCore/rendering/svg/SVGRenderSupport.cpp:270
> > +        if (transformChanged) {
> 
> You could add a small comment here, as it's done for layoutSizeChanged=true, as well.

Fixed

> 
> > LayoutTests/svg/text/text-rescale.html:46
> > +</svg>
> 
> I'd add another test that uses:
> <svg> <svg id="inner" viewBox="0 0 100 100"><text y="0.3" x="0.3" font-size="0.1">Foo</text>.
> And then script inner.viewBox to be 0 0 1 1 - that should lead to a recalculation of the text scaledFont, hopefully.

As usual, you were spot-on with the viewport issues. I added the same transform propagation support to SVGViewportContainer that SVGTransformableContainer has, and added the appropriate test (note: it failed before the patch, and now passes).
Comment 16 Philip Rogers 2012-02-16 13:00:06 PST
Created attachment 127432 [details]
Fix trivial mistake in previous patch.
Comment 17 Nikolas Zimmermann 2012-02-17 07:54:01 PST
Comment on attachment 127432 [details]
Fix trivial mistake in previous patch.

Looks great! I'd r+ if it would apply!
Comment 18 Philip Rogers 2012-02-17 08:38:31 PST
Created attachment 127595 [details]
Rebase for bot happiness
Comment 19 WebKit Review Bot 2012-02-17 12:09:41 PST
Comment on attachment 127595 [details]
Rebase for bot happiness

Attachment 127595 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11542445

New failing tests:
svg/custom/text-ctm.svg
svg/carto.net/window.svg
svg/custom/use-detach.svg
svg/custom/js-late-clipPath-and-object-creation.svg
svg/hixie/perf/003.xml
svg/carto.net/tabgroup.svg
svg/custom/js-late-gradient-and-object-creation.svg
svg/custom/js-late-pattern-and-object-creation.svg
Comment 20 Stephen Chenney 2012-02-22 07:26:04 PST
*** Bug 74003 has been marked as a duplicate of this bug. ***
Comment 21 Stephen Chenney 2012-02-22 12:22:50 PST
Created attachment 128263 [details]
Patch

Philip's patch with new mac expectations. Intended only for comparison, not commit.
Comment 22 WebKit Review Bot 2012-02-22 13:07:09 PST
Comment on attachment 128263 [details]
Patch

Attachment 128263 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11557624

New failing tests:
svg/carto.net/tabgroup.svg
svg/carto.net/window.svg
svg/text/text-rescale.html
svg/text/text-viewbox-rescale.html
svg/custom/use-detach.svg
svg/custom/js-late-clipPath-and-object-creation.svg
svg/hixie/perf/003.xml
svg/custom/text-ctm.svg
svg/custom/js-late-gradient-and-object-creation.svg
svg/custom/js-late-pattern-and-object-creation.svg
Comment 23 Philip Rogers 2012-02-22 14:44:51 PST
Created attachment 128293 [details]
Add skipped tests that need to be rebaselined and add mac results
Comment 24 WebKit Review Bot 2012-02-22 15:49:03 PST
Comment on attachment 128293 [details]
Add skipped tests that need to be rebaselined and add mac results

Attachment 128293 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11574008

New failing tests:
svg/text/text-rescale.html
svg/text/text-viewbox-rescale.html
Comment 25 Philip Rogers 2012-02-23 06:51:08 PST
Created attachment 128475 [details]
Update expectations for bot happiness
Comment 26 Nikolas Zimmermann 2012-02-23 07:13:42 PST
Comment on attachment 128475 [details]
Update expectations for bot happiness

Great job, r=me!
Comment 27 WebKit Review Bot 2012-02-23 16:52:20 PST
Comment on attachment 128475 [details]
Update expectations for bot happiness

Clearing flags on attachment: 128475

Committed r108699: <http://trac.webkit.org/changeset/108699>
Comment 28 WebKit Review Bot 2012-02-23 16:52:27 PST
All reviewed patches have been landed.  Closing bug.
Comment 29 Kenichi Ishibashi 2012-02-23 20:08:45 PST
I fixed wrong path of repaint.js in tests.
http://trac.webkit.org/changeset/108720
Comment 30 Nikolas Zimmermann 2012-02-24 02:28:01 PST
(In reply to comment #29)
> I fixed wrong path of repaint.js in tests.
> http://trac.webkit.org/changeset/108720

http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/svg/text/text-rescale.html?rev=108720 ??
Why are tests now in platform/mac/svg/text as well? I must have overlooked this in the review.
I guess this is an error, and " 18        * platform/mac/svg/text/text-viewbox-rescale.html: Added." shall be removed.

Reopening bug (Need to set to UNCONFIRMED, it doesn't let me reopen it, weird).
Comment 31 Philip Rogers 2012-02-24 07:10:36 PST
Created attachment 128732 [details]
Remove spurious mac tests
Comment 32 WebKit Review Bot 2012-02-24 11:00:31 PST
Comment on attachment 128732 [details]
Remove spurious mac tests

Clearing flags on attachment: 128732

Committed r108823: <http://trac.webkit.org/changeset/108823>
Comment 33 WebKit Review Bot 2012-02-24 11:00:39 PST
All reviewed patches have been landed.  Closing bug.