summaryrefslogtreecommitdiffstats
path: root/layout
Commit message (Collapse)AuthorAgeLines
* Issue #1053 - Part 2a: Remove android from /layout (partial)Moonchild2020-12-26-540/+56
| | | | | This removes android code from base, build, forms, generic, inspector, style, printing, tools and xul.
* Issue #1696 - Propagate flex sizes to the table wrapperMoonchild2020-12-15-0/+3
| | | | | | | This avoids overlapping of table styled elements inside flexboxes as used on some websites. Resolves #1696
* Merge pull request 'Fix up -moz-tab-size and unprefix it.' (#1674) from ↵Moonchild2020-10-30-326/+377
|\ | | | | | | | | | | athenian200/UXP:tab-size-length into master Reviewed-on: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1674
| * Issue #1673 - Part 5: Fix brace style and missed -moz-tab-size reference.athenian2002020-10-29-255/+212
| |
| * Issue #1673 - Part 4: Unprefix -moz-tab-size.athenian2002020-10-28-7/+18
| | | | | | | | 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.
| * Issue #1673 - Part 3: Bring minimum tab advance up to spec.athenian2002020-10-28-11/+30
| | | | | | | | This provides a clearer rule for the minimum tab advance that brings us to alignment with the spec and both major browsers.
| * Issue #1673 - Part 2: Make tab-size animatable and fix typos.athenian2002020-10-28-5/+7
| | | | | | | | 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.
| * Issue #1673 - Part 1: Allow tab-size to accept <length>.athenian2002020-10-28-62/+124
| | | | | | | | 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.
* | Issue #1656 - Nuke the remaining vim lines in UXPMoonchild2020-10-26-48/+0
| | | | | | | | Closes #1656
* | [layout] Re-order rowgroups if reflowing.Moonchild2020-10-23-2/+14
| | | | | | | | This logic was missing for tfoot. See existing code in second hunk.
* | [layout] Avoid negative availSize.BSizes in paginated table reflow.Moonchild2020-10-23-9/+11
| |
* | [DOM] When failing to create a channel and an image request, make sure to setMoonchild2020-10-22-0/+4
|/ | | | | | | the image blocking status appropriately. This is the same status as we do for known no-data protocols and ensures we treat these two cases the same.
* Merge branch 'master' of https://github.com/MoonchildProductions/UXPMoonchild2020-10-20-12/+114
|\
| * Merge branch 'master' of https://github.com/MoonchildProductions/UXP into ↵athenian2002020-10-18-335/+206
| |\ | | | | | | | | | caret_color
| * | Issue #1668 - Part 2: Visited color and auto support for caret-color property.athenian2002020-10-18-8/+26
| | | | | | | | | | | | 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.
| * | Issue #1668 - Part 1: Implement support for caret-color property.athenian2002020-10-18-11/+95
| | | | | | | | | | | | | | | | | | 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
* | | Issue #1671 - Unprefix ::-moz-selectionMoonchild2020-10-20-2/+13
| |/ |/| | | | | | | | | | | | | 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.
* | Issue #1666 - Implement overflow-wrap: anywhereMoonchild2020-10-03-4/+11
| | | | | | | | | | | | | | 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
* | Issue #1665 - Take overflow-wrap into account when calculating min-content ↵Moonchild2020-10-03-0/+10
| | | | | | | | intrinsic size.
* | Issue #1647 - Followup: Remove excessive VARIANT_OPACITY statements.athenian2002020-09-30-7/+7
| | | | | | | | | | | | | | | | 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.
* | Issue #1656 - Part 10: Manual cleanup.Moonchild2020-09-24-9/+1
| |
* | Issue #1656 - Part 9: Single-line-comment style.Moonchild2020-09-24-1/+0
| |
* | Issue #1656 - Part 8: Devtools and misc.Moonchild2020-09-24-20/+0
| |
* | Issue #1656 - Part 6: Clean up the build filesMoonchild2020-09-23-25/+0
| |
* | Issue #1656 - Part 4: Manual cleanupMoonchild2020-09-23-20/+0
| |
* | Issue #1656 - Part 3: Nuke more vim config lines in the tree.Moonchild2020-09-23-27/+0
| | | | | | | | Another S&R run with some smarter matching.
* | Issue #1656 - Part 2b: Unmangle one more lost little UTF-8 victim.Moonchild2020-09-23-1/+1
| |
* | Issue #1656 - Part 2: Unmangle some unfortunate UTF-8 victims.Moonchild2020-09-23-8/+8
| | | | | | | | The poor fellows got lost in an ASCII-interpretation of the world.
* | Issue #1656 - Part 1: Nuke most vim config lines in the tree.Moonchild2020-09-23-123/+9
| | | | | | | | | | | | 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.
* | Issue #1655: Update MediaQueryList to the current draft spec.Moonchild2020-09-23-110/+179
|/ | | | | | | 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.
* Merge pull request #1654 from athenian200/opacity_percentageMoonchild2020-09-18-25/+38
|\ | | | | Implement percentage for CSS opacity keywords
| * Issue #1647 - Part 2: Implement VARIANT_OPACITY to correctly serialize.athenian2002020-09-17-35/+33
| | | | | | | | 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.
| * Issue #1647 - Part 1: Implement percentage for CSS opacity keywordsathenian2002020-09-16-14/+29
| | | | | | | | | | 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.
* | Issue #1643 - Part 4: Hook up all the plumbing.Moonchild2020-09-16-0/+5
| |
* | Merge pull request #1651 from athenian200/link_element_disabledMoonchild2020-09-13-5/+7
|\| | | | | Clean up local variables from <link> disabled issue.
| * Issue #1629 - Part 5: Remove pointless local variables.athenian2002020-09-09-8/+7
| | | | | | | | 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.
| * Issue #1629 - Part 4: Ensure isExplicitlyEnabled is false upon sheet creation.athenian2002020-09-06-2/+5
| | | | | | | | 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.
* | Issue #1650 - Add null check.Moonchild2020-09-12-1/+1
| | | | | | | | | | | | 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".
* | Issue #1641 - Implement CSS flow-root keywordathenian2002020-09-03-16/+65
| | | | | | | | 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.
* | Merge pull request #1632 from athenian200/link_element_disabledMoonchild2020-08-18-13/+28
|\| | | | | Respond to disabled attribute set on <link> elements from HTML
| * Issue #1629 - Part 2: Implement the Explicitly Enabled flag.athenian2002020-08-13-13/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This part of the bug was significantly complicated by the following major refactors: https://bugzilla.mozilla.org/show_bug.cgi?id=1456435 https://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.
* | Issue #1620 - Intrinsic Aspect Ratio: Debug Follow up.Gaming4JC2020-08-16-0/+2
| | | | | | | | | | | | | | 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.
* | [CSS] Alias -webkit-appearance for compatibility reasonsMoonchild2020-08-10-0/+5
| | | | | | | | | | | | | | | | | | | | 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.
* | Issue #1620 - Remove Development CommentsAndy2020-08-07-16/+4
| |
* | Issue #1620 - Use Intrinsic Aspect Ratio for ImagesAndy2020-08-04-126/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.mozilla.org/show_bug.cgi?id=1547231 https://bugzilla.mozilla.org/show_bug.cgi?id=1559094 https://bugzilla.mozilla.org/show_bug.cgi?id=1633434 https://bugzilla.mozilla.org/show_bug.cgi?id=1565690 https://bugzilla.mozilla.org/show_bug.cgi?id=1602047 Make use of Aspect Ratios in Image frames before Images are loaded. - Check for width and height HTML properties and create a ratio with them. - Overwrite HTML size values with actual image dimensions on load. - Collapse any frames with srcless images. Comments: dom/html/nsGenericHTMLElement.cpp:1483 layout/generic/nsImageFrame.cpp:289
* | Issue #1619 - Nits PickedAndy2020-08-02-8/+8
| |
* | Issue #1619 - Add Vertical Writing TestcaseAndy2020-08-01-20/+0
| | | | | | | | | | Ensures aspect ratio numerator and denominator aren't swapped in vertical writing modes. https://bugzilla.mozilla.org/show_bug.cgi?id=1548768
* | Issue #1619 - Missing Dimension ComputationAndy2020-07-31-0/+10
| | | | | | | | | | This existed in Firefox before this bug. I don't know if it came from a previous bug or was removed post-fork.
* | Issue #1619 - Convert Intrinsic Ratio to FloatAndy2020-07-31-214/+296
|/ | | | | | | | | 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
* Issue MoonchildProductions/UXP#1578 - Add global menubar support for GTKLootyhoof2020-06-09-0/+11
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 09:57:30 +0000