This patch intentionally re-map the following controls from button to toolbarbutton
- browser/components/downloads/content/download.xml#download-subview-toolbarbutton
- toolkit/content/widgets/toolbarbutton.xml#menu-button
MozReview-Commit-ID: E806LA6NAvC
--HG--
extra : rebase_source : 8e7534dc34f95e1d0cc6d00370475cc796acc36e
In most cases (e.g. new tabs added, page navigation, scrolling, etc.), we can
live with the fact the the private tab data held by GeckoApp might be up to ~10
seconds out of date if we don't manage to send an update within the time limit
given by the UI during backgrounding.
Where the closing of private tabs is concerned, this is different, as not
remembering that the user already closed some tabs just before switching away
from Firefox could lead to potentially embarrassing situations when the user
returns and unexpectedly finds those tabs still open.
Therefore we now use the infrastructure added in the previous parts to speed up
the saving process when private tabs are closed.
MozReview-Commit-ID: KpfXinOl5Ki
--HG--
extra : rebase_source : 2c8d8572faed17254f1c4aa6ed4321893afa7b8f
... and also shorten any already running save timer if necessary.
This is because the private tab data kept by GeckoApp, that will be restored if
we are OOM-killed, cannot be updated anymore after Firefox goes into the back-
ground, even if we aren't immediately killed by the OS.
Because during backgrounding the UI only waits a limited amount of time for the
latest private tab data in order to avoid causing an ANR if Gecko is busy, we
need to compensate by sending private tab data updates faster to GeckoApp than
the usual write throttling interval of every 10 s would allow.
To allow multiple successive tab events to be batched together in one update,
e.g. if the user closes *all* private tabs, we still introduce a small save
delay of a few hundred ms.
MozReview-Commit-ID: J15RNfAlfy2
--HG--
extra : rebase_source : d61d7ae272eb07dd924305419040472c2eb3f579
Private tabs are saved in memory only by sending them to GeckoApp, so to speed
up processing (compare part 3), we want to avoid writing out the full session
store file for normal tabs as well if all outstanding saveState(Delayed) calls
concerned private tabs only.
To that effect, we slightly change the semantics of our pendingWrites counter
and now increment it each time saveStateDelayed is called, even if the save
timer is already running. This is because if e.g. a private tab update started
the timer and then another saveStateDelayed call happens for a non-private tab,
we need to change our plans and write the normal session store file after all as
well. Tracking every saveStateDelayed call allows us to do this.
Because writeFile only cares about the fact whether additional pending writes
were queued while it was executing asynchronously or not, but not about the
absolute amount of pending writes (if no additional writes were queued, the
count is simply reset to 0), incrementing the pending writes count even
when the timer is already running causes no ill effects.
MozReview-Commit-ID: AjhIp8bpyf
--HG--
extra : rebase_source : 558cdba8fc833b51d069101bebefc6100165f638
When we get a timer callback for delayed saving, we already only proceed if
we've still got a write pending. Conversely if for whatever reasons _saveState()
is called from outside of a timer callback, any still pending save timer is
cancelled again.
With that in mind, when executing the delayed write timer callback there's no
reason to call the public version of saveState(), whose only extra task is to
increment the pending write count again. Instead, we can just directly call the
internal _saveState() version.
MozReview-Commit-ID: 11EucNm5KFB
--HG--
extra : rebase_source : a80379157dec1e01ab515eab30125ab06621b549
As far as I can tell, that line dates back to approximately the time Private-
BrowsingUtils were introduced in the first place.
MozReview-Commit-ID: BLn13X7DVJt
--HG--
extra : rebase_source : 2a00f5ca572cf65e3fbd6763f4be32c84b18c0d8
We attempt to get the session store into a known state as far as is possible
from Java and then test various situations to check that the expected
"PrivateBrowsing:Data" message is received in each case.
MozReview-Commit-ID: 8RkCQjAPXTT
--HG--
extra : rebase_source : 5c6b1ae911aed0e6ac5d121e78ce06090f14a795
There are two parts to this:
1. While the file writing itself by the session store can be done either
synchronously or asynchronously, the session store's _writeFile function as
a whole always behaves asynchronously. In addition, just writing the file
(which will be done synchronously when flushing tabs) takes time which we
don't have, as we should send the private tabs data as fast as possible to
Java in order to avoid hanging the UI or missing a possible timeout.
2. Sending the data to Java needs to happen synchronously as well, so we need
to listen for "PrivateBrowsing:Data" on the Gecko thread now. This in turn
means that some sychronisation is now required between the UI thread handling
onSaveInstanceState and the Gecko thread that is actually receiving the data.
To avoid hanging the UI and causing ANRs, we only wait a limited amount of time
for Gecko to respond with fresh private tabs data, though.
As this still leaves a certain possibility of outdated private browsing data
being saved and possibly restored after an OOM-kill, we're also going to speed
up the processing of TabClosed events by the session store in the following
parts.
MozReview-Commit-ID: EkNFre5RhQW
--HG--
extra : rebase_source : ae878b72eb66dddb3f803d654c76ae75c8b9caa1
extra : source : 2b7ed5cdc9db4791c2818580b5ac995ab0e36ddf
We need to block onSaveInstanceState until we're sure that our private browsing
data is up to date, however we can't block on the whole of our application-
background handling (GeckoThread.onPause), as that will take too much time.
In addition, we need to update the stored tab data not just when the application
goes into the background, but every time we're leaving GeckoApp and onSave-
InstanceState is called, e.g. when visiting our settings activity.
MozReview-Commit-ID: DgtUvatD6h3
--HG--
extra : rebase_source : 215659505d0bc52fb7f27ca2a9fea2fd618b0efe
If onActivitySaveInstanceState is called, this normally happens just before
onActivityStopped, which means we can attempt to use the same logic currently
used for onActivityStopped to determine whether the whole app is going into the
background or we're doing just an internal activity switch.
This allows us to trigger our Gecko onPause/"application-background" handling
*before* e.g. GeckoApp's onSaveInstanceState handling, meaning we still have
time to update the private browsing data held in GeckoApp before it is passed
off to the OS.
MozReview-Commit-ID: 5TZ6uX0gyz1
--HG--
extra : rebase_source : eb5f636ab4df0dae6e60ebf4d03ff4f88f00e2f5
This also changes a few MOZ_LOG() messages to use the error name
instead of the raw numerical nsresult value.
MozReview-Commit-ID: Jcngd0S9j2z
--HG--
extra : rebase_source : f6e974569d8845211e0b25dabef2c41dda2ca1b6
After the React monkeypatch removal (bug 1420130), some events can be duplicated
because both privileged and non-privileged versions are dispatched.
To work around this, we can stop propagation for the event in cases like this
where it is safe to do so.
MozReview-Commit-ID: L6cHpuTw1D2
--HG--
extra : rebase_source : 6f7eaf26cda0776be4678141760d7890d928185d
The X11 symbol interposition isn't enough, possibly because Cairo can
also use XCB. Interposing XCB is more difficult because the API exposes
more protocol details. Instead, just allow shmget to be called and
fail; this will tell Cairo that it can't use SysV IPC with the X server,
which is what we want.
MozReview-Commit-ID: 5y9tE7UXMTE
--HG--
extra : rebase_source : bb1e81116742a299bc4e412062327e69032ab3b3
Require the current stable Rust release so new features can
be used in development.
MozReview-Commit-ID: 4NQNk3RfBkF
--HG--
extra : rebase_source : 9d88e6fdb823bd2e2ca8ac9940b1fafd420eebdc
The only thing that cares about it is the frame constructor, it's a shame that
everyone else (in particular, the style system) needs to pay this extra walk
over the DOM.
MozReview-Commit-ID: F7S5zx9KMlp
This is a regression from bug 1429593. The code that was added to enable/disable controls on the page
depending on whether an extension is in control was being run when the page opened, which overrode
the code which disables specific controls based on the current proxy setting. All that is needed is
to call that code (which is in gConnectionsDialog.proxyTypeChanged()) if an extension is not in control
after the new code that was added. This patch fixes that issue, and includes a test verifying that
the manual controls are not enabled when the screen first opens.
MozReview-Commit-ID: 7jpp1wewZ2k
--HG--
extra : rebase_source : 3bd13747ba9ba95fe50bce83a583af387352f8ef
This also reveals a regression on the border color for warning and error messages
in dark mode, which is fixed by this patch.
MozReview-Commit-ID: H24hOYVhpr7
--HG--
extra : rebase_source : f1510acd85d443ef7518059420f4facd82dd5a49
This includes simplifiying the startup process, migrating to a new
pref namespace, renaming files, and updating references to the code.
MozReview-Commit-ID: A2cYpsjCOAE
--HG--
extra : rebase_source : abf1f517b78952d42b0142ca458444eed61c939a
At this point in the series:
- AxisOrientationTracker::IsCrossAxisHorizontal() has zero callers, so it can
be deleted.
- AxisOrientationTracker::IsMainAxisHorizontal() only has two callers, and
both are inside its own class. So it's effectively become an implementation
detail of its class, and it can be made private. (I'm not entirely removing
it, because it does make its two callers more readable. The callers are
working with a physical-axis-dependent type, 'LayoutDeviceIntSize', which
comes from an API that isn't logical-axis-friendly, "GetMinimumWidgetSize",
so they're not easily logicalized. So: it's nice to keep
IsMainAxisHorizontal() around as an internal convenience method to tell us
whether to extract the width or height inside of these two specific
methods. But we don't want to introduce more callers, so let's leave it
around & make it private.)
MozReview-Commit-ID: 1iz1e52NmxV
--HG--
extra : rebase_source : e8e92bbaadb5b8e636bd1dda79cb0041ce36a2ea
This patch doesn't affect behavior. Each of these macros only had one caller
remaining, and this patch simply expands each of these macros at its sole
callsite.
Note that I'm using the "IsMainAxisHorizontal()" helper in *both* expansions
here, which makes the alternative variant "IsCrossAxisHorizontal()" unused as
of this patch. The next patch in this series will remove that now-unused
method, which will reduce the "Horizontal"-querying API surface here.
The documentation for the macros is still relevant to their still-existing
"_LOGICAL" variants (and those variants do still have callers), so I'm updating
the documentation to be about those variants.
MozReview-Commit-ID: 5i32VYXzo3r
--HG--
extra : rebase_source : 4697e6c23ea743e6b928b091c9dfc9ca1ce4c403
This patch doesn't change behavior.
The GET_MAIN_COMPONENT macro (some of whose calls I'm removing here) makes a
call to IsMainAxisHorizontal() under the hood. So I want to get rid of calls
to this this macro, to get closer to killing that method.
In this code, we're interested in the flex item's min-size property in the flex
container's main axis. This patch makes us simply use MinISize/MinBSize (in
terms of the *flex container's* writing mode) to get the appropriate min-size
property. The call to IsRowOriented() (querying the flex container's
"flex-direction" property) tells us whether the inline or block axis is the
main axis.
This patch also does away with an unnecessary axis-specific 'overflow-{x/y}'
check, which we don't need to bother with, as noted in a new code-comment (due
to how the 'overflow' subproperties influence each other).
MozReview-Commit-ID: Kqyh69W5IQJ
--HG--
extra : rebase_source : 92d20c8b607d9526c19f387258248388d1c89d85
This patch doesn't affect behavior. It does the following:
- Changes the AxisOrientationTracker "GetMainComponent/GetCrossComponent" APIs
to take a LogicalSize rather than a nsSize.
- Changes FlexItem::mIntrinsicRatio to be a LogicalSize rather than a nsSize.
- Simplifies the MainSizeFromAspectRatio() helper-function (in particular, it
removes a call to IsCrossAxisHorizontal(), which is an API I'm gradually
removing in this patch series.)
MozReview-Commit-ID: KXUmaUVPMZa
--HG--
extra : rebase_source : 345e95978a8abd3ed3ab5b8acabbc6f163785f63
This patch doesn't change our behavior -- not in opt builds, at least. In debug
builds, this patch does change an assertion condition, to remove a usage of
IsCrossAxisHorizontal(). This means debug builds may proceed a bit further
when loading e.g. bug 1384266's testcase (which up until now was tripping this
assertion). Now that testcase fails a slighlty later assertion (which I'll
sort out on that bug).
The first hunk of this patch is just a simplification -- replacing a
complicated condition (IsRowOriented==IsOrthogonalTo) with a simpler
formulation of the same condition. I'm making that simplification in this
patch so that we're more clearly consistent about what condition we depend on
for baseline alignment. After this patch, that (simplified) condition matches
the condition that we assert inside of GetBaselineOffsetFromOuterCrossEdge().
Note: I'm adding two XXXdholbert comments in this patch, for outstanding issues
that I ran across which are out-of-scope for this patch series.
MozReview-Commit-ID: 5x5xqWWilQZ
--HG--
extra : rebase_source : b25e8bfd7425f76b9784df0bd60fc454d4089347
This patch doesn't affect behavior.
It removes a helper-function that simply returned nsStylePosition::mWidth or
mHeight -- whichever was in the flex container's cross axis. This helper was
only used to answer the question "is the cross size 'auto'", at a single
callsite. So, this patch replaces the helper with a new helper that more
directly answers that question. The new helper's implementation uses logical
axes for its reasoning, too, whereas the removed one used physical axes (and in
particular, it relied on AxisOrientationTracker::IsCrossAxisHorizontal(), which
I'll be getting rid of later in this patch series).
MozReview-Commit-ID: EJ8MObTauZH
--HG--
extra : rebase_source : 74caa7a1d06a2a9c5113d4e3cfabaa1d0e9ec1ab
Dan Glastonbury
Timothy Guan-tin Chien
Jan Henning
Emilio Cobos Álvarez
Jean-Luc Bonnafoux
Hiroyuki Ikezoe
Matthew Noorenberghe
Zibi Braniecki
Edouard Oger
J. Ryan Stinnett
Narcis Beleuzu
Francois Marier
Jed Davis
Ralph Giles
Jonathan Kingston
Julian Descottes
Xidorn Quan
Jan Odvarko
Ken VanDine
Bob Silverberg
Nicolas Chevobbe
Dão Gottwald
Mike Cooper
Daniel Holbert