Closed Bug 211167 Opened 21 years ago Closed 19 years ago

Bookmark sticks and jumps on initial Mouse Wheel use

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jimstew, Assigned: p_ch)

Details

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4; en-US; rv:1.5a) Gecko/20030602
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4; en-US; rv:1.5a) Gecko/20030602

Sometimes the Bookmark line does not work properly initially when using the
mouse wheel.  Depending on where the mouse approaches the bookmark page and
which initial highlighted line appears the mouse wheel doesn't work properly.

If the initial highlight is down the page eight or so lines then the mouse wheel
works correctly.  On the other hand if the mouse induced highlight starts at the
top of the page the mouse wheel is erratic.

This condition can be best described as the bookmark stuck on home position and
requiring a good kick to get it going.

Once the erratic bookmark has started the bookmark is on line one and the mouse
wheel moves it down just as it should, but after scrolling down it jumps right
back to the top line.

After this condition has started it continues in some cases even after you use
the normal mouse function to move the bookmark down the page.  This can result
in the highlighted bookmark being in the middle of the page and returning to
that position regardless of mouse wheel action.

This incorrect action will continue until you use the normal mouse to move the
down to the bottom of the displayed page and move the page up at least one line.
 This has the result of "kick starting" it and from then on the mouse wheel
works correctly.

I also saw this in OS/2 RC2, but can not say prior to that.



Reproducible: Sometimes

Steps to Reproduce:
1. Bookmarked pages should be longer than one page, possibly two or three pages
2. Mouse wheel must be installed 
3.
What mouse driver are you using for your scroll mouse?
Do you still see this?
OS: other → OS/2
Yes I still see this problem.  You may recall that there was a bug reported in
upgrading from 1.4.1 to 1.4.2 so I'm still at Mozilla/5.0 (OS/2; U; Warp 4.5;
en-US; rv:1.4.1) Gecko/20031229.  The Mouse wheel is AMouse SERVICELEVEL '020500'


In the mean while I've upgraded my system from 300 MHz to 2.8 GHz so that is not
an issue.  I believe that with more usage that I can give you a more accurate
description of the problem I see.

First, in order to see the problem I believe you must have several pages of
bookmarks.

If you open bookmarks and "stop" the mouse pointer at the top line (with the up
arrow) the internal counters have a chance to get it together and everything
works as it should.

On the other hand if you quickly pass the first line or bypass the first line
then somehow the internal counters related to the mouse wheel are confused and
the operation is erratic.  At this point you must move the pointer to the top
line and allow the internal stuff to get it together. I'm assuming that some
internal counters get reset to an initial starting point.   

I've had difficulty the last few weeks downloading any updates, not sure why
seems mozilla ftp site is having problems.  If you want me to try another 1.4.1
I'll be happy to do that.  I've been slow to move to 1.4.2 because of the
problem where 1.4.1 conversions cause loss of email sticky sort which you are
aware of.  Going to 1.4.2 will take a complete setup from scratch on my part and
every time I try to get the new code it bombs 1/3 of the way through because the
mozilla ftp site cannot hang with me long enough on a 56kb dial line.

If you want follow up on my part please advise and I'll do what I can.      
In your amouse driver, what are you using for scroll mouse emulation?

There is a page where you specify arrow keys or the like.
I'm not sure about your question on emulation.

I have:
Comet Cursor = ON
Wheel Speed = 3
Pointers = Large

Tried turning off (or 1) each of these one or two at a time and thought
this was the answer because the problem was harder to reproduce.  With
all three of these off I first thought the problem was fixed but after
really working at it I was able to reproduce the problem.  This may be
due to practice on my part and it explains why most people using a
vanilla environment do not see the problem.

It's a timing thing where you must get reset at home position or you will
have the jumping condition.  Customizing the mouse settings would affect
timing and definitely aggravates the problem.

One more note is that after you have the jumping condition you can get the
internals to reset by going to the last position down arrow in addition to
the top  up arrow.

When you use your scroll mouse in the bookmarks window, does it actually move
the highlight?

