1913666 - Implement new Fullscreen API Architecture

Status: ASSIGNED

(Core :: DOM: Core & HTML, task)

Description

[Simon Farre [:sfarre]]

Move JSWindowActor implementation of Fullscreen to C++

Comment 1

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 1: Introduce Fullscreen Service r=sefeng!

Comment 2

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 2: Add Fullscreen Manager & FS Service Request base class r=sefeng!

This patch introduces the FullscreenManager. A fullscreen manager
manages the queue of requests that corresponds to 1 app window (not a tab).
Each queue is processed in order (and only ever 1 at-a-time). This is possible
due to how the spec has a synchronous and "in parallell" block for both
entry and exit requests, thus, the synchronous parts of the algorithm can
run before posting a request to the Fullscreen service - a request
that does the remainder of the work necessary.

It also introduces the base class for all fullscreen service requests
FullscreenServiceRequestBase.

FullscreenServiceTimerObserver is responsible
for cancelling fullscreen API requests that may or may not have hung in their respective
content processess. We have several mochi tests that more or less test this scenario
(javascript code that while trues in some background window/tab where we need to be
able to terminate). This timer only affects the fullscreen service requests
that involve DOM Fullscreen.

This patch does not introduce any Fullscreen API request, but only
the BrowserRequest which is a request that processes things like
go chrome fullscreen using F11 (or cmd+shift+f on Mac), i.e. non-DOM fullscreen.
BrowserRequest as such never enters DOM fullscreen but it can make
a window exit out of DOM fullscreen. Being a non-DOM fullscreen request, it is
not cancellable.

Comment 3

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 3: Add Fullscreen API Service Requests (Enter) r=sefeng!

This patch introduces the UserEnterFullscreen and SystemEnterFullscreen
requests which services a request to go DOM Fullscreen (or just simply add
a new element to an already fullscreened document's top layer).

We repurpose some of the previous implementation for configuring state
in the Document objects, so this logic really doesn't differ all that much except
that the control flow has been lifted out (since that is now FullscreenService's
responsibilities). So before, something like ApplyFullscreen would apply fs,
but also instruct the algorithm to keep going. Now, ApplyFullscreenState just
"does the thing".

Fullscreen API requests has a "in content process-representation" as well as the "service request"
and these are keyed by a unique monotonic id (uint64_t), these ID's are also used in the IPC
messaging scheme. The in-content-process data contains things like the document
where the request originated from, the element and the Javascript promise that was
handed out to the user. FullscreenServiceChange is the base class for these types
and in this patch, FullscreenServiceRequest is introduced for fullscreen-entry.

Comment 4

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 4: Add Fullscreen API Service Requests (Exit) r=sefeng!

This patch introduces UserExitFullscreen and SystemExitFullscreen
requests which services a request to perform the in-parallell parts of
the document.exitFullscreen() algorithm, for non-trusted as well as "chrome js"
javascript.

FullscreenServiceExit is introduced as the "in-content-process" representation
of a Fullscreen API exit-request.

Comment 5

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 5: Add cancelability to requests r=sefeng!

This patch introduces all the logic that involves the cancellation of
fullscreen requests (defined as "user agent deems it necessary to end
fullscreen session" in the spec). This is (probably, at least I think so)
the most complex part because there's quite a bit of edge cases that
needs handling.

Cancelling requests happen when we unload pages (or on page hide rather),
switch tabs (if the tab is in DOM Fullscreen) etc. So it needs to both
exit DOM fullscreen but also cancel any requests made by "that tab"
and it needs to be sure that the state we eventually end up in, is deterministic.

Comment 6

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 6: Frontend additions to make them work with new arch r=sefeng!

This patch introduces the front end changes that needs to happen with this
new Fullscreen Architecture. One thing to note is that fullscreen-painted
might seem like it has something to do with painting, but that's not how this
notification message is actually used, it's just used as a sort-of "hey
we're done with the transition"-message. In the previous patches of this series
we can see this message be "simulated". This is (possibly) confusing, because we're not
actually waiting for a MozAfterPaint anywhere. Because the front ends,
both on desktop and android relies on seeing this message, we therefore
fire it at the end of a "Fullscreen Service request".

Comment 7

[Simon Farre]

Does this mean 1943086 blocks this patch series?

The bug is specifically Fenix related and there's a pref that is set to off (default). Should I add a secondary issue, that depends on this issue 1913666, that aims to flip the pref on by default and have that one depend on 1943086?

Comment 8

[Edgar Chen [:edgar]]

(In reply to Simon Farre from comment #7)

Does this mean 1943086 blocks this patch series?

The bug is specifically Fenix related and there's a pref that is set to off (default). Should I add a secondary issue, that depends on this issue 1913666, that aims to flip the pref on by default and have that one depend on 1943086?

If we are not going to flip the perf here, yes, file a new bug which is for flipping the pref and having that one depend on bug 1943086 sounds good.

Comment 9

[Simon Farre [:sfarre]]

Attachment: Bug 1913666 - Part 7: Re-use of previous 'prepare fullscreen change' behavior r=sefeng!

This patch aims to re-use parts of what existed in
nsDOMWindowUtils.cpp, particularly OldWindowSize and
PrepareForFullscreenChange that tries to set the window dimensions in
advance.

I'm not entirely convinced yet, that the old code does what it think it
does, in a fission-like setting. Regardless, it will carry over to the
new architecture, so whatever it means to do, it should do here as well.

This also caches the window size and rotation, so that the old rotation
can be queried, which is relevant for things like Android, where we may
want to restore to landscape or portrait depending on what our original
rotation was.