Bug 1481139 - p1: handle invalid file descriptors.
Bug 1481139 - p2: add dummy fds for GMP process.
Two file descriptors were added in bug 1438678 and 1471025 for content/child
process but not GMP process, and it breaks the IPC channel on Android.
Add dummy values to make it work for now before bug 1440207 clean up the mess.
Differential Revision: https://phabricator.services.mozilla.com/D3541
--HG--
extra : moz-landing-system : lando
The previous implementation attempted to delete files from /res/fonts (i.e.
root). I don't believe this was intended either:
https://bugzilla.mozilla.org/show_bug.cgi?id=878674#c0 indicates the fonts
directory should be inside the data dir of the application. The crash occurs
when the /res/fonts directory exists (only some devices) but the user doesn't
have read access. If the user has write access, our code may actually delete
these system files: uh oh!
My fix is to change the deletion from /res/fonts to <dir>/res/fonts. I verified
this fix worked by creating a clean profile, adding dummy files to the
res/fonts dir, and making sure only the correct ones were deleted (in zsh):
export DIR=/data/data/org.mozilla.fennec_mcomella; \
adb shell pm clear org.mozilla.fennec_mcomella && \
adb shell mkdir -p $DIR/res/fonts && \
for i in touch.ttf lol.rdf; do adb shell touch $DIR/res/fonts/$i; done && \
adb shell ls $DIR/res/fonts
MozReview-Commit-ID: 8atpcjYjGu0
Now that GeckoScreenOrientation generally offers notifications of screen
orientation changes, the PromptService no longer needs to do its own orientation
tracking and require to be fed orientation changes from each activity using it.
MozReview-Commit-ID: K7KbDsQip7b
--HG--
extra : rebase_source : 8b447d9db079794c9ad231a31a52f2787ab742ce
As of bug 1475875, cached screen data is now held by Gecko, so
- we no longer need to cache the screen size (retrieval of which can be
expensive when called en masse, as required e.g. by font inflation) within
GeckoAppShell, and
- we need to trigger a refresh of that data instead when the activity
orientation changes.
MozReview-Commit-ID: JsY6sBCcOih
--HG--
extra : rebase_source : f286f3b01732bd724da3988c4713adb7329a5fae
By moving the calls to GeckoScreenOrientation.update() into GeckoView, any app
using a GeckoView will automatically update the screen orientation in Gecko,
too, without any further action being required by the embedding app.
The synchronisation around GeckoScreenOrientation.update()/(un)lock() is
required for the following scenario:
If (un)locking of the screen orientation as requested by Gecko caused the
actual screen orientation of the app to change, there are two ways in which this
will cause our internal screen orientation to be updated:
1. Either the call to delegate.setRequestedOrientationForCurrentActivity
(happening on the Gecko thread if the original request to (un)lock came from
Gecko) returns first and update() is subsequently first called from the Gecko
thread, too, meaning the onOrientationChange notification to Gecko can occur
synchronously as well. In that case, as soon as (un)lock returns to Gecko,
querying our internal screen orientation will return the correct value.
2. Or else the GeckoView.onConfigurationChanged() call resulting from the screen
rotation manages to call GeckoScreenOrientation.update() first and does so
from the Android UI thread. This means that the onOrientationChange
notification will be redispatched asynchronously to the Gecko thread, while
the Gecko thread's call to GeckoScreenOrientation.update() will return early
without doing any work, as the screen orientation had already been previously
updated by the UI thread.
As a result,there will be a period of time between the Gecko thread returning
from GeckoScreenOrientation.(un)lock() and the onOrientationChange
notification finally executing where querying the internal screen
orientation will not yet return the new orientation. This can cause problems
for Gecko (test) code that expects to (un)lock the orientation and then be
able to immediately query the new, changed orientation after the call to
(un)lock returns.
Without additional measures in place, there are no guarantees at what point
the GeckoView will receive the onConfigurationChanged() call in relation to the
request to change the activity's orientation making its way back to (un)lock().
Therefore, we add synchronisation such that no other thread will be able to up-
date the screen orientation in GeckoScreenOrientation while another thread is
still busy (un)locking the screen orientation.
MozReview-Commit-ID: 5s5NEJcuS0p
--HG--
extra : rebase_source : cbfbc6da99aa23af4eee8c4bf6018359f9e71304
The call to mSession.transferFrom(ss.session) in the line above also transfers
the window from ss.session into mSession, which means we subsequently won't be
able to retrieve a runtime from ss.session any more, thereby defeating the goal
of calling mRuntime = ss.session.getRuntime().
This case is encountered e.g. when the containing activity is destroyed and sub-
sequently recreated after a configuration change that isn't handled by the app,
e.g. screen rotation in the GeckoView example app.
MozReview-Commit-ID: 5YGskdLZWqw
--HG--
extra : rebase_source : 3293fcaaf645706133531cb0180b6514a289b612
Once responsibility for notifying GeckoScreenOrientation of potentially changed
screen orientations moves from GeckoApp into GeckoView, the former will no
longer be able to benefit from the return value of calling GeckoScreen-
Orientation.update(), indicating whether the orientation actually changed or in
fact remained the same.
GeckoApp however requires that information in order to reset/refresh parts of
the UI when the orientation changes, and since GeckoScreenOrientation is already
doing all the work of tracking screen orientation changes, we don't want to have
to partially duplicate those efforts again in GeckoApp.
Instead, we introduce a mechanism for GeckoScreenOrientation to notify
interested parties on the Android app side as well.
The GeckoScreenOrientation.update() call in GeckoApp.onResume() is removed
completely (as opposed to merely removing the refreshChrome() bit) at this stage
already because it is unnecessary. If any screen rotation happened while the
activity was in background, it will receive an onConfigurationChanged() call
anyway before being resumed again.
MozReview-Commit-ID: Ila1evcj8Ud
--HG--
extra : rebase_source : f342800628f930d717fe346779894793a1bac0e9
This makes things saner for all consumers, which makes it worth doing on its
own. But it also gives me an easy nsTArray to work with, which I can use to
dispatch DOM events with array properties.
Differential Revision: https://phabricator.services.mozilla.com/D3466
--HG--
extra : rebase_source : e8bcc75e84845e42c932886502f99ca3154df48d
Creating non-shared scopes for frame scripts is fairly expensive. After these
changes it's even more expensive. However, many frame scripts have no use for
the shared scopes at all. Run-once scripts which execute in closures, for
instance, make no use of them. And after bug 1472491, neither do most of our
default frame scripts.
MozReview-Commit-ID: 9PK7bYdQ0yh
--HG--
extra : rebase_source : db2516d2f00a75e233e1957649f2b62a9299b7cd
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
