URL classifier initializes PSM/NSS during startup if homepage is an HTTP page

RESOLVED FIXED in Firefox 19

Status

()

RESOLVED FIXED
10 years ago
5 years ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {perf})

unspecified
Firefox 19
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ts] fixed by bug 756313)

(Reporter)

Description

10 years ago
See bug 390324 for the code change that introduced this.  I certainly hit my PSM/NSS init breakpoint before a window is ever shown.  This does require that the homepage be something that the URL classifier will care about (so not about:blank), but I suspect that's the common case.

You'll need to apply the patch in bug 462806 to hit this, since without that we init PSM from the jar code.
(Reporter)

Comment 1

10 years ago
I should note that even with about:blank, all that happens is that we delay url-classifier load by 2 seconds, then we init NSS.  Maybe that's unavoidable, and maybe we're guaranteed that the window is mapped by then, even on slow hardware...

Comment 2

10 years ago
So we init PSM for nsCryptoHash, which we need to perform the lookup (the db stores hashed urls).  To fix this well, we'd need to separate out hash initialization from the rest of NSS initialization (see bug 424093).
Depends on: 448579

Comment 3

10 years ago
(In reply to comment #2)
> To fix this well, we'd need to separate out hash
> initialization from the rest of NSS initialization (see bug 424093).

Err, bug 448579
(Reporter)

Comment 4

10 years ago
Wait.  Why do we need to separate things out to fix this?  We could also fix PSM init to work from non-main threads and take out the "force init from main thread" code, no?  Or would we still need to hash before we get the HTTP response?
(Reporter)

Comment 5

10 years ago
I should also note that if we're not worried about the user's homepage being a phishing page we could skip url-classifying that one load.  I'm not sure we shouldn't worry about it, though.

Comment 6

10 years ago
(In reply to comment #4)
> Wait.  Why do we need to separate things out to fix this?  We could also fix
> PSM init to work from non-main threads and take out the "force init from main
> thread" code, no?  Or would we still need to hash before we get the HTTP
> response?

Yeah, we still need to hash before we get the response.  The blacklist doesn't contain urls, it contains hashes.  We need to hash the urls before we can look them up in the db.

Comment 7

10 years ago
(In reply to comment #5)
> I should also note that if we're not worried about the user's homepage being a
> phishing page we could skip url-classifying that one load.  I'm not sure we
> shouldn't worry about it, though.

Another, much more hacky, workaround would be to keep the hashes of homepage urls around somewhere so that we can skip initializing psm for them..
Whiteboard: [ts]
Blocks: 447581
I'm pretty sure that this bug was fixed by bug 756313. Please reopen if I am wrong.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Updated

6 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: WORKSFORME → FIXED
Whiteboard: [ts] → [ts] fixed by bug 756313
Target Milestone: --- → Firefox 19
(Assignee)

Updated

5 years ago
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.