Closed Bug 580983 Opened 14 years ago Closed 13 years ago

test_pointer-events-2.xhtml | foreignObject with clip-path - got [object SVGForeignObjectElement @ 0x* (native @ 0x*)], expected [object SVGRectElement @ 0x* (native @ 0x*)]

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: hsivonen, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Attachments

(1 obsolete file) 

66098 ERROR TEST-UNEXPECTED-FAIL | /tests/content/svg/content/test/test_pointer-events.xhtml | foreignObject with clip-path - got [object SVGForeignObjectElement @ 0x11c1b51b0 (native @ 0x116d28f70)], expected [object SVGRectElement @ 0x115390ea0 (native @ 0x116e63f10)]

Happened in response to a push that seems unrelated:
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=0f5fc40c6a0f
Depends on: 576986
There seems to have been an initial period from the 15th to to 21st where the test didn't cause problems. It does seem that something has changed that causes the foreignObject to appear to be either missing or in the wrong place.
Attached patch possible patch (obsolete) — — Splinter Review 

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Robert - per bug 598208 comment 4, I can land this for you if you like (sharing a push on m-c so as not to trigger a separate test cycle).  Have you tested this on TryServer, though?

(This could probably be justified to land during the b7-blockers-only lockdown with "a=tests-only", but only if it's been verified to not cause perma-orange on any platform.)

    
    

    
  
(not that this would be likely to cause perma-orange -- I'd just be more comfortable pushing this if we were absolutely sure this was safe from a TryServer run.  The tree is effectively reserved for b7-blocker-only work right now, and it would be bad to mess that up with an accidental typo in a test-fix. :))

    
    

    
      
  

    
    

    
      
  

    
    

    
  
checked in http://hg.mozilla.org/mozilla-central/rev/b14c94a85555 I'll leave this bug open for a while and see if it occurs again.

    
    

    
  
Not seen this again after the check in fix.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED

    
    

    
      
  
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  
Summary: test_pointer-events.xhtml | foreignObject with clip-path - got [object SVGForeignObjectElement @ 0x11c1b51b0 (native @ 0x116d28f70)], expected [object SVGRectElement @ 0x115390ea0 (native @ 0x116e63f10)] → test_pointer-events-2.xhtml | foreignObject with clip-path - got [object SVGForeignObjectElement @ 0x11c1b51b0 (native @ 0x116d28f70)], expected [object SVGRectElement @ 0x115390ea0 (native @ 0x116e63f10)]

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  
Summary: test_pointer-events-2.xhtml | foreignObject with clip-path - got [object SVGForeignObjectElement @ 0x11c1b51b0 (native @ 0x116d28f70)], expected [object SVGRectElement @ 0x115390ea0 (native @ 0x116e63f10)] → test_pointer-events-2.xhtml | foreignObject with clip-path - got [object SVGForeignObjectElement @ 0x* (native @ 0x*)], expected [object SVGRectElement @ 0x* (native @ 0x*)]

    
    

    
      
  

    
    

    
      
  

    
    

    
  
This test was failing at a relatively low rate until May, at which point it looks like something changed to make it much more failure-prone.

Summarizing this bug's tbplbot posts since the test got its current name (in http://hg.mozilla.org/mozilla-central/rev/049638523ae9 ):

 [ Month ]     [failure count]
 Feb   2011:      9  
 March 2011:      2
 April 2011:      6
 May   2011:     32 so far  -- projected 83 failures for this whole month

There were no failures at all between 4/15 (comment 68) and 5/02 (comment 69), so it seems likely that something happened just before 5/02 that regressed this badly.  (The increase in project branches may have increased the number of opportunities for it to fail, too, but I don't think that explains all of the increase.)

Here's the pushlog for the 38 hours before comment 69 (that day up to the first failure, and the full day before it):
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-05-01+00%3A00%3A00&enddate=2011-05-02+14%3A00%3A00

jwatt, perhaps you could look into this if you get a chance?  This is quickly becoming a major source of tinderbox orange.
OS: Mac OS X → All
Hardware: x86_64 → All

    
    

    
  
(note that the pushlog from comment 101 might not be exactly the right one - it's possible that comment 69 was a "low-frequency failure" and that the high-frequency failures just happened to start soon afterwards)

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Pushed http://hg.mozilla.org/mozilla-central/rev/c6b086e676f2

The handler in the 'onload' attribute on the <svg> tag is defined to fire once its closing tag is parsed, which is too early. This change makes us wait until the document is complete by using the 'onload' attribute on the <body> instead.

    
    

    
      
  

    
    

    
  
(In reply to comment #111)
> jwatt%jwatt.org
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1305384316.1305387012.
> 6396.gz
> Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central debug test mochitests-1/5 on
> 2011/05/14 07:45:16

This happened on 3f21638a8c8e39e2e8b472f8ead71a7539f3b313, which is an indirect child of c6b086e676f2, which I think tells us that the patch landed in comment 110 is not enough.  :(

    
    

    
  
We've basically put it back to what it was before the patch in comment 6 I think. Perhaps we need to do something to the foreignObject and wait for a mozAfterPaint event.

    
    

    
      
  

    
    

    
  
Err, actually the "failure" result is what we want! We should never be getting the foreignObject from document.elementFromPoint() since the foreignObject is entirely filled by the <path> (formerly <rect>).

Changing the expected element to be the path would turn this virtually permaorange, so for now I'm going to disable this test.

If I had to guess, I'd say that what's going on here is that the foreignObject hasn't been given it's initial reflow when the document's 'load' event fires. If I throw in a setTimeout then elementFromPoint() returns the path element instead of the foreignObject as it should.

I'm not sure what the correct way to proceed with fixing the underlying bug is though. Probably we should make sure the foreignObject gets reflowed before the document 'load' event is fired. If we don't think that needs to be the case then maybe we should do something along the lines of what longsonr suggested in comment 113.

    
    

    
  
Actually this orange is figured out now, so I'm closing this. I've opened bug 657155 for making sure that foreignObject can be relied upon to have been reflowed before the document 'load' event is fired.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → INVALID
Whiteboard: [orange]

        Attachment #461786 -
        Attachment is obsolete: true

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: