The expandable overflow fields in the cert viewer have 0px border and 1px
padding by default, and 1px border and 0px padding on hover. Since subpixel
borders are calculated differently from subpixel padding, this causes different
results when window scaling factor is not an integer multiple of 1.
For 1.5x scaling, an input 1px padding can yield either 2px or 1px output
depending on results of scaling algorithm, but an input 1px border will only
yield a 1px output, in order to keep the border crisp and symmetric on every
edge of the bounding box. So when we hover the long hex field, it may lose 1-2
pixels of height as ~1.5px worth of padding (between 1px and 2px) is replaced
with exactly 1px of border.
Patch will fix this by just replacing the 1px padding with a 1px transparent
border. That way the field's height is a function of the same scaling scheme in
all states, so won't change on hover.
Differential Revision: https://phabricator.services.mozilla.com/D139563
This was done because the existing cancel icon (browser/components/newtab/data/content/assets/glyph-cancel-16.svg) is a variation of the (/toolkit/themes/shared/icons/close.svg) in the toolkil icon library and it makes sense for the former to live alongside the latter.
Differential Revision: https://phabricator.services.mozilla.com/D144075
This patch adds support for including the canvas contents in Firefox
Screenshots for Canvas 2D, WebGL and WebGPU. It is already working for
context's created through an OffscreenCanvas, but we failed to hook up
the main thread path after refactoring in previous bugs.
Differential Revision: https://phabricator.services.mozilla.com/D144310
This patch hooks up the improved CanvasManagerChild::GetSnapshot method
to the WebGPU canvas context object in order to do readbacks for various
DOM facing methods such as ConvertToBlob and for Firefox Screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144309
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
The function was setting extra classes on both
the summary and the detail, running extra checks
to not remove the base classes.
It's only called from one place, and we only care
about adding classes to the summary element, which
we have access to directly.
We're switching to classList.(add|remove) , which
allows us to get rid of the SplitView method.
Differential Revision: https://phabricator.services.mozilla.com/D144427
Only the detail element was needed in the callback, so we remove all the other
unnecessary parameters.
This allows us to also remove the `data` option.
Differential Revision: https://phabricator.services.mozilla.com/D144268
Since there's nothing asynchronous happening before the item gets added to the
list, the consumer can directly use the properties of the object returned by
'appendTemplatedItem'.
Differential Revision: https://phabricator.services.mozilla.com/D144267
MHomeObjectSuperBase has the same semantics as MSuperFunction, but only the
latter is marked as movable and has a congruentTo override.
Differential Revision: https://phabricator.services.mozilla.com/D144300
While adding this new html page for breakable lines,
I revisit how we load same-url.sjs and use this iframe document instead.
This feel more natural than dynamically injecting a document-builder iframe.
Also I promote breakable lines and positions tests to become features tests.
And it looks like adding the iframe target slow things down for the quick open.
So I tuned the related assertion to avoid intermittents.
Last but not least, this patch highlights two limitations for iframe html debugging:
* only the first inline script is "breakable" (others are ignored)
* on reload, no content is displayed at all (this is new to me)
Differential Revision: https://phabricator.services.mozilla.com/D143989
This can happen on regular content (I see it when loading google.com on
a debug build for example). Given there's no action to take it seems
only noise atm. No strong opinion into whether it's better to ifdef the
code or just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D144415
In child processes, Gecko Profiler's profiler_start/stop are running OFF the main thread, so the calls to Ensure/ReleaseBufferForMainThreadAddMarker should be dispatched to the main thread for them to actually create/destroy the main-thread buffer.
Note that this is not done in the Base Profiler, because it should always run on the main thread, and if it wasn't there would be no way to dispatch a task to the main thread -- and it wouldn't be too much of an issue anyway, there are few markers running outside of Gecko Profiler sessions.
Differential Revision: https://phabricator.services.mozilla.com/D144387
