GNOME Bugzilla – Bug 142143
Epiphany stored URL's that you haven't explicitly visited in history
Last modified: 2010-02-12 15:38:05 UTC
[Using Epiphany 1.2.5] When visiting a page with Epiphany it currently stores not only the URL you visit, but also some other URL's that are unvoluntarily fetched (such as ad related URL's) in the browser history. Mozilla only stores the URL you have explicitly visited, which reduces history clutter (and makes going to a previous site from the location bar quicker, since less URL's are shown there). Below I will attach two screenshots - one from Mozilla and one from Epiphany - that clearly should show the difference in behaviour between Mozilla and Epiphany. I have taken OSNews.com as an example site, but the same thing happens on other sites as well.
Created attachment 27486 [details] Screenshot showing the history window in Mozilla after visiting OSNews.com As can be seen from this screenshot only the URL you explicitly visited - namely osnews.com - is stored in Mozilla's history.
Created attachment 27487 [details] Screenshot showing Epiphany's history window after visiting OSnews.com Epiphany also stores two other URL's that were apparently fetched when osnews.com was loaded. These are not useful to the user.
http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsGlobalHistory.cpp#590 has a bunch of checks for that, and they were introduced with the latest API changes in nsIGlobalHistory2/nsIBrowserHistory and not there before. Seems we should just copy that, marco?
chpe please wait on this until I land mozilla-embed-strings branch (when 1.7 is released)
*** Bug 137848 has been marked as a duplicate of this bug. ***
Created attachment 28145 [details] [review] port changes from mozilla
Created attachment 28153 [details] [review] patch as committed to gnome-2-6 I've committed something to gnome-2-6 branch which should fix this (this should happen on moz >= 1.7* only). Will commit to HEAD after string api port; attaching patch here for reference.
I understand from the above udpate that the above changes work fine only with moz >=1.7*. chpe: can you point out the corresponding Mozilla bug it depends on?. It would be useful for the people who are releasing the products based on mozilla 1.6.
I'm a bit confused by Christian comment. There are no defines in the patch so it should work also with mozilla 1.6. Christian did you mean that this bug should be reproducable with mozilla >= 1.7 only ?
Does this problem even exist using mozilla 1.6 ? As far as I know, the code I added in GlobalHistory existed in nsDocShell prior to the nsIGlobalHistory2 introduction, see http://bugzilla.mozilla.org/attachment.cgi?id=140724&action=view which is the final patch on bug http://bugzilla.mozilla.org/show_bug.cgi?id=224829 .
I reported the bug with Epiphany compiled against Mozilla 1.6, so the problem certainly exists there.
Ok, I think what needs to be done is to replace NS_IMETHODIMP MozGlobalHistory::HidePage(const char *url) { return NS_ERROR_NOT_IMPLEMENTED; } with a real implementation in GlobalHistory.cpp.
Christian, can you explain the status of this ? Is it fixed for mozilla 1.7 ?
Created attachment 28703 [details] [review] proposed fix Can someone who uses epiphany with mozilla 1.4, 1.5 or 1.6 please test this patch?
Marco: I cannot repro this using 1.8a2, and the GlobalHistory code is the same with 1.7.
The patch is only for gnome-2-6 branch, obviously.
Created attachment 28732 [details] [review] updated patch Seems we need to implement is for GlobalHistory2 too, it's called on redirects.
I had a patch which was very close to comment #14, that is working fine. Is there any specific testcase to test your updated patch?. This what I did in the hide page: I just called ephy_history_remove_page (mGlobalHistory, url); and implmented the ephy_history_remove_page(..) by calling ephy_node_unref(..) [similar to yours]
Committed. To test, use the URL from comment 1.
Re comment 17: it's not necessary to implement it on GlobalHistory2 (mozilla >= 1.7) after all, the only place that calls it is nsHistoryLoadListener.cpp which doesn't get built (and isn't even updated for the API change). I've therefore removed that again; only the case for mozilla <= 1.6 is really needed, i.e. the patch from attachment 28703 [details] [review].
This patch has introduced the following problems: - redirected pages doesn't show in autocompletion. So you type a page, it redirects (happens for example on wikipedia.org), you want it again but it doesn't autocomplete - pages loaded in frames don't show in history (only the toplevel load shows) Reopening.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
*** Bug 313756 has been marked as a duplicate of this bug. ***
I've removed the redirected-url check because of dup bug 313756.
Some notes from irc: tko there was a flag that indicated whether the page had been 'toplevel' document (as opposed to iframes etc. as I understood it) . you only show toplevel URLs in history searches tko if you alread have a URL in history as non-toplevel, and it comes in again with the toplevel flag set, upgrade it :)tko chpe, I update the history record every time, but record toplevel = false only if toplevel was previously undefined chpe and you omit !toplevel sites in the history window tko yep chpe should be relatively easy to port to ephy tko now, if you see a URL as iframe, it's !toplevel and doesn't show up in dialog. if you ever open the frame URL itself, the toplevel is recorded as TRUE and will never get downgraded tko and then of course there's the 'hide' flag which I was giving precedence, but I forgot the semantics tko I figured that it's better to record as much info as possible, then tweaking the UI becomes easier
You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you please check again if the issue you reported here still happens in a recent version and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!