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
