Firefox 20 severe problem - All shapes are shifted (even at 100% zoom level)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new document, draw a simple square (or anything else). It displays 
OK
2. Get the SVG code (or open a previously-saved SVG document). Click OK.
3. Now everything is shifted down-right outside the canvas.

What is the expected output? What do you see instead?
When I edit one of the squares, the square appears outside the canvas, while 
the editing controls appear in the correct position.

In what browser did you experience this problem? (ALL, Firefox, Opera, etc)
Firefox 20 (the issue is not present in Firefox 16.0.2, or Chrome).

In what version of SVG-edit does the problem occur? (Latest trunk, 2.5.1,
etc)
The problem occurs in both 2.6 and Latest trunk.

Please provide any additional information below.
Screenshot that shows the effect of the problem:
https://www.dropbox.com/s/zmp50vyi248jdz1/svg_edit_fail.png

Once the problem appears, it stays there until browser cache is deleted. 
Creating a new document without emptying browser cache results in broken 
behaviour (shapes are rendered as shifted down-right!).

Original issue reported on code.google.com by mantma...@gmail.com on 7 Apr 2013 at 3:38

[GoogleCodeExporter]

It seems to be the same problem reported in issue 1067

Original comment by mantma...@gmail.com on 7 Apr 2013 at 3:43

[GoogleCodeExporter]

This should be raised to high priority.

Original comment by astei...@gmail.com on 8 Apr 2013 at 8:01

[GoogleCodeExporter]

Issue is similar to Issue 1067 and Issue 1077 and Issue 1081 

Original comment by zeee.sz...@gmail.com on 12 Apr 2013 at 8:41

[GoogleCodeExporter]

Please review the attached SVG file.  

I've tested this in the current Firefox 20.0 release and Firefox Nightly: 
23.0a1 (2013-04-15)

Firefox 20.0 will show the ellipse incorrectly
Firefox 23.0a1 (2013-04-15) will show the ellipse correctly positioned

This may be a slightly contrived example because in svg-edit trunk, the 
svgcontent node does not have a transform="" attribute as it's probably getting 
removed during the running app -- yet, as Jeff and Robert have pointed out on 
the list, at some point a setAttribute("transform","") or 
setAttribute("transform",null) is probably getting done.

In the attached file, if you do *not* have the transform="", the snippet *does 
render properly* in Firefox 20.0...

Do I need to simulate a programmatic setAttribute with a javascript snippet and 
a button to perform a setAttribute("transform","") ?

Original comment by mark.nic...@gmail.com on 15 Apr 2013 at 7:41

Attachments:

• simple-svg-showing-transform-bug.svg

[GoogleCodeExporter]

Thanks to some of the insights provided by Jeff and Robert, I modified 
recalculate.js.

With this svn diff patch applied to trunk, i was able to successfully open and 
view SVG correctly with no strange offsets happening to the svgcontent element.

see: https://bugzilla.mozilla.org/show_bug.cgi?id=861188

I admit that returning null on a <svg> element in recalculateDimensions is a 
bit heavy-handed, but it seems to be working for the scenarios that I attempted 
to test.

I've also attempted a Firefox version detection using navigator.userAgent so 
that this code will only apply to Firefox 20

I have not tried this code against 2.5, but in theory it should work.

Original comment by mark.nic...@gmail.com on 16 Apr 2013 at 5:27

Attachments:

• svg-edit-patch-issue-1081.txt

[GoogleCodeExporter]

Thank you Mark!!

We have applied a similar patch to our 2.6 version.
I confirm that it works! (tested on Firefox 20.0.1)

Original comment by mantma...@gmail.com on 16 Apr 2013 at 1:38

[GoogleCodeExporter]

Hi Mark,

thanks a lot, this is working for us!
Just to say that in the stable version I'm using (I don't know exactly if it's 
2.5 or 2.6), the steps to apply the fix are slightly different.

You have to:
1) Modify the file "svgcanvas.js"
2) Looking for the row: "var recalculateDimensions = this.recalculateDimensions 
= function(selected) {"
3) Apply your patch:
   "
    if (selected.nodeName == "svg" && navigator.userAgent.indexOf("Firefox/20") >= 0) {
        return null;
    }
   "
   between the two instructions:
   a) "if (selected == null) return null;"
   b) "var tlist = getTransformList(selected);"

