This commit consolidates the `insertNewLocalItems` and
`updateExistingLocalItems` triggers into a single trigger that uses
an upsert, and removes the last vestiges of annotations from the
mirror.
Differential Revision: https://phabricator.services.mozilla.com/D14035
--HG--
extra : moz-landing-system : lando
Also, use a single hidden window to hold <browser> elements
for multiple extensions.
Differential Revision: https://phabricator.services.mozilla.com/D14163
--HG--
extra : moz-landing-system : lando
We already have a fallback for items that aren't in a worker scope, we should have the same for ones that are. This means we don't need single maps (foo.js -> foo) in modules.json, and also we can identify more as explicit variables, so that no-unused-vars can detect them.
Differential Revision: https://phabricator.services.mozilla.com/D13299
--HG--
extra : moz-landing-system : lando
This is ultimately the root cause of the issue. I'm landing a test to ensure we
notice the behavior change if we make it, in addition to a test for this issue
itself, to ensure that we don't get stuck, since after bug 1510485 we don't
return such nodes from nsFind when window.find is called anyway.
This code made no sense, it only returned true if the binding parent is the node
itself, which as far as I can tell cannot happen, so it was just a very
expensive way to return false.
Differential Revision: https://phabricator.services.mozilla.com/D14122
--HG--
extra : moz-landing-system : lando
Moves bspatch.h and bspatch.cpp into new folder
Adds LICENSE, moz.yaml, and moz.build for bspatch
Alters bsdiff and updater build files to account for the new location of bspatch
Renames toolkit/mozapps/update/common/errors.h to toolkit/mozapps/update/common/updatererrors.h for
breaking windows builds. It collided with MSVCRT's exported errors.h after being added to the export list for
the 'updatercommon' library
Differential Revision: https://phabricator.services.mozilla.com/D13735
--HG--
rename : toolkit/mozapps/update/common/errors.h => toolkit/mozapps/update/common/updatererrors.h
rename : toolkit/mozapps/update/updater/bspatch.cpp => toolkit/mozapps/update/updater/bspatch/bspatch.cpp
rename : toolkit/mozapps/update/updater/bspatch.h => toolkit/mozapps/update/updater/bspatch/bspatch.h
extra : moz-landing-system : lando
Bug 1505887 changed the behavior here from content calling into nsFind via
window.find(), by making the SetStart and SetEnd calls here fail instead of
succeed for NAC (like the text in textareas).
This patch makes us handle that error gracefully moving on to the next match,
instead of trying to preserve the previous behavior.
This means that we'll fail to highlight textarea content and such from
window.find, which Chromium does, looks like. Though Chromium doesn't expose
the ranges as selection either. In any case I don't think that this is a very
common thing given bugs like bug 1442466, which this bug fixes.
I haven't found anything close to a spec for what window.find() should do... If
we decide to go with this patch then I'll add a crashtest for this and a test
for bug 1442466 as well. Otherwise I'll add a way to skip the security check in
nsFind somehow for NAC, or relax the security restrictions in SetStart /
SetEnd, I guess.
Differential Revision: https://phabricator.services.mozilla.com/D14013
--HG--
extra : moz-landing-system : lando
We already have a fallback for items that aren't in a worker scope, we should have the same for ones that are. This means we don't need single maps (foo.js -> foo) in modules.json, and also we can identify more as explicit variables, so that no-unused-vars can detect them.
Differential Revision: https://phabricator.services.mozilla.com/D13299
--HG--
extra : moz-landing-system : lando
