347918 - evaluating new Date(1155064550775).toString() throws nsURLClassifierTable.js exception

Status: RESOLVED DUPLICATE of bug 347926

(Toolkit :: Safe Browsing, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

When I evaluate the expression "new Date(1155064550775).toString()" in the Error Console, the console correctly displays a message with the result of the expression ("Tue Aug 08 2006 12:15:50 GMT-0700 (PDT)"), but a moment later it displays the following exception:

Error: [Exception... "Component returned failure code: 0x804b000a [nsIURL.spec]" nsresult: "0x804x000a (<unknown>)" location: "JS frame :: file:///home/myk/Projects/minefield/mozilla/dist/bin/components/nsUrlClassifierTable.js :: anonymous :: line 566" data: no]

This doesn't happen on the 1.8 branch, only on the trunk.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Safe Browsing is observing loads in the Error Console's hidden iframe, and it's failing because that javascript: URL is not a valid standard-url.

Why is this code even creating a standard URL by contractid instead of using the IO service? I also see a bunch of other chrome urls passing through PROT_EnchashDecrypter.prototype.getCanonicalHost, is that expected? Seems to me like doing something for each chrome load is probably a waste of cycles, when Anti-Phishing only applies to content.

Comment 2

[Tony Chang (Google)]

(In reply to comment #1)

> Why is this code even creating a standard URL by contractid instead of using
> the IO service?

Hmm, that should definitely be fixed with a try/catch for invalid urls (it is fixed in toolbar, I must have missed it when up merging patches).

> I also see a bunch of other chrome urls passing through
> PROT_EnchashDecrypter.prototype.getCanonicalHost, is that expected? Seems to me
> like doing something for each chrome load is probably a waste of cycles, when
> Anti-Phishing only applies to content.

Expected per bug 341946 where we check all jar urls.  Not great, but safer than ignoring all of them.

Comment 3

[Tony Chang (Google)]

This should have been fixed in bug 347926.

The jar: uri issue should be fixed by bug 348360.

*** This bug has been marked as a duplicate of 347926 ***