User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 The attached SVG file loads correctly, but does not scroll properly. It takes a long time for the browser to repaint when the scroll bar is moved, and the repainting fails sometimes. Reproducible: Always Steps to Reproduce: 1.Load the attached file 2.Try to move the vertical scroll bar 3. Actual Results: The repainting of the browser is very slow or fails
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051121 Firefox/1.6a1 ID:2005112103 I see the same.
Assignee: nobody → general
Component: General → SVG
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Attachment #203910 - Attachment mime type: image/svg → image/svg+xml
The problem also occurs with Firefox 1.5 on Windows XP. I have attached another SVG file which renders at 557px by 6090px and demonstrates the problem. Firefox 1.5 becomes *completely* unresponsive and hence unusable when an attempt is made to view that file.
Created attachment 204669 [details] The attached test3.svg is a 557px by 6090px SVG file and demonstrates the same problem when viewed with Firefox 1.5 on Windows XP I have zipped the file, as it was too big to attach unzipped.
Please could someone change the platform to All, as this occurs on Windows XP as well as Linux.
I've changed this back to Linux from All since it now scrolls just fine for me on WinXP. Can a few other people test too?
OS: All → Linux
The original testcase scrolls fine. The second testcase is quite slow scrolling due to its use of feGaussianBlur on some extremely tall objects (~6000 pixels high).
(In reply to comment #7) > I've changed this back to Linux from All since it now scrolls just fine for me > on WinXP. Can a few other people test too? Scroll usability with Firefox 2 is, in fact, very low with both test cases. Firefox 3 makes first attachment pleasant to scroll, although scroll in second attachment is still somehow slow - which is perfectly acceptable, IMHO, given the document itself - huge, both in canvas size and complexity (comment 8). Tested in both Windows and Linux. Hardware description included also, as scrolling performance, given these test cases, is tightly related to processing power. As the report refers to broken scroll behavior, maybe this issue could be marked "fixed" or even "invalid" - as the scroll behavior was never broken but simply unusable. Versions: Firefox 2 (Windows) - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20080311 Firefox/22.214.171.124 Firefox 3 (Windows) - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040805 Minefield/3.0pre Firefox 2 (Linux) - Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:126.96.36.199) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/188.8.131.52 Firefox3 (Linux) - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040804 Minefield/3.0pre Hardware: Windows - Pentium IV 3.0GHz processor, 1GB RAM Linux - Pentium M 1.6GHz processor, 512MB RAM
Marking as WFM then as performance would seem to be fixed by unknown check-ins.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.