Closed Bug 939949 Opened 10 years ago Closed 8 months ago

Back gesture goes through menu panel into content

Categories

(Firefox :: Toolbars and Customization, defect, P4)

x86_64
All
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mconley, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [Australis:P4-] [reserve-photon-structure])

STR:

1) Browse to several pages so that you have history and an enabled back button
2) Open the menu panel
3) Place your mouse cursor over top of it
4) Use the "back" gesture for the platform - like two or three finger swipe on OS X - while the mouse is overtop of the menu.

AR:

The content receives the back gesture, and we go back a page

ER:

The back gesture should not be received by content.

Context: the reason Ehsan ran into this was because he'd opened up the History subview and wasn't sure how to go back to the main view. He tried the back gesture first, and that resulted in him going back a page, which was unexpected. The back gesture probably should have taken him back to the main view - or, at the very least, it shouldn't have been received by content.
The gesture is listened to from chrome, and works even over e.g. toolbars; it's unconnected to the content area. See browser-gestureSupport.js . I'm really not sure we should make an exception for the panel menu, and if we should, I don't think this needs to be P3.
Whiteboard: [Australis:M?][Australis:P3] → [Australis:M?][Australis:P4]
Well then the fix should be rather trivial: move the listener to the mozbrowser container, and it should work as expected. ;)
(In reply to Florian Bender from comment #2)
> Well then the fix should be rather trivial: move the listener to the
> mozbrowser container, and it should work as expected. ;)

I'm not sure if the target depends on where the drags end/finish and so on, so it might not work as expected in that case if you swipe to/from somewhere that's out of that range. In any case, I really don't think this needs to be a top priority.
Nonetheless, it's confusing. Is this Mac only?

Just tested it on my Mac, the mouse does not move if I use the two-finger-swipe gesture, so there is no start/end problem.

Steve, iirc you implemented or at least reviewed the swipe gesture for OS X. Is it possible to limit the swipe gesture to the content area only easily (at least for the browser-back feature)? How easy/feasible is it to add this gesture to subviews like the Australis history menu?
Flags: needinfo?(sphink)
Definitely the wrong Steve. Wild guess: smichaud?
Flags: needinfo?(sphink) → needinfo?(smichaud)
I *did* do our initial implementation of support for the two-finger horizontal swipe.  But Stephen Pohl's done all the (quite substantial) work on it since then.  So he's probably the best person to ask this kind of question.

But I can give some general advice:  I think the two-finger history swipe should only work in contexts where the Back and Forward buttons also work, and it should work in (more or less) the same way.
Flags: needinfo?(smichaud) → needinfo?(spohl.mozilla.bugs)
> 2) Open the menu panel

What does this mean?
(In reply to Steven Michaud from comment #7)
> > 2) Open the menu panel
> 
> What does this mean?

Click the hamburger / 3-line / menu-tools-awesomeness button on the right-hand side of the navbar in an Australis-enabled build (ie Nightly).

Basically, if the mouse is over that/any panel, we still go back/fwd rather than the panel 'consuming' the gesture. Similarly, gestures over other bits of UI (like the toolbars) will do the same rather than area-specific behaviour. The question is whether the gesture should only work over the content area, or at least stop working "in" the panel / do something else in there.
OK thanks.  Now I understand the issue better.

The current behavior doesn't seem right to me -- especially as it *doesn't* happen if a context menu is open over a page.  In fact in that case it doesn't happen whether or not the mouse is over the context menu.

I suspect the reason it happens with a "panel" but not a context menu is that a context menu is a "real" (native) window, while a "panel" (presumably) isn't.

Stephen, do you agree with me that the behavior reported here seems wrong?

What's the story on other platforms that support the two-finger horizontal history swipe?
The fix for this should probably be in high-level code -- maybe in CSS code.  Not in widget code.

I strongly suspect this also happens on other platforms.
Widget code doesn't know what a "panel" is.  Nor does it need to, since it doesn't correspond to any native object.
(In reply to Steven Michaud from comment #11)
> Widget code doesn't know what a "panel" is.  Nor does it need to, since it
> doesn't correspond to any native object.

Really? Panels aren't rendered as part of the host window but as separate widgets, much like menus, so what you're saying doesn't seem to make sense.
(In reply to comment #12)

We may mean different things by the word "panel".  I'm using it (as others have in this bug) to refer to the object that looks like a speech bubble, which (as far as I know) only exists in Australis, and which you see if you click on the "hamburger" on the right end of the "main" toolbar in current m-c nightlies.
Uh, sorry, too many Steve's here! (Not that that's bad, but confusing ;-) )

