RESOLVED FIXED 75091
[SVG] Text does not show after scripted scaling.
https://bugs.webkit.org/show_bug.cgi?id=75091
Summary [SVG] Text does not show after scripted scaling.
Branimir Lambov
Reported 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.
Attachments
Testcase (1.28 KB, image/svg+xml)
2011-12-22 08:50 PST, Branimir Lambov
no flags
foreignObject test (1.54 KB, text/html)
2011-12-23 03:30 PST, Branimir Lambov
no flags
Use CSS smart font minimums for SVG font minimums (6.42 KB, patch)
2012-02-12 17:06 PST, Philip Rogers
zimmermann: review-
webkit.review.bot: commit-queue-
Rough cut at properly calculating font metrics when scale changes. (15.63 KB, patch)
2012-02-15 14:21 PST, Philip Rogers
no flags
Updated patch per reviewer comments (32.20 KB, patch)
2012-02-16 06:55 PST, Philip Rogers
webkit.review.bot: commit-queue-
Update per reviewer comments (fixed several bugs, added support for SVGViewportContainer) (44.31 KB, patch)
2012-02-16 12:47 PST, Philip Rogers
no flags
Fix trivial mistake in previous patch. (44.31 KB, patch)
2012-02-16 13:00 PST, Philip Rogers
no flags
Rebase for bot happiness (44.28 KB, patch)
2012-02-17 08:38 PST, Philip Rogers
webkit.review.bot: commit-queue-
Patch (79.70 KB, patch)
2012-02-22 12:22 PST, Stephen Chenney
webkit.review.bot: commit-queue-
Add skipped tests that need to be rebaselined and add mac results (103.62 KB, patch)
2012-02-22 14:44 PST, Philip Rogers
webkit.review.bot: commit-queue-
Update expectations for bot happiness (129.88 KB, patch)
2012-02-23 06:51 PST, Philip Rogers
no flags
Remove spurious mac tests (4.59 KB, patch)
2012-02-24 07:10 PST, Philip Rogers
no flags
Branimir Lambov
Comment 1 2011-12-23 03:30:44 PST
Created attachment 120450 [details] foreignObject test The same happens with text in foreignObject.
Philip Rogers
Comment 2 2012-02-12 17:06:20 PST
Created attachment 126691 [details] Use CSS smart font minimums for SVG font minimums
WebKit Review Bot
Comment 3 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
Nikolas Zimmermann
Comment 4 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.
Philip Rogers
Comment 5 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
Philip Rogers
Comment 6 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!
Philip Rogers
Comment 7 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.
Nikolas Zimmermann
Comment 8 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.
Philip Rogers
Comment 9 2012-02-16 06:55:37 PST
Created attachment 127371 [details] Updated patch per reviewer comments
Philip Rogers
Comment 10 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
Nikolas Zimmermann
Comment 11 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.
Nikolas Zimmermann
Comment 12 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.
WebKit Review Bot
Comment 13 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
Philip Rogers
Comment 14 2012-02-16 12:47:29 PST
Created attachment 127430 [details] Update per reviewer comments (fixed several bugs, added support for SVGViewportContainer)
Philip Rogers
Comment 15 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).
Philip Rogers
Comment 16 2012-02-16 13:00:06 PST
Created attachment 127432 [details] Fix trivial mistake in previous patch.
Nikolas Zimmermann
Comment 17 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!
Philip Rogers
Comment 18 2012-02-17 08:38:31 PST
Created attachment 127595 [details] Rebase for bot happiness
WebKit Review Bot
Comment 19 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
Stephen Chenney
Comment 20 2012-02-22 07:26:04 PST
*** Bug 74003 has been marked as a duplicate of this bug. ***
Stephen Chenney
Comment 21 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.
WebKit Review Bot
Comment 22 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
Philip Rogers
Comment 23 2012-02-22 14:44:51 PST
Created attachment 128293 [details] Add skipped tests that need to be rebaselined and add mac results
WebKit Review Bot
Comment 24 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
Philip Rogers
Comment 25 2012-02-23 06:51:08 PST
Created attachment 128475 [details] Update expectations for bot happiness
Nikolas Zimmermann
Comment 26 2012-02-23 07:13:42 PST
Comment on attachment 128475 [details] Update expectations for bot happiness Great job, r=me!
WebKit Review Bot
Comment 27 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>
WebKit Review Bot
Comment 28 2012-02-23 16:52:27 PST
All reviewed patches have been landed. Closing bug.
Kenichi Ishibashi
Comment 29 2012-02-23 20:08:45 PST
I fixed wrong path of repaint.js in tests. http://trac.webkit.org/changeset/108720
Nikolas Zimmermann
Comment 30 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).
Philip Rogers
Comment 31 2012-02-24 07:10:36 PST
Created attachment 128732 [details] Remove spurious mac tests
WebKit Review Bot
Comment 32 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>
WebKit Review Bot
Comment 33 2012-02-24 11:00:39 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.