Closed Bug 595608 Opened 10 years ago Closed 9 years ago

"ASSERTION: wrong type" with <svg:set> and invalid "type" attribute (nsSVGTransformSMILAttr::ValueFromString)

Categories

(Core :: SVG, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- final+

People

(Reporter: jruderman, Assigned: longsonr)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(3 files, 1 obsolete file)

Attached image testcase
No description provided.
Attached file stack trace
###!!! ASSERTION: wrong type: 'Type() == eAtom', file content/base/src/nsAttrValue.h, line 396
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → longsonr
Attachment #478050 - Flags: review?(dholbert)
Comment on attachment 478050 [details] [diff] [review]
patch

r=dholbert if you add a comment above this line...
>+    if (typeAttr->Type() != nsAttrValue::eAtom) {
... saying something like this:
  // Recognized values of |type| are parsed as an atom -- so if we have
  // something other than an atom, then it means our |type| was invalid.
  // (see nsSVGAnimateTransformElement::ParseAttribute)and include the test as a crashtest.

I'd be happy to land this for your (when the tree reopens to non-b7-blockers), particularly if you post the updated version with with author & commit message set, so I can just |hg import| and push. :)
Attachment #478050 - Flags: review?(dholbert) → review+
Blocks: 468996
OS: Mac OS X → All
Hardware: x86 → All
Summary: "ASSERTION: wrong type" with <svg:set> (nsSVGTransformSMILAttr::ValueFromString) → "ASSERTION: wrong type" with <svg:set> and invalid "type" attribute (nsSVGTransformSMILAttr::ValueFromString)
(In reply to comment #4)
>   // (see nsSVGAnimateTransformElement::ParseAttribute)and include the test as
> a crashtest.

Sorry.. I could've sworn I had a newline after the ")" in ")and" there.
Attachment #478050 - Attachment is obsolete: true
I've added the comment or at least the first two lines of it which is the best bit. I've also added the crashtest.

I've never got mq to work which is clearly my fault so this is still just a patch rather than the funky mq thing you really wanted. Sorry.
Attachment #478072 - Flags: approval2.0?
Ah, no worries. :)

FWIW, you can generate |hg import|-able patches pretty easily without Mq, by doing:
>  [make edits, or directly apply a patch]
>  hg commit # type your commit message in editor when prompted
>  hg export tip > patch_with_headers.txt
This outputs a patch with (a) you set as the author, and (b) your commit message already included.

No need to do that here -- I'm just mentioning it for future reference, so that you can generate "funky" :) patches without using Mq.

(It's well worth investing time to get Mq working, thouygh, IMHO -- it makes life so much better, particularly if you take it to the extreme and version-control the patches themselves! :))
(In reply to comment #8)
> >  [make edits, or directly apply a patch]
> >  hg commit # type your commit message in editor when prompted
> >  hg export tip > patch_with_headers.txt
...and to keep your repo clean, you probably would want to follow that with:
> hg rollback
OR
> hg strip tip
either of which will remove the (outgoing) changeset from your repository.
Whiteboard: [needs landing]
Landed:
 http://hg.mozilla.org/mozilla-central/rev/11ec679b3aa7
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.