Or just it just scroll the window?
Normal mouse movement moves the highlight to the bottom or top which then forces
the list to move to accommodate the continued highlight directional movement.

Using the wheel is different!  The highlight sticks to the particular item where
the mouse movement last left it.  The wheel action causes the list to move up or
down and continued wheel action will move many lines even to the extent of
moving the highlight off the page.  Normal action after wheel list movement is
the list stops where you put it with the mouse arrow.  Then the slightest mouse
movement or a click will cause the highlight to move to the "arrow" position.

Wheel action when jumping:  highlight starts under arrow, arrow doesn't move and
indicates new correct intended list item, list and highlight move up or down per
wheel instructions, when wheel stops list and highlight jump back to original
position with highlight under arrow.
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

I still believe this is a valid problem and experience it daily.
Currently I'm using ecs 1.2 and Mozilla/5.0 (OS/2; U; Warp 4.5; en-US;
rv:1.7.10) Gecko/20050726

A little background is in order which may explain why I see it and others do
not.  I still use dial up 56kb which is slow but by using 5 browser sessions and
rotating through I read one while others are loading.  This may not be a good
idea but it works well for me.  I suspect that the five sessions puts stress on
the clock cycles or something like that for the browser session I'm using which
results in the jumping bookmark.  This would suggest that the five browser
sessions is a big mistake, but I also see the problem with only two browser
sessions just not very often. So with five sessions I see it almost every time I
use the bookmark and with two sessions it's so little that you might have
trouble reproducing it.

Specific instructions for reproducing the problem:
1. A large bookmark list of more than two times the page list length is required.
2. Use five active browser sessions.
3. Alternatily using all five sessions use the bookmarks as indicated below. 

Note: It appears that the bookmark counter resets to home when the cursor is
dragged down over the (top) up arrow line.  If you slow down or stop over this
up arrow line then the counter is properly reset and it works normally.  If on
the other hand you drag the cursor very fast down to the middle of the list 
then this "reset to home" is missed and the erratic bookmark jumping problem
starts.  When the problem starts you can solve the problem by moving the cursor
 to the top up arrow position and the "reset to home" takes place.      

My current machine is 1.8 GHz so it's not a slow machine problem and as I've
said I on occasion see the problem with two sessions, but with five sessions it
so bad that I must make a point to slow down and do the "reset to home"
procedure or it will show up 1 in 3 uses.      


James, I am not sure that I understand correctly what the problem is. Let me summarize what I tried (with SeaMonkey 1.8 20051212 and Mozilla 1.7.12 20050923):

- Added lots of bookmarks to make my bookmarks listing much
  longer than my screen height
- Pressed the Bookmarks menu item (or the Bookmarks button in 
  the Personal Toolbar) to open the list
- Positioned the mouse somewhere in the list of bookmarks and
  rolled the scrollwheel down and up again
  -> bookmarks are scrolling down and up again
- Positioned the mouse at the top of the bookmarks list, in
  the same line as the arrow, rolled the scrollwheel down
  -> bookmarks are scrolling down and then up again
- Positioned the mouse at the bottom of the screen, in the same
  line as the downwards arrow
  -> bookmarks begin to scroll down
  While there scroll upwards
  -> bookmarks scroll upwards then downwards again
- Position mouse at the top of the bookmarks list, over the
  item "Bookmarks this page", scroll down with wheel
  -> bookmarks scroll down
- Move the mouse over the menu item Window
  -> Window menu is opened
  then move back again other menu item Bookmarks
  -> bookmarks list is opened at the scroll position that I
     left it

Hmm, I can see nothing wrong with this behavior. Which part works differently for you?
Peter, Thanks for your follow up and your detailed test setup.
Yes I agree that your test which follows is the correct operation
and what is expected.  That is exactly how it works most of the
time.  Below in your example I have indicated where and how
the problem occurs.

------------------------------------------------------------
- Added lots of bookmarks to make my bookmarks listing much
  longer than my screen height
- Pressed the Bookmarks menu item (or the Bookmarks button in
  the Personal Toolbar) to open the list
