This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This is a similar concept as `nullptr` is to a pointer.
`BlocksRingBuffer` now skips the first byte in the buffer, so that no entries
start at 0 (the internal default `BlockIndex` value).
All `BlocksRingBuffer` public APIs handle this default value, and do nothing
and/or return Nothing (as if it pointed at an already-deleted entry).
Added tests for this, and for all BlockIndex operations.
Differential Revision: https://phabricator.services.mozilla.com/D38667
--HG--
extra : moz-landing-system : lando
Actually we set _DEPEND_CFLAGS to both host and target compiler. But if host and target are different compiler type, we may pass invalid option.
Differential Revision: https://phabricator.services.mozilla.com/D38457
--HG--
extra : moz-landing-system : lando
Without declaring them, ModuloBuffer had its copy&move constructor&assignments
defaulted. This means it could have been copied, and then both objects would now
own the same resource and attempt to free it on destruction!
So now:
- Copy construction&assignment are now explicitly disallowed.
- Move assignment is disallowed, to keep some members `const`.
- Move construction is allowed (so a function can return a ModuloBuffer), and
ensures that the moved-from object won't free the resource anymore.
Bonus: `mBuffer` is now `const`, to ensure that it cannot point at something
else, but note the pointed-at bytes are *not* const.
So ModuloBuffer is like an unchanging resource, but it allows to be moved-from
as an xvalue that should not be used after the move.
Differential Revision: https://phabricator.services.mozilla.com/D38665
--HG--
extra : moz-landing-system : lando
In `Breakpoint.js` I added an if else statement to the function `addBreakpoint()` to add/remove class "breakpoint-disabled" depending on the value of `breakpoint.disabled`. I then added a selector in `Editor.css` to set `color: blue`.
Differential Revision: https://phabricator.services.mozilla.com/D38017
--HG--
extra : moz-landing-system : lando
This patch adds an additional data output to android power tests. This data is the power usage of the test calculated as a percentage increase relative to the OS baseline. test_power.py needed to be changed to accommodate these changes as well.
Differential Revision: https://phabricator.services.mozilla.com/D37462
--HG--
extra : moz-landing-system : lando
This is latent bug in the code. The layers id used in the parent process'
call to SetTargetAPZC was always the one that the APZ hit-test produced.
But in the case where the parent process had a chrome event listener that
does a preventDefault on the event, that is the wrong layers id to use,
because we want to use the parent process' layers id instead of the content
process' layers id.
The reason the test in this bug hits this is because with WebRender enabled
the code in APZCTreeManagerParent that receives the SetTargetAPZC message
checks the layers id to see if it matches expectations (if it doesn't, it
assumes a malicious content process). In this scenario the layers id doesn't
match and causes an assertion failure. With this fix the layers id matches
expectations.
I don't believe this has any functional effect beyond the malicious content
process check.
Differential Revision: https://phabricator.services.mozilla.com/D38238
--HG--
extra : moz-landing-system : lando
This is because of profiling and performance regressions, which we don't want
to live with while we investigate.
Differential Revision: https://phabricator.services.mozilla.com/D38645
--HG--
extra : moz-landing-system : lando
Removing the lwt aliases from the theme API schema is not going to be enough, because the images and colors properties are very permissive on the unknown properties (likely to prevent a property supported on chrome but not on firefox to prevent the theme from being installed), and so removing the lwt aliases from the schema would not raise any error (the theme API implementation would just be silently ignoring the deprecated lwt aliases).
For the above reason the following patch use the following approach:
- kept the deprecated lwt aliases in the schema, but changes the deprecation warning message to mention that the property is now completely ignored by Firefox, and which property should be used instead
- removed the deprecation warning from the toolbar_text theme colors property, as we decided that we are not going to deprecate it anymore
- changed the theme API implementation to ignore the deprecated lwt alias property
- repurposed browser_ext_themes_lwtsupport.js test file to verify that the lwt aliases are ignored as expected
A separate addons-linter pull request is going to be created, to ensure that the addons-linter will raise linting errors (instead of linting warning) when these deprecated lwt aliases are being used in a theme (to prevent that newly submitted theme versions including the aliases will go unnoticed).
Depends on D37890
Differential Revision: https://phabricator.services.mozilla.com/D37891
--HG--
extra : moz-landing-system : lando
