`inputmode` attribute controls software keyboard layout like `<input type>`.
Originally this was by B2G (bug 746142) and for `<input>` element only.
WHATWG spec allows this attribute for HTML element and WebKit and Blink have
already implemented this.
Differential Revision: https://phabricator.services.mozilla.com/D69348
--HG--
extra : moz-landing-system : lando
This restores our previous behavior with the new <input type=number>
implementation (see the changes in test_input_number_l10n.html, which undoes the
changes of the regressing bug), and adds a test that shows that we display the
localized value properly.
Differential Revision: https://phabricator.services.mozilla.com/D66822
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
If the actual input value didn't change, we'd skip updating form validity, but
that's not always correct because GetStepBase() depends on the value attribute.
Differential Revision: https://phabricator.services.mozilla.com/D66836
--HG--
extra : moz-landing-system : lando
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
If `TextControlState` does not have `TextEditor` and its `SetValue()` is called
from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput`
event.
If the value is modified by `beforeinput` event listener, it's intended that
`preventDefault()` is called by the web apps. However, the behavior in this
case is not mentioned by UI Events nor Input Events spec. We should just file
a spec issue instead of emulating Chrome's behavior for now because it requires
more changes, but this case must be an edge case.
The spec issue is: https://github.com/w3c/input-events/issues/106
Differential Revision: https://phabricator.services.mozilla.com/D58126
--HG--
extra : moz-landing-system : lando
If `TextControlState` does not have `TextEditor` and its `SetValue()` is called
from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput`
event.
If the value is modified by `beforeinput` event listener, it's intended that
`preventDefault()` is called by the web apps. However, the behavior in this
case is not mentioned by UI Events nor Input Events spec. We should just file
a spec issue instead of emulating Chrome's behavior for now because it requires
more changes, but this case must be an edge case.
The spec issue is: https://github.com/w3c/input-events/issues/106
Differential Revision: https://phabricator.services.mozilla.com/D58126
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
Note that `TextControlState::BindToFrame()` may also run script if it's
called without script blocker. However, it shouldn't occur. Therefore,
we don't need to mark it `MOZ_CAN_RUN_SCRIPT`, but we should check
script blocker existence with `MOZ_ASSERT`.
Differential Revision: https://phabricator.services.mozilla.com/D55776
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Currently, only `HTMLInputElement` reuses `TextControlState` instance since
`HTMLTextAreaElement` had the instance as a member rather than allocate it.
Now, all instances are allocated in the heap independently for guaranteeing
their lifetime. So, the reuse mechanism should be managed by
`TextControlState` itself.
Depends on D51393
Differential Revision: https://phabricator.services.mozilla.com/D51394
--HG--
extra : moz-landing-system : lando
Currently, nobody guarantees that `TextControlState` won't be deleted while
it handles something with `MOZ_CAN_RUN_SCRIPT` methods.
This patch hides its destructor (and constructor) for making only
`TextControlState` itself can delete its instances. Then, if instance owner
wants to delete it while handling action(s), the oldest `AutoHandlingState`
will delete the `TextControlState`.
Depends on D51392
Differential Revision: https://phabricator.services.mozilla.com/D51393
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
When we call nsContentUtils::IsPatternMatching, we swallow JS engine errors
unconditionally returning true.
This is bad, because if it happens in one of the value sets that arguably
shouldn't change the state of the element, we end up returning an arbitrary
value (true) which may or may not match the previous state of the element.
Handle error explicitly instead, by not updating the state.
Differential Revision: https://phabricator.services.mozilla.com/D45727
--HG--
extra : moz-landing-system : lando
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
The various margin attributes on <body> are "pixel length attributes" in the
spec, which should get parsed as non-negative integers. That said, Chrome and
Safari implement marginwidth, marginheight, marginleft, and margintop as
"dimension attributes" instead, and don't implement marginright and marginbottom
at all.
Differential Revision: https://phabricator.services.mozilla.com/D36372
--HG--
extra : moz-landing-system : lando
The spec allows non-integer values, but we don't have a good way to store them
in nsAttrValue yet. See https://bugzilla.mozilla.org/show_bug.cgi?id=1561440
HTMLTableCellElement::MapAttributesIntoRule can now call
MapImageSizeAttributesInto instead of manually mapping width and height, because
0 values (which it was excluding before) are now excluded at attribute parse
time.
For 'width' on HTMLTableElement I kept our old behavior for 0, which matches the spec
but not Safari or Chrome.
For 'height' on HTMLTableElement I kept our old behavior for 0, which matches
Safari and Chrome but not the spec. https://github.com/whatwg/html/issues/4715
tracks a possible spec change.
Same thing for 'height' on HTMLTableRowElement.
Same thing for 'width' on HTMLTableColElement.
The ParseImageAttribute call in HTMLMediaElement is not needed, because
HTMLAudioElement does not map any of those to style and HTMLVideoElement only
maps width/height, which it already parses.
Differential Revision: https://phabricator.services.mozilla.com/D36127
--HG--
extra : moz-landing-system : lando
This should be the minimal patch to fix the issue (should be safe for branches too).
Reusing an existing mouse/touch test for the crash testing.
Differential Revision: https://phabricator.services.mozilla.com/D34717
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep = true,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(aDeep,#UnbindFromTree(#g' $file; done
$ ./mach clang-format
And fix the two callers and little use of the aDeep argument (see the "Manual
changes" patch attached to bug).
Differential Revision: https://phabricator.services.mozilla.com/D32898
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsContentUtils::DispatchXULCommand()` because
it guarantees the lifetime of **only** `PresShell` in it. So, we need to check
the lifetime of each argument at each caller here.
Differential Revision: https://phabricator.services.mozilla.com/D29199
--HG--
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
This patch creates new header, `mozilla/PresShellForwards.h`. It should have
all forward declarations of global class/struct in `nsIPresShell.h` and
`mozilla/PresShell.h`.
Additionally, this moves all `enum`s and `constant`s in them into the new file
with changing them to `enum class`es.
This will make other headers which require only specific types in the header
files not include them.
Differential Revision: https://phabricator.services.mozilla.com/D28605
--HG--
extra : moz-landing-system : lando
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
Editable elements will no longer get click events for non-primary mouse buttons
since they are being unshipped from the web in favour of auxclick events.
Listen for auxclick as well so middle-click paste still works.
Don't stop propagation after middle-click paste, instead ignore clicks on
contenteditable elements in ClickHandlerChild.
Update test_middle_click_paste.html for the new behaviour.
Also remove the mNoContentDispatch overrides in HTMLInputElement and
HTMLTextAreaElement that were needed for middle-pasting.
Differential Revision: https://phabricator.services.mozilla.com/D26792
--HG--
extra : moz-landing-system : lando
- Remove expectation that 'preventScroll.html' fails.
- Use '[NoInterfaceObject] interface' workaround to simulate missing 'mixin' support.
Differential Revision: https://phabricator.services.mozilla.com/D26922
--HG--
extra : moz-landing-system : lando
This is closer to what other UAs do, it's simpler, and fixes the bug.
It looks like the complexity of multiple buttons or what not is related to
bug 1188880, which is WONTFIX. We no longer have multiple buttons in the same
file input, so this is better IMO.
Differential Revision: https://phabricator.services.mozilla.com/D26825
There's only one button in a file input. This used to be an
input[type="button"].
There's no point in using more specific rules or such, the regular UA rules just
work, and content can't style this button so it can't be overriden.
This should be an idempotent patch.
Differential Revision: https://phabricator.services.mozilla.com/D26753
`nsIControllerCommandTable` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, it's inherited only by nsControllerCommandTable. So, all users
in C++ can treat the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D25727
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
When `nsContentUtils::DispatchInputEvent()` dispatches `input` event, the
editor's value was changed by somebody. In this case, it needs to update
the valid state **and** notify to update the style.
(Note that I'm not sure whether this is right approach.)
Differential Revision: https://phabricator.services.mozilla.com/D25029
--HG--
extra : moz-landing-system : lando
In order to trigger the 'onchange' event when resetting the 'date' or
'time' html input elements.
Differential Revision: https://phabricator.services.mozilla.com/D24206
--HG--
extra : moz-landing-system : lando
Even less so on reframe, where it's just unsound to do so. I had to give a value
to eSetValue_Internal, since otherwise I cannot check for its presence. I can
further special-case the reframe case if you prefer.
Differential Revision: https://phabricator.services.mozilla.com/D20133
--HG--
extra : moz-landing-system : lando
"input" event listener may want to check HTMLInputElement.validationMessage.
However, due to moving "input" event dispatcher from
HTMLInputElement::SetUserInput() to editor, HTMLInputElement::SetValueInternal()
updates it **after** dispatching "input" event.
This patch makes nsContentUtils::DispatchInputEvent() guarantees to update
validationMessage value before dispatching every event. On the other hand,
SetValueInternal() may be called without "input" event dispatchers. Therefore,
it needs to keep updating validationMessage value in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D19126
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
ImageLoadingContent will take care of updating element to correct state, we don't need to do this.
Especially for HTMLImageElement, because it may not reload the image after BindToTree (
e.g. the selected source isn't changed), clearing broken state may put element into
incorrect state.
The original code seems from https://bugzilla.mozilla.org/show_bug.cgi?id=491063#c32
for a performance reason, however I test the http://mozilla.pettay.fi/moztests/1x1image.html
again on recent codebase, I don't see difference with/without applying this patch.
--HG--
extra : rebase_source : 2de29cced4ad0a18a5a6908641305203cc88a5f4
The XBL binding implementation relied on nsDateTimeControlFrame to call into
its nsIDateTimeInputArea implementation. This is correct because the XBL binding
is only constructed when the element has a frame. If the value is set while the
element is hidden, the XBL binding will pick up the correct value during construction.
That is not the case for UA Widget. As it is constructed when the DOM is attached,
relying on nsDateTimeControlFrame to send an event when attributes change means
the event won't be sent to the already constructed UA Widget.
This patch fixes that by moving the event dispatching calls originating from
HTMLInputElement out of nsDateTimeControlFrame, so they will behave correctly in
the absence of the frame.
I've also moved the gut of nsDateTimeControlFrame::HasBadInput() to
DateTimeInputTypeBase::HasBadInput(). Content script should be allowed to validate
the input without the frame.
Sadly this means the XBL implementation and the UA Widget implementation
have further diverged. The complexity should go away when we could finally
remove the XBL implementation.
nsDateTimeControlFrame still dispatches a few events to UA Widget, in
AttributeChanged() and SyncDisabledState(), as they are originated from the layout.
The name of the events in AttributeChanged() are incorrect though -- I am correcting
that in this patch too.
Differential Revision: https://phabricator.services.mozilla.com/D15601
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Cache whether an input was ever type=password so consumers can handle sites which toggle password visibility and don't want to save the value of the field.
Differential Revision: https://phabricator.services.mozilla.com/D15145
--HG--
extra : moz-landing-system : lando
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
When editor is modified as part of user action, aFlags of
nsTextEditorState::SetValue() includes eSetValue_BySetUserInput. In this case,
TextEditor (if there is) or the method itself (if there is no editor yet)
should dispatch "input" event by themselves because we will need to initialize
InputEvents more since we're going to implement Input Event specs.
Note that even with this patch, password field stops dispatching "input" event
with call of HTMLInputElement::SetUserInput(). This is caused by a hidden bug
of TextEditRules. This will be fixed in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D12245
--HG--
extra : moz-landing-system : lando
Currently, a lot of code dispatch "input" event and some of them dispatch
"input" event with wrong interface and/or values. Therefore this patch
creates nsContentUtils::DispatchInputEvent() to make all of them dispatch
correct event.
Unfortunately, due to bug 1506439, we cannot set pointer to refcountable
classes of MOZ_CAN_RUN_SCRIPT method to nullptr. Therefore, this patch
creates temporary RefPtr<TextEditor> a lot even though it makes damage to
the performance if it's in a hot path.
This patch makes eEditorInput event dispatched with
InternalEditorInputEvent when "input" event should be dispatched with
dom::InputEvent. However, this patch uses WidgetEvent whose message is
eUnidentifiedEvent and setting WidgetEvent::mSpecifiedEventType to
nsGkAtoms::oninput when "input" event should be dispatched with
dom::Event because we need to keep that eEditorInput and
InternalEditorInputEvent are mapped each other.
Differential Revision: https://phabricator.services.mozilla.com/D12244
--HG--
extra : moz-landing-system : lando
This patch converts datetimebox.xml to datetimebox.js and loads it as a UA Widget,
while touches things here and there to make it work.
In HTMLInputElement manages the lifecycle of the datetimebox UA Widget.
It is loaded when in <input> has type date or time, or have its type switch to date or time.
nsDateTimeControlFrame is changed so that when UA Widget is enabled,
it would not generate <xul:datetimebox>.
Like bug 1483972, a check is added in nsCSSFrameConstructor::CreateGeneratedContentItem()
to make sure we don't generate pseudo content inside <input>.
Assertions in IntlUtils is changed to allow UAWidget to call the methods.
Depends on D9056
Differential Revision: https://phabricator.services.mozilla.com/D9057
--HG--
rename : toolkit/content/widgets/datetimebox.xml => toolkit/content/widgets/datetimebox.js
extra : moz-landing-system : lando
This patch simplifies the nsIDateTimeInputArea interface, implemented by the
datetimebox bindings, to a point that is easier to convert it to dispatch events,
by doing the following:
- hasBadInput() is re-implemented in C++ in nsIDateTimeControlFrame since
C++ needs the return value synchronously.
- SetValueFromPicker() and SetPickerState() are avoided completed since they
are simply called by HTMLInputElement methods exposed to the frame
script. They are avoided by having the frame script access the NAC and call
the nsIDateTimeInputArea methods directly.
- Merge setEditAttribute() and removeEditAttribute() to updateEditAttributes()
which takes no arguments, and have the method access the attribute values by
reading the values from <input>.
This patch is a scaled-down version of the patch proposed in bug 1456833.
The event approach is only usable in UA Widget version of datetimebox because
there is no way to avoid leaking events to the document without Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D9056
--HG--
extra : moz-landing-system : lando
Allow untrusted Events and Custom events to be dispatched at disabled form element. This is for interop and some developers have asked for this.
Differential Revision: https://phabricator.services.mozilla.com/D10000
--HG--
extra : moz-landing-system : lando
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
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
