Closed
Bug 778608
Opened 13 years ago
Closed 13 years ago
Move SafeBrowsing.jsm to toolkit
Categories
(Toolkit :: Safe Browsing, defect)
Toolkit
Safe Browsing
Tracking
()
RESOLVED
FIXED
Firefox 19
People
(Reporter: Dolske, Assigned: Dolske)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file, 4 obsolete files)
|
3.98 KB,
patch
|
Details | Diff | Splinter Review |
Other apps (mobile, b2g, webrt) will likely want to be using the code in SafeBrowsing.jsm. So let's move it to Toolkit. This leaves very little stuff in in browser/components/safebrowsing, so I've folded it into browser/base/content.
This is on top of the patch in bug 778606, and is not yet tested. ;-)
Attachment #647043 -
Flags: review?(gavin.sharp)
| Assignee | ||
Comment 1•13 years ago
|
||
Note to self, after this we should probably move Bugzilla's Firefox::PhishingProtection component over to Toolkit.
| Assignee | ||
Comment 2•13 years ago
|
||
Oops, forgot to fix a jar.mn path, but it seems to be working fine now.
Attachment #647043 -
Attachment is obsolete: true
Attachment #647043 -
Flags: review?(gavin.sharp)
Attachment #647046 -
Flags: review?(gavin.sharp)
| Assignee | ||
Comment 3•13 years ago
|
||
Oops again, tiny fix to makefiles.sh.
Attachment #647046 -
Attachment is obsolete: true
Attachment #647046 -
Flags: review?(gavin.sharp)
Attachment #647066 -
Flags: review?(gavin.sharp)
| Assignee | ||
Comment 4•13 years ago
|
||
Fixed few other small mistakes.
Mostly-green in https://tbpl.mozilla.org/?tree=Try&rev=dbacbd4d62f4
Fixed the M(oth) problem: https://tbpl.mozilla.org/?tree=Try&rev=028530f8507a
Attachment #647066 -
Attachment is obsolete: true
Attachment #647066 -
Flags: review?(gavin.sharp)
Attachment #648582 -
Flags: review?(gavin.sharp)
| Assignee | ||
Updated•13 years ago
|
Attachment #648582 -
Attachment is patch: true
Comment 5•13 years ago
|
||
Comment on attachment 648582 [details] [diff] [review]
Patch v.4
It really pains me to add more tests to browser/base, particularly well-grouped tests that could live somewhere else - a browser chrome run of browser-base takes way too long already. I guess I don't have a better suggestion at the moment, though :/
Attachment #648582 -
Flags: review?(gavin.sharp) → review+
| Assignee | ||
Comment 6•13 years ago
|
||
Comment 7•13 years ago
|
||
This patch caused "Timed out while waiting for: test #6 succesful finish" failures in browser_webconsole_bug_595934_message_categories.js on win debug; exactly like in your second try push.
Comment 8•13 years ago
|
||
| Assignee | ||
Comment 9•13 years ago
|
||
Exciting. I can't reproduce on a local win-debug build, nor is it at all obvious how that test could possibly be affected by this patch!
Time to debug via Try, I guess. :(
| Assignee | ||
Comment 10•13 years ago
|
||
The test (referenced in comment 7) is loading an invalid XML page, and watching for "no element found" to be logged in the error console via a console observer. So far it appears that the test is successfully loading the page, but the parsing goop simply isn't logging this message. So, still baffled as to what's happening.
Comment 11•13 years ago
|
||
Comment on attachment 648582 [details] [diff] [review]
Patch v.4
Review of attachment 648582 [details] [diff] [review]:
-----------------------------------------------------------------
::: toolkit/components/url-classifier/Makefile.in
@@ +20,5 @@
> +# Normally the "client ID" sent in updates is appinfo.name, but for
> +# official Firefox releases from Mozilla we use a special identifier.
> +ifdef MOZILLA_OFFICIAL
> +ifdef MOZ_PHOENIX
> +DEFINES += -DUSE_HISTORIC_SAFEBROWSING_ID=1
Could we avoid the MOZ_PHOENIX, or maybe move it to a branding prefs file? (probably as a separate bug) ... it tends to be a pain when we have app specific ifdefs in core (e.g. for xulrunner style builds etc). It'd also avoid the need for preprocessing the file.
Comment 12•13 years ago
|
||
As pointed out here https://bugzilla.mozilla.org/show_bug.cgi?id=741808#c4 there's also issues with this define for Fennec.
| Assignee | ||
Comment 13•13 years ago
|
||
A while back the thought occurred to me that the bizarre test failures this triggered before were likely just test timing issues. I trimmed down the patch to leave the tests in-place, and that's passed a few try runs at different times.
I keep forgetting to land it, though, so I'll do so now. Will file followup to move tests and finish debugging (if it's still reproducible).
Attachment #648582 -
Attachment is obsolete: true
| Assignee | ||
Comment 14•13 years ago
|
||
Pushed http://hg.mozilla.org/integration/mozilla-inbound/rev/70d9ba6b84f8
Filed bug 806757 to investigate moving the tests.
Comment 15•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
Updated•11 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•