The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
In each case, the atom had an obvious name and a weird name. Where possible, I
kept the obvious name and commented out the weird name, viz:
- `mixed` over `_mixed` for "mixed"
- `el` over `el_` for "el"
- `other` over `other_` for "other"
- `remote` over `Remote` for "remote"
But for several of them I didn't do that, because the weird name is used
within the HTML5 parser -- which is a huge pain to modify because it involves
code generated by code from another repo -- so I kept the weird name and
commented out the obvious name, viz:
- `list_` over `list` for "list"
- `svgSwitch` over `_switch` for "switch"
- `set_` over `set` for "set"
MozReview-Commit-ID: Jp3CpdWXNDm
--HG--
extra : rebase_source : 421ce5316772f1951488307e81f2ceee696d363d
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
This removes the extremely verbose "[nsFrameLoader] ReallyStartLoadingInternal
tried but couldn't show remote browser" warning. We already return NS_OK in
this case, so the behavior is expected.
--HG--
extra : rebase_source : 1b5a61542996ec4af9ff6a646ee15cb5ea22efdf
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Right now every document in a docshell makes a copy of the list. In practice,
this list is usually pretty short (limited by depth of iframe nesting), so this
is probably not a problem. We could add a bit of complexity and have a
refcounted struct that contains the list... I wish we had something as simple
as Rust's Arc that we could use here.
MozReview-Commit-ID: 8jGIlkhp1DU
We allow swapping frameloaders between unrelated documents, so we need to
reparent wrappers when the owner content changes.
MozReview-Commit-ID: LNIf4ZrCZLo
--HG--
extra : rebase_source : 8041d1601962d61e675e78e3447c7772eee89df0
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
Editor treated in nsFrameLoader is always HTMLEditor. So, it should treat the editor as is.
MozReview-Commit-ID: 7bZMbLGKsED
--HG--
extra : rebase_source : 47c22423062cd724551ad3b4fde168e03891b4c7
