Scroll wheel doesn't work after selecting bookmark from toolbar until you move mouse.

RESOLVED FIXED in mozilla1.8beta5

Status

Core Graveyard
Widget: Mac
RESOLVED FIXED
13 years ago
8 years ago

People

(Reporter: Drew D. Saur, Assigned: Mark Mentovai)

Tracking

({fixed1.8})

Trunk
mozilla1.8beta5
PowerPC
Mac OS X
fixed1.8
Dependency tree / graph
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040812 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040812 Firefox/0.9.1+

Mouse scroll wheel doesn't work after selecting bookmark from the bookmarks
toolbar until after you have moved your mouse. Same problem does not occur if
you select a bookmark from Bookmarks menu.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

13 years ago
confirm.

>Same problem does not occur if
you select a bookmark from Bookmarks menu.

In almost all cases, if Bookmark is chosen from the Bookmark menu, I will think
that a mouse pointer is in the page display domain of a browser window.
That is, a mouse is in the place of a thing to make it scroll.

Probably, it will be the same when Bookmark in the Bookmark folder registered
into Bookmark Toolbar is chosen.
But in this case, it does not work.
if a mouse pointer is moved, it will work.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7.2) Gecko/20040812
Firefox/0.9.1+

Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

13 years ago
Yes, I just went out for a run and thought about this and figured I needed to be
clearer:

This happens when I am selecting a bookmark from a *drop-down* (i.e., folder) in
the bookmarks menu, where the mous pointer *does wind up* in the "page display
domain" where it would make sense for the scroll wheel to automatically work. I
would understand the behavior in the case where my mouse wound up remaining in
the bookmark menu bar domain.

FWIW, I have gone back and verified that this problem exists in 0.9.3 as well! I
just never noticed it before. 

Drew

(In reply to comment #1)
> confirm.
> 
> >Same problem does not occur if
> you select a bookmark from Bookmarks menu.
> 
> In almost all cases, if Bookmark is chosen from the Bookmark menu, I will think
> that a mouse pointer is in the page display domain of a browser window.
> That is, a mouse is in the place of a thing to make it scroll.
> 
> Probably, it will be the same when Bookmark in the Bookmark folder registered
> into Bookmark Toolbar is chosen.
> But in this case, it does not work.
> if a mouse pointer is moved, it will work.
> 
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7.2) Gecko/20040812
> Firefox/0.9.1+
> 
> 

(Reporter)

Comment 3

13 years ago
I have just confirmed that this issue does *not* exist in the Windows version of
Firefox.

Drew

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.2) Gecko/20040812 Firefox/0.9.1+
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.2) Gecko/20040812 Firefox/0.9.1+
> 
> Mouse scroll wheel doesn't work after selecting bookmark from the bookmarks
> toolbar until after you have moved your mouse. Same problem does not occur if
> you select a bookmark from Bookmarks menu.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.
> 2.
> 3.
(Reporter)

Updated

13 years ago
Version: unspecified → 1.0 Branch

Comment 4

12 years ago
Confirm, I am using dialy build Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.8b2) Gecko/20050320

I can't use mouse wheel to scroll in extended view for Bookmark this page...
(cmd-d).

Seems to be here for a very long time already.
(Reporter)

Comment 5

12 years ago
I'm wondering here, hearly 9 months later - am I the only person in the world
who actually *cares* if this bug is fixed, or even notices it? I think a lot of
other people are probably having it happen, but don't really realize what is
going on.

Can I do anything to help clarify this bug? It's pretty obvious - and annoying -
once you realize what it is and how it happens (and how often)!

Please let me know. Thanks,

Drew

Updated

12 years ago
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
Version: 1.0 Branch → unspecified
(Assignee)

Comment 6

12 years ago
This isn't a bug, it's the correct and intended behavior.  Scroll wheel focus is
dictated by cursor position.  If it's not pointing at something scrollable, it
shouldn't scroll.  I admit that it seems a little bit odd to not scroll a simple
page when the cursor is in the toolbar area, but there's no good way to handle
this when windows might contain multiple scrollable frames.

