Closed Bug 345544 Opened 18 years ago Closed 17 years ago

Appending URI fragment to SVG documents breaks gradients

Categories

(Core :: SVG, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla.mozilla.wayne, Unassigned)

References

()

Details

(Whiteboard: CLOSEME 06/27)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Seems that webpages that display SVG (standalone or in a application/xhtml+xml bundle) are rendered differently when a uri fragment (# or #whatever) is appended to the URI.  The gradients are not displayed.

Reproducible: Always

Steps to Reproduce:
1.Go to http://ptaff.ca/images/ptaff.ca.svg
2.Go to http://ptaff.ca/images/ptaff.ca.svg# and shift-reload


Actual Results:  
On the URI with a fragment, the gradients are missing

Expected Results:  
The document rendering should be the same.

Using the FF binary from mozilla site.

cairo-1.0.4
glib-2.8.1
glibc-2.3.5
gtk+-2.8.3
xorg-6.9.0
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!
Whiteboard: CLOSEME 06/27
Version: unspecified → 1.5.0.x Branch
Problem still there with FF2.0.0.4 on GNU/Linux (test case above fails)

cairo-1.4.4
glib-2.12.11
glibc-2.5
gtk+-2.10.11
xorg-7.2
Thanks for the feedback! Could you also test with trunk build and report back too?
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

(best to launch firefox with
firefox.exe -profilemanager
and make a new profile for testing this trunk build)
Bug fixed in firefox-3.0a6pre.en-US.linux-i686.  Leaving the bug status as is - I don't know if it deserves a backport to FF<3.
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Version: 1.5.0.x Branch → 1.8 Branch
I'll punt this over to Core:SVG - they'll be able to tell you if such a thing is going to be backported or not (I suspect not, the 2.0 branch only gets security, stability and regression fixes).

This bug should be WORKSFORME if it works on the trunk and no backport will take place.
I'm pretty sure the answer is no - it won't get backported. I think the trunk fix was a combination of bug 29580 and bug 309020. Individually these are probably too large to make the risk worthwhile IMHO.

In fact I think I remember this question being asked in some other bug which I can't currently find and bzbarsky ruling it out. 
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.