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...)

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.

Even though this bug is closed, I want to give some feedback on the evangelism aspect. This is from Smart Technologies support: I’ve (Lloyd from SMart) put through a request to our testing team to replicate the issue with our logging for the developers enabled – I included a request to test several language packs in case the comma is only occurring in the Swedish language pack.  We had a problem with the Linux file-format using German not to long ago from a similar bug.  (Something that was a decimal was being saved as a comma and really throwing off the file structure) I’ve also put through a request for the developers to revisit the SVG export code, as well as examine the JavaScript code that auto-exports with the files.  Thanks for the information I’ll let you know when I hear from them – I sent them the link to your Mozilla Case as well.