1265308 - Change cross-platform scrolling behaviour when context or menulist menus are up

Status: RESOLVED WONTFIX

(Core :: XUL, enhancement)

Description

[:Gijs (he/him)]

Bug 982121 brought Windows in line with OS X and Linux by, while context menus or dropdown menus were open, ignoring wheel scroll events outside the open menu / context menu. This is platform convention on all three platforms, but some people feel the new Windows behaviour is a regression in terms of user experience.

We could theoretically do something other than platform convention, though that then has other side effects we'll need to address (cf. bug 430806 and friends).

It would be useful if UX could weigh in on what they think the right behaviour is here.

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

I'm flagging this as a regression for now as per dup bug 1263989.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Madhava, does your team have an opinion on the desired UX here?
mconley, we thought you might have some input too. If we want to put this on someone's backlog, we can remove it from periodic platform triage. Thanks!

Comment 7

[Mike Conley (:mconley) (:⚙️)]

My position is, we should always opt for the native behaviour unless the alternative is a significant improvement on the native behaviour.

Being able to scroll while a context menu is open seems (to me) more glitchy and accidentally useful than a significant improvement. I say glitchy, because it seems quite odd to have context commands for a thing that is no longer visible - the context that the menu is for has disappeared.

Comment 8

[Stephen Horlander [:shorlander]]

(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #7)
> Being able to scroll while a context menu is open seems (to me) more glitchy
> and accidentally useful than a significant improvement. I say glitchy,
> because it seems quite odd to have context commands for a thing that is no
> longer visible - the context that the menu is for has disappeared.

Native behavior (on all platforms AFAIK) is not scrolling the page at all while the context menu is open. It does not scroll the page while leaving the context menu open.

Our current behavior on Nightly seems to be to dismiss miss the context menu when you scroll outside of it. Which seems to contradict what I thought I Comment 0 was saying?

Comment 9

[Mike Conley (:mconley) (:⚙️)]

(In reply to Stephen Horlander [:shorlander] from comment #8)
> (In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #7)
> > Being able to scroll while a context menu is open seems (to me) more glitchy
> > and accidentally useful than a significant improvement. I say glitchy,
> > because it seems quite odd to have context commands for a thing that is no
> > longer visible - the context that the menu is for has disappeared.
> 
> Native behavior (on all platforms AFAIK) is not scrolling the page at all
> while the context menu is open. It does not scroll the page while leaving
> the context menu open.

To be clear, I was commenting on the requested behaviour (scrolling while leaving the context menu open), and not the current state (native behaviour)



> Our current behavior on Nightly seems to be to dismiss miss the context menu
> when you scroll outside of it. Which seems to contradict what I thought I
> Comment 0 was saying?

Hm, I'm not seeing that behaviour. On both Windows and OS X, using Nightly, if I have a context menu open, the content area becomes non-scrollable.

Comment 10

[Stephen Horlander [:shorlander]]

(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #9)
> > Our current behavior on Nightly seems to be to dismiss miss the context menu
> > when you scroll outside of it. Which seems to contradict what I thought I
> > Comment 0 was saying?
> 
> Hm, I'm not seeing that behaviour. On both Windows and OS X, using Nightly,
> if I have a context menu open, the content area becomes non-scrollable.

I was looking at option/select menus for some reason. Disregard.

Comment 11

[Neil Deakin]

Yes, the only remaining bug related to this is that <select> elements should ignore wheel events outside their popups.

Comment 12

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Gijs, is there any further info needed from me, given what Stephen has provided already?

In general, the behavior of disregarding scroll events with the context menu open makes sense, especially the kinds of low-quality trackpads that many affordable Windows laptops have (which might tend to trigger scroll events unexpectedly).

Comment 13

[:Gijs (he/him)]

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #12)
> Gijs, is there any further info needed from me, given what Stephen has
> provided already?
> 
> In general, the behavior of disregarding scroll events with the context menu
> open makes sense, especially the kinds of low-quality trackpads that many
> affordable Windows laptops have (which might tend to trigger scroll events
> unexpectedly).

No, I think we're all agreed that we should keep the new/current behaviour. I'll close as WONTFIX.

(In reply to Neil Deakin from comment #11)
> Yes, the only remaining bug related to this is that <select> elements should
> ignore wheel events outside their popups.

Is there a bug on file for this already? I couldn't find one off-hand, but maybe I missed it? If not, I suggest we file a separate bug to avoid confusion with the dupes and earlier discussion here.

Comment 14

[Neil Deakin]

I don't think there is a separate bug; I assumes that this one was it.

The first two patches in bug 1263982 should fix this for <select> elements.

Comment 15

[arni2033]

Must comment on logical failures first. A lot of things weren't considered, so NI requests were
removed also without sufficient reason. Therefore reopening, until everything below is considered.

____
(In reply to :Gijs Kruitbosch from comment #0)
> We could theoretically do something other than platform convention, though
> that then has other side effects we'll need to address (cf. bug 430806 and friends).
Just a note. There are NO side effects. And never would be, if only authors of XUL pages like Options
and Add-ons simply wrote XUL properly, i.e. add attribute [rolluponmousewheel="true"] for <menupopup>.
Furthermore, "fix" in bug 982121 wasn't needed, because devtools switched to HTML in bug 1246514
I know you're going to rewrite Options and Add-ons in future, so there'll be no issues as well.

____
(In reply to Mike Conley (:mconley) - (needinfo me!) from comment #7)
> My position is, we should always opt for the native behaviour unless the
> alternative is a significant improvement on the native behaviour.
It is. I haven't seen any people complaining that context menu does NOT prevents page from scrolling.

> Being able to scroll while a context menu is open seems (to me) more glitchy and accidentally
> useful than a significant improvement. I say glitchy, because it seems quite odd to have context
> commands for a thing that is no longer visible - the context that the menu is for has disappeared.
1) Seriously? If I open context menu for element E1, modern-day web content can always
   move/create/remove some element above E1, or load an image (adjusting its size)
   therefore I get context menu is opened for a thing that is "no longer visible".
1.1) Also it's possible to open context menu for an item in ANOTHER tab (bug 1239532).
   Somehow I don't see anybody in Mozilla who is concerned about that. Therefore your reasoning only
   intended to close this bug at all costs. This is not the right way to go, it affects the outcome.
2) Scrolling by 3 lines doesn't hide E1. You said exactly "disappeared". That is a lie.
3) This bug didn't asked to compare previous behavior with current broken behavior. It states that
   current behavior is the worst possible. The behavior you just described is NOT the only option:
   see what GoogleChrome developers did for one of the alternate options
4) This bug is not about just context menus, see "duplicates". There're several different UI elements,
   that are not "context menus". It's just a coincidence that Firefox uses the same underlying
  "technology" for all those elements. Bug 982121 broke:
  4.1) Page scrolling when bookmarks folder is open. Your only (wrong) argument doesn't even apply.
  4.2) Actually, context menu opened for ANY element in chrome will not move from that element.
  4.3) Tabs strip scrolling when drop-down "all-tabs" menu is open.
       Now I can't scroll tabs strip easily find and close/mute desired tab w/o switching tabs
  4.4) Page scrolling when bookmarks panel is open. It looks like any other panel, but prevents scroll
  4.5) Shift+Scroll to navigate in history doesn't work. It wasn't considered here / in connected bugs
