Status

()

--
enhancement
RESOLVED FIXED
17 years ago
5 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

17 years ago
 
(Reporter)

Comment 1

17 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

17 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

17 years ago
Blocks: 136666

Comment 5

17 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

17 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

17 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

17 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

17 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

16 years ago
Blocks: 163993

Comment 13

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

Updated

15 years ago
Hardware: PC → All

Updated

15 years ago
Severity: normal → enhancement
Blocks: 153896
Blocks: 160883
Depends on: 258511

Updated

15 years ago
Depends on: 264132
(Assignee)

Updated

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

Updated

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

Comment 14

14 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)

Updated

14 years ago
Attachment #180397 - Flags: review?(benjamin) → review+

Updated

14 years ago
Depends on: 292054
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

14 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..
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.
Flags: blocking1.8b2+

Updated

14 years ago
No longer blocks: 163993

Comment 19

14 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

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

Thanks,
Mike

Comment 21

14 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

14 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

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

Comment 24

13 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

13 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

Comment 27

13 years ago
So let's call this fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.