Closed Bug 731612 Opened 12 years ago Closed 10 years ago

Clicking "More" button in search results triggers scrolling to the top of list.

Categories

(Thunderbird :: Search, defect)

10 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 29.0

People

(Reporter: gooyozh, Assigned: DomDenham)

References

Details

(Keywords: polish, ux-efficiency)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120228 Firefox/13.0a1
Build ID: 20120228031102

Steps to reproduce:

Do a global email search (f.e. via Ctrl-K). 
If result list is long enough "More" button appears at the bottom. 
Click on "More" button.


Actual results:

Next portion of matched emails is loaded which is OK. But simultaneously view "jumps" almost to the top of list which requires user to scroll down back to where he was before clicking "More".


Expected results:

Scrolling should not happen, user should be left where he was before clicking "More" button.
(In reply to Artem Karpenko from comment #0)
Agreed. When you press "more", you get the next 10 search results added to the list, and the view scrolls and you no longer see the previous message. You have to scroll down again to see it.
User Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
Application Build ID: 20120216022139
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Please see the attached patch.

This issue is partly caused by the broken function ensureNodeVisible in glodaFacetBindings.xml, this patch fixes this (it now includes the current scroll position in the scrollTo calculation) which would allow the intended functionality of scrolling automatically to the top most item of the next set of 10 shown.

However as this bug reported the expected functionality is for no scrolling to occur (which I agree with, it felt odd having it jump down automatically) I've also removed the call to this function completely.

I don't believe ensureNodeVisible is used by anything else, but it made sense to fix it anyway.

Can I have this assigned to me.
Attachment #8354920 - Flags: review?(bugmail)
Assignee: nobody → DomDenham
Thanks for taking a crack at this, Dom!
Comment on attachment 8354920 [details] [diff] [review]
gloda search no longer scrolls when clicking more and ensureNodeVisible function in glodaFacetBindings.xml fixed

Thanks for the patch!

I'm not a reviewer anymore for Thunderbird; I think this may fall under the general Thunderbird module now, so a peer like Magnus (see https://wiki.mozilla.org/Modules/Thunderbird) is probably the way to go.  If you want to change the scrolling behaviour, then this needs UX sign-off via the "ui-review" flag, which is either :bwinton or :mconley.  The wiki page above is not clear on who to use for that.  I'll see if I can find that out and update it.  I'll flag them now because since this is currently pretty broken, arguably any behaviour other than the current one is a major improvement! :)

To the best of my memory, the intent of the scrolling logic was that if you hit 'more' so that we were now showing messages 11-20, we would scroll them so that 11 was the first message on the screen.  That way you wouldn't have to click and then scroll; if you wanted to see more messages, why not help you see them as soon as possible?  (Of course, this could potentially still annoy the user if they expect/want to manually scroll the messages on screen, especially if they scan as messages cross 'the fold'.)  The idiom today would probably just to do infinite scrolling once we get down to the bottom of the list.  (Although that would be a somewhat dangerous change to make currently.)

I agree ensureNodeVisible is only used at that one spot, so if the decision is to go with not triggering scrolling at all, the code should be removed.
Attachment #8354920 - Flags: review?(bugmail) → ui-review?(bwinton)
Personally I think any time you move the viewpoint when hitting the "more" you cause the viewer to re-figure out where they were ...this is a mental dystopia that ought to be avoided by just adding more down the bottom so no text jumps around.  I have tons of messages where the reply goes on the bottom or theres a header block at the top of the message so all the matches "look" identical with the little preview ... so its a huge pain to figure out which ones I've seen already if it "jumps".  Please just have it add "more on the bottom" so I can continue to scroll and click to view without moving anywhere..

thanks!
Comment on attachment 8354920 [details] [diff] [review]
gloda search no longer scrolls when clicking more and ensureNodeVisible function in glodaFacetBindings.xml fixed

It seems the general opinion is towards no automated scrolling, so I'd like to push this forwards if possible for the sake of making the gloda search more usable as this has been broken for so long.
Attachment #8354920 - Flags: review?(mkmelin+mozilla)
Status: NEW → ASSIGNED
Comment on attachment 8354920 [details] [diff] [review]
gloda search no longer scrolls when clicking more and ensureNodeVisible function in glodaFacetBindings.xml fixed

Review of attachment 8354920 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, and i agree it's an improvement. r=mkmelin
Going forward it would be nice to implement an infiniscroll type of behavior so people don't normally have to click "more". But that's another topic for another bug.
Attachment #8354920 - Flags: review?(mkmelin+mozilla) → review+
(still pending ui-r)
Keywords: checkin-needed
Comment on attachment 8354920 [details] [diff] [review]
gloda search no longer scrolls when clicking more and ensureNodeVisible function in glodaFacetBindings.xml fixed

I agree with pretty much everything Magnus said.  ui-r=me.

Thanks,
Blake.
Attachment #8354920 - Flags: ui-review?(bwinton) → ui-review+
Keywords: checkin-needed
Please check this patch in. It fixes an important UI usability bug.
That's why checkin-needed was added. Someone will check it in once the tree opens again - https://tbpl.mozilla.org/?tree=Thunderbird-Trunk
https://hg.mozilla.org/comm-central/rev/3004aa37ac7f
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 29.0
Thanks for everyone re this very frustrating problem.   My version of Thunderbird is 24.4.0 and it thinks it is up-to-date.   How long do I have to wait for this update to be implemented in Thunderbird 29???  Or is there some way I can do it now?  Thunderbird used to behave properly in this respect and I cannot believe it has taken so long for someone to have a go at it.  As far as I am concerned this is NOT "Resolved Fixed" until I have access to the fix.

Regards,

Peter
Flags: needinfo?
You can always use nightly or beta - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/
The target milestone tracks nightly.
Flags: needinfo?
Thanks again to Dom and everybody else who helped get this fixed.  Every time I do a search and remember to go for the workaround (having to jump to the end and load several "More" clicks before starting to look at any results) and I remember this is fixed, I'm thankful for the patch.  Thanks again!
You need to log in before you can comment on or make changes to this bug.