An HTML element attach to the DOM is not render if an SVG filter apply to it

UNCONFIRMED
Assigned to

Status

()

Core
SVG
UNCONFIRMED
7 years ago
2 months ago

People

(Reporter: Jeremie, Assigned: cjku)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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
(Reporter)

Comment 1

7 years ago
Created attachment 456678 [details]
testcase
(Reporter)

Updated

7 years ago
Summary: A HTML element attach to the DOM is note render if an SVG filter apply to it → An HTML element attach to the DOM is not render if an SVG filter apply to it

Comment 2

7 years ago
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.

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

7 years ago
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?

Comment 5

7 years ago
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?
(Reporter)

Comment 7

7 years ago
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.
(Reporter)

Updated

7 years ago
Blocks: 590434
(Reporter)

Comment 9

7 years ago
(In reply to comment #8)
> Comment 7 seems like a different bug that should be filed separately.

Done on Bug 590434

Updated

6 years ago
Attachment #468654 - Attachment is obsolete: true

Comment 10

6 years ago
The original testcase works for me now. No idea what fixed it.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 11

6 years ago
It seems that the change occur with this build : http://hg.mozilla.org/mozilla-central/rev/d708c2fa7fea

Comment 12

6 years ago
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)
(Reporter)

Comment 13

6 years ago
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).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 14

5 years ago
Seems to work on trunk now.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago5 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 15

5 years ago
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.

Comment 16

5 years ago
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.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: WORKSFORME → ---
(Reporter)

Comment 17

5 years ago
(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

Comment 18

5 years ago
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.
(Reporter)

Comment 19

5 years ago
(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.
(Assignee)

Updated

3 months ago
Assignee: nobody → cku
Comment hidden (typo)
(Assignee)

Comment 21

2 months ago
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.
(Assignee)

Comment 22

2 months ago
nsFilterInstance::GetPostFilterDirtyArea(nsIFrame *aFilteredFrame,
                                         const nsRegion& aPreFilterDirtyRegion)

The size of aPreFilterDirtyRegion, which is passed from FrameLayerBuilder, is (1X1)
You need to log in before you can comment on or make changes to this bug.