This patch assumes that only element node can have content node. I.e., we
won't hit the following `MOZ_ASSERT`:
```
Element* element = nullptr;
nsIContent* content = aContent;
while (content) {
if (content->IsElement()) {
element = content->AsElement();
break;
}
content = content->GetParent();
}
MOZ_ASSERT(!content || content == element || content->GetParent() == element);
```
Differential Revision: https://phabricator.services.mozilla.com/D63308
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
I made `nsContentUtils::DispatchInputEvent()` update validity of event target
before dispatching `eEditorInput` event in bug 1584963. However, this is not
enough because it updates validity only when the type of `<input>` element is
`mail`, but it's required for other types, for example, `<input required>`.
This patch reverts the hack added in bug 1584963, instead, makes
`TextControlState::SetValueWithoutTextEditor()` notifies `TextControlElement`
of value change before dispatching `eEditorInput` event because it may have made
damage to the performance if `nsContentUtils::DispatchInputEvent()` updated
**all** validity state of the event target.
Differential Revision: https://phabricator.services.mozilla.com/D60828
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
This doesn't solve all problems with potential reentrancy during window.open
nested event loops, but it does improve the situation somewhat. Since any
window in the same BrowsingContextGroup can target any window in the same
group, we need to suspend all windows in the group, not just the root of the
new window's parent. We also need to make sure we suspend all in-process
windows, even if we have out-of-process frames somewhere in the parent chain.
This patch takes care of suspending timeouts and input event handling in all
of these cases. It doesn't block all potential paths for running code in the
suspended windows, though, so the next patch explicitly prevents the
problematic reentrancy.
Differential Revision: https://phabricator.services.mozilla.com/D57666
--HG--
extra : moz-landing-system : lando
This doesn't solve all problems with potential reentrancy during window.open
nested event loops, but it does improve the situation somewhat. Since any
window in the same BrowsingContextGroup can target any window in the same
group, we need to suspend all windows in the group, not just the root of the
new window's parent. We also need to make sure we suspend all in-process
windows, even if we have out-of-process frames somewhere in the parent chain.
This patch takes care of suspending timeouts and input event handling in all
of these cases. It doesn't block all potential paths for running code in the
suspended windows, though, so the next patch explicitly prevents the
problematic reentrancy.
Differential Revision: https://phabricator.services.mozilla.com/D57666
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
We are going to introduce a new function in Document in this commit series,
which enumerates all child documents regardless of whether it's in the same
process, in content processes or in out-of-process iframes. The function takes
std::functions, but I don't have any good ideas to convert lambda functions with
capturing variables to function pointer.
Differential Revision: https://phabricator.services.mozilla.com/D57434
--HG--
extra : moz-landing-system : lando
We are going to introduce a new function in Document in this commit series,
which enumerates all child documents regardless of whether it's in the same
process, in content processes or in out-of-process iframes. The function takes
std::functions, but I don't have any good ideas to convert lambda functions with
capturing variables to function pointer.
Differential Revision: https://phabricator.services.mozilla.com/D57434
--HG--
extra : moz-landing-system : lando
foo ? true : false
or:
foo ? false : true
Have always a nicer way to be written.
Differential Revision: https://phabricator.services.mozilla.com/D56842
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
