Closed Bug 296462 Opened 19 years ago Closed 17 years ago

SVG Mouse Click causes browser to scroll

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: codedread, Unassigned)

References

(
URL
)

Details

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.
I've reproduced this bug as described. 
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Looks like this bug is still not assigned. It is very annoying and I think it should be given proper priority. Added my vote.
Looks like this bug is still not assigned. It is very annoying and I think it should be given proper priority. Added my vote.
Flags: blocking1.8.1?
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?
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.
WFM in Fx in Windows too - we can probably close this bug
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.