If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

reftest foreignObject-01.svg fails with red area where scrollbar would be

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: jwatt, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

Created attachment 263613 [details]
foreignObject-01.svg

The reftest foreignObject-01.svg fails with a red area where the scrollbar would be if the image were large enough to cause scrolling. It seems that the lime div in the foreignObject is not taking the full width of the viewport for some reason.

This began failing between the 2007-05-01-04-trunk and 2007-05-02-04-trunk builds.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-01&maxdate=2007-05-02+04%3A00&cvsroot=%2Fcvsroot
Could be bug 378975.  We're now guessing that we should have a scrollbar to start with, and expecting the kid to tell us if we shouldn't.  Is the kid lying in this case?

btw, I won't be able to debug this because that testcase hangs X...
Flags: blocking1.9?
Keywords: regression
(Reporter)

Comment 2

11 years ago
So thanks to bz's speedy debugging skills it turns out this is fixed by the patch in bug 369827. Because the foreignObject has percentage width, and because the SVG now gets the two stage reflow as described in comment 1, it gets stuck on the initial "assuming scrollbars" reflow width. Marking dependent so I remember to re-enable this test once the patch in that bug gets review.
Depends on: 369827
(In reply to comment #2)
> gets stuck on the initial "assuming scrollbars" reflow width. Marking dependent
> so I remember to re-enable this test once the patch in that bug gets review.

You should mark the reftest as "fails" in the manifest, so the tree will go orange if whoever checks in the fix forgets to remove the "fails".
(Reporter)

Comment 4

11 years ago
> You should mark the reftest as "fails" in the manifest, so the tree will go
> orange if whoever checks in the fix forgets to remove the "fails".

Done, with the exception of the tests that are crashing the reftest script on linux. I'll have to leave them commented out I guess.
(Reporter)

Comment 5

11 years ago
This was fixed by the checkin for bug 369827.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Reporter)

Updated

11 years ago
Flags: blocking1.9? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.