Original comment by marco.vi...@gmail.com on 16 Apr 2013 at 1:54

[GoogleCodeExporter]

Thanks Mark for the patch.  Here a review comment:  Can you just check if it's 
an <svg> element and return early, it doesn't seem like it's valid for any 
browser, right?

Original comment by codedr...@gmail.com on 16 Apr 2013 at 6:35

[GoogleCodeExporter]

It isn't valid yet!, it's being added in the SVG 2 specification. Firefox has 
started to implement some of those changes in a default disabled state. In this 
case not quite disabled enough though.

Original comment by longs...@gmail.com on 17 Apr 2013 at 8:51

[GoogleCodeExporter]

When the patch is "confirmed", can you also apply on branch 2.6?

http://code.google.com/p/svg-edit/source/detail?r=2509

Thanks!

Original comment by marclaporte on 9 May 2013 at 2:52

[GoogleCodeExporter]

I'm not sure if the above mentioned patch has been applied to the 2.6 branch, 
but using that version of svg-edit I'm having this offset problem

Firefox Nighlty 23.0a1 (2013-05-09)

I'm not sure if a feature or two was reverted in Nightly, but I'm getting the 
same result as was experience in Firefox 20.0, even after applying Marco's 
fix-it edits to 'svgcanvas.js'

Thanks,
Rev

Original comment by stylogic...@gmail.com on 9 May 2013 at 5:45

[GoogleCodeExporter]

Note:
Could this be an issue with the client operating system, as well? I'm on 
Windows 7 Pro and I've notice that after the first time I load svg-edit from a 
particular source, every subsequent time I load svg-edit, the last file I was 
editing is shown in the display. Beside being a little annoying, it has the 
effect of propagating this bug, beyond the first time it occurs, which is when 
I first load an SVG file using the open dialog. If I want to get rid of it I 
have to clear EVERYTHING from my Firefox history (and I mean everything), 
before I can load svg-edit without a previous file opening in the display, and 
therefore sans the offset bug. Is this a Windows-only effect?

Peace,
Rev

Original comment by stylogic...@gmail.com on 9 May 2013 at 5:51

[GoogleCodeExporter]

Update:

OK, now I've gone back to Firefox 20.0.0.1

After the FIRST time loading svg-edit from a specific source, at which point 
the offset bug does not occur, EVERY subsequent loading of the application from 
that same source will produce the bug (whether or not I've used the open 
dialog)... 
UNLESS I do the following:

1) Close the window or tab in which svg-edit has been loaded
2) Chooses 'History' > 'Clear Recent History' (Ctrl+Shift+Del) from Firefox menu
3) Select 'Everything' from the Time Range to Clear dropdown
4) Check 'Cookies' (only this seems necessary in Firefox 20.0.0.1)
5) Click the 'Clear Now' button

Then, the next time I load svg-edit from that source I will have a blank canvas 
that I can draw to with no offset problems. At this point, I can use the New 
dialog without issues, but if I reload the window/tab, even if I haven't drawn 
anything yet, the reloaded instance of svg-edit will exhibit the offset bug. 
Also if I access the <SVG> tag editor window, as soon as I click 'Apply' this 
bug will occur.

Thanks,
Rev

Original comment by stylogic...@gmail.com on 9 May 2013 at 6:58

[GoogleCodeExporter]

I encountered this (or related) issue in Firefox 21 and verified that it also 
shows up in IE 10.0.5 while using svg-edit 2.6.

I added the patch to svgCanvas.js and cleared the cache as well. 

Differing from the example page on the svg-edit home page, my implementation 
involves embedding the editing interface inside a div.  When the interface is 
first loaded no issue appears. After scrolling the parent page, drawn elements 
appear below (y axis) where they should be the amount that I have scrolled, 
x-axis is fine. Returning the scroll of the page to the top corrects the 
problem.

If I zoom the edit interface, drawn elements now appear to the lower right the 
amount I have zoomed. Returning the interface to the original zoom corrects the 
issue.

