Firefox 23 screws up drawings (again...)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. draw any form
2. actual drawing is shifted down and right from the mouse position
3.

What is the expected output? What do you see instead?

In what browser did you experience this problem? (ALL, Firefox, Opera, etc)
FIREFOX 23

In what version of SVG-edit does the problem occur? (Latest trunk, 2.5.1,
etc)
LATEST

Please provide any additional information below.
Apparently the same as issue 1081, but workaround no longer works :(

Original issue reported on code.google.com by inmagnav...@gmail.com on 7 Aug 2013 at 9:31

[GoogleCodeExporter]

I found that the reason for this is that getScreenCTM returns other values.
(in mousedown, mousemove handler in svgcanvas.js)

I postetd it on bugzilla
https://bugzilla.mozilla.org/show_bug.cgi?id=905122
-> they said it's no bug and they said getScreenCTM now works right
-> does this mean Chrome and other Browsers (and previous versions of Firefox) 
returning wrong values in getScreenCTM ?

Original comment by huebner....@gmail.com on 14 Aug 2013 at 1:38

[GoogleCodeExporter]

Yes,the problem is getScreenCTM returns different value with IE and Chrome, 
then its wrong, you can re-calculate getScreenCTM ().e and getScreenCTM().f by 
distance from left and top, i use this way and see it works.

Original comment by minhtuan...@gmail.com on 15 Aug 2013 at 2:42

[GoogleCodeExporter]

There are new comments on the posted bug on bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=905122

it sounds like they want to reconsider:
"While I agree that the new behavior is better in terms of consistency with the 
"from user space" concept, the old, unpleasant inclusion of the x/y values is 
at least interoperable across browsers. We should consider what we can do to go 
back to the old behavior I suspect."

They propose this cross browser solution:
"Calling getScreenCTM on a child <g> should give the same result in all 
browsers as the old behavior of calling it on the <svg>."

So I hope that this bug here will be accepted soon,
and the svg-edit developers will implement that solution.

Original comment by huebner....@gmail.com on 15 Aug 2013 at 8:12

[GoogleCodeExporter]

-> does this mean Chrome and other Browsers (and previous versions of Firefox) 
returning wrong values in getScreenCTM ?

Yes, that's exactly what it means. See the testcase in the bug and see if you 
can see why it should give different answers for the different getScreenCTM 
cases.

Original comment by longs...@gmail.com on 15 Aug 2013 at 11:28

[GoogleCodeExporter]

Based on the Bugzilla comments, I made a patch that fixes this issue.  In 
editor/svgcanvas.js, search for the line:
root_sctm = svgcontent.getScreenCTM().inverse();
There should be two matches.
Replace the line with:
root_sctm = getCurrentDrawing().getCurrentLayer().getScreenCTM().inverse();
This calls getScreenCTM() on the current layer (which is a <g>) instead of the 
SVG root.  This fix doesn't break IE/Chrome behavior as far as I can tell.

Original comment by r...@kcrossan.com on 20 Aug 2013 at 8:34

[GoogleCodeExporter]

Nope, it doesn't fix anything... Firefox 23 on Mac OSX machine

Original comment by piatkows...@gmail.com on 23 Aug 2013 at 10:14

[GoogleCodeExporter]

Same here. Tried replacing the line instances and now it doesn't even draw the 
shapes...

Original comment by pedam...@gmail.com on 31 Aug 2013 at 11:10

[GoogleCodeExporter]

I just tried applying the fix on a fresh checkout of 2.6, and it worked as 
expected on Firefox 23.0.1.  I'm not sure why it's not working for you two.  
The trunk has been fixed 
(http://code.google.com/p/svg-edit/source/detail?r=2524) so you can also check 
that out.  The fix applied to the trunk is only slightly different than mine - 
it uses the first <g> in the SVG instead of the <g> of the current layer.  If 
you want to try that out instead, you can replace
root_sctm = svgcontent.getScreenCTM().inverse();
with
root_sctm = $('#svgcontent g')[0].getScreenCTM().inverse();

Original comment by r...@kcrossan.com on 31 Aug 2013 at 7:38

[GoogleCodeExporter]

the 
root_sctm = getCurrentDrawing().getCurrentLayer().getScreenCTM().inverse(); 

fix has worked for me as well. Great work.

Original comment by Thomas.W...@gmail.com on 26 Sep 2013 at 8:56

[GoogleCodeExporter]

Works for me too. Significantly reduces the amount of Firefox specific code
^^
Thank you.

Original comment by inmagnav...@gmail.com on 25 Oct 2013 at 2:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just applied the change mentioned in svg-edit2.6 and it works.. now after the 
zoom is changed to fit to canvas the offset is removed, Thank you
I am using Mozilla firefox 21.0

Original comment by kmuhamma...@gmail.com on 26 Nov 2013 at 4:21

[GoogleCodeExporter]

Unfortunately this isn't working for me, both #5 and #8. In firefox 26.0 
firebug says that svgcanvas.js is not even loaded.
I'm new to all things js so I hope I interpreted correctly the firebug 
interface. The only files open from the svg-edit dir are: jquery.js, 
svgedit.compiled.js and touch.js.

Original comment by subscr...@gmail.com on 4 Feb 2014 at 12:53

[GoogleCodeExporter]

Nevermind, when I understood that I had to modify svgedit.compiled.js I was 
also smart enough to apply the #8 patch, which works. #5 does not.

Original comment by subscr...@gmail.com on 4 Feb 2014 at 2:33