5) You forgot to mention a side effect of preventing scroll on mousewheel. Action "rotate mouse wheel"
   is directly connected to visual system (in brain). When I rotate mouse wheel down, my eyes expect
   all content to rapidly move to the top by 1 screen. If that does't happen, it feels really bad.
   Huh, I have to do a lot of "brain research", as Mozilla ignores it (muscle memory, eye movement)

____
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #12)
> ... is there any further info needed from me, given what Stephen has provided already?
I don't see any arguments from him in this bug

> In general, the behavior of disregarding scroll events with the context menu open makes sense
6) That alone doesn't mean that current behavior should stay. Any possible option makes sense.

> especially the kinds of low-quality trackpads that many affordable Windows laptops have
> (which might tend to trigger scroll events unexpectedly).
7) Seems unrelated. If they randomly trigger scroll events, shouldn't it be the general issue?
   It should. Because if context menu isn't open, they will still trigger scroll events and break UX.

____
I never liked how Mozilla closes unintentional regressions with invalid reasoning, only to avoid
"more work". Especially if a bug doesn't require much work, like this one.
Why don't you ever provide the real reason, like "we just want it to be broken"? I would be much more
satisfied if I saw the real reasons like the one I mentioned in bug discussions and in release notes.

Comment 16

[Neil Deakin]

> I never liked how Mozilla closes unintentional regressions with invalid reasoning

The behaviour was changed intentionally to match the way all other applications work on all of the main platforms we support. While there may be valid reasons why a different behaviour is better or worse, I see no reason to behave differently.

Comment 17

[arni2033]