The current behavior is precisely what other Mac applications implement.  Give
Mail or the Finder a try.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Component: Toolbars → OS Integration
Resolution: --- → INVALID
(Reporter)

Comment 7

12 years ago
In the scenario I describe, the mouse is over the *web page content,* since the
drop-down menu disappears once you have made your selection from it. This is a
VERY hard bug to describe and for people to understand - hence my clarification
in post #2. Please re-read carefully to see what I am talking about.

And, of course, the bug still exists in the 1.5 alphas. Sigh.....

Drew

(In reply to comment #6)
> This isn't a bug, it's the correct and intended behavior.  Scroll wheel focus is
> dictated by cursor position.  If it's not pointing at something scrollable, it
> shouldn't scroll.  I admit that it seems a little bit odd to not scroll a simple
> page when the cursor is in the toolbar area, but there's no good way to handle
> this when windows might contain multiple scrollable frames.
> 
> The current behavior is precisely what other Mac applications implement.  Give
> Mail or the Finder a try.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 8

12 years ago
Sorry, Drew, you are indeed correct.  Thanks for being persistent!
(Assignee)

Comment 9

12 years ago
The pointed-to widget (gEventDispatchHandler.GetWidgetPointed()) is wrong in
nsMacEventHandler::Scroll.  It's supposed to be what's under the mouse, but it's
something else - the bookmark folder's menu?  Mouse-move events reset the
pointed-to widget, so the scroll wheel begins functioning properly again once
the cursor is moved.

This has the same root cause as bug 308898 (which is probably a dupe, but I'm
not sure of what).  I find that bug to be particularly nasty: the scroll wheel
doesn't scroll the document when tabs are switched by keystroke until the mouse
is moved, and if the pointed-to widget is the previous tab's document, then the
out-of-view previous tab will scroll.

I'm asking for blocking1.8b5 because it's a serious and well-known problem.
Assignee: nobody → mark
Status: REOPENED → NEW
Flags: blocking1.8b5?
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Component: OS Integration → Widget: Mac
Product: Firefox → Core
Target Milestone: --- → mozilla1.8beta5
Version: unspecified → Trunk
(Assignee)

Comment 10

12 years ago
Created attachment 196500 [details] [diff] [review]
Find widget to scroll by walking the widget hierarchy

Rather than trying to get the pointed-to widget (or, in case of failure, the
active widget) in nsMacEventHandler, I'm traversing the widget hierarchy with
nsWindow::FindWidgetHit, rooted at the nsMacWindow that received the scroll
wheel event.

nsMacWindow::ScrollEventHandler now calls through nsMacWindow::Scroll, which
needs to be implemented although it may have been unused previously?

As an added bonus, I'm providing warning cleanup.
Attachment #196500 - Flags: superreview?(sfraser_bugs)
Attachment #196500 - Flags: review?(bugs.mano)
(Assignee)

Updated

12 years ago
Blocks: 308898
(Assignee)

Updated

12 years ago
Blocks: 282256
(Assignee)

Comment 11

12 years ago
Comment on attachment 196500 [details] [diff] [review]
Find widget to scroll by walking the widget hierarchy

This patch needed to be revised slightly to accomodate a fix in bug 171680. 
The new patch, which addresses both bugs, is attached to the other one as
attachment 196562 [details] [diff] [review].
Attachment #196500 - Attachment is obsolete: true
Attachment #196500 - Flags: superreview?(sfraser_bugs)
Attachment #196500 - Flags: review?(bugs.mano)

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5-
(Assignee)

Comment 12

12 years ago
Fixed along with bug 171680.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

12 years ago
fixed1.8 due to branch checkin in bug 171680
Keywords: fixed1.8
(Assignee)

Updated

12 years ago
Depends on: 309822

Updated

8 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.