Currently when we have an in-process WindowProxy object, we will attempt
to either use the cached mWindowProxy value, or fetch the
nsGlobalWindowOuter object from through the nsDocShell. Unfortunately,
when the BrowsingContext is detached, we will fail to get the
nsGlobalWindowOuter object. This happens to be OK for our test cases, as
the cached mWindowProxy value doesn't have the chance to go away, but
isn't acceptable long-term.
These patches exascerbated that issue by causing the nsDocShell pointer
itself to be cleared when it is destroyed, which caused the Remote
WindowProxy logic to be triggered. To deal with that case, this patch
adds a new mIsInProcess flag to continue to act like the old code-path.
In the future, we will need to also handle ensuring that the
nsGlobalWindowOuter lives for long enough, however that is not being
done in this patch in order to land it sooner rather than later.
Depends on D22763
Differential Revision: https://phabricator.services.mozilla.com/D22764
--HG--
extra : moz-landing-system : lando
This is important to allow creating BrowsingContexts outside of the process
where they are going to be used. This is largely a re-arrangement of existing
code.
There is currently no way to do this type of attaching for browsing contexts in
existing BrowsingContextGroups, which creates some limitations, but happens to
be sufficient for us in the current situation.
Differential Revision: https://phabricator.services.mozilla.com/D21095
--HG--
extra : moz-landing-system : lando
1. Add a new private member class DelayedUpdateCallback in
ServiceWorkerRegistrationProxy for handling the deley time up.
2. Modify the lambda function in ServiceWorkerRegistrationProxy::Update(). Get
the update delay time at first. If the delay time does not equal zero. create
a timer and a timer callback(DelayedUpdateCallback) to perform the delay
update. Otherwise execute update directly.
Differential Revision: https://phabricator.services.mozilla.com/D17358
--HG--
extra : moz-landing-system : lando
Also, remove a test that's no longer relevant, since we don't need to
fetch all subscriptions at startup.
Differential Revision: https://phabricator.services.mozilla.com/D20085
--HG--
extra : moz-landing-system : lando
We do this for non-static ones already; we should do it for static ones too.
Differential Revision: https://phabricator.services.mozilla.com/D23390
--HG--
extra : moz-landing-system : lando
Adds a method for to nsFrameLoaderOwner destroying and rebuilding a
FrameLoader in order to facilitate a process switch. Method works
without requiring that the work be done in the frontend.
Depends on D22789
Differential Revision: https://phabricator.services.mozilla.com/D22790
--HG--
extra : moz-landing-system : lando
We have mRemoteFrameChild which owns a RemoteFrameChild, but
mRemoteFrame is just a state. Change to mIsRemoteFrame to reflect
this.
Differential Revision: https://phabricator.services.mozilla.com/D22789
--HG--
extra : moz-landing-system : lando
mProcessedQueueLength is int32_t (wrapped around an Atomic) but it is updated from the method FramesToUsecs() which returns int64_t (wrapped around a CheckedInt) thus it is changed to unsigned int to avoid integer overflow.
Differential Revision: https://phabricator.services.mozilla.com/D22949
--HG--
extra : moz-landing-system : lando
We had an assertion here that assumed progression along a motion path must be
positive, but that's not the case when we have decreasing values of
the `keyPoints` attribute. The assertion wasn't justified and nothing
depended on it being valid, so let's just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D23354
--HG--
extra : moz-landing-system : lando
Just set the RemoteType in the options object argument, instead of
doubling up the information.
Differential Revision: https://phabricator.services.mozilla.com/D23250
--HG--
extra : moz-landing-system : lando
mDocShell is now a strong reference, and it does not need to be
explicitly initialized in the constructor because it is an nsCOMPtr.
Differential Revision: https://phabricator.services.mozilla.com/D23376
--HG--
extra : moz-landing-system : lando
Right now we just block the image returned from nsIFrame::GetCursor, which is
the first loading cursor image.
I think we should do the same we do when the image fails to load, which is to
fall back to the next image instead.
This patch moves all the custom cursor code selection logic to
EventStateManager, and lets the frame return a CursorKind and whether custom
images are allowed.
Differential Revision: https://phabricator.services.mozilla.com/D23289
--HG--
extra : moz-landing-system : lando
