Open Bug 1328269 Opened 3 years ago Updated 2 years ago

No sensible way to exit 'Full Screen' mode on Windows 10 tablet device


(Firefox :: General, defect)

50 Branch
Not set




(Reporter: goldencut, Unassigned)


(Blocks 3 open bugs)


(Keywords: ux-affordance)


(1 file)

Attached image Clipboard02.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507
Firefox for Android

Steps to reproduce:

Select 'Full Screen' from Ff menu (3 stripes).

Actual results:

All of the Ff controls and OS controls disappeared, only web content remained. Right-click menu on web content is of no help. No  way to control Ff, access OS, or exit 'Full Screen' mode.

Expected results:

A sensible way to control Ff, access OS and/or exit 'Full Screen' should have remained. As the only remaining control point present was the Right-click menu it should contain a way to exit this locked state ('Exit Full Screen').
Component: Untriaged → General
Product: Firefox → Firefox for Android
windows 10 tablet is regular Firefox
Component: General → Untriaged
Product: Firefox for Android → Firefox
Component: Untriaged → General
Bug 1322349 work for you?
Flags: needinfo?(goldencut)
Swiping down doesn't work as it just drags away a random tab to a separate window. Careful tapping on the upper edge works slightly better as it makes FF show the URL-bar and tabs but also activates a random tab (that just happened to be in the place where I tapped blindly). So at this moment there seems to be still no solution. If new FF version is released with some fix (something mentioned in that discussion) I'll test it out and give feedback.
Blocks: windows-10
Flags: needinfo?(goldencut)
This is awful.

Jim or kats, how hard would it be to add native support for coming out of fullscreen for downswipes from the top of the window, or whatever the native behaviour here is?

Additionally, I guess we should indeed add a context menu option...
Ever confirmed: true
Flags: needinfo?(jmathies)
Flags: needinfo?(bugmail)
Keywords: ux-affordance
52 and up will support touchswipes from the top (see bug 1322349). Although really that should be working in previous releases as well because we didn't have proper touch support and we would do the same with the synthetic mouse events.

goldencut, what device are you using?
Flags: needinfo?(bugmail) → needinfo?(goldencut)
FWIW, on my X1 Carbon (Win 10, Nightly) (touchscreen laptop) I have quite a broad bezel around the touch screen, and from full screen in Nightly I can swipe down from the top to get the menubar back. I can see how on a tablet with a very thin bezel this might be difficult though.  

I'm trying to see how Edge handles this, but I don't see a fullscreen option there?  

In Chrome, there's is no swipe-from-top behavior at all. The only way to get out of fullscreen is using the context menu where "Exit full screen" is the top option.
I'm using Lenovo Miix 310. It has quite wide bezel (~1,5cm) but swiping down just drags away some random tab, tapping precisely on the screen edge activates some random tab. By random I mean that I have no way of knowing which tab is going to be where I swipe or tap as there is no visible tabs.
Thanks. It seems like we should provide a better way to exit fullscreen on tablets then, when the only input method available is touch.
Blocks: fx-touch
Flags: needinfo?(goldencut)
I'm actually more concerned about there is no way to exit DOM fullscreen on tablet...
Do we deliver w3c touch events to front end? If so it should be pretty easy to detect this and act on it. 

We still have simple gesture detection code [1]  down in widget left over from win7 time frame, but I think apz has mostly usurped what that code was doing.

Flags: needinfo?(jmathies)
(In reply to Jim Mathies [:jimm] from comment #11)
> Do we deliver w3c touch events to front end?

We do, yes. (In 52 and up, assuming e10s is enabled).

> We still have simple gesture detection code [1]  down in widget left over
> from win7 time frame, but I think apz has mostly usurped what that code was
> doing.

Yeah I don't think this code is activated if we have w3c touch events enabled.
Here's some old metrofx front end touch event processing code, which should serve as an example.
So is the implication we need to write frontend JS to fix this? I would imagine this applies to all windows, and fullscreen is a state we keep in widget, so I kind of assumed this would need a native code fix. I'm also a bit surprised Windows doesn't provide this. :-\
Flags: needinfo?(bugmail)
If there is a Windows API for this I don't think we're using it, because even ignoring touch (e.g. just using mouse input) the exiting-fullscreen mechanisms are all in the frontend JS, AFAIK. So I assumed that's where we would do it for touch as well.
Flags: needinfo?(bugmail)
See Also: → 1334173
You need to log in before you can comment on or make changes to this bug.