Closed Bug 804656 Opened 7 years ago Closed 7 years ago

flyout panel blocking events to sidebar

Categories

(Firefox Graveyard :: SocialAPI, defect)

19 Branch
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 21

People

(Reporter: ashughes, Assigned: mixedpuppy)

References

Details

Attachments

(1 file, 2 obsolete files)

When I hover an activity item in the sidebar it displays a flyout, but if I try to mouse-scroll the activity stream with a flyout visible I can't. This makes scrolling the activity stream difficult because I need to make sure I start scrolling within the hover timeout for displaying the flyout.
Duplicate of this bug: 797196
scroll and click events are consumed by the flyout on osx and linux.  Windows does not seem to be affected by this.  All versions are affected.
Summary: Displaying activity flyout prevents scrolling activity stream → flyout panel blocking events to sidebar
click events (on osx) will go through if using consumeoutsideclicks=false on the panel, however this does not fix the scroll event issue.
Neil, do you have any thoughts around the scroll issue here?
The addition mentioned at http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsXULPopupManager.cpp#215 would need to be implemented. Similar issue as with bug 628020.
actually, consumeoutsideclicks=false causes some very strange behavior in our sidebar, I don't think it is a content issue since this works as expected on windows (without consumeoutsideclicks=false).
Duplicate of this bug: 804251
Duplicate of this bug: 800816
Duplicate of this bug: 800816
Attached patch scroll event patch (obsolete) — Splinter Review
This patch allows the scroll event to reach the sidebar while the flyout panel is open.  This matches the windows behavior.
Attachment #689489 - Flags: feedback?(enndeakin)
Comment on attachment 689489 [details] [diff] [review]
scroll event patch

It doesn't match the Mac behaviour though. In fact, my testing shows that it isn't correct on Windows either. That is, when a menu is open, the scrollwheel should not be able to scroll the document.

What we actually want is a way to customize either the consume of the scroll event or whether the the rollup occurs (or probably both), as I mentioned in comment 5.
Attachment #689489 - Flags: feedback?(enndeakin) → feedback-
Attached patch rollup on mousewheel (obsolete) — Splinter Review
this adds a rolluponmousewheel attribute for panels, and in combination with consumeoutsideclicks I get the behavior I need on the social flyout panel.
Attachment #689489 - Attachment is obsolete: true
Attachment #692121 - Flags: feedback?(enndeakin)
Comment on attachment 692121 [details] [diff] [review]
rollup on mousewheel

This is fine, although someone else just recently asked for the ability to control consume on mousewheel separately from click, so I want to think for a bit about how this might be incorporated as well.

> +  content->GetAttr(kNameSpaceID_None, nsGkAtoms::rolluponmousewheel, rollup);
> +  return rollup.EqualsLiteral("true");

Note that you can use AttrValueIs here.
Attachment #692121 - Flags: feedback?(enndeakin) → feedback+
Neil, I'm going to assign this to you while you think about stuff from your last comment.  Once you figure out how you want it to go, I'll be happy to have it reassigned to me to update/etc.
Assignee: nobody → enndeakin
I can't find any reference to who asked about the ability to control the 'consume' ability as well, so let's just go with this patch and change it later if someone asks.

- change to use AttrValueIs
- move the check to before the autocomplete popup and allow rolluponmousewheel="false" to override it (like http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuPopupFrame.cpp#1392 does for consumeoutsideclicks)
- put the atom in alphabetical order in nsGkAtomList
Assignee: enndeakin → mixedpuppy
Attachment #692121 - Attachment is obsolete: true
Attachment #698835 - Flags: review?(enndeakin)
Attachment #698835 - Flags: review?(enndeakin) → review+
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/cf2bcfc5cb4d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21
I've not been able to reproduce this recently, marking verified fixed.
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.