gecko-dev/dom/base/DOMRect.h

195 строки
4.2 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef MOZILLA_DOMRECT_H_
#define MOZILLA_DOMRECT_H_
#include "nsTArray.h"
#include "nsCOMPtr.h"
#include "nsWrapperCache.h"
#include "nsCycleCollectionParticipant.h"
#include "mozilla/Attributes.h"
#include "mozilla/dom/BindingDeclarations.h"
#include "mozilla/ErrorResult.h"
#include <algorithm>
struct nsRect;
namespace mozilla {
namespace dom {
class DOMRectReadOnly : public nsISupports
, public nsWrapperCache
{
protected:
virtual ~DOMRectReadOnly() {}
public:
NS_DECL_CYCLE_COLLECTING_ISUPPORTS
NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS(DOMRectReadOnly)
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
explicit DOMRectReadOnly(nsISupports* aParent, double aX = 0, double aY = 0,
double aWidth = 0, double aHeight = 0)
: mParent(aParent)
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
, mX(aX)
, mY(aY)
, mWidth(aWidth)
, mHeight(aHeight)
{
}
nsISupports* GetParentObject() const
{
MOZ_ASSERT(mParent);
return mParent;
}
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
virtual JSObject* WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto) override;
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
static already_AddRefed<DOMRectReadOnly>
Constructor(const GlobalObject& aGlobal, double aX, double aY,
double aWidth, double aHeight, ErrorResult& aRv);
double X() const
{
return mX;
}
double Y() const
{
return mY;
}
double Width() const
{
return mWidth;
}
double Height() const
{
return mHeight;
}
double Left() const
{
double x = X(), w = Width();
return std::min(x, x + w);
}
double Top() const
{
double y = Y(), h = Height();
return std::min(y, y + h);
}
double Right() const
{
double x = X(), w = Width();
return std::max(x, x + w);
}
double Bottom() const
{
double y = Y(), h = Height();
return std::max(y, y + h);
}
protected:
nsCOMPtr<nsISupports> mParent;
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
double mX, mY, mWidth, mHeight;
};
class DOMRect final : public DOMRectReadOnly
{
public:
explicit DOMRect(nsISupports* aParent, double aX = 0, double aY = 0,
double aWidth = 0, double aHeight = 0)
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
: DOMRectReadOnly(aParent, aX, aY, aWidth, aHeight)
{
}
NS_INLINE_DECL_REFCOUNTING_INHERITED(DOMRect, DOMRectReadOnly)
static already_AddRefed<DOMRect>
Constructor(const GlobalObject& aGlobal, double aX, double aY,
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
double aWidth, double aHeight, ErrorResult& aRv);
virtual JSObject* WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto) override;
void SetRect(float aX, float aY, float aWidth, float aHeight) {
mX = aX; mY = aY; mWidth = aWidth; mHeight = aHeight;
}
void SetLayoutRect(const nsRect& aLayoutRect);
void SetX(double aX)
{
mX = aX;
}
void SetY(double aY)
{
mY = aY;
}
void SetWidth(double aWidth)
{
mWidth = aWidth;
}
void SetHeight(double aHeight)
{
mHeight = aHeight;
}
static DOMRect* FromSupports(nsISupports* aSupports)
{
return static_cast<DOMRect*>(aSupports);
}
private:
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz Some notes: this does not fully bring us to compliance to the current spec. Instead, these are the fixes that I needed to make in order to make css/geometry/interfaces.html pass with the DOMPoint changes in the previous patches. I don't fully understand why that patch caused the test to fail the way it did, but it ended up being easier to fix our code than understand why the harness was falling over. The DOMQuad::QuadBounds class was the source of some confusion for me. Now that DOMRectReadOnly is a concrete class with members, I wanted to avoid wasting them. However, the spec is unclear as to whether a DOMQuad's bound's should be live -- that is because DOMQuad exposes DOMPoint, we can set its points after retrieving a QuadBounds object. Our current code is live, setting the points changes the QuadBounds. Chromium's current behavior is to never update the QuadBounds object. I've left our behavior untouched in this patch (and waste 4 doubles per QuadBounds object), but I am intending to file a bug to understand what the intent of the spec is. I wonder if the author intended the points to be DOMPointReadOnly instead. If so, we could simplify the DOMRectReadOnly code and get rid of the virtual getters, which would be nice. I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly class, but for brevity and simplicity of implementation, I've made them public. I briefly considered making the setters protected on the ReadOnly version of the class, but I'm not convinced that having to explicitly make them public on the derived class is worth the extra copies of the names. MozReview-Commit-ID: CjdW4Nbnc6A --HG-- extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
~DOMRect() {}
};
class DOMRectList final : public nsISupports,
public nsWrapperCache
{
~DOMRectList() {}
public:
explicit DOMRectList(nsISupports *aParent) : mParent(aParent)
{
}
NS_DECL_CYCLE_COLLECTING_ISUPPORTS
NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS(DOMRectList)
virtual JSObject* WrapObject(JSContext *cx, JS::Handle<JSObject*> aGivenProto) override;
nsISupports* GetParentObject()
{
return mParent;
}
void Append(DOMRect* aElement) { mArray.AppendElement(aElement); }
uint32_t Length()
{
return mArray.Length();
}
DOMRect* Item(uint32_t aIndex)
{
return mArray.SafeElementAt(aIndex);
}
DOMRect* IndexedGetter(uint32_t aIndex, bool& aFound)
{
aFound = aIndex < mArray.Length();
if (!aFound) {
return nullptr;
}
return mArray[aIndex];
}
protected:
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
nsTArray<RefPtr<DOMRect> > mArray;
nsCOMPtr<nsISupports> mParent;
};
} // namespace dom
} // namespace mozilla
#endif /*MOZILLA_DOMRECT_H_*/