The problem was because on API >=26 the JobIntentServices used for the updater
functionality will be used by JobScheduler by binding to them.
But because they were set to run in a different process the binding was not
possible.
MozReview-Commit-ID: I8rbcoLyhyJ
--HG--
extra : rebase_source : 1bc423f6012aff6c9b0d960b046af04f32b8bd7b
PromptService will be informed when the screen is rotated and in turn it will
ask every Prompt shown to reset it's current layout.
For this, every Prompt will
- save it's current input value in PromptInput's mValue or similar field
already used for storing the default PromptInput value.
- create a new widget to be used in the new AlertDialog, with a new appropriate
layout for portrait / landscape. This is when the mValue field will be used
to initialize the new widget with the previous input.
MozReview-Commit-ID: L6eHyGNDt3d
--HG--
extra : rebase_source : ada913a8e6ada99a7d49eb47d1c64831a8f698da
Use adoptFd and detachFd so we don't duplicate FDs unnecessarily. Also
fix a bug where we didn't close the pref FDs.
MozReview-Commit-ID: Gugcyi4cj7V
--HG--
extra : rebase_source : 035f62d8ba4d1ec964d5b7f7556bae7164ab78b3
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
Upon saving the state of onboarding fragments, the bundle can exceed 3MB because of the bitmaps.
Therefore, now we pass a resources id instead of passing the full bitmap through the bundle.
MozReview-Commit-ID: 9zpXrmolT38
--HG--
extra : rebase_source : 9ab3a9ad680c415852c02abc2ef046c190438a5e
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : b15f75e39d04c8485b4eb63416fd1f1e4175fafe
This alters nsILoadURIDelegate.loadURI() to return a Promise rather than spinning the event loop to synchronously return a boolean, and alters nsDocShell::InternalLoad to allow for those changes by re-calling itself if necessary based on the resolution of the promise.
Since GeckoJavaSampler::Stop() isn't called from locked_profiler_stop, Java
sampler is never stopped after stopping profiler.
And when calling GeckoJavaSampler::Stop(), it causes dead lock since stop()
is acquiring lock. So when calling join method, we should release this lock.
MozReview-Commit-ID: BLREo0lH6DS
--HG--
extra : rebase_source : f9c43f3d0e2a527abf1828d023d1a962fc526bde
When migrating GeckoService to Oreo (Bug 1467840), the Gecko initialization was
inadvertently moved on a background thread.
This patch moves the initialization back on main thread.
MozReview-Commit-ID: Cxp7lGzPgXH
--HG--
extra : rebase_source : cf12c311dcae47cad42235587ace684788a848a1
After API 24 DownloadManager.COLUMN_LOCAL_FILENAME got deprecated and querying
for it would throw an error.
To get around this DownloadManager.COLUMN_LOCAL_URI can be used but which adds
the "file://" prefix.
MozReview-Commit-ID: CvkoFyRCLo6
--HG--
extra : rebase_source : 66b0eeecf40b1b1b9fa51860f29032e02ebe507b
In Bug 1188240 we disabled autoplay on Android < API version 16 because of a
vulnerability in old libstagefright, but as of Firefox 55 our minimum supported
Android version is 4.1, or API verion 16.
We've renamed the media.autoplay.enabled pref, so we can just remove the
check on media.autoplay.enabled added in bug 1188240 as it's testing for a
version of Android we no longer support anyway..
MozReview-Commit-ID: Gc8ZnlOiiMn
--HG--
extra : rebase_source : 12817b6e782331f3e4f26be0b97181418ec3287f
We're planning on enabling block autoplay on desktop by default, so in order to
be consistent across platforms, we think we should also enable it on mobile by
default.
The change here makes us allow autoplay in tabs which have had user
interaction, rather than the legacy block autoplay implementation which
"blessed" media elements which had certain functions called in a user generated
event handler.
Current plan is to enable this on Nightly only (desktop & mobile) and solicit
feedback and then decide on whether to let it ride the trains.
MozReview-Commit-ID: IkusfUOrcgO
--HG--
extra : rebase_source : 0c0a8f80d3670fffe66540f66954eaa980a42e74
We download the update APK into the public downloads directory and normally the
only relevant app consuming that URI should be the system package installer, but
just to be safe we only switch usage from Nougat onward, too.
This patch had already landed as part of bug 1450449, but subsequently got
overwritten during the refactoring in bug 1407046.
MozReview-Commit-ID: Ipmmlpm91zK
--HG--
extra : rebase_source : 426d98084fd26d5312e1aa5809256a5f29cd7b4d
This patchset changes the MediaDevice type names from "audio" and "video" to "audioinput" and "videoinput". GeckoSession has been updated to expect the new string names. In parallel a new type "audiooutput" has been added but it is not important for this patch.
MozReview-Commit-ID: FUdG5QtD9re
--HG--
extra : rebase_source : 2a4bec49ef12898ef7aea7747ff7407577521916
To conform to Android behavior, we intentionally suppress the selection
toolbar when an input is first focused. However, that code has a bug
where right after we show the selection toolbar, we still think the
toolbar should be suppressed, and therefore end up hiding the toolbar
immediately. The patch fixes that bug and introduces an ACTION_HIDE
action, which is necessary to re-hide the toolbar when the user
dismisses it manually.
MozReview-Commit-ID: DbLd2MCxSyL
--HG--
extra : rebase_source : e28fd088ff07e09931fc0bb98fd0d057843d7eb6
Because of the START_STICKY flag, upon boot completed, the service
would be started by the system which would trigger onStartCommand
and the notification being shown on Android Oreo+ devices without
a following call to onHandleIntent.
MozReview-Commit-ID: EldSSzRb7Zd
--HG--
extra : rebase_source : 2f39e499b744188e48adbdf03e426d9d50c45262
Refactored the previous test which verified if a Service was started with the
right Intent to now check if JobScheduler has the right Job enqueued with the
right work Intent.
MozReview-Commit-ID: G46GbjVVkqR
--HG--
extra : rebase_source : 4d9f030ed37767c02a27aa291f2c0338afd0619a
This tests verified if a Service was started or not. After the IntentServices
migration to JobIntentService this checks would not work anymore.
To keep the same test logic they will now check if JobScheduler has any
scheduled jobs.
Removed testStartIfReadyDoesNotRunTwiceInSuccession() because JobScheduler
already guarantees no two identical jobs can be scheduled in parallel.
MozReview-Commit-ID: JZ2XMecjsXq
--HG--
extra : rebase_source : 9d90e226adc15763c6e85842d5f896e671433e3a