Since we don't properly unmount the Console React app,
FilterBar's componentWillUnmount is never called.
This was where we planned to disconnect the resize observer,
but it was in fact never called.
So what we do in this patch instead is in the resize observer
callback, check if the observed node is connected, and if
it's not, we disconnect the resize observer.
This prevent the console from dispatching an action, that
may slow down closing the console.
Differential Revision: https://phabricator.services.mozilla.com/D45006
--HG--
extra : moz-landing-system : lando
Actually, spellchecker always allocates the heap to get text from text node. But it is unnecessary to allocate another heap here since `WordSplitState` walks text only and it is stack class.
If text is in '<textarea>', text node may be too large, so we shouldn't allocate memory to walk character in `WordSplitState` if possible. Because `TextNodeContainsDOMWordSeparator` will be called per input.
And `mWordUtil` is unused, so we should remove it.
Differential Revision: https://phabricator.services.mozilla.com/D42257
--HG--
extra : moz-landing-system : lando
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
