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 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
