Closed
Bug 312232
Opened 19 years ago
Closed 19 years ago
getScreenCTM fails somehow in xulrunner builds
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: readams, Unassigned)
Details
(Keywords: fixed1.8)
Attachments
(2 files, 1 obsolete file)
16.14 KB,
application/zip
|
Details | |
1.85 KB,
patch
|
jwatt
:
review+
tor
:
superreview+
asa
:
approval1.8rc1+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051012 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051012 Firefox/1.6a1 Under XULRunner, for some reason calling getScreenCTM fails: [JavaScript Error: "uncaught exception: [Exception... "Component returned failure code: 0xbfaaeeac [nsIDOMSVGLocatable.getScreenCTM]" nsresult: "0xbfaaeeac (<unknown>)" location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=197708 :: doDrag :: line 11" data: no]"] Load https://bugzilla.mozilla.org/attachment.cgi?id=197708 in an iframe for example in any xulrunner application. I'll also attach a very minimal xulapp testcase that also shows the problem. Click on the black square in the test case. Reproducible: Always
Updated•19 years ago
|
Assignee: nobody → general
Component: XULRunner → SVG
Product: Toolkit → Core
QA Contact: xulrunner → ian
Version: unspecified → 1.8 Branch
Comment 2•19 years ago
|
||
Is this perhaps a problem with any document loaded in a toplevel window (not in a <xul:browser>, <iframe>, whatever)? What happens when you load the equivalent SVG using firefox -chrome "http://whateverurl.svg"?
I apologize; this appears to only happen in my personal build. I'll mess around with it more.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Ok this is caused by an unitialized return value in GetViewboxToViewportTransform. Trivial patch to be attached.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Attachment #199436 -
Flags: review?(jonathan.watt)
Comment 6•19 years ago
|
||
Comment on attachment 199436 [details] [diff] [review] initialize the return value in GetViewboxToViewportTransform Please just initialize at the declaration point. And please fix up the same method on nsSVGMarkerElement while you're there.
Attachment #199436 -
Flags: review?(jonathan.watt) → review-
Attachment #199436 -
Attachment is obsolete: true
Attachment #199467 -
Flags: review?(jonathan.watt)
Comment 8•19 years ago
|
||
Comment on attachment 199467 [details] [diff] [review] Style change and also update nsSVGMarkerElement::GetViewboxToViewportTransform as well r=me and requesting sr from tor.
Attachment #199467 -
Flags: superreview?(tor)
Attachment #199467 -
Flags: review?(jonathan.watt)
Attachment #199467 -
Flags: review+
Attachment #199467 -
Flags: superreview?(tor) → superreview+
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•19 years ago
|
||
Comment on attachment 199467 [details] [diff] [review] Style change and also update nsSVGMarkerElement::GetViewboxToViewportTransform as well jwatt/tor, can one of you land this on trunk for readams?
Attachment #199467 -
Flags: approval1.8rc1?
Comment 10•19 years ago
|
||
Done. The patch is an obviously correct three line patch (exclucing the indentation changes) to prevent us from returning an uninitialized nsresult. Up until relatively recently we returned the correct value without any problems, so the risk from this patch is very small. The value SVG authors, especially in chrome, is significant I would think.
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Attachment #199467 -
Flags: approval1.8rc1? → approval1.8rc1+
You need to log in
before you can comment on or make changes to this bug.
Description
•