regression open the url in new macbook pro, the dark orange square is meant to cover the whole yellow area. check using iPad2 ,10.6 and ppc 10.5.8, firefox etc... reduced testcase: peepo.com/index.svgz contains xhtml canvas, when the svgz file is rescaled in the html5 page index.html, the canvas is not rescaled.
Created attachment 109012 [details] svg with canvas
Created attachment 109013 [details] html using 'svg with canvas'
open html attachment, foreignObject scaled, SVG red rectangle scaled, but canvas black border not scaled wfm latest 10.6 Safari, and recent Mozilla or Opera broken Google Chrome 16.0.891.0 dev and believed broken latest Safari 10.7
wfm chrome 16.0.891.1 dev is this transient, coincidence or fix? need to confirm for 10.7.1
Confirmed broken in Safari 5.1 (7534.48.3) running on OS X Lion (10.7.1). SVG red rectangle is scaled up, but canvas black border is not. Jon
You mean scaling in "svg with canvas" (your first testcase) is broken? I can confirm that. For "html using 'svg with canvas'" there seems to be a similar bug, but not necesarily the same, it behaves differently, but also broken.
I was curious to hear whether there has been any movement on this one. We have a usability issue whose resolution is held up by this.
(In reply to comment #7) > I was curious to hear whether there has been any movement on this one. We have a usability issue whose resolution is held up by this. Thanks for the reminder, I checked this again, and it got better. The <canvas> is now resizing properly when resizing the Safari window. Only zooming is left broken. When zooming this file, the size of the black rectangle changes, where it doesn't in other browsers (only stroke-width changes). Can anyone else confirm that as well please using a Safari/Chrome nightly?
please read recent comments bug3781 re slow rendering
(In reply to comment #9) > please read recent comments bug3781 > re slow rendering This is unrelated to this bug. I've changed this bug title, to reflect the current state of <canvas> in SVG: zooming problems, no more sizing problems.
#9 please do not morph my bugs. file another bug for zoom
#9 please advise: what evidence do you have that scaling is not causing slow rendering? ie if you compare the two testcase given, pretty much the only difference is the scaling. in one case the animation runs fine, in the other it does not.
(In reply to comment #12) > #9 please advise: what evidence do you have that scaling is not causing slow rendering? I'll summarize again for you: - your original bug report has been fixed in trunk. The rectangle is correctly resized! - zooming in/out is still broken, as the black rectangle doesn't behave as expected, if you compare to Opera/FF This has NOTHING to do with "slow rendering". It's just that canvas in SVG + zooming is broken.
(In reply to comment #12) > #9 please advise: what evidence do you have that scaling is not causing slow rendering? Your original bug report said that something is broken, now you're claiming its rendering slow, please decide. "please read recent comments bug3781 re slow rendering" ??? (In reply to comment #11) > #9 please do not morph my bugs. "morph? The bug you filed is gone, and I'm reusing this to track zooming + SVG <canvas> which is broken.
DO NOT MORPH I politely wrote you off this bug, you ignored me. I will not file bugs if this continues!
#12 it wasn't possible to tell that the scaling might be slow, until there was scaling. as the slow renfering appears to be related to scaling, I am content to morph this bug to current scaling causing slow rendering, if that doesn't suite then either the slow rendering bug could morph or I could enter a new bug. however it needs someone else to try out the two tests, one of which has scale the other doesnt, and advise how you would like to proceed. else frankly I am content to watch webkit hang, its your product not mine that has the bug...
Please note the URL for this bug is given as peepo.com that is the test case, the attachments are reduced test cases, which necessarily cannot cover all possible eventualities!
filed as bug82147
(In reply to comment #15) > DO NOT MORPH > > I politely wrote you off this bug, you ignored me. For the record: I replied Jay in private and told him, that it's not respectful to revert changes to bug reports that a WebKit reviewer changes. As he thinks I'm not in the position to "morph" "his" bug reports, I am not sure how to go on here. Jonathan, it would help if you would actually answer questions I posted here: Example: (In reply to comment #8) > Can anyone else confirm that as well please using a Safari/Chrome nightly? Your answer: please read recent comments bug3781 re slow rendering Honestly, do you think anyone will understand you posting fragments of sentences, ignoring my question? You've a track record of bug reports like this. It makes me sad. Example 2: > Your original bug report said that something is broken, now you're claiming its rendering slow, please decide. Your answer: > DO NOT MORPH -- Sorry this is going nowhere, if you just don't answer questions, I can't help you.
see bug 82835 for aspect related to canvas and SVG layers
#19 Nikolas, apologies not having access to Mountain Lion until very recently it was difficult for me to update this bug. it appears the issue relates to updating canvas content, (the attachments for this bug render as expected) however you will readily discern that that the canvas on the url reverts after resizing, to the original size set. first, click anywhere on the board. this may be a regression as safari 5 does not exhibit this behaviour, neither does Firefox... else it may be one of those oddities around. I shall attempt to create a working testcase, now I understand the issue a little better regards
is iOS6 a webkit platform? in any case it is another case for this bug...
Created attachment 175759 [details] now updates canvas now updates canvas
Created attachment 175765 [details] updates canvas updates canvas
bug#103117 replaces part of this bug
dupe
please change status of Bug 103117 *** This bug has been marked as a duplicate of bug 103117 ***