Added files to UNIFIED_SOURCES and removed conflicts. Files that required flags still remain in SOURCES. SOURCES use "StrictOrderingOnAppendListWithFlagsFactory" base class and UNIFIED_SOURCES use "StrictOrderingOnAppendList" base class. As of now I do not think there is an option to add flags for the later. So the files requiring flags are kept in SOURCES.
Differential Revision: https://phabricator.services.mozilla.com/D23795
--HG--
extra : moz-landing-system : lando
With the current code we'll eventually detect the cycle, but will take much
more, creating many shadow trees unnecessarily. Take for example the following:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="133" height="232774">
<style>
symbol { display: block }
</style>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<use xlink:href="#svg-sprite" width="500" height="500" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="228958" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="230866" />
</svg>
Before this patch, we'd create an svg use element subtree for #svg-sprite. That
subtree will contain two other <use> elements, one under the <symbol>, one not
under it.
Both point to #svg-sprite, but we fail to detect we're an ancestor since the
element #svg-sprite we're looking at is the clone of the #svg-sprite element.
Thus we need to take a look at mOriginal instead (which is the <use> element
under #svg-sprite) rather than at the clone.
Yeah, I had to draw the trees, it's messy :)
Blink and WebKit do something slightly different (they check the element id
directly[1]). That's not 100% correct, since you can have multiple elements with
the same ID.
[1]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_use_element.cc?l=560&rcl=861855dcb8c39ba8d42497247d433277858df79b
Differential Revision: https://phabricator.services.mozilla.com/D24565
--HG--
extra : moz-landing-system : lando
The shield historgram was reporting once per content blocking event, now it reports per page load.
Differential Revision: https://phabricator.services.mozilla.com/D24017
--HG--
extra : moz-landing-system : lando
cert_storage migrates revocations.txt via one transaction per entry, which can be expensive. This change uses a single transaction to migrate all entries.
Differential Revision: https://phabricator.services.mozilla.com/D24579
--HG--
extra : moz-landing-system : lando
Before the Array<T> type, the calltype argument could be in, out, or inout,
however with Array<T> the element type was added.
When I added Array<T>, I changed the checks in files which check calltype !=
'in' to instead check 'out' in calltype, such that element would act more like
in in most cases (not adding the outparam *).
However, I never made that change for rust code, as it didn't support Array<T>
at the time. When I turned on Array<T> support for rust code, I forgot to go
through and change the conditions, which lead to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D24283
--HG--
extra : moz-landing-system : lando
Implements a function to enable or disable all breakpoints on a line based on shift-clicking. Uses the first breakpoint's state to decide whether to enable or disable all.
Differential Revision: https://phabricator.services.mozilla.com/D24524
--HG--
extra : moz-landing-system : lando
This fixes a bug in where we render out the text content of the template when searching.
Differential Revision: https://phabricator.services.mozilla.com/D24544
--HG--
extra : moz-landing-system : lando
_autofillValueOnInput correctly uses the placeholder string as the autofilled value, but it incorrectly uses _lastSearchString as the current input value. _lastSearchString at that point is -- yes -- the previous search string, not what the user has just typed. So when _autofillValueOnInput sets selectionStart to _lastSesarchString.length, the length is one char less than what it should be.
But why does that mess up only the last char typed and not every char? Because when the first result comes in, we correctly autofill it. It's only when the first result is not an autofill result that the incorrect placeholder autofill sticks around -- e.g., just after you type the last char in an @ alias.
This patch just gets rid of _autofillValueOnInput and inlines the body in _maybeAutofillOnInput.
Differential Revision: https://phabricator.services.mozilla.com/D24551
--HG--
extra : moz-landing-system : lando
Before this change the plain text document in reader mode was not formatted/styled properly.
Differential Revision: https://phabricator.services.mozilla.com/D24541
--HG--
extra : moz-landing-system : lando
Added assert to check if the id is exceeding bounds of signed 32 bit integer.
```
x < (1<<29)
x+1 <= (1<<29)
((x+1)<<2) <= (1<<31)
((x+1)<<2) | (two bit tag t)<= (1<<31)
```
Differential Revision: https://phabricator.services.mozilla.com/D23808
--HG--
extra : moz-landing-system : lando
Except for rawParentNode, all consumers of getDocumentWalker should be ok with this fallback.
Differential Revision: https://phabricator.services.mozilla.com/D24414
--HG--
extra : moz-landing-system : lando
If we try to send them separately as we were before, we can run into
cases where we try to destroy the actors and then send the OpRemoveTexture,
which crashes.
Differential Revision: https://phabricator.services.mozilla.com/D23987
--HG--
extra : moz-landing-system : lando
I'd like to move an ipc::ByteBuf member of a struct into a Maybe,
and in order for that to work IPDLParamTraits<Maybe> needs to support
the rvalue Write.
Differential Revision: https://phabricator.services.mozilla.com/D23986
--HG--
extra : moz-landing-system : lando
As discussed in IRC. AFAICT the ORTHO_NEAR|FAR_PLANE should match
up with the ranges of valid ZBufferIds, but please double-check
me.
Differential Revision: https://phabricator.services.mozilla.com/D23599
--HG--
extra : moz-landing-system : lando
This corrects A) An issue encountered with our strategy for skipping
the end_pass call for all but an offscreen render target. See the
comment above the end_pass call for details, and B) An issue with
depth clearing where we do not clear the whole rect if there are
multiple non-intersecting documents.
Differential Revision: https://phabricator.services.mozilla.com/D23056
--HG--
extra : moz-landing-system : lando
Just a little rename for clarity - I ended up scratching my head at
something for a little more time than I should have because I assumed
this was synchronous without looking at the implementation.
Differential Revision: https://phabricator.services.mozilla.com/D21584
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
