114782 - don't set browser.history.last_page_visited if not needed

Status: RESOLVED FIXED

(Core Graveyard :: History: Global, defect, P3)

Description

[Jeremy M. Dolan]

Unless Nav is set to display the last page visited on startup,
browser.history.last_page_visited shouldn't be set or writen to the prefs, for
performance and privacy reasons. (user could clear cookies and cache, but the
pref will still be around)

Comment 1

[Brian Nesse (gone)]

This belongs to history. I'm not sure whether it's session or global though.
Guessing global...

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Taking, I have a patch in the works for this.  The perf issue really isn't that
big here since we have to either read or set the pref in this case.  However, we
can get a perf win by not getting a new pref service for each page load.  My
patch will do that too.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch v.1.0

Uses our new pref APIs and caches the prefbranch we use so as not to keep
creating them for every page load.  Fixes this bug by checking the pref in C++
and not setting anything if the user doesn't want to track their last visited
page, and fixes JS code to do the right thing when we switch between prefs. 
Plus makes the buttons work as they should (Set to current page is disabled if
the home page is the current page, same for set to default).

Comment 4

[Blake Ross]

Comment on attachment 93057 [details] [diff] [review]
Patch v.1.0

sr=blake

Comment 5

[Alec Flett]

Comment on attachment 93057 [details] [diff] [review]
Patch v.1.0

sr=alecf
nice cleanup!

Comment 6

[Alec Flett]

Comment on attachment 93057 [details] [diff] [review]
Patch v.1.0

oops, that sr was blake's
r=alecf

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

Drivers say this won't make 1.1.

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

Checked into trunk