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.
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
Last Resolved: 13 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.