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)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 29.0
People
(Reporter: gooyozh, Assigned: DomDenham)
References
Details
(Keywords: polish, ux-efficiency)
Attachments
(1 file)
1.84 KB,
patch
|
mkmelin
:
review+
bwinton
:
ui-review+
|
Details | Diff | Splinter Review |
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.
Comment 1•12 years ago
|
||
(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
Updated•12 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: polish,
ux-efficiency
OS: Linux → All
Hardware: x86 → All
Assignee | ||
Comment 3•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
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!
Assignee | ||
Comment 7•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Comment 8•10 years ago
|
||
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+
Updated•10 years ago
|
Keywords: checkin-needed
Comment 10•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 12•10 years ago
|
||
Please check this patch in. It fixes an important UI usability bug.
Comment 13•10 years ago
|
||
That's why checkin-needed was added. Someone will check it in once the tree opens again - https://tbpl.mozilla.org/?tree=Thunderbird-Trunk
Comment 14•10 years ago
|
||
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
Comment 15•10 years ago
|
||
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?
Comment 16•10 years ago
|
||
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?
Comment 17•9 years ago
|
||
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.
Description
•