The repo has seen three notable changes since last time:
- The pdb changes from PR #2, which don't really affect any outward behavior.
- I updated the version of wasm-bindgen.
- I created a WasmMemBuffer abstraction which lets us avoid the buffer copy
without relying on wasm-bindgen implementation details. This is possible due
to the new Uint8Array::view API that wasm-bindgen shipped in April.
The last part is what allowed me to simplify the code in ProfilerGetSymbols-worker.js.
Those changes are the only part that's worth reviewing.
The changes in profiler_get_symbols.js are not worth reviewing; they're
autogenerated by wasm-bindgen. The new version of wasm-bindgen generates
slightly different JS code, and the addition of the WasmMemBuffer struct also
caused some of that JS code to change.
Differential Revision: https://phabricator.services.mozilla.com/D37130
--HG--
extra : moz-landing-system : lando
Bug 1557789 added categories to all JS frames, so as a result JS frames
where all filtered out because of the condition removed in this patch.
This condition is basically a premature optimization, removing it
shouldn't bring any behavior difference.
Differential Revision: https://phabricator.services.mozilla.com/D44803
--HG--
extra : moz-landing-system : lando
Previously, primitive sub-dependencies (such as transforms, opacity
bindings etc) were invalidated by comparing the dependency array
only. This means that it's not possible to correlate an area of
a tile that is affected by those sub-dependencies.
Now, comparisons on sub-dependencies are handled as part of the
dependency check for each primitive. This means we have the
affected rectangle of the tile available, which will allow
dirty regions within a tile to be built correctly.
This patch is only preparation work - the actual dirty rect
calculation will be done as a follow up patch.
Differential Revision: https://phabricator.services.mozilla.com/D44771
--HG--
extra : moz-landing-system : lando
This change introduces the HTML-based UI for the 2D Content window in Firefox
Reality for Desktop, accessed via the --fxr command line parameter.
Differential Revision: https://phabricator.services.mozilla.com/D42546
--HG--
extra : moz-landing-system : lando
I haven't been able to work out a reason why we should show the
spinner before this.loadTimer is cleared. All this does is allow
for random reordering of events to sometimes show a spinner early.
This should ideally just make the spinner logic more rubust to
event ordering changes, without sacrificing visibility into tab
switch timings.
Differential Revision: https://phabricator.services.mozilla.com/D44878
--HG--
extra : moz-landing-system : lando
This just adds a bit of information to the AsyncTabSwitcher's
logging and cleans up the display to make it quicker to find
what changed, especially with large numbers of tabs. The bit of
new information that I'm particularly interested in is what
event triggered a particular update - so now every time we call
postActions, we include the name of the event.
Differential Revision: https://phabricator.services.mozilla.com/D44710
--HG--
extra : moz-landing-system : lando
We were assuming that in the case that the status matched expected we'd have
no expected entry in the log data. But actually it was being set to None, so
handle both those cases.
Differential Revision: https://phabricator.services.mozilla.com/D44874
--HG--
extra : moz-landing-system : lando
Flex containers resolve a main-axis size for each of their flex items, and they
impose this size on the flex items by stomping on the items'
ReflowInput::ComputedISize() or ComputedBSize() data. For cases when we're
stomping on the flex item's block-axis, then this can make us improperly treat
this size as definite (i.e. use it for percent resolution).
The flexbox spec does call out some cases where the item's size *is* supposed
to be considered definite[1], but if we're not in one of those cases, we need
to be careful to treat the size as indefinite even though it's been resolved.
This patch achieves this by:
- adding a flag to FlexItem, which gets set in cases where we know we need to
treat the size as indefinite.
- adding a flag to ReflowInput, which gets set whenever a ComputedBSize is
imposed (if the FlexItem had its flag set).
- adding some code to the ReflowInput percent-resolution codepath to test for
this flag and skip past percent-resolution if it's set.
This patch makes us pass all of the existing testcases in the web-platform-test
"percentage-heights-003.html". This patch also adds a few more subtests
there to exercise cases where the flex container and item have orthogonal
writing-modes.
(Note the XXXdholbert comments in the patch about items being "fully
inflexible" in some cases in order to be treated as having a definite size.
If I were to address that comment here, then we would start failing the
web-platform-test "percentage-heights-005.html", which all browsers currently
pass[2]. Therefore, I'm not adding that restriction at this point.)
[1] https://drafts.csswg.org/css-flexbox/#definite-sizes
[2] https://wpt.fyi/results/css/css-flexbox/percentage-heights-005.html
Differential Revision: https://phabricator.services.mozilla.com/D43705
--HG--
extra : moz-landing-system : lando
As of this bug, flex items in a vertical flex container will sometimes be
considered to have "indefinite" sizes, i.e. percent sizes in them will no
longer resolve. To work around this, they need to provide a definite flex-basis
(e.g. as part of the "flex" shorthand property) if we want percent sizes to
resolve (instead of being treated as "auto") inside of them.
Differential Revision: https://phabricator.services.mozilla.com/D44734
--HG--
extra : moz-landing-system : lando
This is not the minimal patch for this issue. The minimal patch is a
one-liner that adds `MOZ_ANDORID_MMA=1` to
mobile/android/config/mozconfigs/android-aarch64/nightly. However,
the underlying issue is that the mozconfigs have not stayed internally
consistent. To reduce the likelihood of a repeat of this
inconsistency, it would be best to extract the shared flags and reduce
duplication and the risk for inconsistent updates. There's two ways
to do that: teach `moz.configure` to have the correct defaults or
share some small stanza across mozconfigs. The former is non-trivial
and not worth the risk at this time. The latter is trivial but more
effort than this is worth. Here's something in the middle: making all
the mozconfigs have minimal differences with the mainline mozconfig
for `android-api-16`. This at least allows easy auditing of the
mozconfigs with `diff`.
Differential Revision: https://phabricator.services.mozilla.com/D44865
--HG--
extra : moz-landing-system : lando
The assert verifies that there is only one preferred device. On windows it is expected to have more than one preferred device so it is removed.
Differential Revision: https://phabricator.services.mozilla.com/D44848
--HG--
extra : moz-landing-system : lando
Falls back to 'false' in non-nightly builds instead of using the gfx.webrender.start-debug-server pref, which is only available in nightly builds.
Differential Revision: https://phabricator.services.mozilla.com/D44743
--HG--
extra : moz-landing-system : lando
Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
