Our `INSTEAD OF INSERT` trigger for local tags reused existing tag
folders if they already existed, but not existing tag entries. This
caused us to insert duplicate tag entries for items whose tags
didn't change, which, in turn, threw unique constraint violations
when we tried to insert rows for tag entries that already existed
into `itemsAdded`. This commit gives tag entries the same treatment as
tag folders.
This commit also improves debug logging during application, so we
can pinpoint errors like this better in the future.
Differential Revision: https://phabricator.services.mozilla.com/D44769
--HG--
extra : moz-landing-system : lando
For now, when we turn on `disable cache` switch in DevTools[1], web page loads
the contents without using the cache. Furthermore, DevTools as well comes to
load the contents DevTools inspects without using the cache. And, if the loaded
contents from the web page and DevTools was different, becomes impossible to
inspect the content correctly.
Thus, in order to make DevTools refer the same content the web page loaded,
makes DevTools load the contents inspecting from the cache at first, no matter
if disables the switch or not.
When turns on disable cache in DevTools, `LOAD_BYPASS_CACHE` flag is set into
`loadFlags` in the `docshell`.[2] The other hand, the content DevTools inspects
is loaded from a channel DevTools creates with `LOAD_FROM_CACHE` flag.[3]
However, because this channel is belong to same `loadGroup` of the `docshell`,
`LOAD_BYPASS_CACHE` is inherited and is choosen even if `LOAD_FROM_CACHE` is set.
Thus, in this patch, we introduce an attribute `preferCacheLoadOverBypass`
which raises the priority for `LOAD_FROM_CACHE` above `LOAD_BYPASS_CACHE` and
`LOAD_BYPASS_LOCAL_CACHE`.
[1] https://developer.mozilla.org/en-US/docs/Tools/Settings#Advanced_settings
[2] https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1227
[3] https://searchfox.org/mozilla-central/source/devtools/shared/DevToolsUtils.js#542-544
Differential Revision: https://phabricator.services.mozilla.com/D44626
--HG--
extra : moz-landing-system : lando
The principals used in worklet scripts derive from the relevant settings object
of the main thread Worklet object, rather than the network loads of the scripts.
Moving the data off LoadInfo removes any implication that the principals might
depend on script module loads.
Differential Revision: https://phabricator.services.mozilla.com/D44775
--HG--
extra : moz-landing-system : lando
We can end up in here from a style worker thread. But that's safe since
we only read data from the FontFaceSet, and the main thread is blocked
so writes can't happen underneath us.
Differential Revision: https://phabricator.services.mozilla.com/D44589
--HG--
extra : moz-landing-system : lando
The `padding-right` is the only oversight afaict. This patch is based on D45125.
Differential Revision: https://phabricator.services.mozilla.com/D45126
--HG--
extra : moz-landing-system : lando
When toolbar is wrapped onto two rows, the second row to have white background, class `devtools-input-toolbar` is being added up
onto `devtools-toolbar devtools-input-toolbar`
Differential Revision: https://phabricator.services.mozilla.com/D42665
--HG--
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
Specially permit www.mozilla.org after ensuring other origin checks but failing ALLOW_ACTION.
Differential Revision: https://phabricator.services.mozilla.com/D45069
--HG--
extra : moz-landing-system : lando
PresentScreenBuffer() or screen->PublishFrame() may fail for different reasons. In that case we shouldn't call surface->Commit() because it may be in a not swaped state or not available.
Differential Revision: https://phabricator.services.mozilla.com/D44813
--HG--
extra : moz-landing-system : lando
Markus Stange
Masayuki Nakano
Lina Cambridge
Cosmin Sabou
Daisuke Akatsuka
Rail Aliiev
Cameron McCormack
Noemi Erli
Karl Tomlinson
Andreea Pavel
Emilio Cobos Álvarez
Harry Twyford
Drew Willcoxon
Paolo Amadini
Sonia Singla
Brian Hackett
Bogdan Tara
Toshihito Kikuchi
Mike Conley
Csoregi Natalia
Will Hawkins
Brindusan Cristian
Ed Lee
Imanol Fernandez
Gurzau Raul
Edgar Chen