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
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
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.
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
The semantics of the VisualViewport resize/scroll events aren't quite what is
needed for internal browser usage, so we need a separate set of events that can
be used e.g. by the session store. To avoid future web compatibility issues,
that event should be kept internal, however none of the existing
options to achieve that are suitable:
- mNoContentDispatch can actually end up being dispatched to content after all
and as per its comment preferably shouldn't be used any more for new features
- mOnlySystemGroupDispatchInContent would work perfectly, except that it
shouldn't be used for frequent events, which the resize/scroll events
arguably are
- mOnlyChromeDispatch doesn't work for the Desktop session store's content
script, plus it might have the same performance problems as
mOnlySystemGroupDispatchInContent
Therefore, I propose to introduce a new mOnlySystemGroupDispatch event flag,
which skips the comparatively expensive IsCurrentTargetChrome() check and relies
only on the event listener having been registered in the system group.
Differential Revision: https://phabricator.services.mozilla.com/D14045
--HG--
extra : moz-landing-system : lando
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
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 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/D13046
--HG--
extra : moz-landing-system : lando
When fingerprinting resistance is enabled, content should only view the
pointer capture events from the spoofed interface. In order to do so,
first, we need to restrict content to only set or release pointer capture
for only the spoofed pointer id. Second, we have to map other interfaces
into the spoofed one for pointer capture events.
Depends on D9531
Differential Revision: https://phabricator.services.mozilla.com/D9532
--HG--
extra : moz-landing-system : lando
This patch makes it to spoof the pointer id into mouse pointer id
when resistfingerprinting is enabled. And we will only spoof for
content but not for chrome. Since we don't know the pointer id
beforehand, we have to cache the pointer id of the mouse interface when
it is activated. And use that pointer for the purpose of fingerprinting
resistance.
Differential Revision: https://phabricator.services.mozilla.com/D9531
--HG--
extra : moz-landing-system : lando
For touch events, we use 'touchend' to activate document, because 'touchstart' can be the start of either draging
or touch. As 'pointdown' is a precedent event of the 'touchstart', we should not activate document if the source of
event is from touch event.
Differential Revision: https://phabricator.services.mozilla.com/D12333
--HG--
extra : moz-landing-system : lando
For touch events, we use 'touchend' to activate document, because 'touchstart' can be the start of either draging
or touch. As 'pointdown' is a precedent event of the 'touchstart', we should not activate document if the source of
event is from touch event.
Differential Revision: https://phabricator.services.mozilla.com/D12333
--HG--
extra : moz-landing-system : lando
We should set the 'mGestureDownPoint' correctly when receiving 'touchstart' so that we can
distinguish whether the 'touchend' comes from dragging or simply touching by calling
'IsEventOutsideDragThreshold()'.
Differential Revision: https://phabricator.services.mozilla.com/D11395
--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
"text" event is Mozilla specific event, not in any standards. The event follows
"compositionupdate" event and editor modifies composition string when receives
the event in the system group.
So, we'd like to stop dispatching this unnecessary event but we need to get
actual usage in the web.
Differential Revision: https://phabricator.services.mozilla.com/D11600
--HG--
extra : moz-landing-system : lando
This patch re-enables the new behavior of bug 1479964, to set keyCode or
charCode of keypress event whose value is zero to the other's non-zero value.
However, some web apps are still broken with the new behavior. Therefore,
this patch adds a blacklist to keep using our legacy behavior in some specific
web apps.
Note that Google Docs, Gmail and Remember The Milk are reported as broken.
However, I don't see any broken shortcut with Gmail. Therefore, this patch
adds only Google Docs and Remeber The Milk into the blacklist.
Differential Revision: https://phabricator.services.mozilla.com/D10322
--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
The pointerType field in the pointer event will reveal the details of
users' hardware; this is a fingerprinting vector. So, we would spoof all
types of pointer events into mouse type pointer events for protecting
users from browser fingerprinting when fingerprinting resistance is on.
In this patch, we would spoof the pointerType as well as other fields
that mouse pointer events don't support, like pressure, tiltX/Y and so
on when fingerprinting resistance is on.
Differential Revision: https://phabricator.services.mozilla.com/D6003
--HG--
extra : moz-landing-system : lando
This patch makes EventStateManager handle middle click paste as a default
action.
Unfortunately, we cannot remove the call of HandleMiddleClickPaste() in
EditorEventListener because it's important to consume middle click event
before any elements in the editor. For example, if clicked HTMLEditor has
non-editable <a href> element, middle click event needs to be handled by the
editor rather than contentAreaUtils which handles click events of <a href>
elements. The cause of this kind of issues is, any click event handlers
which handle non-primary button events still listen to "click" events.
Therefore, this patch makes HandleMiddleClickPaste() do nothing if the mouseup
event is fired on an editor.
Differential Revision: https://phabricator.services.mozilla.com/D7855
--HG--
extra : moz-landing-system : lando
This is preparation of the last patch. Even if no editor is clicked with
middle button, we need to do:
- collapse Selection at the clicked point.
- dispatch "paste" event.
Therefore, HandleMiddleClickPaste() should dispatch ePaste event by itself
and each editor methods should have a bool argument which the caller wants
ePaste event automatically.
Note that Chromium dispatches "paste" event and pastes clipboard content
into clicked editor even if preceding "auxclick" event is consumed.
However, our traditional behavior is not dispatching "paste" event nor
pasting clipboard content. Unless Chromium developer keeps their odd
behavior, we should keep our traditional behavior since our behavior is
conforming to DOM event model.
Differential Revision: https://phabricator.services.mozilla.com/D7854
--HG--
extra : moz-landing-system : lando
EventStateManager needs to handle middle click paste without editor.
Therefore, the handler should be in EventStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D7852
--HG--
extra : moz-landing-system : lando
We need to move EditorEventListener::HandleMiddleClickPaste() into
EventStateManager to handle middle click paste after all click events are
dispatched. This is preparation of the change.
HandleMiddleClickPaste() uses UIEvent::GetRangeParent() and
UIEvent::RangeOffset() to collapse Selection at clicked point. However,
EventStateManager cannot access them since EventStateManager can handle it
with WidgetMouseEvent. Fortunately, only WidgetMouseEvent is necessary for
implementing them. Therefore, we can move the implementation into
nsLayoutUtils and merge them.
Differential Revision: https://phabricator.services.mozilla.com/D7851
--HG--
extra : moz-landing-system : lando
EventStateManager::InitAndDispatchClickEvent() sends given nsEventStatus to
nsIPresShell::HandleEventWithTarget(). Then, it sends the status to
EventStateManager::PreHandleEvent() before dispatching the event. At this
time, EventStateManager::PreHandleEvent() resets the state to
nsEventStatus_eIgnore. Therefore, for example, if eMouseClick event is
consumed but eMouseAuxClick is ignored, the event status result is
nsEventStatus_eIgnore. So, neither DispatchClickEvents() nor
PostMouseUpEventHandler() cannot check whether at least one click event
is consumed.
This patch makes EventStateManager::InitAndDispatchClickEvent() sends
local variable of nsEventStatus to nsIPresShell::HandleEventWithTarget().
Then, merge the result with current status.
If we'd change nsEventStatus to enum class, we could make this change as
custom "operator|=" or something.
Differential Revision: https://phabricator.services.mozilla.com/D7850
--HG--
extra : moz-landing-system : lando
This patch splits EventStateManager::CheckForAndDispatchClick(). One is for
handling default action of eMouseUp, the other is for dispatching click events.
This makes it easier to add other default actions after dispatching click
events.
Differential Revision: https://phabricator.services.mozilla.com/D7849
--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
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--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
Some steps in file_fullscreen-api.html are adjusted in order to test
the behavior that the event is correctly dispatched to the document
when element is disconnected.
Depends on D5415
Differential Revision: https://phabricator.services.mozilla.com/D5416
--HG--
extra : moz-landing-system : lando
Some methods on Window are not changed because they are part of public
interface. Method names from widget are also unchanged.
Many "full-screen" in comments are also updated to "fullscreen" instead.
Differential Revision: https://phabricator.services.mozilla.com/D5639
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Cosmin Sabou
Tooru Fujisawa
Jorg K
Ciure Andrei
Boris Zbarsky
Daniel Varga
Jon Coppeard
Peter Van der Beken
Sylvestre Ledru
Coroiu Cristina
Neil Deakin
Jan Henning
Andrea Marchesini
Olli Pettay
Gabriele Svelto
Kyle Machulis
Masayuki Nakano
Ehsan Akhgari
Tom Schuster
Csoregi Natalia
Tim Huang
Razvan Maries
alwu
Andreea Pavel
Timothy Guan-tin Chien
Brian Grinstead
Nazım Can Altınova
Margareta Eliza Balazs
Julian Descottes
Nika Layzell
Mark Banner
Gijs Kruitbosch
Neil Deakin
Nicholas Nethercote
Gurzau Raul
Andrew McCreight
shindli
Jonathan Kingston
Brindusan Cristian
arthur.iakab
Tiberius Oros
Jonathan Kew
Xidorn Quan