`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, duplicate it to nsContentUtils as a util function.
This is a duplication because CSSValue uses stringbuffers and not nsStrings.
While Bug 1356060 - "Just use nsString in URLValueData" converts this use from stringbuffer to nsString, it builds on a bunch of vartype refactoring (nsString vs. nsAString, etc.) which is too much of a headache to deal with just to deduplicate this simple function.
`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, move it to nsContentUtils as a util function.
* Part 1. Move IsLocalRefURL to nsContentUtils to reuse this function. (port-rewrite)
`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, move it to nsContentUtils as a util function.
* Revert "Part 1. Move IsLocalRefURL to nsContentUtils to reuse this function. (port-rewrite)"
This reverts commit 19f010c62022e269f99066a8d90e3522fe31adaf.
* Part 1. Duplicate IsLocalRefURL to nsContentUtils to reuse this function.
`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, duplicate it to nsContentUtils as a util function.
This is a duplication because CSSValue uses stringbuffers and not nsStrings.
While Bug 1356060 - "Just use nsString in URLValueData" converts this use from stringbuffer to nsString, it builds on a bunch of vartype refactoring (nsString vs. nsAString, etc.) which is too much of a headache to deal with just to deduplicate this simple function.
* Part 2. Implement nsSVGEffects::GetBaseURLForLocalRef to export local-ref-url-resolving logic.
ResolveURLUsingLocalRef is designed to be internally used by nsSVGEffects::Get-{SVGEffect}-URI functions.
Since we also need it in SVGUseElement::LookupHref, make it public in nsSVGEffects.
* Part 3. Resolve local-ref in SVGUseElement::LookupHref by nsSVGEffects::GetBaseURLForLocalRef.
* Part 4. Reftest for using local-ref as xlink:href value.
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.
- Use placesutils for favicons
- Switch to the PageThumbs service for thumbnails (like QuickDial)
- Make thumb requests asynchronous
- Update canvas handling
This resolves#731
Our in-tree FFmpeg doesn't support optimized assembly code very well on 32-bit *nix systems, which causes performance issues during video playback.
Essentially, this commit restores the behavior from Pale Moon 27 on 32-bit Linux builds (for video playback rely on the system-installed FFmpeg packages or libvpx if FFmpeg packages can't be found).
This resolves#717.
Note: this does not affect other applications because the platform
default is to use the "darknoise" background image for standalone
image, which effectively overrides a bg color.
|entryCount| tracks -- in fast-to-check manner -- the number of entries in the hashtable. But to actually enumerate entries, we have to loop through all of |table|, checking for entries that are actually live. A live entry is indicated by a zero |hash| in the entry. The |memset| would properly zero that; removing the memset will not.
It's not entirely clear whether a memset that overwrites a lot of stuff but is maybe simpler, is faster than compiler-generated likely-SIMD code that zeroes out *just* |hash| fields in all the entries. But I am going to guess that SIMD is good enough. For now, we should just do the simple and thing: don't distinguish POD and non-POD, and know that the compiler is going to recognize that |mem.addr()->~T()| is a no-op when T is trivial. So with POD, the loop should degenerate to just zeroing |hash| at consistent offset, and SIMD will eat that up, and it can't be *that* different from the memset in performance (if it is at all).
nsTabSizes is non-trivial only because of the user-defined constructor. The idea desired here is certainly to zero all the members without listing them -- but the very act of doing so with a user-defined constructor, makes the idea impossible.
Arguably this is something that is permissible in the language, and that the warning should be tailored to permit. I don't think this falls afoul of any of the issues flagged in https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01527.html for example. In the meantime, just explicitly zeroing the three member fields is easy and fixes the warnings.