- Positioned the mouse somewhere in the list of bookmarks and
  rolled the scrollwheel down and up again
  -> bookmarks are scrolling down and up again

    >>> the float problem occurs in the above line
    >>> this is the point of failure
    >>> when the scrollwheel stops the bookmarks float back

    >>> <start problem description>
    >>>   assumes first use after web page update
    >>>   move pointer quickly through first line
    >>>   or move pointer around first line
    >>>   the problem occurs here while using the scrollwheel
    >>>   bookmarks and highlight scroll up normally
    >>>    -> but then float back to middle start point
    >>>   bookmarks and highlight scroll down normally
    >>>    -> but then float back to middle start point

    >>> <start fix>
    >>>   move pointer to top or bottom (up down arrow) line
    >>>   (internal counters get it together and synchronize)
    >>>   move pointer to center of bookmarks and scrollwheel
    >>>     -> "bookmarks are scrolling down and up again"
    >>>     -> scrolling stops and locks at desired position
    >>> <end fix>

    >>>   internal counters remain fixed until a new web page
    >>>   trouble may or may not occur on next 6 or 8 try's
    >>> <end problem description>

- Positioned the mouse at the top of the bookmarks list, in
  the same line as the arrow, rolled the scrollwheel down
  -> bookmarks are scrolling down and then up again
- Positioned the mouse at the bottom of the screen, in the same
  line as the downwards arrow
  -> bookmarks begin to scroll down
  While there scroll upwards
  -> bookmarks scroll upwards then downwards again
- Position mouse at the top of the bookmarks list, over the
  item "Bookmarks this page", scroll down with wheel
  -> bookmarks scroll down
- Move the mouse over the menu item Window
  -> Window menu is opened
  then move back again other menu item Bookmarks
  -> bookmarks list is opened at the scroll position that I
     left it
-------------------------------------------------------------
The problem as I see it is that a registration/synchronization
process must take place for the scrollwheel at the first line
(up arrow) or last line (down arrow).  When this "registration"
takes place then the scrollwheel works correctly.  When the
pointer slips by this "registration" process due to some speed?,
tick?, clock?, busy? problem then the float problem occurs.
It is fixed by manually going to top or bottom and registering
the pointer, then everything works as designed.

Again, I'm using a dial modem and five repeat five browser
sessions with one mail session on a fast machine.

Jim

OK, I didn't understand your description very well but after reading it several times I think I have an idea what you mean:

- Click on bookmarks menu in main menu
  -> bookmarks list opens
- move mouse quickly onto one items near the top that does
  not have a submenu (like "Manage Bookmarks...")
- Scroll the wheel downwards
  -> bookmarks list scrolls down
- Stop scrolling
  -> bookmarks list scrolls upwards again as if positioned
     over the upwards arrow at the top

Yes, I indeed see that happening in Mozilla 1.7.12, but to me it works fine in a recent SeaMonkey (the successor of the Mozilla suite) build, so I tend to mark this bug WORKSFORME.

Please give SeaMonkey 1.0a or a current nightly build of SeaMonkey a try (i.e. http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-trunk/seamonkey-1.5a.en-US.os2.zip) and reopen the bug if you can still reproduce the problem there. (It should not interfere with your profile but please make a backup first.)
As said, works with SeaMonkey. Jim, when you find the time to switch and discover that it doesn't help for you, please reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
(In reply to comment #13)
> As said, works with SeaMonkey. Jim, when you find the time to switch and
> discover that it doesn't help for you, please reopen.
> 
Peter,  I switched over to seamonkey around January 1 and the bookmark problem (# 211167) is fixed in seamonkey.  The bookmark sticks like glue to it's correct location.  Looks to me like the internals are much faster with this operation which may be why.

I also note that two other problems I was having are resolved:  

1) While composing in mail the spaces between words indicated by cursor position were stored but not always pushed out to the display. This caused confusion for a two fingered typist.

2) My thinkpad P166 had worked fine with netscape 4.61 but was dying with all flavors of mozilla.  I don't now why but it works well with seamonkey, maybe it's the internals have been cleaned up or are faster.

Jim
You need to log in before you can comment on or make changes to this bug.