Right now, date/time fields in Fennec appear as regular text fields,
which display the date/time values without formatting. This patch makes
the fields use the Gecko controls, which do support formatting. This
only changes the appearance of the fields; we still display the native
date/time pickers when the fields are tapped on. The reset button is
hidden in the controls because the Fennec date/time picker provides
a separate "clear" button.
MozReview-Commit-ID: EBE2U1zL74Q
In geckoview_example multiprocess mode, preload child process during
startup to make e10s startup faster.
MozReview-Commit-ID: GinwBZlrnps
--HG--
extra : rebase_source : a43ef4708d311c9a100aafba0c84ee4a2e27090b
We need to wait for GeckoThread to load the Gecko libs in the main
process before we can launch any child processes, so that the child
process doesn't try to extract libs, which can conflict with any
extraction going on in the main process.
MozReview-Commit-ID: 2gUd2R1TUBI
--HG--
extra : rebase_source : d48b9e2e744669a89f2b761cf6936f28948c17c3
Avoid going through GeckoAppShell and move the start child process JNI
call directly to GeckoProcessManager.
MozReview-Commit-ID: KU62TiHVQJX
--HG--
extra : rebase_source : 0e8546da502257e1c59bc00b79f50c79a314f3e6
Refactor the code in GeckoProcessManager and GeckoServiceChildProcess so
that, we can have a ChildConnection object that's bound but not started.
This way we can bind the connection to preload Gecko child process, but
hold off starting until told by Gecko main process.
Some code is simplified. For example, `IChildProcess.stop` is removed in
favor of killing the child process directly.
MozReview-Commit-ID: 4XgmTuT0IAs
--HG--
extra : rebase_source : 94fe748556c66f639d1f8e5bb26c28ea3ed950b3
Although, Firefox for Android doesn't use urlbarBindings.xml for declaring its
awesome bar, for consistency with widget code for desktop OSes,
GeckoInputConnection should treat "mozAwesomebar" inputmode value as "url"
since Android doesn't have any special input type for "search" and we should
keep current behavior.
MozReview-Commit-ID: DpUnUx4E2Sp
When changing locales, an open dialog will not refresh but clicking on the
"Top sites" preference again (to display the dialog) will show the correct
dialog for the current locale.
MozReview-Commit-ID: 6UJvDIJZJtc
--HG--
extra : rebase_source : 777d0f4bc34829c8aacdeaac42fc0e27c3e7afd6
After speaking with liuche, we decided it'd be better to add a bit to determine
this rather than combining it with the isPocketEnabled field (which would be
loss of data) or cross-referencing the locale of the submitted event when
checking the Pocket value during telemetry analysis (which is hard to get right
and likely to get out of date).
MozReview-Commit-ID: JKFrdEsEbyp
--HG--
extra : rebase_source : bc20193ca29238cbde5361a840cbd367b492a346
Ideally, we'd centralize all queries as to which options are user specified.
However, I wanted to do the smallest change so we can uplift so I filed
bug 1405161 for this centralization.
I opted not to include the "de" locale that is included on desktop because it
does not appear we ever get the "de" locale on Firefox for Android [1].
I tested this patch by changing the system locale between locales with Pocket
on my device (en-US, en-GB, de-DE) and locales without Pocket (ko-KR). The
locale switching system makes this refresh automatically without extra code.
I also intend to test via the in-app locale switcher but that will take time
because I can't do artifact builds with multi-locale so I'm pushing this for
review before I'm finished.
Follow-up changes:
- Add to telemetry
- Hiding the preference in the undesired locales.
- A test for isPocketEnabledByLocaleInner (useful to document how this is
intended to work for locales with variants, different scripts, etc.)
[1]: https://sql.telemetry.mozilla.org/queries/4613#table
MozReview-Commit-ID: 7AVQ8fWub8I
--HG--
extra : rebase_source : 948f1a4ea6c6bbc51c8ae945b940d8ab4770e34e
This code was being mistakenly activated when getting top sites for Activity
Stream.
This is the first removal of old top sites code and will mean we can't go back
to old top sites by flipping the `ActivityStream.isEnabled` flag. Since we're
planning to ship AS, this shouldn't matter.
MozReview-Commit-ID: 9VB0RqNHmE0
--HG--
extra : rebase_source : 0c40456d12de5d7f2f2e4a0fda58b7c090754530
This is a relative of Bug 988605, with an exception that instead of going the whole way
and ensuring pickled data is kept up-to-date as Nick proposed, this patch simply ensures that
we pickle as soon as possible, with a goal of eliminating pickle races. The end goal is to kill
off pickling entirely, and so the assumption here is that this workaround is good enough
in the meantime.
MozReview-Commit-ID: 7IjRH7KE2Z9
--HG--
extra : rebase_source : e25b6d6baf5544d5a087cd9e12ec41d6176c317f
When a site opens link in a new tab that redirects to an external app,
we should close the new (empty) tab and return to the previous page.
MozReview-Commit-ID: KXWA2d26RBh
--HG--
extra : rebase_source : 601dd7a26b070102c7785f68bf2f3fec3f6f003b
Add a test case to testInputConnection that makes sure GeckoEditable's
Editable interface still behaves correctly even after disconnecting from
Gecko due to a blur.
MozReview-Commit-ID: 7Z6Kpv2tpRy
--HG--
extra : rebase_source : 9ec338c77d362a86fb0097b51bd4d55a15654f43
Bug 817386 added code to ignore IndexOutOfBoundsException when using
GeckoEditable because the code wasn't mature enough back then, and there
were many race conditions. I think the situation is a lot better now, so
we can try removing that code and see if we still need it. We can always
add it back if we do.
MozReview-Commit-ID: 4pirfaUuSNu
--HG--
extra : rebase_source : ed68d545bb5e40491720aeafe86221163c064449
Translate non-ASCII characters into hex instead of trying to print them
out.
MozReview-Commit-ID: 1aABRy6J1nm
--HG--
extra : rebase_source : f620d35e3cff12ab60e48568f33af65ad4f493c8
We want to always perform actions on the shadow text side even if a
particular GeckoEditable instance is disconnected from Gecko, because
there could be other users of Editable that still expect the object to
perform valid actions.
MozReview-Commit-ID: 48OIEaPZqUE
--HG--
extra : rebase_source : 1ab86138c81061aeb7ea600497af5290581a9fbc
When page option 'add page shortcut' is clicked, creating a shortcut(not PWA) on launcher.
Also make sure that heavy tasks are executed in background thread.
MozReview-Commit-ID: 8KtwdXENtEd
--HG--
extra : rebase_source : 12a427f549a41f9d8650b4b8d95394bdc4192c4b
Extend timeout for testEventDispatcher to 40 seconds and fix a bug where
the wrong mode is used for event callback tests. r=me for trivial
test-only fix.
MozReview-Commit-ID: JiyW8lFW8kg
By using the PartialConfigEnvironment, the clients of buildconfig will
depend on config.statusd/ files instead of config.status directly.
Clients can access substs and defines using buildconfig.substs['FOO'] or
buildconfig.defines['BAR'], and then collect file-level dependencies for
make using buildconfig.get_dependencies(). All GENERATED_FILES rules
already make use of this because file_generate.py automatically includes
these dependencies (along with all python modules loaded).
As a result of this commit, re-running configure will no longer cause
the world to be rebuilt. Although config.status is updated, no build
steps use config.status directly and instead depend on values in
config.statusd/, which are written with FileAvoidWrite. Since those
files are not official targets according to the make backend, make won't
try to continually rebuild the backend when those files are out of date.
And since they are FileAvoidWrite, make will only re-run dependent steps
if the actual configure value has changed.
As a result of using JSON to load data from the config.statusd
directory, substs can be unicode (instead of a bare string type).
generate_certdata.py converts the subst manually to a string so the
value can be exported to the environment without issue on Windows.
Additionally, patching the buildconfig.substs dict no longer works, so
the unit-symbolstore.py test was modified to patch the underlying
buildconfig.substs._dict instead.
The other files that needed to be modified make use of all the defines
for the preprocessor. Those that are used during 'mach build' now use
buildconfig.defines['ALLDEFINES'], which maps to a special
FileAvoidWrite file generated for the PartialConfigEnvironment.
MozReview-Commit-ID: 2pJ4s3TVeS8
--HG--
extra : rebase_source : d6bb0208483f9f043e7be1b36907ca13243985f8
Switching key name/default value means that we'll drop this pref for some _very_ early
adopters of this feature on the nightly channel, but that's why it's a nightly channel.
MozReview-Commit-ID: KtQmmFFPDPR
--HG--
extra : rebase_source : 725eae2a95e129eba6023eb69ebafbb19226698b
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
Apparently, if you don't have whitespace above the bulleted list, it won't
format as a list.
MozReview-Commit-ID: LiLpSNScBxR
--HG--
extra : rebase_source : b3ec064a98a531aab5f38d7f4b3f338499010e97
The top sites menu button was removed in a previous iteration and long-click is
used to access the context menu now.
MozReview-Commit-ID: KzTg4Py8o8W
--HG--
extra : rebase_source : cc145006028b301b989ded16d15d3b12317be473
In the bug, we decided that it was okay to document this case because:
1) we didn't know the specific questions we were trying to answer
2) We were facing the 57 deadline
The alternative would be to change the behavior to perhaps the more intuitive
behavior where suggested sites will always be marked as "suggested" clicks but
note that there may be privacy concerns with that (in that there are a limited
number of suggested sites so we'd know the frequency that unique users might
visit the suggested sites).
MozReview-Commit-ID: GxQZzwoZ1nQ
--HG--
extra : rebase_source : 9c6697ef478a5ba08e1503d8360d1214419266fd
We're returning a list of only a few items that, at worst, reads from
resources and is infrequently accessed: there is no reason to cache these
values and the bugs, like this one, that caches entail.
At the end of this patch, there's no crash, but the scrolling behavior isn't
great: that's bug 1403139.
MozReview-Commit-ID: 3zoXWk78cM4
--HG--
extra : rebase_source : 337fcaec7eafeaa872173eb50b14b3dbb9067b90
We manipulate the data before the dialog is shown, rather than manipulating the
Views after the dialog is shown: this is more stable.
One question is what is the value of isHidden, which we branch on, when we're
manipulating the data. isHidden is set:
- When the preference is constructed (previous commit)
- When the preference is set as the default (e.g. the default panel was hidden)
- When "Hide" or "Show" is clicked in the preference
Thus the preference (and hidden state) outlives the dialog and each time we
reread the value of isHidden to set the dialog items.
This would fix the bug but the dialog values are actually cached so we'll
need to fix/remove that cache: coming up in the next changeset.
MozReview-Commit-ID: 86v1RDNFZHZ
--HG--
extra : rebase_source : 3cc0d80e9fa5d569320b8ebbf583204dbb7dd467
This is a code clean-up. Functionally, this is the same to the previous
implementation.
setHidden was originally called right after the constructor is called and so
should just be called from the constructor. If it's not called from the
constructor, there can be a period of confusion where a developer wonders, "Has
isHidden been initialized by the time this other method I care about has been
called?" This should make those questions disappear.
This commit does not need to be uplifted (to change less in 57 and that the
other code does not depend on it) but I'm placing it first so it's clearer to
my reviewer when isHidden is initialized (which is relevant to my other
patches).
MozReview-Commit-ID: 80KXFDB1poY
--HG--
extra : rebase_source : fcc731dd0c24bc2472fe014b3b7495a2070b7989
Add a toolchain job description which calls the
repack_rust.py script to package the requested
upstream build of Rust and its standard libraries
for use in gecko builds.
Links are added to these new toolchains for various build
and analysis tasks as appropriate. The base-toolchain
tasks use an explicitly-versioned toolchain since those
can be different from the current release used for most builds.
The corresponding tooltool manifest entries are removed
now that taskcluster artifact versions are available.
This simplifies the update process since new toolchains
can be packaged and used automatically by just updating
the versions in the task descriptions.
A 'linux64-rust' toolchain can be added to other tasks
as a dependency and artifact. It supports linux64-
hosted builds of Rust code targeting linux64 or linux32.
A 'linux64-rust-macos' toolchain targets linux64-hosted
builds of Rust code targeting macOS on x86_64.
A 'linux64-rust-android' toolchain targets linux64-hosted
builds of Rust code targeting various Android architectures.
Two 'win64-rust' and 'win32-rust' toolchain tasks create
similar entries for Windows-hosted builds. All our automation
builds are hosted on win64, so we could use one artifact
with support for both targets, but currently this doesn't
work because of cross-compilation issues in some crates.
This patch maintains the previous separation between
win32 and win64 rust toolchains until that can be addressed.
MozReview-Commit-ID: GRiJml8CtzO
--HG--
extra : rebase_source : 09a3698ce7f9a8b5f2b5d9b5a1fde9c05dc6b540
Only display form validation message when the element becomes invalid
after an invalid submission, by checking the "-moz-ui-invalid"
pseudo-class.
Also fix some message visibility bugs, by making sure in more places
that we only display messages for focused elements.
MozReview-Commit-ID: 16rvMmu8Zj6
--HG--
extra : rebase_source : 4d6ad6a111d7d5ee57c26129f77002c39d2bbe00
The main goal of these changes is to ensure we're not doing any unnecessary work
in the unahppy cases of BatchingUploader. We might fail in three general ways:
- encounter a 412 error
- encounter another type of HTTP error
- encounter a GUID in the "failed" array
Currently, in all of these cases, we de-facto abort the session, without performing
an actual abort. E.g. we won't commit a batch, we'll refuse to upload any still-flowing
records. This patch simplifies our unhappy-case behaviour: if something failed, actually
abort the session (triggering a shutdownNow of the work queues), declare store as failed, etc.
It's important to note that our "did the synchronization fail?" login in the SynchronizerSession
depends on the store failure counts, and so this patch maintains the "record failed to store"
delegate chain. However, these counts are largely meaningless. What does it mean to fail to store
50 records, if we abort on the 51st, and prevent the other 100 from flowing (and from being counted
as failed?).
This patch also fixes an omission in the verstion tracking logic:
- prior, if we encountered a record in the "failed" array, we'd continue on with the flow, won't upload
anything, mark the synchronization as failed, but we'd also call into 'onStoreCompleted' which will
trigger an update of syncVersion for outflowing records
- with this patch, we won't call into onStoreCompleted in the case above, and so won't update syncVersion
in case of such failures
- this is the correct behaviour for batching uploads (now enabled on all but one server), but possibly
non-optimal behaviour if batching isn't enabled. However, this behaviour should be safe from a data consistency
point of view regardless of the batching mode.
MozReview-Commit-ID: LIYCPaRX8JA
--HG--
extra : rebase_source : 110224b2db85a383635db933ec6c19b21af886e7
We temporarily hide `home_add_to_launcher` in API 26, which means directly accesses it without checking
if it exists or not would cause NullPointerException.
MozReview-Commit-ID: KXnP81ZZa6u
--HG--
extra : rebase_source : 9189f3ab940d50702f82365824feff441faeef5a
Remove `GeckoAppShell.setLayerView()/getLayerView()` now that it's no
longer used anywhere.
MozReview-Commit-ID: 6URNFhSs01P
--HG--
extra : rebase_source : bd76d75fe26f9c3d8782475767e5a48fcd2cb9eb
Find the Fennec LayerView through `Solo.getView()` and the View id
instead of going through `GeckoAppShell.getLayerView()`.
MozReview-Commit-ID: FVcPM0fYorf
--HG--
extra : rebase_source : 1787cfde739eac742d28244ab29579a789997b81
Pass in a `GeckoView` instance when sending a11y events so we're not
dependent on `GeckoAppShell.getLayerView()`. However, there's likely
more work to be done to make a11y work for any GeckoView.
MozReview-Commit-ID: DBeDOX5c3qY
--HG--
extra : rebase_source : 49d9a06ec90543c49d03f298a7d78ea54bbe0a58
Jing-wei Wu
Jim Chen
Nevin Chen
Wes Kocher
Masayuki Nakano
L10n Bumper Bot
Michael Comella
James Willcox
Grigory Kruglov
Sebastian Hengst
Eugen Sawin
Atanas Minkov
Kyle Machulis
Hugh Wu
Eugen Sawin
Mike Shal
Michael Kaply
Jan Henning
Mehdi Soleimannejad
Ralph Giles
Dylan Roeh
Francois Marier
Randall Barker
Chenxia Liu
Sebastian Kaspari