| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
|
|
|
|
| |
Since this is a http protocol networking feature, it belongs in the networking
branch of our preferences.
|
| |
|
|
|
|
|
|
| |
This is CVE-2020-15999.
* src/sfnt/pngshim.c (Load_SBit_Png): Test bitmap size earlier.
|
|
|
|
| |
This avoids a number of problems with incomplete sanitation.
|
|
|
|
|
|
|
| |
The root cause in this bug is that the connection info used by
'SpdyConnectTransaction' is the same instance as the connection info in
'nsHttpTransaction', so we should clone it and let 'SpdyConnectTransaction' use
the cloned one.
|
|
|
|
|
|
|
|
|
| |
The original patch handled the grow case but not the shrink case. When the
current and new allocation sizes are in different size classes, jemalloc's
realloc will move the allocation when shrinking, not just truncate the existing
one.
Based on work by Jon Coppeard.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This fix is included in NSPR 4.27 and Mozilla bug 1652330.
Also put a main thread check in the cocoa draw callback.
|
|
|
|
|
|
|
| |
This involves refactoring the vibrancy and OpenGL/Pixel rendering changes contained
in the following Mozilla meta bugs: 1496823 and 1491445
Also add Big Sur to the features tests and update popup menu look and feel based
on Mozilla bug 1656301.
|
|
|
|
| |
jemalloc
|
|
|
|
|
| |
Since several entities have started to ban .9 versions, even if they are valid
ESR versions.
|
|
|
|
| |
Also adds options for new functionality in #1683
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This has been broken for 11 years. About time it's fixed.
Tag #1683
|
| |
|
|
|
|
|
| |
There don't seem to be any drawbacks to this; tested for the past month disabled
and there have been no issues with any sites visited. Adoption seems very low.
|
|
|
|
|
|
| |
This was a leftover from HPKP removal.
Also remove a couple of unused variables from security/manager/ssl/nsSiteSecurityService.cpp.
|
|
|
|
|
|
|
|
| |
This is required for UniquePtr to accept <void>,
which is required for PseudoHandle = mozilla::UniquePtr<T, JS::FreePolicy>;
in turn for mozilla::SegmentedVector<PseudoHandle<void>> uniquePtrArena_;
Tag #1679
|
|
|
|
| |
Tag #1679
|
| |
|
|
|
|
| |
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.
|
|
|
|
| |
This provides a clearer rule for the minimum tab advance that brings us to alignment with the spec and both major browsers.
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Rename MCP back to MoonchildProductions.
|
| |
|
|
|
|
| |
This logic was missing for tfoot. See existing code in second hunk.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Presentation of a document is destroyed.
|
| |
|
|
|
|
| |
Tag #1666
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
intrinsic size.
|