- 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
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
This patch changes the paramters to setSearchMode. The original patch to introduce search mode passed engineName to setSearchMode instead of the entire engine object. It was suggested in review that the nsISearchEngine be passed so we could run instanceof to distinguish it from a RESULT_TYPE. This patch reverses this and passes engineName instead through a destructured parameter.
In pickResult, we need to enter search mode synchronously based on the information in a result payload. Result payloads can't/shouldn't pass around complex objects like an nsISearchEngine, so we just pass engineName and the alias as strings. Since pickResult is synchronous, we can't use UrlbarSearchUtils to look up the engine based on the engineName. Besides, setSearchMode only uses engineName, so looking up the engine only to just use its name seems like a waste of resources.
This patch also disables autofill in search mode queries. Autofill was interfering with alias replacement. We were already half doing this (https://searchfox.org/mozilla-central/rev/26b13464c2beb26e0d864d561c30e817a85c348a/browser/components/urlbar/UrlbarController.jsm#391) but adding the searchMode check to UrlbarInput._maybeAutofillOnInput should resolve bug 1655473.
There's still one more bug I'm working through where the placeholder disappears after alias replacement. I though I'd get this out to start review regardless since we want to get the three patches discussed in Thursday's meeting out ASAP.
Differential Revision: https://phabricator.services.mozilla.com/D86389