Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
--HG--
extra : moz-landing-system : lando
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
The change to test_bug558726.html is because we always serialize mapped
attributes after non-mapped ones. So this change is actually improving our
serialization in that test.
For number controls, nsContentUtils::IsFocusedContent doesn't really do the
right thing, because the thing it thinks is focused is the anonymous text
element inside the number control. As a result, we weren't properly updating
the state of the currently-focused number control when hitting enter in it to
submit the form.
The HTMLFormElement change is enough on its own to fix the bug. The constraint
validation change is a just-in-case.
I haven't figured out a sane way to write a reftest for this, unfortunately:
the enter key press needs to look like a real user event to trigger the
submission behavior.
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Permissions checks for popups were happening in nsIPopupWindowManager,
but that really only required a pref and perm check. The XPCOM
machinery around this isn't really needed, and the check was only
called from two places in content, so this fits in nsContentUtils.
MozReview-Commit-ID: 9x60x1BKWcr
--HG--
extra : rebase_source : d6e2dcfcae8310770eb209ccb42c96315511bb86
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
Summary: In this case the radiobox is in a SVG <use> subtree.
Reviewers: smaug
Bug #: 1409183
Differential Revision: https://phabricator.services.mozilla.com/D741
MozReview-Commit-ID: Abkg7ahST5t
In each case, the atom had an obvious name and a weird name. Where possible, I
kept the obvious name and commented out the weird name, viz:
- `mixed` over `_mixed` for "mixed"
- `el` over `el_` for "el"
- `other` over `other_` for "other"
- `remote` over `Remote` for "remote"
But for several of them I didn't do that, because the weird name is used
within the HTML5 parser -- which is a huge pain to modify because it involves
code generated by code from another repo -- so I kept the weird name and
commented out the obvious name, viz:
- `list_` over `list` for "list"
- `svgSwitch` over `_switch` for "switch"
- `set_` over `set` for "set"
MozReview-Commit-ID: Jp3CpdWXNDm
--HG--
extra : rebase_source : 421ce5316772f1951488307e81f2ceee696d363d
Wow, the setup for <input type="number"> is really weird :(.
Looking at the callers, this should be sane.
MozReview-Commit-ID: C0ZNNSdg0Hb
--HG--
extra : rebase_source : ff8efaaa3b0068b35e3b408e16b6f9d133165e5c
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
--HG--
extra : rebase_source : 5dba46f61d70ec647cae16383b62961ac72d2f47
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
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
(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
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
The files relevant to the memory allocator are currently spread between
memory/mozjemalloc and memory/build, and the distinction was
historically from sharing some Mozilla-specific things between
mozjemalloc and jemalloc3. That distinction is not useful anymore, so
we fold everything together.
As we will likely rename the allocator at some point in the future, it
is preferable to move away from the mozjemalloc directory rather than in
its direction.
--HG--
rename : memory/mozjemalloc/Makefile.in => memory/build/Makefile.in
rename : memory/mozjemalloc/mozjemalloc.cpp => memory/build/mozjemalloc.cpp
rename : memory/mozjemalloc/mozjemalloc.h => memory/build/mozjemalloc.h
rename : memory/mozjemalloc/mozjemalloc_types.h => memory/build/mozjemalloc_types.h
rename : memory/mozjemalloc/rb.h => memory/build/rb.h
Keyboard APZ dispatches an eVoidEvent to gather all event targets that a key event
would normally go to. This can sometimes trigger an HTMLInputElement to initialize its
editor, which can cause unnecessary DOM modifications.
MozReview-Commit-ID: 6EEttouVB81
--HG--
extra : rebase_source : e7ff9c50a13f43f66976e3f0294e3d1696b87169
nsTextEditorState::GetValue() refers nsITextControlElement::IsPlainTextControl()
via nsTextEditorState::IsPlainTextEditor(). However, it always returns true and
virtual call with QI. So, we should get rid of these unnecessary methods.
MozReview-Commit-ID: 3gHdGrzlys4
--HG--
extra : rebase_source : a1be33a18e93e64b8cc87e4f12d5e494b14520bf
We use a bitfield in HTMLInputElement to cache whether the input element has the
@pattern set, and skip pattern mathching in HasPatternMismatch() if the
attribute is not set.
--HG--
extra : rebase_source : 797deb99bfee31bda824c809052083b66d62fd7c
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
Currently, these two functions take nsIFormControl* as argument, but we only
pass HTMLInputElements to it, so we can change it to take HTMLInputElement* to
avoid overhead in casting.
MozReview-Commit-ID: CHG0F3xWCVF
--HG--
extra : amend_source : 6052bfec33bb8aa7d92e31b242757ed265256002
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
IsRequired() helper function returns the current 'required' state of the
element, that is, whether its required attribute is set or not. This will be
used only for input elements that @required applies.
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
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
We should consider step and step base when deciding whether to show second and
millisecond field, since step and step base can affect the valid time intervals,
and the valid intervals may have second/millisecond part.
MozReview-Commit-ID: H4mJvLTvBOM
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
--HG--
extra : rebase_source : 3e0464067b30daf8254805458c5358d7ea644be8
Using concrete class rather than interface classes (nsI*Editor) will allow to reduce QI and some virtual calls. Therefore, Editor classes should be used as concrete class as far as possible.
Unfortunately, if classes referring editor are initialized via scriptable interface, we cannot do this because nsI*Editor is still not marked as builtinclass. Therefore, their editor may be implemented by JS. E.g., inline nsIInlineSpellChecker.init() and nsIDocShell.editor. Such remaining cases should be fixed after nsI*Editor classes are marked as builtinclass.
Note that this patch also creates nsIdentifierMapEntry.h which is separated from nsDocument.h because ShadowRoot.h needs the class but exposing nsDocument.h to the global and includes it causes bustage on Linux and Android. Therefore, for fixing the include hell, this patch touches them and ContentChild.cpp.
MozReview-Commit-ID: i6fLWw6Qeo
--HG--
rename : dom/base/nsDocument.h => dom/base/nsIdentifierMapEntry.h
extra : rebase_source : c57bdfc1c13775acdcfd4732d8157d04d6b6613f
The old setup unset the HasDirAuto flag when changing the "dir" attr away from
the value "auto", and reset it when setting it to "auto", before calling
SetDirectionalityFromValue. But SetDirectionalityFromValue doesn't depend on
the HasDirAuto flag, and that flag is set correctly for us by nsGenericElement,
so we don't have to manage it ourselves at all.
The callers outside BeforeSetAttr/AfterSetAttr just preserved the flag value, so
there's no behavior change at all for them.
MozReview-Commit-ID: AC8uV3cOtH2
If all fields in date/time input box are available but the input element's
value is empty, implies that it has been sanitized. In this case, we'll set the
'bad input' validity state. If any of the fields is cleared, we'll remove the
'bad input' validity state, as incomplete field does not imply 'bad input'.
MozReview-Commit-ID: 4EBpH5CWqXM
In this patch, we change it so that we always set the input element's value
once all fields are available and let DOM HTMLInputElement sanitize it. The
value after sanitization is not updated in the displayed input box, but may
display an error message (this will be done in Part 2) if needed.
Also, when any of the field's value is deleted, we will set input element's
value back to the empty string, so that a value is not accidentally submitted.
MozReview-Commit-ID: 9NAL8UlkoBK
We get previous input.value twice in HTMLInputElement::SetValue and nsTextEditorState::SetValue when setting input.value. Since nsTextEditorState::GetValue uses DocumentEncoder, it is expensive. So we should use old value as parameter of nsTextEditorState::SetValue if possible.
MozReview-Commit-ID: A1UPfETTVCn
--HG--
extra : rebase_source : f751289b42b4d9d5c389042f688c53bde47d1620
HTMLInputElement::IsValueEmpty uses DocumentEncoder when input element has focus. DocumentEncoder is slow, so we should use fast path (nsTextEditorState::HasNonEmptyValue) to check whether value is empty.
MozReview-Commit-ID: 1JxAeZ6z5A4
--HG--
extra : rebase_source : 8cf89721bf59f0bde09e217428bb593ad6d328de
In order to facilitate the movement of code with side-effects called by Element::SetAttr to Element::BeforeSetAttr and Element::AfterSetAttr, Element::AfterSetAttr should have access to the old value of the attribute. This includes information about whether there was previously a value set or not.
Accomplishing this involved passing an additional argument through functions that find and change the old attribute value in order to ensure that we can differentiate between an empty old value and an absent old value (attribute was not set).
Note that while I tried to ensure that accurate values (and their absence) are reported to Element::AfterSetAttr, I largely ignored SVG. While the old value reported for SVG values should be however accurate the value already being reported to SetAttrAndNotify was, SVG elements do not currently report unset values properly because they will never pass a null pointer to SetAttrAndNotify.
MozReview-Commit-ID: K1mha8CNFZP
--HG--
extra : rebase_source : 42776eb01451d371e4aebcc17fe3dd112c8d268b
Nobody uses them anymore. Therefore, we can remove them from the tree.
MozReview-Commit-ID: KTqCeI2eeFW
--HG--
extra : rebase_source : f3fc274f39c135af51245efd4c4aebbc4c49a61f
This part is mainly to mark the channel as urgent-start if src related
attributes in HTMLImageElement and HTMLInputElement is set and the channel is
open due to user interaction. Unfortunately, we cannot just check the event
state just after creating channel since some loading image tasks will be queue
and execute in stable state. Thus, I store the event state in elements and
pass it to the place where create the channel.
MozReview-Commit-ID: GBdAkPfVzsn
--HG--
extra : rebase_source : 715352317b4b600f8a7f78b7bc22b894bb272d27
The container of a radio group is the form, if it belongs to a form, or the
document object otherwise.
When moving a radio out of a form, we should add it back to a radio group.
Similary, before moving the radio to a form, we should remove it from the
original radio group.
MozReview-Commit-ID: 22WsEhz2SXH
--HG--
extra : rebase_source : 68dbd50da523b734086d8e5de6e6ae179b0b4af0
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58
In order to reduce the size of HTMLInputElement for performance gain, we're
going to allocate input type=file related member variables only when type=file.
--HG--
extra : rebase_source : de31e8c55ee44b6ef7f8143b39e64d369d021856
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
Since the inner fields of date/time input are now <span> instead of <input>
text, we are adding an API for binding code to set the focus state of the
bound input element when inner fields are focused/blurred.
MozReview-Commit-ID: 9wvu57xT6HZ
--HG--
extra : rebase_source : c6c3832fe0aa0fe9429052dcb5b15a3497c33fa4
In the new architecture of Quantum DOM, all timer callback need a
specified event target. So, we add the new document arg to Start
function to get the event target from it. And update all callers.
MozReview-Commit-ID: a482mukqGc
--HG--
extra : rebase_source : 36f9d47a4afd7c7113adf3f274656b694b8d0943
In the new architecture of Quantum DOM, all runnables need a name label.
So, we add the new string-label arg to Start function, and update all
callers.
MozReview-Commit-ID: G9LXFjtFcQv
--HG--
extra : rebase_source : a19b605013be56d01780c831d2a48ada8825b1c7
This will make the timing of the change more consistent between SetAttr and
UnsetAttr, and ensure that we have both the old and new type available in
AfterSetAttr.
MozReview-Commit-ID: Gsrxkkve7BC
This removes the requirement that BeforeSetAttr comes before AttributeWillChange
(which needs the preparsed new value).
MozReview-Commit-ID: 87C6Mjc7ARh
This introduces two behavior changes:
1) In cached mode, we used to treat unknown selection directions as "none".
Now we treat it like "forward", consistently with the "have an editor" mode.
2) Before this change, in cached mode, we did not fire "select" events on
selectionDirection changes.
MozReview-Commit-ID: 4nBCAm3mAiz
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionEnd changes.
3) Changes the IDL type of HTMLInputElement's selectionEnd attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: J3Gkhr8VnbS
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionStart changes.
3) Changes the IDL type of HTMLInputElement's selectionStart attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: JM9XXMMPUHM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
MozReview-Commit-ID: AEW9D1zG6sM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
At this point, all this method does is ensure editor initialization and then ask
the editor state for various information. Let's cut out the middleman.
MozReview-Commit-ID: p491umScJO
This is a terrible hack, asking input[type=range] in our video control
xbl binding content continue to handle mouse/touch event, even if the
event is being defaultPrevented by the content.
MozReview-Commit-ID: G1huxbS7oeq
--HG--
extra : rebase_source : 27153ce36e6883d947894da69dd9aca47965e99b
With this patch, the disabled state is still kept in the nsPresState,
but we will only honor that if the state saved asks as to re-enable the
control.
The behavior is changed so that controls disabled by JavaScript will be
kept enabled as the JavaScript world gets reloaded.
MozReview-Commit-ID: 6PchHfx6KYX
--HG--
extra : rebase_source : 19399db854cc7cb80f45940bfc378c3e09c2979c
I'm not 100% sure that I'm being very consistent in my handling of
mFocusedValue, but since that's not used for file inputs, I don't think it
matters much...
A bigger problem is if people start using this caller type for things other than
file inputs.
Otherwise, when a value="" attribute with a newline in it is copied, we
will strip any newlines even if type="hidden" is set, because type=""
hasn't yet been copied. Other bugs are likely too. This problem was
already solved for the parser, so we can just use that solution for
cloning too.
MozReview-Commit-ID: KqxCnxmxFXp
--HG--
extra : rebase_source : 9a666adad3dbbbaa5e3706747dcf70801b9ef4e8
The idea is to not make consumers think about whether the principal exists or
not when the caller knows for sure that it does.
The substantive changes are in dom/bindings, nsHTMLDocument::SetDesignMode, and
around the CanUseStorage bits. Everything else is pretty mechanical.
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
