Seems like we want to hide it whenever the title is empty, not only in the search @alias case that this bug was filed about.
Differential Revision: https://phabricator.services.mozilla.com/D18004
--HG--
extra : moz-landing-system : lando
When some of a border's corners have a border-radius, and that radius
is larger than the sum of the border width and element size, then it
results in the corners of the border overlapping. Webrender draws
borders by rasterizing each segment individually in to the cache, then
compositing them together. In this overlapping case, this has 2
problems:
a) we composite overlapping segments on top of eachother
b) corner segments are not correctly clipped to the curve of the
overlapping adjacent corners
This patch allows corner segments to be clipped by their adjacent
corners. We provide the outer corner position and radii of the
adjacent corners to the border shader, which then applies those clips,
if required, along with the segment's own corner clip when rasterizing
the segment.
As the adjacent corners now affect the result of the cached segment,
they are added to the cache key.
We continue to rasterize the entire segment in to the cache as before,
but now modify the local rect and texel rect of the BrushSegment so
that it only composites the subportion of the corner segment which
does not overlap with the opposite edges of the border.
Differential Revision: https://phabricator.services.mozilla.com/D16872
--HG--
extra : moz-landing-system : lando
In Android the embedded GeckoView can be in a scrolling parent, and move
along with the user's finger. In order to intepret touch movements for
gestures, we need to account for the device position of each touch.
Differential Revision: https://phabricator.services.mozilla.com/D17045
--HG--
extra : moz-landing-system : lando
We currently use ParentLayer pixels in GestureEventListener, it should
be Screen pixels because we care about physical distances and
thresholds, not layer-relative ones.
Differential Revision: https://phabricator.services.mozilla.com/D17042
--HG--
extra : moz-landing-system : lando
On Linux32 debug, the test switched from fail to timeout when dedicated app profiles landed (bug 1474285 etc.). It was already failing in central-as-beta simulations for the last week, the execution flow seems to have aligned with the other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D18249
--HG--
extra : moz-landing-system : lando
This was causing an issue with console.trace calls
triggered from different paths (i.e. the message
was repeated in the console, only showing the first
stacktrace).
This fixes the issue, and a test is added to
ensure we don't regress this.
This also revealed an erroneous test where we were
asserting the buggy behavior.
Doing this modifies the message shape, so we also
need to update the stubs.
Differential Revision: https://phabricator.services.mozilla.com/D18094
--HG--
extra : moz-landing-system : lando
This test seems to be still failing intermittently, and its intermittency rate looks high enough.
Looking to the logs collected on the recent intermittent failures, it seems that the issue
is still related to the extension tabs opened in the test:
The two extension tabs (each one part of one of the two test extension) are going to exchange messages
between each other, and currently there is a chance (and apparently a very good chance) that one of the
two extension tabs is not yet ready to listen to the messages sent from the other extension tab.
This patch applies to the test the additional changes needed to ensure that both the extension tabs
are ready to exchange messages, before we let them exchange these messages over the extension messaging
API.
Differential Revision: https://phabricator.services.mozilla.com/D18230
--HG--
extra : moz-landing-system : lando
`ATTRIBUTE_TYPES` was an object and we used to access it's attributes using e.g.
`ATTRIBUTE_TYPES["href"]`, which is fine in almost all cases.
The problem occurred when the attribute name was `"constructor"`. This caused us
to attempt to parse `ATTRIBUTE_TYPES["constructor"]`, which returned
`{}.constructor` therefore breaking the attribute parser.
Changing `ATTRIBUTE_TYPES` to a Map fixes the issue because
`ATTRIBUTE_TYPES.get("constructor")` returns null rather than an object
constructor.
Differential Revision: https://phabricator.services.mozilla.com/D18220
--HG--
extra : moz-landing-system : lando
Fractions of a second are lost because the division
in getting the timeout value operates on decimal valus.
As such a timeout of 100ms will result in 0ms.
Depends on D18214
Differential Revision: https://phabricator.services.mozilla.com/D18219
--HG--
extra : moz-landing-system : lando
This fixes the following regressions as introduced by
bug 1510929 for the Marionette client.
1) The custom timeout as set isn't reset if the
script times out.
2) Fractions of a second for the script timeout are
lost because the division operates on decimal valus.
As such a timeout of 100ms will result in 0ms.
Differential Revision: https://phabricator.services.mozilla.com/D18214
--HG--
extra : moz-landing-system : lando
These are not generally used for support, and there can be many of them which makes the report larger and harder to understand.
Differential Revision: https://phabricator.services.mozilla.com/D18195
--HG--
extra : moz-landing-system : lando
Bug 1450114 -Update browser themes to allow customization of selection background and text r=Jaws
Differential Revision: https://phabricator.services.mozilla.com/D17076
--HG--
extra : moz-landing-system : lando
browser_UrlbarInput_unit.js leaks the empty.xul window every time I run it on a debug build. I narrowed down the leak to the objects/properties that this patch nulls out after closing the window. Simply cleaning up these properties in a register-cleanup function isn't enough to stop the leak. It happens after the test creates either one of its two UrlbarInputs. Cleaning up the properties after each UrlbarInput is created doesn't stop the leak either. Cleaning up the properties *plus* opening a new window for each UrlbarInput does stop the leak though, so that's what this patch does.
However, the leakcheck test still logs `UNEXPECTED-FAIL leakcheck: default 1392 bytes leaked` at the end, which it does currently without this patch. That doesn't cause the test to fail though, unlike the leaks reported in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D18154
--HG--
extra : moz-landing-system : lando
Now, DevTools server is loaded with a custom loader every time we want to debug chrome
resources. We ensure toggle the "invisibleToDebugger" flag on Loader.jsm which itself propagates to DevTools Sandboxes.
Differential Revision: https://phabricator.services.mozilla.com/D18215
--HG--
extra : moz-landing-system : lando
Clang 7 was making the pow => exp2 optimization for us, and for some reason clang 8 stopped doing so. This resulted in a surprisingly large regression in raptor numbers.
Differential Revision: https://phabricator.services.mozilla.com/D18148
--HG--
extra : moz-landing-system : lando
