We want to use the same line decoration (dashed, dotted, wavy) shader code for
both horizontal and vertical lines, so it makes sense for them to use a
coordinate system that has been rotated (transposed, actually) so that .x always
runs parallel to the line being decorated, and .y is always perpendicular.
Before this patch, we passed the orientation enum as a vertex attribute, used a
switch to swap coordinates in the vertex shader, and then swapped them again in
the fragment shader.
This patch trades the orientation for a f32 'axis select' vertex attribute, and
uses `mix` to swap them in the vertex shader. Then no consideration is necessary
in the fragment shader: the vLocalPos varying is already in the appropriate form.
Since get_line_decoration_sizes is already thinking in terms of line-parallel
coordinates, it might seem like a good idea for decoration jobs to simply use
line-parallel coordinates throughout. However, this actually results in more
swapping and opportunities for confusion: much of the CPU work is concerned with
the rectangle the decoration's mask occupies in the texture cache, which is
axis-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D60926
--HG--
extra : rebase_source : 8dcd8455c664067dd25f583c944d611a35c25e79
extra : source : dfb21632ea198c1acdc6a34ee08113d516f666d5
Without this change, get_line_decoration_sizes returns an (inline_size,
block_size) pair, where inline_size is parallel to the line being decorated, and
block_size perpendicular. However, these values are generally used as the
dimensions of an axis-aligned bounding box for the line, not as specific
parameters to the rendering process, so it makes sense to arrange them into a
LayoutSize value in this function, since it is already taking the orientation
into account anyway.
The caller, SceneBuilder::add_line, then doesn't need to swap the components,
and the adjustment of the clipping rectangle to avoid partial dots looks a bit
more natural: widths with widths, heights with heights.
Differential Revision: https://phabricator.services.mozilla.com/D60925
--HG--
extra : rebase_source : 093d572a7a35bddc6e070fc08d511f7f164a4d89
extra : source : 3549dd471446c291864822736f4587c81741cd56
For some of these I had to take a guess due to lack of familiarity with this
code, so careful review of the actual strings would be much appreciated.
There's still a bunch of code in dom/serviceworkers that constructs a
CopyableErrorResult from just an nsresult, but I don't understand that code well
enough to write good error messages.
Differential Revision: https://phabricator.services.mozilla.com/D61201
--HG--
extra : moz-landing-system : lando
Some of these error messages are not very informative; better ones would be appreciated.
Differential Revision: https://phabricator.services.mozilla.com/D61200
--HG--
extra : moz-landing-system : lando
I think the current code made us filter out all the carefully crafted TypeError
messages we might have reported...
Differential Revision: https://phabricator.services.mozilla.com/D61198
--HG--
extra : moz-landing-system : lando
Set nsFtpChannel's content-type to application/octet-stream only when downloading a file.
Differential Revision: https://phabricator.services.mozilla.com/D61494
--HG--
extra : moz-landing-system : lando
We want to use the same line decoration (dashed, dotted, wavy) shader code for
both horizontal and vertical lines, so it makes sense for them to use a
coordinate system that has been rotated (transposed, actually) so that .x always
runs parallel to the line being decorated, and .y is always perpendicular.
Before this patch, we passed the orientation enum as a vertex attribute, used a
switch to swap coordinates in the vertex shader, and then swapped them again in
the fragment shader.
This patch trades the orientation for a f32 'axis select' vertex attribute, and
uses `mix` to swap them in the vertex shader. Then no consideration is necessary
in the fragment shader: the vLocalPos varying is already in the appropriate form.
Since get_line_decoration_sizes is already thinking in terms of line-parallel
coordinates, it might seem like a good idea for decoration jobs to simply use
line-parallel coordinates throughout. However, this actually results in more
swapping and opportunities for confusion: much of the CPU work is concerned with
the rectangle the decoration's mask occupies in the texture cache, which is
axis-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D60926
--HG--
extra : moz-landing-system : lando
Without this change, get_line_decoration_sizes returns an (inline_size,
block_size) pair, where inline_size is parallel to the line being decorated, and
block_size perpendicular. However, these values are generally used as the
dimensions of an axis-aligned bounding box for the line, not as specific
parameters to the rendering process, so it makes sense to arrange them into a
LayoutSize value in this function, since it is already taking the orientation
into account anyway.
The caller, SceneBuilder::add_line, then doesn't need to swap the components,
and the adjustment of the clipping rectangle to avoid partial dots looks a bit
more natural: widths with widths, heights with heights.
Differential Revision: https://phabricator.services.mozilla.com/D60925
--HG--
extra : moz-landing-system : lando
The issue was caused by us making a copy of the platform writer thus
triggering the destructor twice.
Differential Revision: https://phabricator.services.mozilla.com/D61477
--HG--
extra : moz-landing-system : lando
We replace SetWidthIfLength and SetOffsetIfLength with ComputeDecorationLine{Thickness,Offset} functions,
and consolidate more of the computation of the offset within this function to simplify callers.
Differential Revision: https://phabricator.services.mozilla.com/D61454
--HG--
extra : moz-landing-system : lando
Making the reverse search input not taking into account
for the editor grid layout.
This meant we needed to group icons in their own
element to be able to wrap.
Differential Revision: https://phabricator.services.mozilla.com/D61395
--HG--
extra : moz-landing-system : lando
This patch allows us to dump per-domain hit counts to add more insights in the
proxy usage.
Differential Revision: https://phabricator.services.mozilla.com/D61432
--HG--
extra : moz-landing-system : lando
Calling gtk_window_hide without pausing renderer cause crashes. Also to avoid repeated calls of NativeMoveResizeWaylandPopup from NativeMoveResizeWaylandPopup we don't call
Resize or Move anymore, we just update mBounds which is enough.
Differential Revision: https://phabricator.services.mozilla.com/D61312
--HG--
extra : moz-landing-system : lando
In the StackTracePanel component we're fetching
stacktrace data on demand. In Bug 1570476 we
added a check to make sure we wouldn't fetch
the data if the same request was selected.
The issue is that the check is done on an
undefined property, and so the stacktrace
are never fetched from componentWillReceiveProps.
The test checking the stack trace data wasn't
actually doing so by triggering the UI, so the
bug wasn't caught.
This patch fixes the issue and modifies the test
so we make sure that the stacktrace is displayed
when selecting the stacktrace panel.
Differential Revision: https://phabricator.services.mozilla.com/D61467
--HG--
extra : moz-landing-system : lando
From the documentation:
" While this interface is almost exclusively used with non-blocking streams, it is not necessary that nsIInputStream::isNonBlocking return true"
So we can't assume that a nsIAsyncInputStream is always non-blocking. Handle the case where it is.
Differential Revision: https://phabricator.services.mozilla.com/D61368
--HG--
extra : moz-landing-system : lando
The PseudoArray mechanism was introduced a while ago to render jquery-result objects as arrays (even if they're objects).
This was confusing users, so this patch removes this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D61418
--HG--
extra : moz-landing-system : lando