Closed
Bug 371409
Opened 17 years ago
Closed 17 years ago
canonicalNum_ fails with 7 hex digits
Categories
(Toolkit :: Safe Browsing, defect)
Toolkit
Safe Browsing
Tracking
()
RESOLVED
FIXED
People
(Reporter: bryner, Assigned: tony)
References
Details
(Keywords: fixed1.8.1.4)
Attachments
(2 files)
6.02 KB,
patch
|
bryner
:
review+
|
Details | Diff | Splinter Review |
3.30 KB,
patch
|
bryner
:
review+
dveditz
:
approval1.8.1.4+
|
Details | Diff | Splinter Review |
canonicalNum_ fails to parse a number like 0x1234567, because it takes the last 8 characters so the "x" is the first character. parseInt() isn't able to parse that. It should probably substitute \1 from the IS_HEX regexp, which trims off the leading 0x.
Assignee | ||
Comment 1•17 years ago
|
||
This rolls together fixes for this bug, bug 371412, and bug 371414.
Attachment #256435 -
Flags: review?(bryner)
Assignee | ||
Comment 4•17 years ago
|
||
From bug 371412: When parsing an address like "1.2.3.00x0", parseIPAddress ignores the failure return from canonicalNum for the last octet, and returns a bogus IP address. It should fail immediately so that the hostname remains unchanged. From bug 371414: When parsing an IP address like "12.34.56.78 xy", we should ignore the space and everything after it. This is to match what Windows does when resolving the host. The exact test should be something like this: if (host.length <= 15 && (host matches "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) ") { host = (match); } before testing against POSSIBLE_IP.
Reporter | ||
Comment 5•17 years ago
|
||
Comment on attachment 256435 [details] [diff] [review] fixes to parseIPAddress >Index: tests/test_bug371409.xhtml It seems like it would be clearer to have all of the IP address parsing tests together, rather than creating a new test file for each bug. But if this is generally the convention for unit tests, I guess it's ok. Looks good.
Attachment #256435 -
Flags: review?(bryner) → review+
Assignee | ||
Comment 6•17 years ago
|
||
On trunk. I moved the tests into test_bug356355.xhtml file to be close to the other tests as you mentioned. There's no real convention here. Checking in content/enchash-decrypter.js; /cvsroot/mozilla/toolkit/components/url-classifier/content/enchash-decrypter.js,v <-- enchash-decrypter.js new revision: 1.11; previous revision: 1.10 done Checking in tests/test_bug356355.xhtml; /cvsroot/mozilla/toolkit/components/url-classifier/tests/test_bug356355.xhtml,v <-- test_bug356355.xhtml new revision: 1.4; previous revision: 1.3 done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•17 years ago
|
||
same as above except for branch (no mochitests)
Attachment #256508 -
Flags: review?(bryner)
Attachment #256508 -
Flags: approval1.8.1.3?
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.8.1.3?
Reporter | ||
Comment 8•17 years ago
|
||
Comment on attachment 256508 [details] [diff] [review] branch patch This is missing the new files.
Assignee | ||
Comment 9•17 years ago
|
||
Which new files?
Reporter | ||
Comment 10•17 years ago
|
||
Comment on attachment 256508 [details] [diff] [review] branch patch Oops, sorry I was thinking of your other patch.
Attachment #256508 -
Flags: review?(bryner) → review+
Updated•17 years ago
|
Flags: blocking1.8.1.4? → blocking1.8.1.4+
Comment 11•17 years ago
|
||
Comment on attachment 256508 [details] [diff] [review] branch patch approved for 1.8 branch, a=dveditz for drivers
Attachment #256508 -
Flags: approval1.8.1.4? → approval1.8.1.4+
Assignee | ||
Comment 12•17 years ago
|
||
on branch Checking in content/enchash-decrypter.js; /cvsroot/mozilla/toolkit/components/url-classifier/content/enchash-decrypter.js,v <-- enchash-decrypter.js new revision: 1.1.2.6; previous revision: 1.1.2.5 done
Keywords: fixed1.8.1.4
Updated•10 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•