bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

SVG Mouse Click causes browser to scroll




13 years ago
11 years ago


(Reporter: Jeff Schiller, Unassigned)


Windows XP
Bug Flags:
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)





13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050602 Firefox/1.0+

I tried many many times to search for a duplicate of this bug, but the search 
would just hang.

If an embedded SVG document does not have its origin (i.e. top-left) in the 
current browser's viewport and the mouse click event is being captured, the 
browser will scroll the browser window so that the top-left corner of the 
embedded SVG is visible and the mouse event will be tossed away (does it even 
go into the SVG document?).  This is very undesirable behavior.  It 
effectively breaks the ability to use embedded SVG to handle mouse events if 
you have a large document that is bigger than the user's screen.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.codedread.com/
2. Size the window such that there is no way for both the  "Home" button and 
the "About" button to be on the screen at the same time.
3. Click on the "About" button.

Actual Results:  
The page is scrolled to the top of the embedded SVG, the mouse event is not 
processed within the SVG document.

Expected Results:  
Leave the page alone (do NOT scroll) and then process the mouse event.

Comment 1

13 years ago
I've reproduced this bug as described. 
Ever confirmed: true

Comment 3

13 years ago
Can we get this marked as blocking for 1.5?  It is REALLY annoying and hurts
usability for any SVG image that is larger than the browser viewport.  See the
test case in the original post for what I'm talking about.

Comment 4

13 years ago
Looks like this bug is still not assigned. It is very annoying and I think it should be given proper priority. Added my vote.

Comment 5

13 years ago
Looks like this bug is still not assigned. It is very annoying and I think it should be given proper priority. Added my vote.


13 years ago
Flags: blocking1.8.1?

Comment 6

12 years ago
Not going to block 1.8.1 for this bug, but we'll happily consider a baked-on-trunk patch.
Flags: blocking1.8.1? → blocking1.8.1-
Is this still an issue?

Comment 8

11 years ago
I haven't noticed this issue in awhile.

WFM in Fx 2.0 in Linux.  Will let you know about Fx 2.0 in Windows.

Comment 9

11 years ago
WFM in Fx in Windows too - we can probably close this bug


11 years ago
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.