This may serve as a tracking bug.
I want complete SVG static support in, at least. Maybe SVG basci instead,once 1.1 is released. I don't want to release half an implementation. -> FUTURE, since this wil depend on how much time various people have.
Agreed, but since there wasn't a bug for this, I thought it was warranted. Perhaps, we could put what bugs this would depend on as dependencies?
Sure. As for dependancies, I don't think its worth it at this stage. Once the majority of stuff is done, then it may be worth it.
May be I did it wrong but it seems that SVG only works with <embed> tag, not <object>. If that's right, why this use of a non-standard tag ? I've tried with a native release and with Adobe viewer. Or if I'm wrong, is there an URL to see an exemple ? Thanks.
bbaetz, what would implementing this using 'SVG basci' involve? Also, is 1.1 out yet? It sounds interesting.
Quite a bit of work... See the w3c pages.
Since the SVG enabled build for linux is very old and has a security problem, I'd like to see SVG enable too.
we don't need this tracking bug. Use bugzilla to query for all open browser::SVG bug. can we close this bug?
I would concur, lets close this tracking bug, since it only refers to a component in bugzilla
Mozilla already has SVG support, but it is not enabled on the default builds. This bug covers enabling SVG. It is not a tracking bug for all SVG bugs. But before SVG is enabled, there's a basic level of functionality required. This will probably serve as a tracking bug for those when the time comes near.
*** Bug 216610 has been marked as a duplicate of this bug. ***
*** Bug 233301 has been marked as a duplicate of this bug. ***
Created attachment 180397 [details] [diff] [review] patch to enable in builds by default, when the tinderboxes are ready
Comment on attachment 180397 [details] [diff] [review] patch to enable in builds by default, when the tinderboxes are ready a=asa for landing in 1.8b2
Comment on attachment 180397 [details] [diff] [review] patch to enable in builds by default, when the tinderboxes are ready let's not land this just yet..
oops. my bad. I misunderstood this. we want to wait on this until our infrastructure is ready. I meant to plus bug 292160, not this one (just yet).
After taling with tor, I think we're going to just enable on the specific tinderboxes and not necessarily land this (breaking lots of unprepared ports). Either way, getting the tier 1 platforms updated is covered by other blocking bugs and so this doesn't need to be a 1.8b2 blocker.
Since (a limited implementation of) SVG is now enabled by default on the trunk and branch (using Cairo on all OSes), this should be closed. If this bug is about full implementation of SVG 1.1, then its summary should be changed as such.
Before closing this bug, could you mention what version of Mozilla Firefox will most likely contain SVG support? Thanks, Mike
(In reply to comment #20) > Before closing this bug, could you mention what version of Mozilla Firefox will > most likely contain SVG support? > > Thanks, > Mike > Firefox 1.5.
This bug was originally intended for enabling SVG support, full or subset, by default. As far as using referring to the full SVG 1.1 standard, it could be upgraded to that. But I think that is better suited to another bug. Bug 160883 is a chicken-n-egg issue. This is still waiting on bug 286422 to be closed.
wfm shouldn't this bug be closed already?
This is surely FIXED now 1.5 is out?
No. SVG support was turned on in Mozilla Firefox 1.5, yes. But if you check out the source and build it yourself you'll find that SVG is not build by default. You still need to configure using --enable-svg. Before we can fix this we need to wait on bug 286422.
Bug 311198 enabled SVG by default on back in February. But the configure option should be renamed from --enable-svg to --disable-svg accordingly (same for canvas).
So let's call this fixed.