frame #5 of report https://crash-stats.mozilla.org/report/index/4dca6cb1-8d45-4bf5-8836-216810200217
This crash was rather obvious in retrospect, but I missed it because I was
looking at the wrong thing. We're not actually crashing in FlushCache,
instead mHostResolver is null in nsDNSService::Observe
What made it obvious is frame #5 of report https://crash-stats.mozilla.org/report/index/4dca6cb1-8d45-4bf5-8836-216810200217
Included here because crash reports expire:
```
1 libxul.so nsHostResolver::FlushCache(bool) netwerk/dns/nsHostResolver.cpp:740
2 libxul.so nsDNSService::Observe(nsISupports*, char const*, char16_t const*) netwerk/dns/nsDNSService2.cpp:1132
3 libxul.so nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverList.cpp:66
4 libxul.so nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverService.cpp:295
5 libxul.so DecreasePrivateDocShellCount() docshell/base/nsDocShell.cpp:306
6 libxul.so nsDocShell::Destroy() docshell/base/nsDocShell.cpp:5076
```
See the code points to this line:
ef373efc99/docshell/base/nsDocShell.cpp (l306)
As we can see, it emits the "last-pb-context-exited" notification,
and nsDNSService tries to call FlushCache.
However, it appears this notification may be called after we get the shutdown
notification and we null out the pointer. It's unclear why this crash was not
noticed before bug 1450893 landed.
Depends on D63107
Differential Revision: https://phabricator.services.mozilla.com/D63108
--HG--
extra : moz-landing-system : lando
Chrome does not allow nested `Document.execCommand()` calls:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/editing/commands/document_exec_command.cc;l=75;drc=301e5d079a1b4c29c5b17574d0470e6db7370acc
On the other hand, Safari (and Firefox) allows it. However, it's worthwhile to
follow Chrome's behavior.
This patch makes `Document::ExecCommand()` return `false` when it's called
while running another `Document::ExecCommand()` call on Nightly and early Beta.
This is exactly same behavior, and we should watch broken web apps reports
for a while before riding this on the train.
And this patch sets the pref to `true` when all crash tests under
`editor/libeditor/crashtests` which depend on nested calls of `execCommand` run
since same things may be reproducible with other DOM APIs.
Differential Revision: https://phabricator.services.mozilla.com/D62815
--HG--
extra : moz-landing-system : lando
Factor some parts of the YUV brush shader out into a shared
yuv.glsl shader include.
In future, this shader code will also be referenced by the
composite.glsl shader when using the simple (Draw) compositing
mode, to composite video surfaces directly into the framebuffer
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D63123
--HG--
extra : moz-landing-system : lando
Depends on D62894
Using a real local client allows to cover more codepaths than using a complete mock here.
Differential Revision: https://phabricator.services.mozilla.com/D62891
--HG--
extra : moz-landing-system : lando
Depends on D62893
The issue here is that we are trying to destroy the workers-listener after the target was destroyed,
and calling unwatchFront on a destroyed Front throws.
Most of the fronts monitored in workers-listener are handled by the watchFront API, so properly adding
onDestroyed handlers fixes some issues. However the rootFront cannot be handled with a similar pattern
at the moment.
In general, I think making watchFront/unwatchFront safer to call makes sense, but I could also check
if the rootFront is already destroyed in workers-listener's destroy
Differential Revision: https://phabricator.services.mozilla.com/D62894
--HG--
extra : moz-landing-system : lando
This will avoid part of the exceptions thrown when disconnecting a remote runtime.
However the rootFront unwatchFront calls will still throw because the root front is already gone at this point
Differential Revision: https://phabricator.services.mozilla.com/D62893
--HG--
extra : moz-landing-system : lando
MS-IME should get `TS_E_NOLAYOUT` error correctly when it's running on Win10
Build 17643 or later. However, according to the bug report, MS-IME itself
does not handle it correctly. Therefore, we need to enable a hack for MS-IME
for Japanese even when
`intl.tsf.hack.allow_to_stop_hacking_on_build_17643_or_later` is true.
Differential Revision: https://phabricator.services.mozilla.com/D63045
--HG--
extra : moz-landing-system : lando
'fixed' because Talos reports FPS and I'm not sure how to change it.
'30000' because so long as we're over ~3fps, we should get solid perf
data. (and Chrome hits 60fps for me on 10k, but ~30fps at 30k, and we
want room to grow)
Differential Revision: https://phabricator.services.mozilla.com/D63011
--HG--
extra : moz-landing-system : lando
The original check, `currentContent != startContent`, is to skip the element we started on in frame traversal.
This would happen for instance on a scrollable element, where frame traversal could return the element again.
However, in shadow dom case, the frame traversal may start on a redirected shadow host, where `startContent` is still the original start element.
Differential Revision: https://phabricator.services.mozilla.com/D61566
--HG--
rename : testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero.html => testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-host-scrollable.html
extra : moz-landing-system : lando
The checks for `*TopLevelScopeOwner` are to skip the scope that we have already checked.
But when the shadow host is scrollable, we will traverse anonymous children for the scroll frame first in frame traversal and `oldTopLevelScopeOwner` will be reset.
Then we don't realize that we have already checked the host's scope.
Differential Revision: https://phabricator.services.mozilla.com/D60923
--HG--
rename : testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-host-not-set.html => testing/web-platform/tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-host-not-set-scrollable.html
extra : moz-landing-system : lando
IsCombiningDiacritic(-1) returns false, so there is no need to specially
handle -1 in GetLowerUTF8Codepoint_inline.
It is no longer necessary for GetNaked to check whether a character is a
combining character because all callers now skip combining diacritics
and GetNaked already makes sure that decomposition removes a diacritic
and not something else.
Differential Revision: https://phabricator.services.mozilla.com/D62533
--HG--
extra : moz-landing-system : lando
This patch upgrades the major browsertime version used in-tree from 4 to 8 (including some additional fixes to fix some failing tests on our end).
We also add the node v10 requirement in this patch. Also, there were some changes in the browsertime repo's visualmetrics.py script that made it necessary to change where we find the file.
Differential Revision: https://phabricator.services.mozilla.com/D59235
--HG--
extra : moz-landing-system : lando
We're going to enable this on Mac, and it won't do to have configure
assert when we actually do so.
Differential Revision: https://phabricator.services.mozilla.com/D62799
--HG--
extra : moz-landing-system : lando