Original comment by NotionSl...@gmail.com on 28 May 2013 at 6:40

[GoogleCodeExporter]

I am seeing this bug in firefox 23.0 again. here it moves horizontally only 
outside the canvas

Original comment by imranash...@gmail.com on 16 Aug 2013 at 12:14

[GoogleCodeExporter]

I know this is a little late since version 2.6 has already been released, but 
I've just started using svg-edit.

What's happening is the same as what's been reported by stylogic.
You can use it fine on firefox, but after i saved a svg file and opened it, 
everything that's drawn, placed or moved is half the screen to the right and to 
the bottom.

My O.S. is Ubuntu 13, the issue started when I was on firefox20, but now I've 
upgraded it to firefox23 and the issue is still here.

My svg-edit version is 2.6 and I've applied the patch to svgcanvas.js, with no 
success (actually it seems the problem isn't even related, since i tried to 
state some alerts and it just didn't happen when i started drawing).

Hope my comment helps in the fixing of said issue, since it's a really annoying 
one.

I will probably look into the issue myself for a while, but, just in case.

##BTW, I don't think it's related to the view-source problem

Thanks.

Original comment by osmar.ma...@gmail.com on 5 Sep 2013 at 1:41

[GoogleCodeExporter]

In svgedit.compiled.js find viewBox:"0 0 " and set viewBox:"640 480 " then it 
work on firefox.

Original comment by vi...@cybertrontechnologies.com on 25 Sep 2013 at 6:47

[GoogleCodeExporter]

Hi,

hitting "CTRL + F5" multiple times, especially when the canvas is still empty, 
seems to clear the cache & delete the old image...

Original comment by Lucian.D...@gmail.com on 16 Dec 2013 at 10:45

[GoogleCodeExporter]

Hi,

I confirm that the patch proposed by Mark that was working successfully on 
Firefox 20 (see post #7) is currently not working anymore neither for FF 25 nor 
FF 26, because the code execution is not going anymore into the function 
"recalculateDimensions" during the creation of a new shape (e.g. a rectangle in 
my case).

Any new suggestion?

Thanks,
Marco

Original comment by marco.vi...@gmail.com on 18 Dec 2013 at 10:58

[GoogleCodeExporter]

I also tried the solution suggested in post #17, both in the last version 
available on the website and in the version I was using in April 2013 (that 
does not have the svgedit.compiled.js file).

Unfortunately, even if the shape this is drawn in the right position, when you 
select it the selection border (and the controls that enables rotation and 
resizing) are still in the wrong position in the lower right area.

Now I'm stuck: this problem can be seen in the public Svg-Edit Demo 
(http://svg-edit.googlecode.com/svn/branches/2.6/editor/svg-editor.html) only 
with the latest release of Firefox, Chrome and IE are working fine.

Any patch/suggestion from the developers?

Thanks,
Marco

Original comment by marco.vi...@gmail.com on 18 Dec 2013 at 11:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tried the solution suggested in post #17, in svg-edit2.6.
It have another problem, the zoom functionality is working at the right bottom 
not at cursor point and the output file coming as empty in all the browsers.

Original comment by sunilkum...@gmail.com on 5 Feb 2014 at 7:38

[GoogleCodeExporter]

This has been fixed in the trunk version of svg-edit: 
https://code.google.com/p/svg-edit/source/detail?r=2524.  You can replace the 
code in that revision in your svgcanvas.js file if you want to keep using 2.6.

View the trunk (latest) demo to see it working correctly: 
http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html.

Original comment by breit...@gmail.com on 24 Feb 2014 at 11:41

[GoogleCodeExporter]

 i had tried #24 this solution but but it's not worked for me, still i'm facing this problem, i'm using SVG 2.6 Version..  Anyone Fix This problem 
      Thanks in Advance

Original comment by ckantc...@gmail.com on 26 Feb 2014 at 2:33

[GoogleCodeExporter]

Hi, just look at the issue 1077 
(http://code.google.com/p/svg-edit/issues/detail?id=1077), the fix suggested 
has solved the problem for me!

Original comment by marco.vi...@gmail.com on 13 Mar 2014 at 9:55