User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090419 Shiretoko/3.5b4pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090419 Shiretoko/3.5b4pre (.NET CLR 3.5.30729) When the Smartboard notebook software generates SVG-files, it should display each page in three ways. In a navigation bar on the left, in the main view pane and on a special sort view. Each of these are using the identical sub-document, but the main view pane remains blank, for no apparent reason. Display and navigation is scripted, the content is hard coded, though. The error console is empty, not even a warning. It works perfectly in Opera, Safari and Adobe SVG viewer. It does not work in FFox 3.5b4pre or 3.0. Background: Smartboards can generate SVG files. By default it checks for the presence of Adobe SVG-viewer, even if the browser has native support. I tried to get the Smartboard team to change this, but they won't until Firefox handles their content. Reproducible: Always Steps to Reproduce: 1. Open testcase Actual Results: Blank main view pane Expected Results: Contents should appear I have edited the testcases, trying to reduce it as much as I could, while maintaining the original feel of Smartboard generated SVG's.
Oh yes, there is a bunch of images missing in the test case, mainly arrows to switch slide. They are not essential. The demo still works.
The testcase needs to be much smaller to have any chance of figuring out what's wrong.
(In reply to comment #1) > Created an attachment (id=373833) [details] > Test case > <clipPath id="pagedisplayclip"><path fill="none" d="M130,90 L930,90 L930,540, L130,540 L130,90"/></clipPath> There is an extra comma after 'L930,540'. Without it, the SVG file works fine.
So the example is invalid per http://www.w3.org/TR/SVG11/paths.html#PathDataBNF Feel free to raise a new bug that we should log this kind of thing in the error log though for easier debugging.
I will take that observation to the Smartboard team. However, while working on a reduced testcase, I find the issue might still be present, even when that whole chunk of SVG is removed. When I've reduced the test as much as I can, I might reopen this bug... (I also wonder why Opera, Safari and Adobe SVG viewer "forgives" the presence of that comma...)
Created attachment 374041 [details] Reduced test case This is a reduced test case showing how clip-path="url(#pagedisplayclip)" is troublesome. I am working on reducing this even further, but i´t will take a while.
I'm the bozo of the day... Removing the clip path, containing the troublesome comma, while keeping a reference to that clip-path! However, doing that, the contents still show in Opera and Safari, so there is a need to clarify which behavior is correct. Perhaps someone could give me a hint, so that I could (if needed) open a bug for Webkit and submit one to Opera. Also, concerning Comment #5. Should I mention this 2nd case in the follow up bug, i.e. should the error log also include a warning that a non-existing clip-path was being addressed?
(In reply to comment #8) > However, doing that, the contents still show in Opera and Safari, so there is a > need to clarify which behavior is correct. Perhaps someone could give me a > hint, so that I could (if needed) open a bug for Webkit and submit one to > Opera. I already gave you two hints: http://www.w3.org/TR/SVG11/paths.html#PathDataBNF and I marked this bug invalid too :-) > > Also, concerning Comment #5. Should I mention this 2nd case in the follow up > bug, i.e. should the error log also include a warning that a non-existing > clip-path was being addressed? Someone has already created bug 489529 for the path parsing warning for us. You would need to raise yet another bug for a warning on a non-existent clip path.