User-Agent: Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100710 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100710 Minefield/4.0b2pre I'm not sure if it's "SVG" related or "Layout: View Rendering" related When you dynamically attach an HTML element to the DOM tree of an HTML document, the element is not render if it exist a stylesheet which define that an SVG filter must apply to it. Reproducible: Always Steps to Reproduce: 1. Open the testcase Actual Results: You can see one grey square Expected Results: You should see 2 grey square
Looks like the filter is created with zero size as all the style is applied together so when the filter region is calculated it is empty as the width and height are still default values i.e. before the style has set them to 100px. Setting the filter asynchronously works. I'm not sure what to do here to fix this.
I've run some tests with an image instead of an arbitrary DIV element and it behave the same even without CSS width and height. So I guess that it's not only a mater of CSS, but a global question of when the size of an element is computed and when the filter is applied. Unfortunately, I've no idea on how the width and height are computed under the hood. But if your right, is it possible to force the SVG filter to be applied after the size of the element is determine? (yes, I know that it's really naive but who knows?) FWIW, if the page is force to reflow (by changing the window size for example), the second square become visible.
Robert, I'd think changes to the element size would recompute the filter. That's the only sane thing to do in this situation, no?
Indeed, I'm not sure why that's not happening though. The resize should cause a repaint which should automatically recompute the filter.
Are we failing to invalidate things due to the filter being applied or something?
Created attachment 468654 [details] Specifique TC for HTML img element Hello, I'm working on a new app that rely on SVG filters over HTML img elements and this bug just drive me crazy (I guess it's the same bug but let me know if it is not). This test case provide a new use case when the `src` attribut of a img element is changed without providing explicitly the width and heigth of the new image source. In this TC, the first image is well loaded and the filter just work fine. The second image have an intrinsic size of 200x100px. When the page is loaded, we change it's source for an image with an intrinsic size of 200x200px. Unfortunately, once this new image is loaded, the filter is partially applied to the new image. It crop it for an height a bit bigger than the previous image source ! I hope this will help finding what's happening with filters here.
Comment 7 seems like a different bug that should be filed separately.
(In reply to comment #8) > Comment 7 seems like a different bug that should be filed separately. Done on Bug 590434
The original testcase works for me now. No idea what fixed it.
It seems that the change occur with this build : http://hg.mozilla.org/mozilla-central/rev/d708c2fa7fea
Jeremie, I don't think that can be right. My build isn't as new as that (http://hg.mozilla.org/mozilla-central/rev/a3f202325d27)
Ok, I found it. In fact, the bug is not resolved. If you open the test case, even with the last build, the test will fail. But, if you let the test open, then relaunch minefield, you'll see the test as it pass (but if you try to reload it you'll see that it's not the case).
Seems to work on trunk now.
The test case is still broken with the current nightly (from 2011/12/18) : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111218 Firefox/11.0a1 http://hg.mozilla.org/mozilla-central/rev/a5e63e00db27 I'm waiting for the next nightly to check it.
There is nothing that would fix things in the next nightly but it didn't disappear on any kind of refresh when I tried it.
(In reply to Robert Longson from comment #16) > it didn't disappear on any kind of refresh when I tried it. I'm not sure what you expect to disappear. The test case should show 2 gray squares and with the current nightly there is only one visible. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111219 Firefox/11.0a1 http://hg.mozilla.org/mozilla-central/rev/d75ebb37080e
I was confused by comment 13 in that I see things exactly the same no matter how I reload it. I do only see 1 item though.
(In reply to Robert Longson from comment #18) > I was confused by comment 13 in that I see things exactly the same no matter > how I reload it. I do only see 1 item though. Yes, it seams that the behavior from comment 13 no longer occur but the test case is still broken.
nsIFrame::FinishAndStoreOverflow of the filtered frame is called three times, if we write <div></div> in html; By using js appending the filtered div, nsIFrame::FinishAndStoreOverflow is only called once, and the size of the filtered frame is not calculated yet(width=0 and height=0) Steps: 1. Set breakpoint at nsFilterInstance::GetPostFilterBounds 2. dump aFilteredFrame->GetVisualOverflowRect(). Case 1: <div></div>: #2 return valid width and height at 2nd and 3rd call. Case 2: js.appendElement: #2 return (0,0,0,0) and is called once only.
nsFilterInstance::GetPostFilterDirtyArea(nsIFrame *aFilteredFrame, const nsRegion& aPreFilterDirtyRegion) The size of aPreFilterDirtyRegion, which is passed from FrameLayerBuilder, is (1X1)