Status

()

Core
SVG
--
enhancement
RESOLVED FIXED
16 years ago
3 years ago

People

(Reporter: Thomas Swan, Assigned: tor)

Tracking

(Blocks: 1 bug)

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
 
(Reporter)

Comment 1

16 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
(Reporter)

Comment 3

16 years ago
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.

Updated

15 years ago
Blocks: 136666

Comment 5

15 years ago
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.

Comment 6

15 years ago
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.

Comment 8

15 years ago
Since the SVG enabled build for linux is very old and has a security problem,
I'd like to see SVG enable too.

Comment 9

15 years ago
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

Comment 11

15 years ago
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. ***

Updated

14 years ago
Blocks: 163993

Comment 13

13 years ago
*** Bug 233301 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Hardware: PC → All

Updated

13 years ago
Severity: normal → enhancement

Updated

13 years ago
Blocks: 153896

Updated

13 years ago
Blocks: 160883

Updated

13 years ago
Depends on: 258511

Updated

13 years ago
Depends on: 264132
(Assignee)

Updated

12 years ago
Depends on: 285177, 285178, 286422
No longer depends on: 264132
(Assignee)

Updated

12 years ago
Flags: blocking1.8b2+
(Assignee)

Comment 14

12 years ago
Created attachment 180397 [details] [diff] [review]
patch to enable in builds by default, when the tinderboxes are ready
Assignee: alex → tor
Status: NEW → ASSIGNED
Attachment #180397 - Flags: review?(benjamin)
Attachment #180397 - Flags: review?(benjamin) → review+

Updated

12 years ago
Depends on: 292054

Comment 15

12 years ago
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
Attachment #180397 - Flags: approval1.8b2+

Comment 16

12 years ago
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..

Comment 17

12 years ago
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).

Comment 18

12 years ago
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.
Flags: blocking1.8b2+

Updated

12 years ago
No longer blocks: 163993

Comment 19

12 years ago
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.

Comment 20

12 years ago
Before closing this bug, could you mention what version of Mozilla Firefox will most likely contain SVG support?

Thanks,
Mike

Comment 21

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

Comment 22

12 years ago
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.

Comment 23

12 years ago
wfm shouldn't this bug be closed already?

Comment 24

11 years ago
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.

Comment 26

11 years ago
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).
Depends on: 311198
So let's call this fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.