Simplify number-optional-number parsing

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: longsonr, Assigned: longsonr)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
Created attachment 326334 [details] [diff] [review]
patch
Attachment #326334 - Flags: superreview?(roc)
Attachment #326334 - Flags: review?(roc)
Nice!

-    ReportAttributeParseFailure(GetOwnerDoc(), aAttribute, aValue);

We're losing these error reports. We really need to keep them.
(Assignee)

Comment 2

10 years ago
I don't think we are. The caller reports the errors using its existing mechanism. Not quite enough context to include it but it goes like this...

    if (foundMatch) {
      if (NS_FAILED(rv)) {
        ReportAttributeParseFailure(GetOwnerDoc(), aAttribute, aValue);
        return PR_FALSE;
      }
      aResult.SetTo(aValue);
      return PR_TRUE;
    }
Comment on attachment 326334 [details] [diff] [review]
patch

ok!

Are there any tests that cover this?
Attachment #326334 - Flags: superreview?(roc)
Attachment #326334 - Flags: superreview+
Attachment #326334 - Flags: review?(roc)
Attachment #326334 - Flags: review+
(Assignee)

Comment 4

10 years ago
We have partial coverage in that some of the reftests you wrote have number-optional-number types. I'll expand the SVG type mochitest when I do my next type conversion to do expanded number-optional-number testing.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.