(In reply to Neil Deakin from comment #16)
> The behaviour was changed intentionally to match the way all other
> applications work on all of the main platforms we support.
Windows is the most popular desctop OS, and good behavior was present for too long there.

> While there may be valid reasons why a different behaviour is better or worse, I see no
> reason to behave differently.
See above. Also, see (4) in comment 15. People in this bug only mention OS behavior of "context menus"
Not behavior of menus like "all tabs" or panels like bookmarks panel, which are not "context menus".
8) Windows7 doesn't simply "ignores scroll outside context menu", it SCROLLS context menu when I
   rotate mouse wheel outside of it. So current "fix" of bug 982121 not only doesn't match
   OS behavior, but also brings a lot of inconsistencies and annoyance.

My personal opinion (can be wrong):   Bug 982121 wasn't intended to match OS behavior. It was just fixed in some of the possible ways, perhaps the easiest one. And after that it was decided to wontfix all unintentional regressions implemented in that bug.

Comment 18

[Neil Deakin]

(In reply to arni2033 from comment #17)
> (In reply to Neil Deakin from comment #16)
> See above. Also, see (4) in comment 15. People in this bug only mention OS
> behavior of "context menus"

4.1, 4.2, 4.3 look correct to me. 4.4 should be considered a bug perhaps. I'm not sure what 4.5 refers to.


> 8) Windows7 doesn't simply "ignores scroll outside context menu", it SCROLLS
> context menu when I
>    rotate mouse wheel outside of it. So current "fix" of bug 982121 not only
> doesn't match
>    OS behavior, but also brings a lot of inconsistencies and annoyance.

I don't see this behaviour on Windows 7 on context menus or any other menu.


> 
> My personal opinion (can be wrong):   Bug 982121 wasn't intended to match OS
> behavior.

It was intended to match the OS behaviour for context menus and all other menus, except for <select> elements.

Comment 19

[arni2033]

(In reply to Neil Deakin from comment #18)
> 4.1, 4.2, 4.3 look correct to me.
Any arguments maybe?
You already said that you see no reason to behave differently. But if I asked you before bug 982121,
why scrolling in 4.3. should not work, what would you answer? I suppose, there's just no strong
opinion about it. Have you ever used any of 4.1.-4.5.?
If not, I suggest you (team) to ask somebody who either relied on that behavior or was annoyed by it,
to get an understanding of how good/bad it is. That would be logical. So far,
I explained why 4.3. is necessary for browser w/ scrollable tabs strip. With no counter-argument.

> I'm not sure what 4.5 refers to.
It navigates back/forward in history when you hold Shift and scroll mouse wheel on page. How cold you
even decide on 4.5 behavior if you don't even know what it does? Ask somebody who use all those things


> > 8) Windows7 doesn't simply "ignores scroll outside context menu", it SCROLLS context menu when I
> >    rotate mouse wheel outside of it. So current "fix" of bug 982121 not only doesn't match
> >    OS behavior, but also brings a lot of inconsistencies and annoyance.
> 
> I don't see this behaviour on Windows 7 on context menus or any other menu.
Oh yes, (8) should be modified a bit to be valid. Sorry.
Windows has a number of popups that have slightly different behavior.
8.1) Context menus indeed don't respond to scroll outside
8.2) Autocomplete drop-downs (in addressbar and searchbar) scroll their contents when I scroll outside
8.3) Drop-down menus like "add to library" (like bookmark folder) also scroll if I scroll outside
8.4) Panels like sound indicator also scroll contents if I scroll mouse wheel outside of them

What do we see in Firefox NOW?
- Context menus don't respond to scroll outside. Bad, but kind of logical
- Scrollable autocomplete drop-downs just disappear instead of scrolling their contents
- Bookmarks folders ignore scroll outside
- (Questionable) Panels that were originally created as analogue of Win7 panels and even had the same
  styling (but now it's different), do not respond to scroll outside. Even allow it.


> > My personal opinion (can be wrong):   Bug 982121 wasn't intended to match OS behavior.
> 
> It was intended to match the OS behaviour for context menus and all other
> menus, except for <select> elements.
So, I wrote (8) to show that there was no intent to actually match anything, no investigation was made

I also see no relation of that bug's summary to the actual patch. Even expectations posted by user are
different from what was implemented. That's kind of disappointing if user asks for one thing you use
bug report to implement (do some work!) the opposite thing, to break.
In such cases it almost seems that it would be better not to report anything.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

Jim, do you think we should keep tracking this?

Comment 21

[Jim Mathies [:jimm]]

The way this works in current nightly is the way it should work.