RESOLVED WORKSFORME 11580
REGRESSION(r16284-r16288): SVGs embedded in an XHTML document do not repaint properly, position wrong, corrupt general HTML rendering 
https://bugs.webkit.org/show_bug.cgi?id=11580
Summary REGRESSION(r16284-r16288): SVGs embedded in an XHTML document do not repaint ...
dzuelke
Reported 2006-11-12 03:32:54 PST
http://www.bitxtender.com/webkitsvg/ contains description, test cases and screenshots. As mentioned there, this used to work some time ago, I'd say four weeks or so. If necessary, I could try to find the specific nightly where it broke, but I'm very busy at the moment, sorry, so I couldn't do that today. Let me know if you need any further assistance. Tested with the latest nightly, of course ;) P.S: the situation where the SVG graphics are rendered black only happens on localhost for me, not if I load the page from the above web server or via file:///.
Attachments
Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 2006-11-12 05:26:07 PST
It seems very likely that the problem is caused by r16286 (<http://trac.webkit.org/projects/webkit/changeset/16286>). I've built both r16285 and r16286, and the problem does not occur in the former. For a reduced test case that demonstrates a repaint issue that appears to have been introduced at the same revision, take a look at <http://trac.webkit.org/projects/webkit/browser/trunk/LayoutTests/svg/custom/simpleCDF.xml?format=raw>. The paragraph saying "You should see an SVG image above this!" does not appear until you make a selection that includes it. It will then disappear when you resize the window, etc.
Eric Seidel (no email)
Comment 2 2006-11-12 13:42:09 PST
IIRC, this regressed about a month before I left apple. It's been broken long before the NSGraphicsContext change... I think.
Mark Rowe (bdash)
Comment 3 2006-11-12 14:01:14 PST
Eric, if you download r16284.dmg">http://nightly.webkit.org/builds/WebKit-SVN-r16284.dmg and r16288.dmg">http://nightly.webkit.org/builds/WebKit-SVN-r16288.dmg you can quite clearly see that it regressed between r16284 and r16288. I checked out and built r16285 and r16286 manually, and they show the same behaviour: working in the former, broken in the latter.
Eric Seidel (no email)
Comment 4 2006-11-12 14:22:08 PST
Sorry, I looked at your comment to quickly. Yes, if the build shows that's the regression... then that's the regression. ;)
dzuelke
Comment 5 2006-12-11 23:30:51 PST
I just checked it again with r18159, and it works flawlessly now, this bug may probably be closed.
Eric Seidel (no email)
Comment 6 2007-06-12 11:09:37 PDT
Looks fixed.
Note You need to log in before you can comment on or make changes to this bug.