User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081016 Minefield/3.1b2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081016 Minefield/3.1b2pre This site had lost numerous svg items in the display, interactive Javascript functions no longer working. Latest nightly is cropping display. Reproducible: Always Steps to Reproduce: 1.Open site in current nightly 2. 3. Actual Results: See above for details of problems. Note there are NO error messages or warnings. Firefox 3.0 works fine. Expected Results: See display in Firefox 3.0 Sorry I can't reduce this to a test case at this time. Since there are no error messages, I am not sure where to start.

This WFM using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081016 Minefield/3.1b2pre with Tracemonkey on and off. Do you have a problem using a new profile?

(And by WFM I mean I see no difference between Firefox 3.0.x and the nightly I was using.)

I toggled Tracemonkey on and off - no difference. How do you try a new profile?

See: http://support.mozilla.com/en-US/kb/Managing+profiles

OK - it is in my profile. A clean profile does not show the error. Toggling back and forth causes/corrects the error. Any ideas on how to find the problem?

You can try this and just move files a few at a time until the problem persists: http://kb.mozillazine.org/Transferring_data_to_a_new_profile_-_Firefox

It is in the content-prefs.sqlite database. Strange - I am looking at this database but nothing jumps out at me. When I find the specific entry I will post it. Thanks

The cause of the error is the text zoom setting. If the above site is loaded and you hit ctl+ or ctl- I think you can recreate the error. The setting in content-prefs.sqlite is settingID 2 to anything other than 1.0 (both 0.9 and 1.1 cause the error) for that particular domain. I have confirmed this on two sites. Could someone please check the following: Go to the above URL. Click on the icon in the upper right just below "Map Navigation". You should see the main map zoom in. Now hit ctl+ OR ctl- and close Firefox (nightly). Reopen Firefox nightly and check the functionality again. On mine it is broken. FF3.0 there is no error. Thanks!

Looks just the same to me trunk vs 3.0. Zooming either text or full page does nothing which is what you would expect since text zoom does nothing for svg and full zoom does nothing for pages that have a width and height of 100%

Well I am stumped then. I can recreate the error every time. When the text size is set to any value other than normal and firefox is closed - saving the setting then reopened, the error appears. I know the text size should not affect SVG but it sure does on mine.

I didn't know you had to restart with the zoom in effect. Even so I can't get anything to go wrong with text zoom but full page zoom restart does show the drawing too small or too large for me. That shouldn't happen.

Exactly. If you see the drawing too large or too small the gui buttons don't work either. If you hit either ctl+ or ctl- the display and functionality resumes. However if you close with a text zoom setting other than 1 and then reopen the bug appears. The setting is saved in content-prefs.sqlite in you profile. That's why a clean profile corrected the error.

I saw the effect with full zoom and not text zoom.

If it works in Firefox 3 and doesn't in the current trunk, can you determine a regression range?

