Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
The end goal of this inheritance changes is,
- The common codes that could be shared between form-assciated custom elements
(FACE) and other form-assciated elements would be left in nsGenericHTMLFormElement.
- The codes that doesn't require for FACE would be moved to nsGenericHTMLFormControlElement.
- The nsGenericHTMLFormControlElement would inherit the nsIFormControl instead.
- HTMLElement would inherit nsGenericHTMLFormElement in order to make it could be
add into HTMLFormElement or HTMLFieldElement if it is a FACE.
This part is just a skeleton change, code movement and adjustment are in subsequent parts.
Differential Revision: https://phabricator.services.mozilla.com/D124785
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
And fix existing users of course.
The frame loader one is the only one slightly scary (but if it causes
trouble we could make nsObjectLoadingContent::Unlink a no-op).
Differential Revision: https://phabricator.services.mozilla.com/D107269
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
Currently, they are never focusable when its type is "plugin".
So, making stop them returning `IMEEnabled::Plugin` won't change
anything, but it guarantees that nobody will see `IMEEnabled::Plugin`
at runtime. This is a preparation for the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D100101
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
As part of the fallback for unsupported plugin elements, we deny them focus. Since elements can be programmatically changed, and object/embed elements can change internal "type" by updating their data/src attributes, and because that type is decided asynchronously, we may need to give up focus if our element has it.
Differential Revision: https://phabricator.services.mozilla.com/D95903
As part of the fallback for unsupported plugin elements, we deny them focus. Since elements can be programmatically changed, and object/embed elements can change internal "type" by updating their data/src attributes, and because that type is decided asynchronously, we may need to give up focus if our element has it.
Differential Revision: https://phabricator.services.mozilla.com/D95903
The spec change HTMLObjectElement tabIndex default to 0, but `test_object_plugin_nav.html` will fail due to HTMLObjectElement’s sequence focus and .focus() rely on default tabIndex. In this patch I separate the logic to not rely on default tabIndex for HTMLObjectElement's plugin type and align the spec.
Differential Revision: https://phabricator.services.mozilla.com/D50801
--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
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.
Make the WindowProxyHolder hold a strong reference to a BrowsingContext, as in the future
we might not have a nsPIDOMWindowOuter (if the document is loaded in a different process).
Differential Revision: https://phabricator.services.mozilla.com/D12651
--HG--
extra : moz-landing-system : lando
Add a WindowProxyHolder type and generate binding code that takes or returns it whenever
the WebIDL refers to the WindowProxy type. This patch just makes the WindowProxyHolder
hold a strong reference to a nsPIDOMWindowOuter.
Differential Revision: https://phabricator.services.mozilla.com/D12650
--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
As part of applet/java plugin removal in bug 1279218, classid checking
was removed, as it was not obvious that this was used anywhere other
than java plugins. The classid is still a valid attribute on object
tags (and is sometimes used on tags for flash embedding). We want
to use a fallback strategy when we find objects with classid
attributes, as we don't support them, meaning we need to revert our
prior removal of the check.
MozReview-Commit-ID: BKQ34HGTkvt
--HG--
extra : rebase_source : 671bc831a7b500ba1a5643a8dbae69dd0c44acf4