(In reply to Steven Michaud from comment #13)
> object that looks like a speech bubble, which (as far as I know) only 
> exists in Australis

The identity uses the same "speech bubble", and the swipe animation also works on it (contrary to what is expected).
(In reply to comment #13)
> (In reply to comment #12)
> 
> We may mean different things by the word "panel".  I'm using it (as others have
> in this bug) to refer to the object that looks like a speech bubble, which (as
> far as I know) only exists in Australis, and which you see if you click on the
> "hamburger" on the right end of the "main" toolbar in current m-c nightlies.

Yes, I believe that is an OS level window as it can bleed outside of the main window.
> Yes, I believe that is an OS level window as it can bleed outside of the main window.

So it can.  I stand corrected.

And so this *may* be a Cocoa widgets bug.  But we really need to hear from testers on other platforms.
(In reply to Steven Michaud from comment #16)
> And so this *may* be a Cocoa widgets bug.  But we really need to hear from
> testers on other platforms.

Setting qawanted for that.
Keywords: qawanted
I agree with Gijs in comment 1 and comment 3: I don't believe adding an exception for this should be a high priority. Swipes only navigate the history if we believe that the viewport was overscrolled [1], see bug 926274. We may have to fine-tune this mechanism for detecting whether the viewport was overscrolled.

(In reply to Steven Michaud from comment #6)
> But I can give some general advice:  I think the two-finger history swipe
> should only work in contexts where the Back and Forward buttons also work,
> and it should work in (more or less) the same way.

Just a note on this: According to bug 875925, we used to have history navigation in contexts where no back/forward buttons were available ("view page source" in this case), and breaking this behavior was reported as a bug.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/events/nsEventStateManager.cpp#3432
Flags: needinfo?(spohl.mozilla.bugs)
I've managed to reproduce this issue with the latest Nightly on a Dell XPS 12 ultrabook with Windows 8 64-bit.

For enabling the "back" gesture for the platform, I followed https://support.mozilla.org/en-US/questions/951281, so I added 2 new preferences in about:config, for navigating to the next and previous page, which are browser.gesture.swipe.left.shift -> Browser:PrevTab and browser.gesture.swipe.right.shift -> Browser:NextTab.

So the "back" gesture is: Shift key + left swipe with 2 fingers.
Keywords: qawanted
Whiteboard: [Australis:M?][Australis:P4] → [Australis:P4-]
Gentle bump: could this be considered again? With the way subviews in Photon completely replace the previous sub/mainview (instead of letting some part of the previous view peek through like in Australis) resulting in a more mobile-like behaviour, and reaching the back button near the top requiring a lot of mouse movement (both towards the back button and then away from it), it would be easier and possibly more intuitive if the back gesture could work.
(In reply to Bruce from comment #21)
> Gentle bump: could this be considered again? With the way subviews in Photon
> completely replace the previous sub/mainview (instead of letting some part
> of the previous view peek through like in Australis) resulting in a more
> mobile-like behaviour, and reaching the back button near the top requiring a
> lot of mouse movement (both towards the back button and then away from it),
> it would be easier and possibly more intuitive if the back gesture could
> work.

I don't think this will make 57, but I'll stick it on our triage radar anyway.
Whiteboard: [Australis:P4-] → [Australis:P4-][photon-structure][triage]
Flags: qe-verify+
Priority: -- → P4
QA Contact: gwimberly
Whiteboard: [Australis:P4-][photon-structure][triage] → [Australis:P4-] [reserve-photon-structure]
Severity: normal → S3

Unable to reproduce on Linux and Windows. Are you still able to reproduce on macOS?

Flags: needinfo?(mconley)

Nope, I can't! Looks like this has been fixed sometime in the last 10 years.

Status: NEW → RESOLVED
Closed: 8 months ago
Flags: needinfo?(mconley)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.