Closed
Bug 804656
Opened 7 years ago
Closed 7 years ago
flyout panel blocking events to sidebar
Categories
(Firefox Graveyard :: SocialAPI, defect)
Not set
Tracking
(Not tracked)
VERIFIED
FIXED
Firefox 21
People
(Reporter: ashughes, Assigned: mixedpuppy)
References
Details
Attachments
(1 file, 2 obsolete files)
2.66 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 2•7 years ago
|
||
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
Assignee | ||
Comment 3•7 years ago
|
||
click events (on osx) will go through if using consumeoutsideclicks=false on the panel, however this does not fix the scroll event issue.
Assignee | ||
Comment 4•7 years ago
|
||
Neil, do you have any thoughts around the scroll issue here?
Comment 5•7 years ago
|
||
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.
Assignee | ||
Comment 6•7 years ago
|
||
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).
Comment 8•7 years ago
|
||
Duplicate of this bug: 800816
Assignee | ||
Comment 10•7 years ago
|
||
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 11•7 years ago
|
||
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-
Assignee | ||
Comment 12•7 years ago
|
||
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 13•7 years ago
|
||
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+
Assignee | ||
Comment 14•7 years ago
|
||
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
Comment 15•7 years ago
|
||
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
Assignee | ||
Comment 16•7 years ago
|
||
Attachment #692121 -
Attachment is obsolete: true
Attachment #698835 -
Flags: review?(enndeakin)
Updated•7 years ago
|
Attachment #698835 -
Flags: review?(enndeakin) → review+
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
Assignee | ||
Comment 17•7 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=04aa7c6726af
Assignee | ||
Comment 18•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/cf2bcfc5cb4d
Comment 19•7 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/cf2bcfc5cb4d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21
Reporter | ||
Comment 20•7 years ago
|
||
I've not been able to reproduce this recently, marking verified fixed.
Status: RESOLVED → VERIFIED
Updated•10 months ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•