This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
The check for isAbsolutelyPositioned was an old incorrect attempt to fix bug
81290. We have since added the proper fix (not adding offsets of the offset
parent frame) in bug 375003.
MozReview-Commit-ID: 7NgnfrYcs8h
nsGenericHTMLElement::GetAssociatedEditor() retrieves TextEditor if the element is <input type="text"> or something, or <textarea>, or if it's editable, HTMLEditor associated to the document. So, this method can return TextEditor (HTMLEditor is a subclass of TextEditor).
MozReview-Commit-ID: BvpFPaPLY70
In order to speed up Required/IsRequired(), instead of querying for the
@required attribute, we're now using the NS_EVENT_STATE_REQUIRED flag to know
whether an element's value is required.
For this to work correctly, we need to set NS_EVENT_STATE_REQUIRED earlier,
that is, in AfterSetAttr(), before any consumer of IsRequired(). We also need
to update or clear our required states when input type changes, since we may
have changed from a required input type to a non-required input type or
vice versa.
Note that NS_EVENT_STATE_REQUIRED/OPTIONAL is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: Bjiby9GqJSB
We'd like to use HasName() to know whether a node has a name attribute, but now
it's only applied to elements that CanHaveName(), hence we change it so that
it's applied to all nodes. Therefore, when document named items related
functions wants to use HasName() now, it must also check CanHaveName().
MozReview-Commit-ID: 2i5hfjnxXIF
In order to speed up IsDisabled(), instead of querying for the @disabled
attribute, we're now using the NS_EVENT_STATE_DISABLED flag to know whether an
element is disabled.
It is safe to use the NS_EVENT_STATE_DISABLED flag for the following reasons:
- For form elements, nsGenericHTMLFormElement::IsDisabled() is only called on
form elements that can be disabled; form elements that can't be disabled
overrides IsDisabled() to return false directly.
And, before this patch, NS_EVENT_STATE_DISABLED flag is set by
nsGenericHTMLFormElement::IntrinsicState() if and only if IsDisabled() in all
cases when CanBeDisabled() is true, and when CanBeDisabled() is false then
IsDisabled() is always false and the flag is not set.
- For non form elements, optgroup and option have the flag matching
IsDisabled(). Note that option's IsDisabled() should also refer to optgroup's
(if it exists) disabled state, which was not done before this patch.
For this to work correctly, we need to set NS_EVENT_STATE_DISABLED earlier,
that is, in AfterSetAttr(), before any consumer of IsDisabled().
We also need to update the flag whenever the element's parent (e.g. fieldset or
optgroup) disabled state changes and when moving into/out of a parent
container.
Note that NS_EVENT_STATE_DISABLED/ENABLED is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: KSceikeqvvU
Unfortunately, nsGenericHTMLElement::GetAssociatedEditor() cannot use concrete classes because it may return nsIEditor which is set via nsIDocShell.editor. The editor set to nsIDocShell may be implemented by JS since nsIEditor isn't marked as builtinclass.
MozReview-Commit-ID: 6GY9LOYp4hM
