SVG Mouse Click causes browser to scroll

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
14 years ago
12 years ago

People

(Reporter: codedread, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 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

14 years ago
I've reproduced this bug as described. 
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

14 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.

Updated

13 years ago
Flags: blocking1.8.1?

Comment 6

13 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?
(Reporter)

Comment 8

12 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.
(Reporter)

Comment 9

12 years ago
WFM in Fx in Windows too - we can probably close this bug
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.