This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500
Differential Revision: https://phabricator.services.mozilla.com/D38809
--HG--
extra : moz-landing-system : lando
All fronts are destroyed when we call TargetMixin.destroy.
All but the inspector. This changeset move the inspector front destruction
from being done in parallel to panels destruction to do it after.
This highlight races in tests that are not waiting correctly for the full
loading of the grid sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D39408
--HG--
extra : moz-landing-system : lando
InspectorFront.destroy isn't returning a promise. So the `await` in the toolbox
code is not relevant and is only spinning the event loop.
Removing it introduce races which should be fixed.
The toolbox buttons shouldn't try to unhighlight if the inspector isn't used.
Differential Revision: https://phabricator.services.mozilla.com/D39407
--HG--
extra : moz-landing-system : lando
This patch ensures that any existing query text in the search bar is highlighted when the Cmd/Ctrl + F shortcut is used.
Differential Revision: https://phabricator.services.mozilla.com/D38934
--HG--
extra : moz-landing-system : lando
This actor isn't implemented for processes, but only by browsing context targets.
Differential Revision: https://phabricator.services.mozilla.com/D38905
--HG--
extra : moz-landing-system : lando
This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500
Differential Revision: https://phabricator.services.mozilla.com/D38809
--HG--
extra : moz-landing-system : lando
WIP for metaclass concept
The best place to start is the test, it outlines what the API looks like.
Differential Revision: https://phabricator.services.mozilla.com/D37253
--HG--
extra : moz-landing-system : lando
Before this patch we would only treat audio elements as replaced if they
had something visible on the page, so if they had the controls attribute.
This is a specific case that we don't really need to worry about. If we
unconditionnally assume audio elements are replaced, then the code is
simpler and the heuristic is still fine for the vast majority of cases.
In fact, it's even more correct, as an audio element that's inline and
does *not* have the controls attribute still has active width/height
properties. So we do need to treat it as replaced even in this case.
Differential Revision: https://phabricator.services.mozilla.com/D39216
--HG--
extra : moz-landing-system : lando
All fronts are destroyed when we call TargetMixin.destroy.
All but the inspector. This changeset move the inspector front destruction
from being done in parallel to panels destruction to do it after.
This highlight races in tests that are not waiting correctly for the full
loading of the grid sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D39408
--HG--
extra : moz-landing-system : lando
InspectorFront.destroy isn't returning a promise. So the `await` in the toolbox
code is not relevant and is only spinning the event loop.
Removing it introduce races which should be fixed.
The toolbox buttons shouldn't try to unhighlight if the inspector isn't used.
Differential Revision: https://phabricator.services.mozilla.com/D39407
--HG--
extra : moz-landing-system : lando
The code callng action.updateRequest, in FirefoxDataProvider, expects the updateRequest action
to be processed once the returned promise is resolved. Otherwise it may spawn
duplicated requestData requests.
Differential Revision: https://phabricator.services.mozilla.com/D39153
--HG--
extra : moz-landing-system : lando
We retrieve the preference in the hudservice, where
WebConsoles and BrowserConsoles are created from.
If the pref is set to true, we assign a different
title to the Browser Console window so it will be
easier to spot.
The preference is then passes to the BrowserConsole,
WebConsole, WebConsoleUI and finally WebConsoleConnectionProxy
instances.
Later, we'll check this pref to connect to different
targets and listen to new ones.
Depends on D39646
Differential Revision: https://phabricator.services.mozilla.com/D39647
--HG--
extra : moz-landing-system : lando