Waiting for delayed startup and then attempting to force any possibly still
pending session store write to disk by flushing the session store data didn't
turn out to be a good idea, because if the session store had already started its
own automatic write at that moment in time, we'd get back an additional
"PrivateBrowsing:Data" event that we didn't expect, thereby confusing the test.
Instead, we now wait for the first session store write after startup to occur
naturally before proceeding with the test.
MozReview-Commit-ID: Hui9YYec1Ow
--HG--
extra : rebase_source : 7c063871fbe47e5f568f19151292c24232939790
This brings us in line with Desktop's session store, in that we can now collect
data for arbitrarily nested frame structures.
At the same time, this also means that we no longer collect data for dynamically
added frames, so the corresponding mochitest needs to be adapted accordingly.
MozReview-Commit-ID: DfJ3C2ccUne
--HG--
extra : rebase_source : bbb2181d5596d21254d2f7394c1383a3979dcef4
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
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
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
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
We had some issues with tabs closed shortly before backgrounding Firefox re-
appearing during session restore, however in hindsight bug 1282830 (closing a
zombie tab didn't trigger a session store file write) seems a more likely cause
for that than my initial theory from bug 1256277 comment 6 (tab events
dispatched *just* before backgrounding might be processed only after our
application-background handling), because as far as I can tell the latter theory
actually requires really split-second timing.
With that in mind, the differing, smaller minimum file write interval while in
background can be removed again.
MozReview-Commit-ID: GSQZYKeYME6
--HG--
extra : rebase_source : 598f49df98b7a09d63cd7e0aad6ad079916fad99
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <