User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1 Build ID: 20120905151427 Steps to reproduce: 1. Open this link: http://vseslava.ru/?firefox=1 2. Open any not external link by left button mouse click 3. Click on logo Actual results: SVG clip-path attribute on <path>s stopped to work Expected results: SVG clip-path must work like in other browsers, for example like in Chrome
Sorry, clip-path on <g>, not on <path>.
What's a logo? Which link? Please provide exact steps and preferably a reduced testcase.
0. All is done in one tab. All internal links are working for AJAX reload of part of content. 1. Open this link: http://vseslava.ru/?firefox=1 2. Click on "обо мне" 3. Click on logo with words "Vseslava" All parts of circle are now squared.
Extra information: After all steps in Firebug <g> has "clip-path" attribute and <clipPath> has appropriate "id" attribute. But "clip-path" not working. If I am trying to remove "clip-path" attribute and then add it again - all is working normal.
Tested on OS X 10.8.1, 32-bit; firefox 15.0.1 - bug occurs Tested on Debian Squeeze, 64-bit; Firefox 15.0 - bug occurs
Could you produce a minimal testcase please? Something with one image and one clipPath preferably?
Works now in trunk. Could be fixed earlier as I haven't checked beta or aurora.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
I'm still able to reproduce this on the linked site in Firefox 27.0.1 on OS X 10.9.2. I'm also seeing the same issue on a site I'm working on: 1. Visit https://omghow.com/ in Firefox (tested up to 27.0.1). 2. Scroll down until a new page is loaded via AJAX. 3. The bottom `rect` in the newly-loaded hexagons no longer follow their set `clip-path`.
Your example works for me on Windows. I think you have a different issue that has similar symptoms. Please can you raise a new bug for this issue. If you could come up with a reduced testcase that would be even better.
I'm able to replicate this on Windows 7 SP1/Firefox 28.0 on both sites as well, so I'm pretty sure it's the same issue. Here are a couple screenshots, for reference: * http://8le.gs/image/3g2i0s130K1r * http://8le.gs/image/0z1M2G082R10 If you're still not able to replicate it, I can work up a reduced test case.
A reduced testcase is the way forward.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Thanks for the update, Robert. Here's the simplest case I could get to break: http://jsfiddle.net/ExYKW/2/ It's incredibly strange, what seems to be breaking it is the `history.replaceState` call. If you just comment that out, it works as expected. Anyhow, that breaks in the browsers/platforms mentioned above.
Thats bug 652991. Does the original comment 0 case do that too? If so we can just mark this as a duplicate of that bug.
You need to log in before you can comment on or make changes to this bug.