892485 - History sidebar/Library scrolls to top when selected history entry is revisited

Status: NEW

(Toolkit :: Places, defect, P5)

Description

[Alice0775 White]

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/04d8c309fe72
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130710 Firefox/25.0 ID:20130710030205

Steps To Reproduce:
1. Open History Sidebar and Change mode to "By Last Visited"
2. Scroll sidebar tree
3. Click any link(history, bookmark or link in page)

Actual Results:
History sidebar scrolls to top

Expected Results:
Scroll position of the tree should not lost

Comment 1

[Alice0775 White]

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/8b1bfcf0ce6e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130602 Firefox/24.0 ID:20130603074139
Bad:
http://hg.mozilla.org/mozilla-central/rev/e8a328c3e5bb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130603 Firefox/24.0 ID:20130603125714
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8b1bfcf0ce6e&tochange=e8a328c3e5bb


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/2ff8cbefdf10
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130603 Firefox/24.0 ID:20130603075740
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/d8cfe163b77d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130603 Firefox/24.0 ID:20130603081941
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2ff8cbefdf10&tochange=d8cfe163b77d

Regressed by:
d8cfe163b77d	Marco Bonardo — Bug 874407 - new visits are inserted incorrectly in the Library and the sidebar treeviews. r=Mano


This is a recent regression! 
Should not remove tracking flag.

Comment 2

[Marco Bonardo [:mak]]

I think what happens is that the node is moved, and thus we move the view to its new position to ensure it's visible.

Comment 3

[Alex Keybl [:akeybl]]

Not critical enough to track for upcoming releases. Would consider a low risk fix.

Comment 6

[msth67]

Not to be unpolite,but this has surfaced in Firefox 22 and it's still there in Firefox 25 and all the pre-release versions that I've tried so far:and it's a very annoying bug,frankly.

Comment 7

[ukrainianconsular]

i'd say, one of the majors browser option msth lol
firefox v27, with all v28 beta releases still already available &:

unfixed.

Comment 8

[ukrainianconsular]

A temporary fix that's not perfect:

https://addons.mozilla.org/firefox/addon/bug892485_preventscrollonhi/

The addon has 3 other bugs:

1) if i make a search "by last visited", it disabled the addon, the scrollbar sends me back to the top.
2) if i try to click on the scrollbar arrow to slowly move up or down while a page is loading, the scrollbar sends me back to the top again .. .
3)  when i click on a link, the next link that's focused shouldn't be the one above, but always the "previous one", since i always revisit links from the last page accessed
in a specific position of the list .. .


This bug was introduced by:

Firefox Setup 22.0b4.exe

Comment 9

[ukrainianconsular]

& every ten minutes or so, it scrolls back to top, it's free ))

Comment 10

[msth67]

This is so weird,we have to rely on an addon to restore the proper functionality of the browser's history?
I mean,this bug has been around for quite a while now,and while a lot of effort is going into questionable non-core features like social integration or sponsored tiles,the browser's history correct behavior has to be fixed by an addon?
Thanks a lot to the addon author,it's not the first time he has to fix some weird stuff,but shouldn't this be addressed where it belongs?

Comment 11

[Marco Bonardo [:mak]]

Resources with knowledge of the history code are reduced, the team that is working on what you define "questionable features" would not work on this code regardless.
So, please be patient, or investigate the cause and post a patch here.

