First, we should move nsContentIterator and nsContentSubtreeIterator into
mozilla namespace and then, remove "ns" prefix.
Additionally, this patch separates the definition of the classes into
ContentIterator.h and exposes it as "mozilla/ContentIterator.h". This allows
everybody access those concrete classes.
Differential Revision: https://phabricator.services.mozilla.com/D15917
--HG--
rename : dom/base/nsContentIterator.cpp => dom/base/ContentIterator.cpp
rename : dom/base/nsContentIterator.cpp => dom/base/ContentIterator.h
extra : moz-landing-system : lando
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
nsContentIterator in post-order collects nodes starting from deepest first
child to next siblings and parents. I.e., collecting end points (i.e.,
"close tag" if element node). This is tested by
test_content_iterator_post_order.html.
nsContentIterator in pre-order collects nodes starting from most ancestor to
last deepest child node. I.e., collecting start points (i.e., "open tag" if
element node). This is tested by test_content_iterator_pre_order.html.
nsContentSubtreeIterator collects most ancestor nodes which are selected
entirely by specified range or positions. This is tested by
test_content_iterator_subtree.html
I.e., all of them start with "test_content_iterator_" for making find easier.
Differential Revision: https://phabricator.services.mozilla.com/D15286
--HG--
extra : moz-landing-system : lando
With same-compartment chrome globals these would end up in the same compartment.
We need to prevent that because the debugger doesn't support it.
Differential Revision: https://phabricator.services.mozilla.com/D15093
--HG--
extra : moz-landing-system : lando
When entering into a Shadow DOM in backward navigation, the frame still points
to the last frame in Shadow DOM which could be a non-focusable frame, so move
the handling of backward navigation for Shadow DOM upward.
Differential Revision: https://phabricator.services.mozilla.com/D14069
--HG--
extra : moz-landing-system : lando
This is ultimately the root cause of the issue. I'm landing a test to ensure we
notice the behavior change if we make it, in addition to a test for this issue
itself, to ensure that we don't get stuck, since after bug 1510485 we don't
return such nodes from nsFind when window.find is called anyway.
This code made no sense, it only returned true if the binding parent is the node
itself, which as far as I can tell cannot happen, so it was just a very
expensive way to return false.
Differential Revision: https://phabricator.services.mozilla.com/D14122
--HG--
extra : moz-landing-system : lando
The reftest in this commit fails without changing the default value. The test
image is shrunk too much.
Differential Revision: https://phabricator.services.mozilla.com/D13172
--HG--
extra : moz-landing-system : lando
Storage events are fired either directly after getting response from synchronous SetItem call or through observers. When a new onstorage event listener is added, we sycnhronously register an observer in the parent process. There's always only one observer actor per content process.
PBackgroundLSDatabase is now managed by a new PBackgroundLSObject protocol. PBackgroundLSObject is needed to eliminate the need to pass the principal info and document URI everytime a write operation occurs.
Preparation of an observer shares some states with preparation of a datastore, so common stuff now lives in LSRequestBase and preparation of a datastore now implements a nested state machine.
This patch was enhanced by asuth to drop observers only when the last storage listener is removed.
EventListenerRemoved is invoked on any removal, not just the final removal, so we need to make sure it's the final removal before dropping observer.
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
The one exception are properties that are:
1) Defined in the ES spec.
2) Non-configurable.
3) Readonly.
4) Have values that don't observable change on navigation.
The one exception are properties that are:
1) Defined in the ES spec.
2) Non-configurable.
3) Readonly.
4) Have values that don't observable change on navigation.
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
It's difficult to create new test which checks "input" events caused by
all edit operations especially when text is inserted from our UI. Therefore,
this adds "input" event type checks into existing tests.
Additionally, this adds new test for MozEditableElement.setUserInput() whose
behavior needs to be fixed in this bug.
Currently, InputEvent interface should be used only on text controls or
contenteditable editor when dispatching "input" event.
https://w3c.github.io/input-events/#events-inputevents
You may feel odd to use different event interface for same "input" events.
However, other browsers also use InputEvent interface only in the cases. So,
we should follow them for now.
Differential Revision: https://phabricator.services.mozilla.com/D12243
--HG--
extra : moz-landing-system : lando
Referrerpolicy attribute should be taken with high priority order than
mSpeculationReferrerPolicy
Differential Revision: https://phabricator.services.mozilla.com/D11636
--HG--
extra : moz-landing-system : lando
This patch moves the marquee bindings from xbl-marquee.xml to marquee.js and converts them to a UA Widget.
The contenteditable bindings are dropped, replaced with a styling rule that will fix the position of the scrolling text.
Inline styles have been moved to the stylesheet so usage of display: -moz-box can continue to be parsed.
test_bug840098.html is deleted because it is only valid under the context of in-content XBL bindings.
Differential Revision: https://phabricator.services.mozilla.com/D10385
--HG--
rename : layout/style/xbl-marquee/xbl-marquee.css => toolkit/content/widgets/marquee.css
rename : layout/style/xbl-marquee/xbl-marquee.xml => toolkit/content/widgets/marquee.js
extra : moz-landing-system : lando
There are lots of frames which create anonymous content (like scrollframes,
which generate scrollbars) but for which this code was wrong.
Use StyleChildrenIterator which has a defined order between NAC and flattened
tree. I've verified this doesn't break tabbing through input type="date" with
UA widget disabled, fwiw.
Differential Revision: https://phabricator.services.mozilla.com/D12152
--HG--
extra : moz-landing-system : lando
This patch moves the marquee bindings from xbl-marquee.xml to marquee.js and converts them to a UA Widget.
The contenteditable bindings are dropped, replaced with a styling rule that will fix the position of the scrolling text.
Inline styles have been moved to the stylesheet so usage of display: -moz-box can continue to be parsed.
test_bug840098.html is deleted because it is only valid under the context of in-content XBL bindings.
Differential Revision: https://phabricator.services.mozilla.com/D10385
--HG--
rename : layout/style/xbl-marquee/xbl-marquee.css => toolkit/content/widgets/marquee.css
rename : layout/style/xbl-marquee/xbl-marquee.xml => toolkit/content/widgets/marquee.js
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
MIME type should be trimmed of parameters whenever it is retreived
from the tag it relates to, otherwise other checks may fail.
Differential Revision: https://phabricator.services.mozilla.com/D10803
--HG--
extra : moz-landing-system : lando
Following four conditions are where nsIDocument::mAutoSize is true and
test cases for each condition. The conditions are the cases where we
currently set nsIDocument::mAutoSize true in nsIDocument:GetViewportInfo.
1) width=device-width
test_meta_viewport_auto_size_by_device_width.html
2) no width && height=device-height
test_meta_viewport_auto_size_by_device_height.html
3) no width && initial-scale=1
test_meta_viewport_auto_size_by_fixed_height_and_initial_scale_1.html
test_meta_viewport_auto_size_by_initial_scale_1.html
4) invalid width && (invalid height || no height)
test_meta_viewport_auto_size_by_invalid_width.html
Below tests are cases that autoSize is disabled.
test_meta_viewport_auto_size_by_fixed_width_and_initial_scale_1.html
test_meta_viewport_auto_size_by_fixed_width_and_device_height.html
test_meta_viewport_auto_size_by_initial_scale_0_5.html
test_meta_viewport_auto_size_by_invalid_width_and_fixed_height.html
Depends on D9460
Differential Revision: https://phabricator.services.mozilla.com/D9461
--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
Depends on D8739.
This changeset updates calls to ok() that were most likely intended
for is(), but are not working as is.
Differential Revision: https://phabricator.services.mozilla.com/D8740
--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
The 'ipc:content-created' topic doesn't always seem to be propagated to the
browser_force_process_selector.js test. It appears it's not necessary to
actually wait for it, so lets just remove that.
--HG--
extra : rebase_source : 442a64ff580a8c26bca93723d24128184c5798d6
extra : source : fe7ccd9fee7621782676d9bd841c144126e24c04
The 'ipc:content-created' topic doesn't always seem to be propagated to the
browser_force_process_selector.js test. It appears it's not necessary to
actually wait for it, so lets just remove that.
--HG--
extra : rebase_source : 3bd948166ab94007b9e1752fb9a7e934e4341777
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
have XHRs adjust content type of uploads per spec using the MIME Sniffing standard
Differential Revision: https://phabricator.services.mozilla.com/D5969
--HG--
extra : moz-landing-system : lando
This only includes functions that seem to be using it to reference a window.
There are other instances where it's used as a generic chrome URI, and those
are left unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D3806
--HG--
extra : moz-landing-system : lando
Having to add pagehide/pageshow listeners to the chrome event target is a
serious inconvience for the use cases of this bug. Dispatching to system group
listeners has approximately the same effect as the old code, but is much
easier for window-bound code to handle.
--HG--
extra : rebase_source : d67c14e9ba91772d8a9dd82481120b34bdb551e0
A lot of the ad-hoc frame scripts we execute for tests does not run in strict
mode, and therefore has its functions' `this` objects set to the global when
they are called without a target object.
At the moment, this gives them a MessageManager global. Once message managers
become non-global objects, however, it will give them the shared JSM global,
which is not what they expect.
This patches changes scripts which rely on this to explicitly capture or set
the appropriate `this` object for their calls.
MozReview-Commit-ID: DY8DDb0xE1K
--HG--
extra : rebase_source : 86c1fa4df070711f666dfee5487182afe28a7611
Avoid processing anon content in nsCanvasFrame, then getting more anon content
via AccessibleCaretEventHub::Init. Instead call Init before creating the custom
content container. We could also throw a script runner at it I guess, but this
prevents the reentrancy issue.
Avoid cloning nodes during layout, just use the same node (already cloned in
InsertAnonymousContent) instead.
The RemoveChild in GetAnonymousContent to handle the reframes instead of cloning
around is a bit hacky, but I don't think it's really worth extending
PostDestroyData for this special case.
Differential Revision: https://phabricator.services.mozilla.com/D1889
Allows top level non-XUL documents to share this code. Three tests had to
be adjusted to account for the attributes being chrome only now and not
available to content privilege XUL. In two tests, the values attributes
are now simply undefined. The crashtest was converted to a chrome
mochitest to preserve what it was testing.
MozReview-Commit-ID: 99w9Ax4et3C
--HG--
rename : dom/base/crashtests/473284.xul => dom/base/test/chrome/test_bug473284.xul
extra : rebase_source : 924d34a88fe8a48d766f78b02e64275f6e7cdc2b