***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
GitLab's comment calls scrollTop on input event handler. The scollTop may cause
reflow. When causing reflow, editor is destroyed and initialized again. Then
nsTextEditorState will set current value to editor. But this is failure.
By bug 1465702, selection is cached in edit action. When initializing editor,
selection controller is updated, so selection into cache becomes invalid. It
means that all selection methods will return error since document is different.
So we should update selection cache when initializing editor.
Also, I cannot create test case for this situation since we have to cause reflow
in input and/or composition event. Do you have any idea?
Differential Revision: https://phabricator.services.mozilla.com/D16944
--HG--
extra : moz-landing-system : lando
For mozInlineSpellChecker, I would like to add promse-based method to check
word. But this method is
- On content process, it works by async.
- On chrome process, it works by sync.
Some reftests with non-e10s don't wait that spellchecker is finished correctly
due to race condition of spellchecker dictionary update. So it uses sync'd
promise on chrome.
Differential Revision: https://phabricator.services.mozilla.com/D14836
--HG--
extra : rebase_source : 63d8fb1b3a6f8754f5b7604ea920c1a26bcd4f5b
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
nsFilteredContentIterator is used only by TextServicesDocument and there is
no reason that it should be derived from nsIContentIterator except consistency.
Additionally, it's now only class which is derived from nsIContentIterator
except ContentIteratorBase. So, after this change, we can get rid of
nsIContentIterator completely.
This patch moves nsFilteredContentIterator into mozilla namespace and
makes TextServicesDocument treat FilteredContentIterator directly instead of
nsIContentIterator interface.
Differential Revision: https://phabricator.services.mozilla.com/D15925
--HG--
rename : editor/spellchecker/nsFilteredContentIterator.cpp => editor/spellchecker/FilteredContentIterator.cpp
rename : editor/spellchecker/nsFilteredContentIterator.h => editor/spellchecker/FilteredContentIterator.h
extra : moz-landing-system : lando
Now, all users of PostContentIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15923
--HG--
extra : moz-landing-system : lando
Now, all users of PreContentIterator can access it directly. This patch makes
them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15922
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
nsFilteredContentIterator is used only by TextServicesDocument and there is
no reason that it should be derived from nsIContentIterator except consistency.
Additionally, it's now only class which is derived from nsIContentIterator
except ContentIteratorBase. So, after this change, we can get rid of
nsIContentIterator completely.
This patch moves nsFilteredContentIterator into mozilla namespace and
makes TextServicesDocument treat FilteredContentIterator directly instead of
nsIContentIterator interface.
Differential Revision: https://phabricator.services.mozilla.com/D15925
--HG--
rename : editor/spellchecker/nsFilteredContentIterator.cpp => editor/spellchecker/FilteredContentIterator.cpp
rename : editor/spellchecker/nsFilteredContentIterator.h => editor/spellchecker/FilteredContentIterator.h
extra : moz-landing-system : lando
Now, all users of PostContentIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15923
--HG--
extra : moz-landing-system : lando
Now, all users of PreContentIterator can access it directly. This patch makes
them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15922
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
Editor initializes selection and input context (via IMEStateManager) on focus
event. But if content script calls stopImmediatePropagation on focus event,
editor cannot initialize these since editor cannot receive focus event.
It means that Android widget doesn't open virtual keyboard since
GeckoEditableSupport::SetInputContext isn't called. Also, Firefox desktop
doesn't show caret in this situation since selection isn't initialized in
editor.
So the event listener of focus and blur event should use system group.
Differential Revision: https://phabricator.services.mozilla.com/D15921
--HG--
extra : rebase_source : 71ab7e4aa043bac43e307dd6dfe4e84073d5154f
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
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
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.
Summary:
The latest version of Gecko doesn't crash by this HTML, but I would like to add
this for the future.
Bug #: 1441619
Differential Revision: https://phabricator.services.mozilla.com/D14846
--HG--
extra : rebase_source : 5633e508d1c1f405465857a71f7c544fbb3782e8
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
After fixing bug 1427060, HTMLEditor treats attribute of style as nullptr.
However, if empty string is used to call NS_Atomize(), it returns
nsGkAtoms::_empty. Therefore, HTMLEditor fails to check whether attribute is
specified or not with nullptr check since some root callers sets
nsGkAtoms::_empty instead of nullptr.
This patch makes HTMLEditor always use nullptr for empty string of attribute
of style with wrapping NS_Atomize() with AtomzieAttribute(). Additionally,
for safer change, this patch makes PropItem and TypeInState treat
nsGkAtom::_empty as nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D13203
--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.
Turn all const lists and related attributes into cenums, to provide a
vague sense of type safety.
Depends on D11715
Differential Revision: https://phabricator.services.mozilla.com/D11716
--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/D13073
--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/D13073
--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/D13073
--HG--
extra : moz-landing-system : lando
Android's test runner passes this test, so I would like to run
test_dom_input_event_on_htmleditor.html even if Android.
Differential Revision: https://phabricator.services.mozilla.com/D13040
--HG--
extra : moz-landing-system : lando
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
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
TextEditor instance is created per <input> element which has text editor and
<textarea> element. Therefore, we should keep TextEditor slim as far as
possible.
Currently, TextEditor class size is 400 bytes on Win64. So, we should keep
512 bytes border.
Differential Revision: https://phabricator.services.mozilla.com/D12404
--HG--
extra : moz-landing-system : lando
Myk Melez
Kris Maglione
Randell Jesup
Ehsan Akhgari
Cosmin Sabou
Makoto Kato
Sylvestre Ledru
Razvan Maries
Christoph Kerschbaumer
Masayuki Nakano
Csoregi Natalia
Tim Nguyen
Timothy Guan-tin Chien
Tom Schuster
Emilio Cobos Álvarez
Bogdan Tara
Edgar Chen
Benjamin Bouvier
Jan Varga
Geoff Brown
Kyle Machulis
Andreea Pavel