As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 739221 - Remove nsIBrowserHistory::count
: Remove nsIBrowserHistory::count
: addon-compat, dev-doc-complete
Product: Toolkit
Classification: Components
Component: Places (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla15
Assigned To: Marco Castelluccio [:marco]
: Marco Bonardo [::mak]
Depends on:
Blocks: 739219
  Show dependency treegraph
Reported: 2012-03-26 07:35 PDT by Marco Bonardo [::mak]
Modified: 2012-05-07 08:17 PDT (History)
5 users (show)
ryanvm: in‑testsuite-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (3.17 KB, patch)
2012-05-02 13:25 PDT, Marco Castelluccio [:marco]
no flags Details | Diff | Splinter Review
Patch v2 (7.64 KB, patch)
2012-05-03 10:55 PDT, Marco Castelluccio [:marco]
mak77: review+ superreview+
Details | Diff | Splinter Review

Description User image Marco Bonardo [::mak] 2012-03-26 07:35:18 PDT
.count is basically a duplicate of .hasHistoryEntries, it has never reported the actual count.  We don't need two attributes providing the same information.
Comment 1 User image Marco Castelluccio [:marco] 2012-05-02 13:25:29 PDT
Created attachment 620451 [details] [diff] [review]
Comment 2 User image Marco Bonardo [::mak] 2012-05-03 09:34:58 PDT
Comment on attachment 620451 [details] [diff] [review]

Review of attachment 620451 [details] [diff] [review]:

You should also fix call points, replacing PlacesUtils.bhistory.count with PlacesUtils.history.hasHistoryEntries.  This is what I found so far:
Unfortunately sessionhistory has also a .count and is almost always called just history, so searching just for history.count generates lots of false positives due to sessionHistory.
I also tried to search for most common entries like browserHistory.count, browser_history.count, bh.count, hist.count and I couldn't find any use in add-ons mxr, so looks like there shouldn't be much trouble in the removal.

Once these are fixed will be worth to make a tryrun to check for eventual other call points.
Comment 3 User image Marco Castelluccio [:marco] 2012-05-03 10:55:25 PDT
Created attachment 620776 [details] [diff] [review]
Patch v2

Comment 4 User image Marco Castelluccio [:marco] 2012-05-04 06:34:09 PDT
I think we can land it now, as the failures seems unrelated. Do you agree?
Comment 5 User image Marco Bonardo [::mak] 2012-05-04 06:45:08 PDT
Comment on attachment 620776 [details] [diff] [review]
Patch v2

Review of attachment 620776 [details] [diff] [review]:

yep, though this needs SR cause of the idl change.
Comment 6 User image :Gavin Sharp [email:] 2012-05-04 16:44:05 PDT
Comment on attachment 620776 [details] [diff] [review]
Patch v2

Any idea what the potential add-on impact will be? It looks like we had no in-tree callers (outside of tests), so I imagine it should be minimal?
Comment 7 User image Marco Bonardo [::mak] 2012-05-05 04:52:55 PDT
(In reply to :Gavin Sharp (use for email) from comment #6)
> Comment on attachment 620776 [details] [diff] [review]
> Patch v2
> Any idea what the potential add-on impact will be? It looks like we had no
> in-tree callers (outside of tests), so I imagine it should be minimal?

I didn't find any caller in addons mxr, though as I said in comment 2 it's hard to search cause sessionhistory is often called history, and there are many history.count (I checked most of those and were all about sessionhistory).
Comment 9 User image Ryan VanderMeulen [:RyanVM] 2012-05-05 20:29:13 PDT
Comment 10 User image Eric Shepherd [:sheppy] 2012-05-07 08:17:05 PDT
Doc updated:

Listed on Firefox 15 for developers.

Note You need to log in before you can comment on or make changes to this bug.