Moreover the behavior here is still undefined, when you click on a history link, in a unique-uri list, that link gets moved up into the list (the view doesn't allow duplicates and you are viewing by-last-visited), after it moves it gets reselected and correctly the code scrolls to it, otherwise you would have a selection out of the view.
the alternative is to select the next entry in the list, while that may be correct for this specific view, it may be wrong for many others. So it's possible we need options to define the selection behavior for each specific view, that makes the fix non-trivial.

Comment 12

[ukrainianconsular]

New addon update available:
https://addons.mozilla.org/firefox/addon/bug892485_preventscrollonhi/
Now 1.1 .. . author's pretention: fixes autoscroll

Result on ff 27.0.1 (stable release):

totally uneffective addon/"fix".

Comment 13

[msth67]

(In reply to Marco Bonardo [:mak] from comment #11)
> Resources with knowledge of the history code are reduced, the team that is
> working on what you define "questionable features" would not work on this
> code regardless.
> So, please be patient, or investigate the cause and post a patch here.

Sorry,it was not my intention to harass the people working on this specific issue:it just looked strange to me that an extension is currently needed to try to fix this bug.
As for "questionable features",well I stand by my definition:I suppose you too will agree that a fully functional,robust and versatile (think:queries) history & bookmarks database (on which I reckon you are working) is way more of a core function than social integrations or sponsored ads,of which you can have plenty with no need to bury them right into the browser.

> Moreover the behavior here is still undefined, when you click on a history
> link, in a unique-uri list, that link gets moved up into the list (the view
> doesn't allow duplicates and you are viewing by-last-visited), after it
> moves it gets reselected and correctly the code scrolls to it, otherwise you
> would have a selection out of the view.
> the alternative is to select the next entry in the list, while that may be
> correct for this specific view, it may be wrong for many others. So it's
> possible we need options to define the selection behavior for each specific
> view, that makes the fix non-trivial.

I didn't realize the fix had to be so complex,all I've noticed is that starting with Firefox 22 the usual behavior of the history sidebar was broken-BTW,I've tried the addon but apparently it doesn't fix the issue for this kind of visualization *by-last-visited*
Unfortunately,finding a fix is way beyond my reach,so I'll just be patient-thanks.

Comment 14

[ukrainianconsular]

i confirm it msth, & the fix's author tells me "it works for me". so there's nothing we can do at this level.

Comment 15

[ukrainianconsular]

by the way msth, you must have installed v1.1 of the addon, i listed the issues about the given addon above for 1.0, but it still works up to a level & its better than nothing, try not to update to v1.1, it seems to work for the author only for some reason. just keep that version:

https://addons.cdn.mozilla.net/_files/463298/bug892485_preventscrollonhistory-1.0-fx.xpi

until something new's offered.

Comment 16

[Marco Bonardo [:mak]]

(In reply to msth67 from comment #13)
> I didn't realize the fix had to be so complex,all I've noticed is that
> starting with Firefox 22 the usual behavior of the history sidebar was
> broken-BTW,

yes the behavior changed to what was originally designed (so the previous behavior was actually a bug), the fact it may not be what the user expects is another story that requires something more than a trivial patch.

Comment 18

[Colby Russell :crussell (no longer Mozilla-ing)]

(In reply to Marco Bonardo [:mak] from comment #16)
> yes the behavior changed to what was originally designed (so the previous
> behavior was actually a bug), the fact it may not be what the user expects
> is another story that requires something more than a trivial patch.

Could you share the details about why the original design called for this behavior to begin with?  (Alternatively, do you have a bug ID handy for the bug that "fixed" this?)

Comment 19

[Marco Bonardo [:mak]]

(In reply to Colby Russell :crussell from comment #18)
> Could you share the details about why the original design called for this
> behavior to begin with?  (Alternatively, do you have a bug ID handy for the
> bug that "fixed" this?)

Not very specific details, just that the views try to always keep visible the selected node. As I said, the fact it should be applied here is another story.

Comment 24

[ZeroUnderscoreOu]

Suggestion: while library window/history sidebar is open, prevent browsing history from updating and displaying new entries. If a new tab i opened, display a notification about this behavior in library window/history panel. Once they are closed, update browsing history.
I understand this is not a high priority issue but it really makes backtracking difficult.

Comment 25

[Russell Haley]

The core of the problem is bug 604295 from 11 years ago -- from a UX perspective, the "history" store only remembers the most recent visit, and re-visiting a page is a destructive operation. I'm not sure why this is. According to Marco Bonardo in bug 1479441, the backend does actually record the full history.

If it weren't for that problem, "keep selected node visible" would be entirely correct, because opening a history item would just create a new un-selected node at the top of the list.

Comment 27

[cathoderaydude]

(In reply to Marco Bonardo [:mak] from comment #11)

Moreover the behavior here is still undefined, when you click on a history
link, in a unique-uri list, that link gets moved up into the list (the view
doesn't allow duplicates and you are viewing by-last-visited), after it
moves it gets reselected and correctly the code scrolls to it, otherwise you
would have a selection out of the view.

I feel like the bigger question is, why is this a unique-URI list? It's tough for me to imagine a case where someone's particular desire is, "show me the last time a given URL was visited, out of all the times it has ever been visited" rather than, "show me a linear history of browser navigation." Surely the latter is the far more common desire, though I'm open to being surprised if there's data to the contrary. Wouldn't the best fix be to replace this with a simpler view that just lists each entry in-order with date of visit?

Comment 28

[cathoderaydude]

At a cursory glance, it looks like the structure of moz_places in places.sqlite (the Firefox history DB) mirrors this list view almost exactly. While the linear history is also stored, it's a separate table that does not store URIs, but instead references moz_places. I am assuming this DB layout choice was an optimization, so that answering the question, "when was this URL last accessed" didn't require walking tens of thousands of history entries.

I had assumed the unique URI list was taking linear DB data and filtering it into a view with a unique column, but it is not. Since it appears this is the natural layout of the DB table, fixing this bug would require writing a new display component that joins moz_historyvisits to moz_places; hence, non-trivial.

Comment 29

[cathoderaydude]

Beyond "non-trivial," it may not be possible to implement this to a degree of quality expected by the project without significant rework.

For instance, the "Title" column in the history manager corresponds to a column in moz_places, but there is no matching column in moz_historyvisits. In other words, only one title is ever remembered for a given URI, so the current DB structure is incompatible with the format of this view.

Producing a "full detail" history would require either: an adjustment to moz_historyvisits to add that column, with far-reaching code ramifications, as well as packing an order of magnitude more data into that table; or a completely different UI for "full history" mode that removes the "title" column - which would be pretty confusing, since you just asked for full history, yet received less data.

This may not be the only thing that's not being stored 1:1 for each history entry. So as frustrating as this is, it's a sticky problem.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 31

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 33

[[:nickname]blablablah]

https://www.youtube.com/watch?v=qmAYOcjD5XI

Here's a video of this "bug" or problem that needs enhanced.

Comment 34

[[:nickname]blablablah]

Why can't sorting results based on last visit date be ran only once when the history sidebar is initially opened? That way the behavior of scrolling back to the top when a result is revisited also becomes disabled in the process. I am not a coder, but that would be a more simplier approach than reworking the whole software program.

Comment 35

[printstyle]

So - "If it weren't for that problem, "keep selected node visible" ..." - Is it possible to code ff history behavior in this way : on click down temporarily save the selected link somewhere (cash); then shift selection one node up the history list and only after that open the cashed link in background ?

Comment 37

[rballsyck]

Can we get an update on when this will ever get fixed? 10 Years is too long for such a design flaw like to not get addressed. While it may not be as urgent as something like a security vulnerability, this "bug" (more like design flaw), makes it VERY DIFFICULT to search through your history list when that list constantly gets reset back to the top upon clicking on a result. It's like trying to have a conversation with someone with a 10 second attention span.

Comment 38

[rballsyck]

Why are my comments being hidden for "advocacy"? Do I have to send a letter to the Mozilla corporate office? You are suppressing the user's right to provide feedback, which is one of Mozilla's "principles". You moderators are deliberately silencing constructive criticism because it is more convenient to silence your dissonance than to address it. Despicable.

Comment 39

[rballsyck]

Can we get an update on when this will ever get fixed? 10 Years is too long for such a design flaw like to not get addressed.

Does this part sound like "advocacy"? Am I "advocating" too much by requesting an answer for clearly a bug that was abandoned because it would take too much to fix? It just goes to show the comments Mozilla hides are the most showing of their own principles.

Comment 40

[rballsyck]

Go ahead mods, disable my account for critising your ethics and lack of user support. I will send you letters that you would not be able to ban. Go ahead and push my button.

Comment 41

[Sylvestre Ledru [:Sylvestre]]

rballsyck, this is a polite reminder that this is our professional working environment as much as it is our issue tracker, and I'm asking you to refrain from making further comments that don't move this bug towards a resolution.

Comment 43

[Chris Bellini (:cbellini)]

We should retain the position to mitigate the jarring jump as part of upcoming UX enhancements.