Last Comment Bug 739221 - Remove nsIBrowserHistory::count
: Remove nsIBrowserHistory::count
Status: RESOLVED FIXED
: 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]
:
Mentors:
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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
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+
gavin.sharp: superreview+
Details | Diff | Splinter Review

Description 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 Marco Castelluccio [:marco] 2012-05-02 13:25:29 PDT
Created attachment 620451 [details] [diff] [review]
Patch
Comment 2 Marco Bonardo [::mak] 2012-05-03 09:34:58 PDT
Comment on attachment 620451 [details] [diff] [review]
Patch

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:
http://mxr.mozilla.org/mozilla-central/search?string=bhistory.count
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 Marco Castelluccio [:marco] 2012-05-03 10:55:25 PDT
Created attachment 620776 [details] [diff] [review]
Patch v2

Try: https://tbpl.mozilla.org/?tree=Try&rev=7aa2e9385e09
Comment 4 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 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 :Gavin Sharp [email: gavin@gavinsharp.com] 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 Marco Bonardo [::mak] 2012-05-05 04:52:55 PDT
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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 Ryan VanderMeulen [:RyanVM] 2012-05-05 20:29:13 PDT
https://hg.mozilla.org/mozilla-central/rev/790a7f291c9d
Comment 10 Eric Shepherd [:sheppy] 2012-05-07 08:17:05 PDT
Doc updated:

https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIBrowserHistory

Listed on Firefox 15 for developers.

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