- Convert DOMSVGAnimatedString to a concrete class rather than having two almost identical derived classes that differ only by the class of the mVal pointer
- Introduce tear off support for SVGAnimatedClass
- Move to native refcounting rather than nsISupports
Differential Revision: https://phabricator.services.mozilla.com/D84924
This changes the StartupCache::PutBuffer call from Omnijar to use a
fallibly allocated buffer, to reduce OOM crashes. We can/should broaden the
scope of this, but this is a simple initial change to mitigate the OOM
crashed introduced with bug 1627075.
Differential Revision: https://phabricator.services.mozilla.com/D86067
The finally where it's used may be reached before it is set currently,
leading to more important error messages being hidden.
Differential Revision: https://phabricator.services.mozilla.com/D86281
This makes us use one less tool from MSVC, and removes one more use of wine
in cross builds.
We replace the call to either rc/llvm-rc or windres with a wrapper script.
While the script is not strictly needed for the latter, we use a wrapper
in that case anyway because it's one step towards fixing bug 1498414.
For llvm-rc, however, we need a wrapper because llvm-rc doesn't preprocess
on its own, so the wrapper does that too.
The wrapper script also allows to deal with the default flags passed to
llvm-rc or windres, rather than inherit them from old-configure.
We also need to explicitly pass the codepage to llvm-rc, which was not
necessary with rc (presumably, llvm-rc has a different default).
While here, remove the unused WINDRES subst from js/src/old-configure.in.
Also, while here, we remove --use-temp-file, because as described in the
linked bug and in the windres manual page, it was used to work around bugs
on Windows 98 and earlier.
Differential Revision: https://phabricator.services.mozilla.com/D86312
That prevents preceding whitespace from getting collapsed.
When there's a single lone CR (so `a\rb`) our behavior here diverges
from Chrome's but matches Safari's. We treat it as ZWSP.
That matches the initial resolution of [1], but then there have been
various doing and undoings of that resolution, so it's not totally clear
to me what the correct behavior per spec should be. I think "treat it as
other control character"? But I haven't dug into what that implies, so
for now I've just kept behavior there as-is.
[1]: https://github.com/w3c/csswg-drafts/issues/855
Differential Revision: https://phabricator.services.mozilla.com/D86188
We now use `PARAM_BUFFER_COUNT` for slightly more stuff, so update the
comment describing its two uses. Experimentation has also shown that we can
decrease the count slightly, which is a tiny tiny win.
Differential Revision: https://phabricator.services.mozilla.com/D86214
Now that we've statically ensured everything fits into the stack-allocated
array(s), we can delete the case that handled dynamic allocation.
Differential Revision: https://phabricator.services.mozilla.com/D86213
We used to not be able to do something like this, and therefore our xpidl
calling code had to be fully general. But now that we know all possible
xpidl methods at build time, we can ensure that the number of parameters
does not exceed some bound. And we choose that bound to be the maximum
number of stack-allocated parameters our calling code supports.
Differential Revision: https://phabricator.services.mozilla.com/D86212
There's no reason to have a different count depending on whether we have
floating-point registers or not; xpidl functions will have the same number
of parameters regardless. This change also synchronizes soft-float PPC with
every other architecture.
Differential Revision: https://phabricator.services.mozilla.com/D86210
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Differential Revision: https://phabricator.services.mozilla.com/D85704
emcminn
Mike Hommey
Emma Malysz
Razvan Maries
Severin
Christoph Kerschbaumer
yulia
Robert Helmer
Ted Campbell
shravanrn
Emilio Cobos Álvarez
Butkovits Atila
Simon Fraser
alexandru.ionescu
longsonr
Jorg K
pctopgs
Jonathan Kew
Marco Bonardo
Doug Thayer
Artem Polivanchuk
Zibi Braniecki
Nathan Froyd
daemon1024
Gregory Mierzwinski
Tarek Ziadé
Martin Stransky
Timothy Nikkel