WebRenderBridgeParent::RemoveEpochDataPriorTo() does not check when animation is added by using epoch. Then there is a case that animation is deleted too early.
Differential Revision: https://phabricator.services.mozilla.com/D17799
--HG--
extra : moz-landing-system : lando
The patch intend to remove unexpected directories in indexedDB directory instead
of breaking the initialization. Note that since it removes directories while
finding them, it also switches the key (internal) for GetBaseFilename and
GetEntry to external.
Differential Revision: https://phabricator.services.mozilla.com/D16448
--HG--
extra : moz-landing-system : lando
After this patch, in the beginning of each removing for a database, a marker
file will be created and then will be deleted after completing the remove. If
somehow the remove fails, we can know that by checking the file in the next
open.
Note that this patch intends to have a lazy clean-up if there is a failed
remove. Which means that the marker files are checked only when initialization,
and opening the same database again.
Differential Revision: https://phabricator.services.mozilla.com/D16446
--HG--
extra : moz-landing-system : lando
This was added back in bug 1414287, as a sort of quick hack, but since
then, bug 1515528 fixed things such that the hack is not necessary
anymore, and bug 1523201 allows for things to work on automation
(HOST_LINKER ended up being wrong because of the lack of "proper" VC
configuration on automation)
Differential Revision: https://phabricator.services.mozilla.com/D17790
--HG--
extra : moz-landing-system : lando
And remove all the variables that configure will figure out for us as a
consequence. This has the side effect of making the automation builds a
little more like local builds, in that they don't rely on preset PATH,
LIB, etc. for the build to work.
Differential Revision: https://phabricator.services.mozilla.com/D17789
--HG--
extra : moz-landing-system : lando
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--HG--
extra : moz-landing-system : lando
We can't run dump_syms without the DIA SDK binary directory in $PATH
because dump_syms requires the DIA dll from there.
Obviously, the corresponding test can't run if the DIA SDK binary
directory is not known (rather than when the dia2.h header is not found,
since the build system currently relies on WIN_DIA_SDK_BIN_DIR being
given manually).
Differential Revision: https://phabricator.services.mozilla.com/D17892
--HG--
extra : moz-landing-system : lando
PresShell::HandleEvent() and PresShell::HandleEventInternal() are too big.
Additionally, we have a lot of methods used only by them. So, if we'll
split those big methods, PresShell will have a lot of small methods which
are not grouped as a part of event handling. That's too bad because some
of them may depend on the calling order, etc.
So, for grouping them, PresShell should create a stack class instance to handle
each event. Then, we can store shared information in it only while we're
handling an event.
This patch creates PresShell::EventHandler and PresShell methods become
wrappers of the stack class, but this patch does not change any logic in the
code, i.e., just reorganizing existing methods.
Note that HandleEventWithTarget() and HandleEventInternal() need to take
WidgetEvent rather than WidgetGUIEvent. Additionally, some other methods
require WidgetGUIEvent to refer WidgetGUIEvent::mWidget. Therefore, this
patch does not make the new class store the event as a member.
Differential Revision: https://phabricator.services.mozilla.com/D16951
--HG--
extra : moz-landing-system : lando
Record some profiling overhead data, stored in Gecko profiles under
"profilerOverhead_UNSTABLE". Unstable for now as it will first be used
internally to help with profiler performance, and find regressions in upcoming
work; The choice of data may change as we explore what we need.
Eventually this data could be presented in the front-end, to indicate how much
the profiler may have influenced the profiled software.
Differential Revision: https://phabricator.services.mozilla.com/D16522
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
Also allow the nursery to shrink up to half it's current size, previously
it'd be one chunk at a time. Growing is still capped at twice the current
size. These limits tend to prevent it changing too dramantically for small
changes in allocation patterns.
Differential Revision: https://phabricator.services.mozilla.com/D17594
--HG--
extra : moz-landing-system : lando
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--HG--
extra : moz-landing-system : lando
Clang 8 seems to generate destructor decls from different source
locations which breaks an assertion in the code. This patch updates the
code to remove the assertion and more robustly handle the new
declarations.
Differential Revision: https://phabricator.services.mozilla.com/D17902
--HG--
extra : moz-landing-system : lando
Bug 1508522 relaxed async animation size restriction with WebRender. Then test_animation_performance_warning.html also needs to be updated to accept it.
Differential Revision: https://phabricator.services.mozilla.com/D17470
--HG--
extra : moz-landing-system : lando
Skip the test since content side basically does not do painting when WebRender is used and the test depends on content side painting.
Differential Revision: https://phabricator.services.mozilla.com/D17800
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
It turns out, we don't need to `mk_add_options export` the variables
from the in-tree mozconfigs. If anything, that causes problems when
trying to simplify the mozconfigs, because it makes the variables
exported from .mozconfig.mk, overriding what configure may change and
store in autoconf.mk.
All the variables are handled by configure in a way that makes them
available in autoconf.mk, so there's no loss there, and with the
python/shell-based mozconfig loader, it turns out we don't need to go
through extra normalization via cmd.
autospider.py, being its own pseudo-mozconfig parser, still does need
it, though, but it was hooking into it already, so just inline that.
Differential Revision: https://phabricator.services.mozilla.com/D17769
--HG--
extra : moz-landing-system : lando
Previously, we hardcoded HostX64 because configure would autodetect a
x86 host on x64 machines, but the x86 MSVC compiler wouldn't be
suitable.
While the x86 MSVC compiler might still not be suitable, now that
configure detects x64 hosts properly, when the configure host is
detected as x86, we can't even execute the x64 compiler, so we can at
least try with the x86 one correctly.
Differential Revision: https://phabricator.services.mozilla.com/D17788
--HG--
extra : moz-landing-system : lando
The combination of bug 1515579 and bug 1520394 made things harder for
old-configure, because it doesn't necessarily have a complete view of
the search PATH that has been used. This doesn't actually cause problems
on non-Windows builds because things work out fine, but on Windows,
some of the executions of clang-cl in old-configure insist on being able
to find a MSVC install. That, again, doesn't currently cause problems in
general on local builds because clang-cl finds it through the registry
(presumably), and on automation, because it's in the `mk_add_options
export`'ed PATH, but the latter is due to change.
Depends on D17772
Differential Revision: https://phabricator.services.mozilla.com/D17783
--HG--
extra : moz-landing-system : lando
Also, while here, replace subprocess.check_output with check_cmd_output.
Depends on D17771
Differential Revision: https://phabricator.services.mozilla.com/D17772
--HG--
extra : moz-landing-system : lando
Bug 1520394 changed things such that the configure sandbox is using a
copy of os.environ. So when mozconfig injects environment changes, they
only affect the sandbox. Which means when the which module uses
os.environ to get PATH, it gets the original unmodified environment.
So instead of relying on the which module getting PATH itself, we feed
it with it. It's worth noting that the which module adds `.` on Windows,
but we don't copy this behavior, because in the context of configure,
it's actually not important (`.` would be the topobjdir).
Differential Revision: https://phabricator.services.mozilla.com/D17771
--HG--
extra : moz-landing-system : lando
--host is autodetected and may not actually be what the currently given
values are.
Differential Revision: https://phabricator.services.mozilla.com/D17765
--HG--
extra : moz-landing-system : lando
The crash happens when we try to reparent the absolute/fixed
positioned children to the non-column-span wrapper's absolute list.
When constructing the multicol container, we want it to be the
absolute/fixed position container, not the moz-column-content anonymous
blocks. Hence the modification in AppendFramesToParent() and
ConstructBlock().
Delete AdjustAbsoluteContainingBlock() because we'd like to reparent
absolute/fixed children to non-first continuation of block descendant of
multicol. And it doesn't crash anymore today.
Differential Revision: https://phabricator.services.mozilla.com/D16728
--HG--
extra : moz-landing-system : lando
Don't warn about measurements that aren't available for the current platform.
Differential Revision: https://phabricator.services.mozilla.com/D17862
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