Re comment 13 I agree - the bug only happens with full zoom not text zoom (I didn't know there was a difference). Re comment 14 I'm afraid I just auto download the latest nightly when ever available. I don't know how to get historic builds.

Looks like it happened between 2008-10-06 and 2008-10-07. Is this related to bug 458068 ? This bug was fixed at the same time.

I backed out 458068 locally and it has no effect on the drawing size. Backing it out does turn the main picture background black which is expected given what it fixes.

I don't see any problem on Mac with the latest trunk nightly. Can someone attach a screenshot showing how things look when they go wrong?

works (if you ignore what bug 458068 fixed): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081006 Minefield/3.1b1pre ID:20081006034237 http://hg.mozilla.org/mozilla-central/rev/1630d60e624e fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081007 Minefield/3.1b1pre ID:20081007033730 http://hg.mozilla.org/mozilla-central/rev/55366228f456 => range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1630d60e624e&tochange=55366228f456 => comment 17 confirmed => bug 458068/bug 433616 likely as cause

Can someone minimize the testcase? I think it does contain an external reference - at least two outer svg frames are created. If the presence of external references is what is screwing things up, it's bug 433616 that is the cause.

I think I have this reduced quite a bit. Since Mozilla can't have SVG files as an image source, I have to load these separately via XMLHttpRequest(). In the init() function I load a logo as follows: var getDataObj = new getXMLData("logos/DWR.svg",null,"dwrlogo"); getDataObj.getData() The function this calls is: /* ----------------------- getXMLData object ----------------------------- */ /* ----------------------------------------------------------------------- */ //this object allows to make network requests using getURL or XMLHttpRequest //you may specify a url and a callBackFunction or elementID //the callBackFunction receives a XML node representing the rootElement of the fragment received function getXMLData(url,callBackFunction,elemID) { this.url = url; this.callBackFunction = callBackFunction; this.elemID = elemID; this.xmlRequest = null; } getXMLData.prototype.getData = function() { //call getURL() if available if (window.getURL) { getURL(this.url,this); } //or call XMLHttpRequest() if available else if (window.XMLHttpRequest) { var _this = this; this.xmlRequest = new XMLHttpRequest(); this.xmlRequest.overrideMimeType("text/xml"); this.xmlRequest.open("GET",this.url,true); this.xmlRequest.onreadystatechange = function() {_this.handleEvent()}; this.xmlRequest.send(null); } //write an error message if neither method is available else { alert("your browser/svg viewer neither supports window.getURL nor window.XMLHttpRequest!"); } } . . . //this method receives data from XMLHttpRequest getXMLData.prototype.handleEvent = function() { if (this.xmlRequest.readyState == 4) { var importedNode = document.importNode(this.xmlRequest.responseXML.documentElement,true); if (this.elemID != null) { document.getElementById(this.elemID).appendChild(importedNode); } else { this.callBackFunction(importedNode); } } } /* ----------------------------------------------------------------------- */ When the init() function imports the svg file, it gets the file, parses the XML data and appends the data to the node specified in the function. The exact line is near the bottom of the function: document.getElementById(this.elemID).appendChild(importedNode); If I comment this line out the bug does not appear. Next I tested if a different svg file is loaded. The bug did NOT appear with a different svg file. I then looked at the specific parts of the logo in the svgfile. The component that causes the bug is the following: <g fill="rgb(31,65,126)" stroke="none" transform="translate(5,0)"> <g transform="translate(0,5) rotate(0.5,125,3)" > <use xlink:href="#raindrop" /> </g> <use xlink:href="#raindrop" fill="url(#blue_grad)" /> </g> Here #raindrop is a previously defined path. The logo has a blue gradient raindrop with a blue drop shadow so I reuse the path for the logo. I think the xlin:href may be causing the issue. If I comment out that part of the logo, the bug does not appear. I hope this helps

Can you make the reduced testcase available online somewhere please? Can you also make the version without document.getElementById(this.elemID).appendChild(importedNode); that doesn't exhibit the bug available?

Actually if you create the data using DOM rather than XMLHTTPRequest and then append that can you do it without the XMLHTTPRequest at all and therefore just make the testcase an attachment that works in bugzilla?

Reduced test case at: http://www.lrcwe-data.com/reduced.svg The file it calls is at http://www.lrcwe-data.com/logos/drop.svg I cannot create the bug via DOM insertion - not sure what I am doing wrong. Both methods are included in the above referenced reduced.svg

Can you create some kind of working.svg file too please so that I try to figure out where the difference(s) are.

I haven't been able to get a single file to show the bug yet. Still trying but the only way I am getting the bug is loading a node via an init() function.

Is this still a problem? I can't seem to get either Firefox 3.5 or trunk to display incorrectly.

this is still broken. i tested today's trunk nightly (cset: http://hg.mozilla.org/mozilla-central/rev/be1bef87f407) * open http://www.lrcwe-data.com/ in one tab * open http://www.lrcwe-data.com/reduced.svg in another tab * hit ctrl++ a few times in the first tab * switch to the seond tab and hit ctrl+f5 (a few times). you can see a) a clipped SVG and b) after minimizing the FX window and refocusing it you should see the black parts as originally described and c) opening and dismissing the context menu via right click above the image also produces black parts

FWIW, the second URL in comment 30 ("reduced.svg") is currently a 404 for me. longsonr suggested that Bug 579125 is the same as this, and I agree based on the screenshot here & comment 13. I'm duping this to Bug 579125, even though this one is older, since the other bug has a reduced testcase and cuts to the chase quicker than this one. (and there hasn't been any significant activity here for a while)