On 'svg' elements getScreenCTM behaves differently to other implementations

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

({fixed1.8})

Trunk
fixed1.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: SVGWG)

Attachments

(6 attachments, 2 obsolete attachments)

(Assignee)

Description

13 years ago
Bug go make sure I follow up on this:
http://lists.w3.org/Archives/Public/www-svg/2004Sep/0066.html
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 1

13 years ago
Created attachment 170818 [details] [diff] [review]
patch

Okay, this is how I think we should behave, which happens to be the way the
ASV6 alpha behaves (bar a bug I found in it). Certainly we should be accounting
for the transform due to the x and y attributes. I also think we should be
appending the viewBox to viewport transform. There is a note in the source
saying that if we do that for nsSVGSVGElement we need to modify
nsSVGGraphicsElement::GetCTM, but I don't see why. The only time
nsSVGGraphicElement::GetCTM effects nsSVGSVGElement::GetCTM or visa versa is in
nsSVGSVGElement::GetCTM.
Attachment #170818 - Flags: review?(tor)
(Assignee)

Comment 2

13 years ago
Comment on attachment 170818 [details] [diff] [review]
patch

cancelling review request since we can't just use x and y (they are ignored on
outer <svg> elements)
Attachment #170818 - Flags: review?(tor)
(Assignee)

Comment 3

13 years ago
I've followed up this issue in the thread beginning at
http://lists.w3.org/Archives/Public/www-svg/2005Jan/thread.html#15
(Assignee)

Updated

13 years ago
Whiteboard: SVGWG
(Assignee)

Comment 4

13 years ago
CC'ing Chris and Dean. I haven't recieved any confirmation from the SVG WG that
this is an issue, or alternatively an explaination of why it isn't an issue. If
it is agreed that there is ambiguity here, can we have some clarification on
what the correct behaviour is please?
(Assignee)

Updated

12 years ago
Blocks: 293224
(Assignee)

Updated

12 years ago
No longer blocks: 293224
(Assignee)

Updated

12 years ago
Summary: Make getCTM() behave correctly → On 'svg' elements getScreenCTM behaves differently to other implementations
(Assignee)

Comment 5

12 years ago
Created attachment 197708 [details]
testcase 1 - getScreenCTM on 'svg'
Attachment #170818 - Attachment is obsolete: true
(Assignee)

Comment 6

12 years ago
Created attachment 197715 [details]
testcase 2 - getScreenCTM on 'circle'
(Assignee)

Comment 7

12 years ago
Created attachment 197718 [details]
testcase 3 - getScreenCTM on 'circle' with a 'translate' attribute
(Assignee)

Comment 8

12 years ago
Created attachment 197722 [details]
testcase 4 - getScreenCTM on SVG embedded inline in XHTML
(Assignee)

Comment 9

12 years ago
Created attachment 197726 [details] [diff] [review]
unfinished snapshot

The changes to GetScreenCTM are "finished" and pass all the tests I just
attached. GetCTM and GetTransformToElement still need work.
(Assignee)

Comment 10

12 years ago
Created attachment 197790 [details] [diff] [review]
probably finished patch

This is as far as I'm going with this tonight. I'm fairly confident this is
correct, but I'll do some more testing tomorrow.
Attachment #197726 - Attachment is obsolete: true
Attachment #197790 - Flags: superreview?(tor)
Attachment #197790 - Flags: review?(tor)
(Assignee)

Comment 11

12 years ago
Created attachment 197861 [details]
testcase 5 - getScreenCTM on 'circle' with currentScale/Translate changed

Updated

12 years ago
Attachment #197790 - Flags: superreview?(tor)
Attachment #197790 - Flags: superreview+
Attachment #197790 - Flags: review?(tor)
Attachment #197790 - Flags: review+
(Assignee)

Updated

12 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

12 years ago
Comment on attachment 197790 [details] [diff] [review]
probably finished patch

Requesting approval. This bug fixes a high visibility conformance issue. The
modified methods are not run by our internal code, they are only used by
content. The risk from this change should be very low.
Attachment #197790 - Flags: approval1.8b5?

Comment 13

12 years ago
Comment on attachment 197790 [details] [diff] [review]
probably finished patch

last day for non-critical changes.
Attachment #197790 - Flags: approval1.8b5? → approval1.8b5+
(Assignee)

Updated

12 years ago
Keywords: fixed1.8
You need to log in before you can comment on or make changes to this bug.