We'd like to be able to implement label features with a Custom Element, and we
don't want to run CE reactions inside of NAC.
Differential Revision: https://phabricator.services.mozilla.com/D8241
--HG--
extra : moz-landing-system : lando
This is to know if DAMP works without e10s shims.
MozReview-Commit-ID: 2IZGlenkuzb
Differential Revision: https://phabricator.services.mozilla.com/D8839
--HG--
extra : moz-landing-system : lando
Added new getters to the ADB scanner so our runtime objects have now the information we need.
Note that the UX of the devices in this patch doesn't still match what we had in the mockups (icons don't match, and we also need a circle with a tick), but since we have another bug to handle the CSS in the Sidebar, we can always adapt it there. The information needed to display what is shown in the mockups should be passed in this patch –if I miss anything, give me a shout!
Differential Revision: https://phabricator.services.mozilla.com/D7705
--HG--
extra : moz-landing-system : lando
This is a refactor of the components used in the sidebar. TL;DR: sidebar items now use the composition approach outlined here https://reactjs.org/docs/composition-vs-inheritance.html
Before we had a container `Sidebar` component, which in turn had `SidebarItem` components inside. The issue was that depending on what item is inside, the information and UX displayed is different. Before this patch, we had an optional commponent, `DeviceSidebarItemAction` –which was featuring a "Connect" button, and was only rendered in the runtime sidebar items. However, we now need to display even more info, so continue to pass optional components to `SidebarItem` was tricky.
What this patch does is to preserve `SidebarItem` and treat is a generic container of more specific content. This is passed via the `children` prop, which React automatically maps to the DOM content that we pass to that component (this is the same concept as slots in Web Components / Vue). `SidebarItem` now only contains the logic to select items in the sidebar and render them in `<li>` elements. Two new components, `SidebarFixedItem` (for our "static" pages) and `SidebarDeviceItem` are now the ones instancing `SidebarItem` with their specific contents.
Differential Revision: https://phabricator.services.mozilla.com/D7704
--HG--
extra : moz-landing-system : lando
Sometimes the protocol buffer data (RiceEncodingData) sent by Google's Safe Browsing server has the following properties:
1. |has_first_value| is false
2. |num_entries| > 0
In this case, we can still parse the data and apply partial update correctly by assuming that the first value is equal to 0.
Differential Revision: https://phabricator.services.mozilla.com/D6393
--HG--
extra : moz-landing-system : lando
The mNeedsComposite counter was used to force a composite immediately if
the scheduler received a number of composite requests without actually
getting a vsync. It was necessary on Fennec because of main-thread
contention. However it was wrong because it assumes only a single
composite gets requested per vsync interval, which is not true. Instead
of using a counter this patch uses a timestamp to ensure that we only
force the vsync after two vsync intervals have elapsed.
Depends on D8765
Differential Revision: https://phabricator.services.mozilla.com/D8766
--HG--
extra : moz-landing-system : lando
Animated images inside of SVGs and used in XUL frames did not get the
configured animation image mode from the pres context.
Differential Revision: https://phabricator.services.mozilla.com/D8586
* Change to isValidNumber to allow any number length in the range. This also removes 9 as a valid payment card number length
* Amend form autocomplete test for sensitive 9 digit numbers. We no longer consider them valid cc numbers, test for 19 digit numbers instead
* Fix intermittent issue in a session restore tests. It turns out Date.now().toString() can sometimes pass the Luhn algorithm and look like a valid credit card number. I believe this could lead to it being treated as sensitive data which is not saved and restored, failing the test
Differential Revision: https://phabricator.services.mozilla.com/D8271
--HG--
extra : moz-landing-system : lando
A lot of loops in HTMLTableEditor.cpp scans cells along column-axis or
row-axis. In those cases, they need to skip columns/rows which are spanned
from prior column/row. So, we can rewrite them with CellData::NextColumnIndex()
or CellData::NextRowColumn().
Differential Revision: https://phabricator.services.mozilla.com/D8358
--HG--
extra : moz-landing-system : lando