| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
There were a few typos in the previous patch and this patch also makes tab-size animatable which didn't really require much of a change at all.
|
| |
|
|
| |
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 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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
This reverts commit ed88b99849156004c04e4a0c87ea9b2360ef19b6, reversing
changes made to c4b0715baaffc541670fd1158557aa7e61e521d3.
|
| |
|
|
|
| |
This prevents the Alt text from briefly being shown before being replaced
with the image.
|
| | |
|
| |
|
|
|
|
| |
no optimizations in layout/
(and fix a typo for cs fs)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This stub is added because websites insist on considering this
very hardware-dependent and O.S.-variable low-level font-control
as a "critical feature" which it isn't as there is 0 guarantee
that font variation settings are supported or honored by any
operating system used by the client.
On top this is a WD status feature that sites shouldn't be using, and
the feature itself is strongly discouraged for use in favor of standard
CSS font manipulation keywords like `font-weight`.
|
| | |
|
| |
|
|
| |
Tag #1343
|
| | |
|
| |
|
|
|
| |
The behavior change of document.open() requires these tests to be
changed to account for the new spec behavior.
|
| |
|
|
|
|
|
|
|
| |
This updates our behavior for computed DOM styling to no longer return
null on elements that have no display, but return a 0-length (empty)
style instead and don't throw. For this we stop looking at having a
presentation for the style and just look at the document instead.
This resolves #1219
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compared with what Pale Moon had for Solaris originally, this is mostly the same zero point I started patching from, but I've made the following changes here after reviewing all this initial code I never looked at closely before.
1. In package-manifest.in for both Basilisk and Pale Moon, I've made the SPARC code for libfreebl not interefere with the x86 code, use the proper build flags, and also updated it to allow a SPARC64 build which is more likely to be used than the 32-bit SPARC code we had there.
2. See Mozilla bug #832272 and the old rules.mk patch from around Firefox 30 in oracle/solaris-userland. I believe they screwed up NSINSTALL on Solaris when they were trying to streamline the NSS buildsystem, because they started having unexplained issues with it around that time after Firefox 22 that they never properly resolved until Mozilla began building NSS with gyp files. I'm actually not even sure how relevant the thing they broke actually is to Solaris at this point, bug 665509 is so old it predates Firefox itself and goes back to the Mozilla suite days. I believe $(INSTALL) -t was wrong, and they meant $(NSINSTALL) -t because that makes more sense and is closer to what was there originally. It's what they have for WINNT, and it's possible a fix more like that could serve for Solaris as well. Alternatively, we could get rid of all these half-broken Makefiles and start building NSS with gyp files like Mozilla did.
3. I've completely cut out support for the Sun compiler and taken into account the reality that everyone builds Firefox (and therefore its forks) with GCC now on Solaris. This alone helped clean up a lot of the uglier parts of the code.
4. I've updated all remaining SOLARIS build flags to the newer XP_SOLARIS, because the SOLARIS flag is no longer set when building Solaris.
5. I've confirmed the workaround in gtxFontconfigFonts.cpp is no longer necessary. The Solaris people got impatient about implementing a half-baked patch for a fontconfig feature that wasn't ready yet back in 2009, and somehow convinced Mozilla to patch their software to work around it when really they should have just fixed or removed their broken fontconfig patch. The feature they wanted has since been implemented properly, and no version of Solaris still uses the broken patch that required this fix. If anyone had ever properly audited this code, it would have been removed a long time ago.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Layout CSS-Grid
List of relevant patches applied:
1398537 part 2 - [css-multicol] Implement percentages for 'column-gap' (Gecko part).
1434478 part 1 - [css-grid] Stop back-computing percentage grid gaps when the percentage basis is indefinite. Treat them as zero sized instead.
1434478 part 2 - Stop back-computing percentage padding/margin when the percentage basis is indefinite. Treat them as zero sized instead.
1434478 part 3 - Remove IntrinsicISizeOffsetData::hPctPadding/hPctMargin members since they are now unused.
1434478 part 4 - Factor out constants like NS_UNCONSTRAINEDSIZE so they can be used in headers without needing nsIFrame.h (idempotent patch).
1434478 part 5 - Create nsLayoutUtils::ResolveToLength for resolving CSS <length-percentage> (idempotent patch).
1434478 part 6 - Propagate a percentage basis to nsIFrame::IntrinsicISizeOffsets for resolving padding/margin.
This is needed only for CSS Grid since in other cases we're only using IntrinsicISizeOffsets in the inline-axis and the percentage basis is always indefinite for *intrinsic sizing*. When calculating the intrinsic size of grid items in the grid container's block axis however, we do have a definite size for the grid area in the inline-axis and it should be used per: https://drafts.csswg.org/css-grid/#algo-overview "2. Next, the track sizing algorithm resolves the sizes of the grid rows, using the grid column sizes calculated in the previous step." (Percentage padding/margin for grid items is always resolved against the grid area's inline-size nowadays.)
|
| |
|
|
|
|
|
| |
This bypasses the CORS restriction of unique file: URLs in the case of
fonts loaded through CSS.
Resolves #1211.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Since we're now handling this in the network back-end, there's no
need for this anymore.
Tag #993.
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
Follow-up for #891. Tag #457.
|
| |
|
|
| |
This resolves #891
|
| |
|
|
|
| |
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
|
| |\
| |
| | |
Undo Mozilla Bug 1302937; Reinstate -moz-mac-lion-theme media query
|
| | | |
|
| |/ |
|
