The usage of our specific "text" event is enough low (0.0003%). So, let's
stop dispatching the event in the default group of web content. Once we
release this new behavior, we can get rid of dispatching the event even in
chrome. Then, we can optimize the event order for new specs.
Differential Revision: https://phabricator.services.mozilla.com/D13034
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
We can wait for the button fix if you want, but it was easy enough to fix, I
think.
I think we could merge NativeAnonymousContentRemoved with the walk that
NotifyFrameRemoved does, since the content should still be in the tree when that
happens. If you want, I can do that as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D10845
--HG--
extra : moz-landing-system : lando
Depends on D8740.
This changeset replaces calls to ok with 3 arguments to calls with 2 arguments
in situations where the switch does not have a significant impact on the assert.
Differential Revision: https://phabricator.services.mozilla.com/D8741
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Chrome sets both KeyboardEvent.keyCode and KeyboardEvent.charCode of "keypress"
event to same value. On the other hand, our traditional behavior is, sets
one of them to 0.
Therefore, we need to set keyCode value to charCode value if the keypress
event is caused by a non-function key, i.e., it may be a printable key with
specific modifier state and/or different keyboard layout for compatibility
with Chrome. Similarly, we need to set charCode value to keyCode value if
the keypress event is caused by a function key which is not mapped to producing
a character.
Note that this hack is for compatibility with Chrome. So, for now, it's enough
to change the behavior only for "keypress" event handlers in web content. If
we completely change the behavior, we need to fix a lot of default handlers
and mochitests too. However, it's really difficult because default handlers
check whether keypress events are printable or not with following code:
> if (event.charCode &&
> !event.altKey && !event.ctrlKey && !event.metaKey) {
or
> if (!event.keyCode &&
> !event.altKey && !event.ctrlKey && !event.metaKey) {
So, until we stop dispatching "keypress" events for non-printable keys,
we need complicated check in each of them.
And also note that this patch changes the behavior of KeyboardEvent::KeyCode()
when spoofing is enabled and the instance is initialized by initKeyEvent() or
initKeyboardEvent(). That was changed by bug 1222285 unexpectedly and keeping
the behavior makes patched code really ugly. Therefore, this takes back the
old behavior even if spoofing is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D7974
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
This reuses the same code path that was added in bug 1461299 for NAC, but for
generated content as well. DestroyAnonymousContent notifies to the ESM.
Also, remove the NativeAnonymousContentRemoved bit about <svg:use> since it's no
longer NAC.
Differential Revision: https://phabricator.services.mozilla.com/D5575
PresShell does this already.
I updated the scroll / drag code as well, but I need to admit I didn't figure
out how to write a test for it. The rest of the codepaths are needed for the
added test to pass.
Differential Revision: https://phabricator.services.mozilla.com/D2871
We shouldn't fire mouseenter / leave based on the light tree, but the
flattened tree, the same way as the rest of the hover code works.
Differential Revision: https://phabricator.services.mozilla.com/D2866
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
Scrolling is not permitted along the axis whose overflow style is hidden. In
the mochitest test_wheel_default_action, tests which checked if overflow hidden
pages were scrollable failed after the changes in the Part 1 patch were
submitted to try. The tests failed as overflow hidden pages were scrollable.
After investigating the sequence of events, we realized that the
overflow-x:hidden property was taking effect on the compositor thread after the
scroll-wheel event was received on the compositor thread. Therefore, scrolling
took place even before the scrollable rect was sized appropriately and
scrolling beyond the layout viewport size was possible. To solve this, we wait
for all repaints to occur before the test sends a scroll-wheel event. Waiting
for all repaints guarantees that the overflow-x:hidden property will be set
before a scroll-wheel event is received.
MozReview-Commit-ID: 2hc3MTyKhnS
--HG--
extra : rebase_source : 3e84905826a1b7430a245734eaadbda2aadf0e27
