| Commit message (Collapse) | Author | Age | Lines |
... | |
|
|
|
|
|
| |
we have
Look into optimizing out the hashtable lookups from nsContainerFrame
|
|
|
|
|
|
|
|
|
|
|
| |
UXP has:
MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas && sAliveDisplayItemDatas >Contains(this));
sAliveDisplayItemDatas->RemoveEntry(this);
and this gets hit during frame destruction.
Combine these checks.
|
|
|
|
| |
Dispense the shared hashtable and instead attach the frame property list directly to nsIFrame.
|
|
|
|
| |
This reverts commit e69b3f567c4b8957cc09ba4359e84939f77781c5.
|
| |
|
|
|
|
|
|
|
|
| |
* Simplify the dispatch-to-content region
Simplify the dispatch-to-content region in nsDisplayLayerEventRegions::AddFrame() and AddInactiveScrollPort() if it starts to get large.
* tabs to spaces
|
| |
|
|\
| |
| | |
nsFrameList::GetLength() calls in nsDisplayListBuilder::MarkFramesForDisplayList() are slow
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
Tag #1052
|
| |
|
| |
|
|
|
|
|
|
| |
Some SVGs define a mask but an invalid mask frame. Check to make sure
we have a `maskFrame` that isn't null before trying to use it.
This resolves #1034
|
|
|
|
| |
This reverts commit 00baf283622b47ad7926c6e62364854d3dfbc00a.
|
| |
|
|
|
|
|
|
|
|
|
| |
can be null because of OOM or gfx device reset. r=dvander
MozReview-Commit-ID: HX2qsWLZpMg
--HG--
extra : rebase_source : 046befc11151461a682842c31e2ce39247a5e1d8
|
|
|
|
| |
Tag #186
|
| |
|
| |
|
|
|
|
| |
also be zero
|
|
|
|
| |
correctly from the CSS align code
|
|
|
|
|
|
|
| |
Since we're now handling this in the network back-end, there's no
need for this anymore.
Tag #993.
|
|
|
|
| |
This resolves #978.
|
|\ |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
Follow-up for #891. Tag #457.
|
|
|
|
| |
They are no longer supported and don't work with newer Android versions anyway.
|
| |
|
|
|
|
| |
contents elements
|
|
|
|
| |
This resolves #891
|
|
|
|
| |
Follow-up to fdbac095968bc952fec6a03765a7156940ae4733
|
|
|
|
|
|
| |
(mAsyncScroll & mAsyncSmoothMSDScroll) before it's destroyed.
Tag #345
|
| |
|
|
|
|
| |
when measuring block size
|
|
|
|
| |
This resolves #821 (regression).
|
|
|
|
| |
Fixes #820 (regression).
|
|
|
|
| |
Tag #21.
|
|
|
|
| |
Includes a standalone reftest.
|
|
|
|
| |
ref on it on the stack when nsRefreshDriver::Tick can be reached.
|
|
|
|
| |
TickRefreshDriver call.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
+ Used "mFrame->GetType()" instead of "mFrame->Type()"
|