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

RESOLVED DUPLICATE of bug 347926

Status

()

Toolkit
Safe Browsing
RESOLVED DUPLICATE of bug 347926
12 years ago
4 years ago

People

(Reporter: myk, Assigned: Tony Chang (Google))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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.
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.
Component: Error Console → Phishing Protection
OS: Linux → All
QA Contact: javascript.console → phishing.protection
Hardware: PC → All
(Assignee)

Comment 2

12 years ago
(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.

Assignee: nobody → tony
(Assignee)

Comment 3

12 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.