Attaching corrected test case.

Deleted: svg_target_test_V2.zip 1.4 KB

svg_target_test_V2.zip 1.4 KB Download

Tested the same on mac 10.11.6 chrome version 52.0.2743.116 and canary - Window scrolled with both pages.

But the same is observed with firefox browser as well.

Seems this is not chrome specific issue. Could you please recheck and update the thread.

Set up a few VMs and here's what I got:

Firefox 37.0.1/OSX 10.6.8 OK
Firefox 43.0.1/XPx86 OK
Firefox 48.0.2/W7x86 OK
Firefox 48.0.2/OS X 10.6.8 OK
IE 9.0.8112.16421/W7x86 OK
IE 10.0.9200.17.457/W7x86 OK
IE 11.545.10586.0/W10x64 OK
Safari 5.1.10/OSX 10.6.8 FAIL

Could not make Firefox fail, can you specify which version exhibits the same incorrect behaviour on your Mac?

Let me add why I think this is important: stylable SVG sprites. When you have two dozen icons on a page whose visual properties need to be animated, it's a lot better if they're contained in one single SVG download than have two-dozen-minus-one requests fly over the wire from a perf standpoint.

(See here: https://www.sitepoint.com/use-svg-image-sprites/ for more info.)

Waiting on tkonchada to respond to comment #3.

If the bug is real, mark as Untriaged and un-assign owner.

I can see why this is important, and my guess is that we are triggering auto-scroll based on history. That is, trying to get you to the same place you were the last time you viewed the content. This may be extremely hard to fix for all use cases because we can't know if the SVG in question is primary content or a re-used sprite.

Thanks for looking into this. 

The way I see it is that no browser other than WebKit-based ones seem to try to get you to the same place in case of svg content. I can think of few cases where this would be the expected behaviour, but then my knowledge and real-world experience with this stuff is surely not nearly as comprehensive as yours.

It's not so much about history, as about trying to scroll to the anchor ('#circle'), we then "propagate" this scroll - at least up to the closest ancestor same-origin "frame" (which is presumably why test_success.html works.)

I think we could quite trivially not scroll (at all) if the document is an SVG document. Or stop the propagation at the frame-boundary.

I guess you wouldn't be using <object> for this (it'll be quite heavyweight for any non-trivial amount of sprites) if :target worked properly in <img> and background-image =/ (see issue 549590)

You are correct in saying it's about anchors and not scroll history. The main reason I we hoped to use <object> instead of <img> was the ability to style and animate the insides from the parent document, which AFAIK is only possible with <object> and <svg>.

It's possible to animate (and style, within strict limits) in <img>, but it can't do so in response to input for instance.

Hm, as far as I could tell no styling was possible in <img>. What I had to resort to was server-side svg inlining for small images and client-side injection for bigger ones wherever the client wanted any sort of styling done.

dawid.ciecierski@, Could you please let us know if this is still an issue with latest stable version 55.0.2883.87	

It is, the incorrect scrolling behaviour is still present in 55.0.2883.87 (64-bit) on Windows 10 Pro.

I agree that disabling auto-scroll within SVG is the way to go.

 Issue 452854  has been merged into this issue.