da -> 2e7f937e2f8409ba8525986b7a08798aaf0e0b27
fi -> 433270def265c15f1c0c082148ccf20fc2113384
hu -> d6795607a4a80bf666b34cc18c72562423303ae8
it -> 81b12d188498fa459307bc06a9124f476381f3ee
kk -> 730a8e96f01684eedce7db0995a0cdd18b8e2314
nl -> d530826100a72d7a7ef622903ea5e3a3fa880e9c
tg -> 87925c0e1a4133b5c1070057a5513a8c33ca7174
tr -> 24179e96c206916f15ee475e7de00a26257ff63a
The old code in AddFloat() used to call nsBlockFrame::ComputeFloatISize() to
compute a float's inline-size, compare it with current line's available
inline-size, and determine whether FlowAndPlaceFloat() should be called.
However, it doesn't handle an orthogonal float with an auto block-size.
Luckily, FlowAndPlaceFloat() already has logic dealing with orthogonal
floats (bug 1141867), so this patch defers the decision to place a float below
the current line until the float's margin inline-size is computed in
FlowAndPlaceFloat().
Differential Revision: https://phabricator.services.mozilla.com/D151209
This patch is a preparation for the next part, and doesn't change the behavior
yet.
FlowAndPlaceFloat() is used to return true and false. This patch changes its
return value `true` to `PlaceFloatResult::Placed` and `false` to
`PlaceFloatResult::ShouldPlaceInNextContinuation`.
In the next part, we'll move the logic dealing with "below the current line
floats" into FlowAndPlaceFloat(), and make it return
`PlaceFloatResult::ShouldPlaceBelowCurrentLine`.
Differential Revision: https://phabricator.services.mozilla.com/D151208
First of all, `nsBlockFrame::AdjustFloatAvailableSpace()` is misleading. It
doesn't adjust the argument `aFloatAvailableSpace` at all, nor does it use any
fields in nsBlockFrame. It simply returns the available space in the parent
block's content area. Thus, I move it into BlockReflowState, and have it return
the available size rather than a rect because a size is sufficient for reflowing
a float.
Also, nsBlockFrame::ReflowFloat() only cares about the available size, but not
the position of the available space, so it is sufficient to pass a LogicalSize
computed by the new method ComputeAvailableSizeForFloat().
In FlowAndPlaceFloat(), there is a loop searching for a wide enough band to
place the float. We don't need to adjust availSize every time mBCoord is changed
in the loop. We can just call ComputeAvailableSizeForFloat() to get a new
available size before reflowing the float in the `!earlyFloatReflow` branch.
This patch shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151207
In FlowAndPlaceFloat(), condense two identical assertions about float frame
parent into one.
FlowAndPlaceFloat() calls ReflowFloat() only once, either an early reflow (when
`earlyFloatReflow` is `true`) or a late reflow (when `earlyFloatReflow` is
`false`), so the reflow status is always fresh.
Differential Revision: https://phabricator.services.mozilla.com/D151203
We have to make sure the scroll animations is still responsive at
boundaries even if it's playstate is finished.
This patch includes the update of UpdateFinishedState() to match the
spec, and make sure we still tick scroll animations at finished play state.
Getting a finished state might be strange for scroll animations, and this
might be a spec issue. However, for consistency with JS-generated animations,
we'd like to align the behaviors with other browsers, and make sure we are
still match the definition of finished state in the spec.
Besides, we have to use EndTime() on the compositor so
animation-iteration-count works properly.
Tests are in the last patch.
Differential Revision: https://phabricator.services.mozilla.com/D149940
In webrender, external textures provide an override UV rect which is
not known until during rendering when the texture is actually
resolved. For brush shaders this value is automatically read from the
GPU cache, but for other shaders the UVs are passed as instance
attributes. Currently we use the overridden UV rect correctly for the
composite shader, but not the cs_scale shader.
On Android devices which do not support the
GL_OES_EGL_image_external_essl3 extension, the cs_scale shader is used
to render video in some cases. Because we were not handling the
texture's UV rect correctly, video was being rendered upside down on
some websites as a result.
This patch makes us manually override the scale shader's instance
data's source_rects when the source is an external
texture. Additionally, the cs_scale shader needs adapted to handle the
case where the UV rect is inverted.
Differential Revision: https://phabricator.services.mozilla.com/D151233
Per https://drafts.csswg.org/cssom-view/#extensions-to-the-htmlimageelement-interface:
> The x attribute, on getting, must return the x-coordinate of the left
> border edge of the first CSS layout box associated with the element,
> relative to the initial containing block origin, ignoring any
> transforms that apply to the element and its ancestors, or zero if
> there is no CSS layout box.
But we were using GetClosestLayer which stops at the first abspos
containing block or scroll frame.
Differential Revision: https://phabricator.services.mozilla.com/D151263
The object can have sparse elements because `key.isInt()` only checks for
integers up to `INT32_MAX`. Replace it with a check for dense-elements.
Differential Revision: https://phabricator.services.mozilla.com/D151265
We can use this telemetry to track the statistics of using
RemoteSettings to serve Safe Browsing data.
The can help us understand if we can roll out this feature to more users.
Depends on D135990
Differential Revision: https://phabricator.services.mozilla.com/D136107
This patch implements UrlClassifierRemoteSettingsService to get SafeBrowsing data (protocol v2)
from RemoteSettings instead of from the Shavar server. This is only used
by data provided by Mozilla.
To distinguish if the data should be coming from RemoteSettings or
Shavar, We added a custom scheme "moz-sbrs" to denote that the data should be
retrieved from Remote Setting. This is done by changing the value of pref
"browser.safebrowsing.provider.mozilla.updateURL" to something like
"moz-sbrf://tracking-protection-list". (Note that the hostname is not
used at this point).
The goal of this patch is to make the new architecture compatible with
the original Safe Browsing design. So we don't notify Safe Browsing
there is new data available (via "sync" event of RemoteSettings). We still follow
how Safe Browsing periodically checks whether there is a newer version of list.
Note.
This patch changes the flow comparing with how we usualy receive SafeBrowsing response from Shavar.
In Shavar case, the list data response usually comes with
"n:21600\ni:listname1\nu:redirectURL1\ni:listname2\nu:redirectURL2 ..." first.
And then we fetch the data again from the redirectURL for each list.
But in the current implementation, responses don't contain
redirectURL anymore (since we already have the data). So the mocked response
will contain all the data needed in one response.
For example:
"n:21600\ni:listname1\n:chunkdata1\ni:listname2\n:chunkdata2...".
Differential Revision: https://phabricator.services.mozilla.com/D135989
Previously, if we got a test failure and an error during teardown, we'd end up with
multiple results for the same test. This just picks the final result for the test.
Differential Revision: https://phabricator.services.mozilla.com/D151007
Inspired by emilio's suggestion in the shader module API patch. This tries to be the most straightforward way to go from the strings coming from IPC to the ones consumed by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D151024
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
After Bug 1247260, the allow-list code was fixed to handle n_buckets == 100
which means the allowlist entries are no longer needed for a number of GC
metrics.
Depends on D150652
Differential Revision: https://phabricator.services.mozilla.com/D150653
Many SpiderMonkey GC telemetry metrics are old enough that the bug_numbers
metadata was not recorded in tree, so fix that finally.
Depends on D150651
Differential Revision: https://phabricator.services.mozilla.com/D150652
In the browser toolbox window, we include common.css, but we don't
apply the theme-dark/theme-light classes, so we end up overriding the
color-scheme to light.
Instead, only override color-scheme for theme-light/theme-dark, so that
context menus and so have the right appearance.
Differential Revision: https://phabricator.services.mozilla.com/D151131
