This doesn't build due to unknown code state at Mozilla. The BZ bug landed hg
commit has typoes in it so can't have been what landed because it wouldn't be
compile-able. hg history lists a backup but no re-land on the JS part as well
that doesn't make sense.
On top, further work apparently involved 100 refactoring commits to come to
Mozilla's final state. I'm signing off here.
Three debug sources are producing link warnings and will be solved as Issue #1676 progresses.
This does not include JS Testing sources.
Specifically: js/src/gdb or js/src/jsapi-tests
While we do fail a couple of tests, the other mainstream browsers also fail them and I think our implementation of tab-size is good enough to be unprefixed at this point. Having this patch also makes testing easier.
Currently -moz-tab-size only accepts <number> values, and both Chrome and Firefox currently support <length> values and have for some time now. So with this you would be able to support sizes in px or em, for instance. This was implemented in Firefox 53 and was trivial to backport.
This prevents a potential race and simplifies the code a bit by keeping the
bytes read separate instead of using mData, which is modified from another
thread from OnDataAvailable.
Relaxed atomics are fine for these, since they don't guard any memory.
This actually keeps both pseudo-elements for now, since the prefixed version is
still used internally, but we need the unprefixed version for web compat.
Note: while unprefixing a non-spec-compliant pseudo here, it's exactly in line
with what other browsers do. Nobody is following the spec here and at least
we'll be doing what everyone else is with our unprefixed version.
Mozilla's original implementation of this failed a couple of tests, but this seems to solve all the problems. Basically, the caret-color wasn't able to be set differently based on whether a link was visited, and the auto value implementation was incomplete. The only test we fail now is the one where you have grey text on a grey background and the caret is supposed to be visible, but I think that may have been removed from the spec. Even if it wasn't, no other browser supports it anyway.
This CSS property allows input carets (that blinking input cursor you see in text fields), to be given a custom color. This was implemented in Firefox 53, and it was such a minor feature that no one ever missed it, but I don't see any harm in implementing this.
https://bugzilla.mozilla.org/show_bug.cgi?id=1063162
This aligns with the current spec regarding overflow-wrap: break-word and
overflow-wrap: anywhere in if it affects intrinsic sized due to considering
soft-wrap opportunities or not.
See CSS Text Module Level 3, Editor’s Draft, 1 October 2020, Section 5.5
I got very anxious about making sure I included VARIANT_OPACITY in all the places VARIANT_NUMBER was included to make sure it couldn't possibly break unexpectedly, and that led to me accidentally breaking a mechanism that prevented percentages from serializing as numbers in other parts of the code. It was a total accident, and these additions were unnecessary. Basically, the situation is that there was one part of the code where it determines what's allowed for the flex statement (and possibly other statements) by checking whether it got stored as a "number", and basically only disallows percentages if it attempted to store/serialize them as percentages.
However, it only got to that part of the code because I accidentally allowed VARIANT_OPACITY as a valid way for certain tokens to parse where it wasn't necessary. If it tries to parse it that way under very specific circumstances... percentages will be marked valid and fed through the system as numbers rather than being rejected and not serialized at all, because the check to disallow percentages there relied on them being stored as percentages.
It's a really weird thing to have a problem with in a lot of ways, because if percentages aren't allowed in a field, you would think people wouldn't try to use them there, much less depend on the broken behavior that results from them not parsing as a related value.
A race condition seemed to exist between tab destruction and un-registering a ResizeObserver resulting in a null deref crash.
The original reporter in Forum Topic 25311 experienced this on msn.com so that was the functional test reference.
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
This make MediaQueryList inherit from EventTarget and adds MediaQueryListEvent
as an interface as well as the onchange() method.
This should not affect compatibility with other code; the event object is a
MediaQueryListEvent instance, which is recognized as a MediaListQuery instance.
This DiD measure ensures that our async HRTF database loading is completed
before we actually try to use it. If not done, database() simply returns null.
Even though percentages are already treated as floats internally by the style system for computation purposes, you have to go out of your way to stop them from being read back out as percentages. What I do here amounts to storing the percentage token in the "wrong" container, the one normally used for floats. This allows a value that was read in as a percentage to be read back out as something else, which is normally prevented by the design of the style system.
This preliminary step allows percentages to be computed and display correctly,
but unfortunately it fails a test after changing VARIANT_HN to VARIANT_HPN because that allows values to be serialized as percentages. However, not doing this means percentages are rejected as valid values for the user to input. The way the style system is setup makes it hard to change this for opacity without changing it for everything else, especially since some code-saving speed hacks in Bug 636029 and Bug 441367 that make a lot of assumptions about this stuff very rigid.
There are situations where nsCSSClipPathinstance->CreateClipPath(dt)
returns null. We need to check for this before trying to use its
functions. If there is no clip path, then always return "no hit".
Host name was purely being used for HPKP and since HPKP is killed,
this can also go. Currently it doesn't do anything other than
generating build warnings.
Since the local variable is always initialized to false, we don't actually need to declare it and can just pass "false" directly as a parameter to the PrepareSheet function's bool. I was worried about code readability at first, but some well-placed comments took care of that.
This clarifies the assumptions the code is making and the order in which the variables pass through the loading process. The new variable is set after the sheet is created and prepared, and is assumed to be false in the beginning.
This is just a clean port of 1322191 and follow-up 1325970. It really seems to add create a new way to access existing code relating to block formatting and floating elements rather than implementing new functionality, and it is mercifully straightforwards.
Unless a user is debugging media errors, this detail is unnecessary to report
and could include sensitive data which could be abused by third-party
requesters. This aligns it with the standard success/error paradigms in normal
browsing situations.
This commit does several things:
- Moves the pref check from ScriptLoader to ns[I]Document so it can be called on
the document.
- Changes the atrribute freezing function to a better name that takes the
document as a parameter.
- Sets the proper async/defer attributes on HTML script elements based on
keywords and whether they are module scripts or not.
This simplifies handling of combinations of async/defer by assigning one and
only one state to scripts.
If async then always async > if defer or module then defer > otherwise blocking.
This makes sure we don't block body-referred sub-resources by head-referenced
defer and async scripts. This is important for all script loads, not just
modules, but is added here because it was run into while implementing modules.
Our use of SQLite explicitly avoids using MSVC's _msize which the lib would
notrmally use. This was set up this way in BZ bug 719579 for legitimate reasons
(because _msize would end up using the system symbol, which would crash trying
to get the size information from jemalloc allocations). Since we build the
SQLite lib separately there is no easy way to avoid this warning as it's not
directly linked against mozglue.dll which has the jemalloc functions it wants
for _msize when not using the system allocator. It is implicitly assuming the
function is an extern returning an int (with the call specifically casting to
int) which is correct (well, correct _enough_, anyway) so the warning can
safely be ignored for our specific use as it all lines up at link time.
Newly introduced aspect-ratio property did not have CSS_PROP_LIST_EXCLUDE_INTERNAL defines, resulting in the following assertion:
\!nsCSSProps::PropHasFlags(p, (1<<28)) (properties defined outside of #ifndef CSS_PROP_LIST_EXCLUDE_INTERNAL sections must not have the CSS_PROPERTY_INTERNAL flag), at ...layout/style/nsCSSProps.cpp:289
This patch resolves the assertion by adding #ifndef around the aspect-ratio property.
This is not very "clean," and is mostly done in the same sloppy way as Emilio did it because that's basically the only way you can do it. Note well that this does NOT actually turn off everything I've done in a clean fashion like ifdefs would. For instance, the Explicitly Enabled flag is still present, but is now always false because the only condition that can set it true is behind the pref and therefore inert when this pref is off. Also, because the arguments of SetDisabled have changed, my modifications to SetMozDisabled must be present regardless of whether the pref is on or off. What I have done is turn off the actual reflection of the disabled attribute in Disabled and SetDisabled, as well as in AfterSetAttr.
However, turning the pref off seems to restore more or less our old behavior, though there may be subtle differences unlike with an ifdef since this is, unfortunately, not an exact science and I can only turn off changes that happen within individual functions and not changes in how functions interact with each other.
This part of the bug was significantly complicated by the following major refactors:
https://bugzilla.mozilla.org/show_bug.cgi?id=1456435https://bugzilla.mozilla.org/show_bug.cgi?id=1459498
As best as I can tell, we just need to implement the explicitly enabled
flag on every instance of GetStyleSheetInfo, make sure
aIsExplicitlyEnabled is false in every situation except the one where
the disabled content attribute is removed from a link element, and
enable alternate stylesheets if this flag is set on them. So we take the
explicitly enabled flag as an input to PrepareSheet, and also add it to
LoadStyleLink and LoadInlineStyle. I also decided not to defer loading of
alternate stylesheets that have been explicitly enabled.
So basically, I'm trying to adapt this to UXP:
https://bugzilla.mozilla.org/show_bug.cgi?id=1281135
The earliest source of difficulty while adapting Bug 1281135 to our codebase was simply getting the new ErrorResult flag added to the SetDisabled function to play nice with the SetMozDisabled function. At this point, the implementation can actually have a stylesheet be disabled by default but there are supposedly issues with alternate stylesheets.
At first I played around with the return type of SetMozDisabled to no avail, but I found another solution fairly quickly.
https://bugzilla.mozilla.org/show_bug.cgi?id=846972https://bugzilla.mozilla.org/show_bug.cgi?id=1157898
Essentially, the way around the problem of the number of return arguments not matching up is to declare a local variable within SetMozDisabled called ErrorResult rv, and using that to store the return value of the ErrorResult argument from SetDisabled. After that, because ErrorCode was removed, you would return rv.StealNSResult() in order to report success or failure to any consumer that calls on SetMozDisabled.
Since this is supported as an alias by Firefox and Edge for the same
reasons and we have websites using this to (attempt to) override the
system-provided styling with their own, leaving out the only supported
keyword we'd otherwise have (with -moz- prefix) but still stating
-webkit-.
TODO: unprefix this completely and make the vendor prefixes aliases.
This is apparently used for fallback selection and if available it is "assumed"
Shadow DOM is also available, while this is a utility function.
Webcompat is a nightmare sometimes.
The added debug assertion does not work due to missing API.
They were added in BZ 1337491, 1395366, and others, but were primarily used for multi-threading.
This uses our existing non-multithreaded syntax instead, resolving a `no member named` build error.
The added debug assertion did not take into account microtask refactoring done in BZ 1405821.
Resulting in error: no member named 'IsInMicroTask' in 'nsContentUtils'.
This resolves the error.
https://bugzilla.mozilla.org/show_bug.cgi?id=1547792
Aspect Ratio handling simplified by using floating point integers:
- Multiplication of value (or inverse value) to a known side for Scaling
- No unequal equal values such as "4/3" vs "8/6" vs "20/15"
- Truly "Empty" aspect ratios, even if one dimension is not 0
At first, HTMLEditor::GetActiveEditingHost might return null in this situation, we should check whether nullptr is returned. At second, SplitNodeDeep returns error since curent is design mode and selection node has no parent. So we should check error.
Ref: Bug 1350772
I meant to do this a long time ago, but basically it accounts for the new XP_SOLARIS build flag that never made it into the MailNews code. Additionally, it enables a compatibility flag for Solaris 11.4 that allows us to use the three-argument implementation of ctime_r still used by Solaris 11.3 and illumos (which also appears equivalent to the NSLDAPI_CTIME implementation used by libldap internally). Also, the ctime_r function has been added to the time.h header library for a while now, not sure why Mozilla thought we didn't have a ctime_r implementation.
When using AF_CONN addresses, don't put these in the COOKIE
chunk. For these addresses it is possible to reconstruct them
locally. Conceptually, addresses are something to be shared
with the peer, but in the case of AF_CONN this might not be
the case. Therefore, zero then out.
Thanks to Natalie Silvanovich of Google Project Zero for
finding and reporting the issue.
JIT optimizations involving the Javascript 'arguments' object could
potentially confuse later optimizations, so we simply disable these
optimizations as a DiD measure.
These should all be spec-compliant and were (for release-trickling of features)
arbitrarily disabled by Mozilla at our fork point. There's no real reason to
keep them disabled since they are used in the wild.
A version bump triggering add-on compatibility check will re-evaluate the "native" status (among other things) so no extra or special work is required to fix erroneous warnings.
tl;dr instafix!
The added debug assertion did not take into account microtask refactoring done in BZ 1405821.
Resulting in error: no member named 'IsInMicroTask' in 'nsContentUtils'.
This resolves the error.
This changes NativeObject::slotSpan() to get the class from the object group
rather than getting it from the base shape to avoid a race between
Shape::ensureOwnBaseShape and background sweeping.
The implementation is based on the work by Bernstein and Yang
(https://eprint.iacr.org/2019/266)
"Fast constant-time gcd computation and modular inversion".
It fixes the old mp_gcd and s_mp_invmod_odd_m functions. The patch also fixes
mpl_significant_bits s_mp_div_2d and s_mp_mul_2d by having less control flow to
reduce side-channel leaks.
Co-authored by : Billy Bob Brumley
Includes removing an error code for a function that never fails, and removing an
error return when the function successfully did what it said it would.
Ref: BZ 1644477
According to the spec this isn't created until the module is instantiated, but
we create it when we compile the module.
We stored this previously in InitialEnvironmentSlot and copied it to
EnvironmentSlot when it was supposed to be created, but we can just store it in
the latter slot straight away and check the module's status and return null if
it shouldn't exist yet.
This reduces the number of slots needed on a moduleObject to 17.
Re: BZ 1420412 Part 1
We can't implement the second part to further reduce our number of slots,
because it relies on SetProxyReservedSlot which in turn relies on
rearchitecturing JS proxies to make reserved slots dynamic. That's a rabbit hole
we really don't want to fall into.
So, we'll end up being a bit slower because it can't be in-line allocated with
having more than 16 slots, but so be it. I sincerely doubt it will make any
practical difference.
This updates module implementation to match spec regarding handling of
instantiation errors, after it was changed yet again, this time to not remember
instantiation errors, but instead immediately rethrow applicable ones.
Ref: BZ 1420420
For checking if a module is in an error state and what the error is, it
shouldn't matter if we are currently GC-ing or not. So we don't need to check
for it, which removes the requirement to pass in the JS context (needed for
AssertHeapIsIdle's runtime check); this unblocks progress where otherwise we'd
have to figure out what the context is at the module level just to satisfy this
check.
This splits ScriptLoader up the same way Mozilla did with the exception of
ScriptRequest due to the fact that ScriptLoader and ScriptRequest are
interdependent and would create a circular dependency if split apart when not
using unified building.
Dynamic script loading/unloading (thank you modules) can yank the script
out from under us before the JS API for it is initialized, leading to
null deref crashes.
This adds a simple check if the passed-in object is sane and present.
Resolves#1602
2020-06-27 02:09:19 +02:00
8357 changed files with 61517 additions and 32208 deletions
@@ -36,4 +36,4 @@ improvement patches upstream to its origin to mutually improve the platform and
a future for XUL.
## Looking for Pale Moon and Basilisk?
As of [`Issue #969`](https://github.com/MoonchildProductions/UXP/issues/969), release versions `28.9.0` and `2020.03.04` respectively, they have been split off into their own dedicated repositories located at [`MoonchildProductions/Pale-Moon`](https://github.com/MoonchildProductions/Pale-Moon) and [`MoonchildProductions/Basilisk`](https://github.com/MoonchildProductions/Basilisk).
As of [`Issue #969`](https://repo.palemoon.org/MoonchildProductions/UXP/issues/969), release versions `28.9.0` and `2020.03.04` respectively, they have been split off into their own dedicated repositories located at [`MoonchildProductions/Pale-Moon`](https://repo.palemoon.org/MoonchildProductions/Pale-Moon) and [`MoonchildProductions/Basilisk`](https://repo.palemoon.org/MoonchildProductions/Basilisk).
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
Loaded 100 of 8357 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Moonchild
Matt A. Tobin
athenian200
Gaming4JC
adeshkp
J.C. Jones
Kris Maglione
Jon Coppeard
Andy
Michael Tuexen
Andrea Marchesini
Jan de Mooij
Sohaib ul Hassan
Byron Campen [:bwc]
wolfbeast