Finally, we should move the last switch statement in `HandleEventInternal()`
to the new method. Then, `HandleEventInternal() does nothing complicated
things by itself.
Differential Revision: https://phabricator.services.mozilla.com/D22461
--HG--
extra : moz-landing-system : lando
This is the part which actually handles the event. The new method should
notify EventStateManager of dispatching event before and after that, and
actually dispatch the event into the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D22459
--HG--
extra : moz-landing-system : lando
For making `PresShell::EventHandler::HandleEventInternal()` easier to read,
move the large switch statement for preparation into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21341
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` may handle `Escape` key before
dispatching it in some cases. This requires too many lines for somebody who
investigate the method for the other events. Therefore, this patch moves it
into the new method.
Additionally, this patch creates `WidgetKeyboardEvent::CanTreatAsUserInput()`
and `WidgetKeyboardEvent::ShouldInteractionTimeRecorded()` because we should
manage similar checks in one place (we already have
`WidgetKeyboardEvent::CanUserGestureActivateTarget()`). Finally, their
conditions are not enough for what the comment wants to do there since they do
not check some modifier keys. Therefore, this patch makes them check all
possible modifier keys too.
Differential Revision: https://phabricator.services.mozilla.com/D21340
--HG--
extra : moz-landing-system : lando
The first switch statement of `PresShell::EventHandler::HandleEventInternal()`
has 2 jobs:
- Prepare something for specific event type.
- Record the preparation time of some types of events to telemetry.
This intermixed code is not easy to understand and somebody may add new
preparation after recording them. So, even though the preparation time
becomes worse a couple of nanoseconds, we should split those jobs.
The patch moves the latter job into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21339
--HG--
extra : moz-landing-system : lando
Oddly, there are two trusted eMouseMove preparation code in
`PresShell::EventHandler::HandleEventInternal()`. One is in the `switch`
statement which is used only when `aEvent` is trusted. The other is after
`TouchManager::PreHandleEvent()` is called and after
`AutoHandlingUserInputStatePusher` is created. However, both of them do
nothing if the event is `eMouseMove`. Therefore, we can move the latter
into the former.
Differential Revision: https://phabricator.services.mozilla.com/D21338
--HG--
extra : moz-landing-system : lando
If `Shift` state of `eContextMenu` event is active, we make it not fired on
web content. Additionally, if it's not time to open context menu, we shouldn't
dispatch it into the DOM. The new method prepare and check them.
Differential Revision: https://phabricator.services.mozilla.com/D21337
--HG--
extra : moz-landing-system : lando
If `aEvent` requires frame but there is no event target,
`PresShell::EventHandler::HandleEventInternal()` just records the response
time. So, we can reduce one indent level in the big method.
Note that I'm not sure recording the response time in such case because
the *good* values may make the average and median better. But this is
out of scope of bug 1466208.
Differential Revision: https://phabricator.services.mozilla.com/D21336
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` needs to accumulate event
handling time per each event type. The handling start time needs to be
recorded before sending EventStateManager. Therefore, this patch makes the
helper class which is a stack class, records current time at construction
and calls `Telemetry::AccumulateTimeDelta()` at destruction automatically.
Differential Revision: https://phabricator.services.mozilla.com/D21335
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` recodes event handling
response performance with telemetry after it dispatches the event. We can move
it into new method simply.
Differential Revision: https://phabricator.services.mozilla.com/D21334
--HG--
extra : moz-landing-system : lando
We really only have two sets of prefs, one for chrome-like documents
(stuff in chrome docshells + chrome-origin images), and one for the rest.
Differential Revision: https://phabricator.services.mozilla.com/D20946
--HG--
extra : moz-landing-system : lando
The remaining part of `PresShell::EventHandler::HandleEvent()` does:
1. Handles the event at focused content.
2. Handles the event with given frame which is a frame for `mPresShell`.
For making them clearer, this patch moves them into new methods.
Differential Revision: https://phabricator.services.mozilla.com/D21197
--HG--
extra : moz-landing-system : lando
If focused element is in another document,
`PresShell::EventHandler::HandleEvent()` needs to retarget the event to another
`PresShell`. This patch moves the case into new overload method,
`MaybeHandleEventWithAnotherPresShell()`.
Additionally, removes `PresShell::HandleRetargetedEvent()` and makes
`EventHandler::HandleRetargetedEvent()` non-public because the new method
is the only user of them.
Differential Revision: https://phabricator.services.mozilla.com/D21196
--HG--
extra : moz-landing-system : lando
With splitting `HandleEvent()` a lot, it becomes more difficult to keep
managing each set of calling `PushCurrentEventInfo()` and
`PopCurrentEventInfo()`. So, `EventHandler` should have a helper class
to push and pop current event info into/from the stack.
Differential Revision: https://phabricator.services.mozilla.com/D21198
--HG--
extra : moz-landing-system : lando
Most remaining code in `PresShell::EventHandler::HandleEvent()` is what computes
event target of the event which should be handled on focused content. This
patch moves the part to the new method.
Additionally, moves `nsIPresShell::gKeyDownTarget` to
`EventHandler::sLastKeyDownEventTargetElement` and make it use `StaticRefPtr`.
Finally, for using `Element*` instead of `nsIContent*`, changes the result type
of `Document::GetUnfocusedKeyEventTarget()` to `Element*`.
Differential Revision: https://phabricator.services.mozilla.com/D21195
--HG--
extra : moz-landing-system : lando
nsIconChannel (for moz-icon:// images) is unsound, see bug 1438939.
nsMenuPopupFrame::Init is also unsound on mac, looks like...
I'll try to get them fixed on trunk, but it's not worth crashing release for
this IMO, given it's pre-existing. The assert in PresShell::~PresShell hopefully
avoids exploitable issues.
Differential Revision: https://phabricator.services.mozilla.com/D20945
--HG--
extra : moz-landing-system : lando
When the event is not handled with coordinates and there is no frame for
`mPresShell`, `PresShell::EventHandler::HandleEvent()` handles the events
simpler than the case there is a frame. Therefore, this patch moves the
`else` block of `if (aFrame)` and reduce the indent of `if (aFrame)` case.
Differential Revision: https://phabricator.services.mozilla.com/D21194
--HG--
extra : moz-landing-system : lando
Now, the block in HandleEvent(), which handles event using coordinates is
less than 200 lines. Perhaps, this is good amount to be split to a method.
This patch just moves the block to a new method.
Differential Revision: https://phabricator.services.mozilla.com/D21193
--HG--
extra : moz-landing-system : lando
After dispatching pointer events, `PresShell::EventHandler::HandleEvent()`
updates event target only when the event is a touch event. We should do it in
a new method of `EventTargetData`.
Although I don't know why this is done in
`PresShell::EventHandler::DispatchPrecedingPointerEvent()`.
Differential Revision: https://phabricator.services.mozilla.com/D21192
--HG--
extra : moz-landing-system : lando
Now, we can move the block dispatching preceding pointer event to separated
method. Then, we can hide the complicated retarget process after dispatching
a pointer event from HandleEvent().
Differential Revision: https://phabricator.services.mozilla.com/D21191
--HG--
extra : moz-landing-system : lando
Currently, PresShell::EventHandler::HandleEvent() sets `overrideClickTarget`
only when Pointer Events is enabled and there is pointer capturing content,
and this is computed while dispatching a pointer event.
So, if we move it into EventTargetData, we can move the pointer event
dispatching block into a separated method and caller can receive it with
an EventTargetData instance which is anyway necessary to receive new
target frame after dispatching a pointer event.
Differential Revision: https://phabricator.services.mozilla.com/D21190
--HG--
extra : moz-landing-system : lando
We cannot move each block into separated methods while computing EventTargetData
because we need to check capturing contents, etc. Therefore, only each block
should be moved to separated methods for now.
This moves a block which computes event target from point of the event. If
this can be moved to EventTargetData, it might be easier to understand, but
its helper method GetFrameToHandleNonTouchEvent() requires to access members
of EventHandler. Therefore, we need to treat EventTargetData as an out param
of the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21189
--HG--
extra : moz-landing-system : lando
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
--HG--
extra : moz-landing-system : lando
This patch moves the block to compute event target of the event using
coordinates into the new method of PresShell::EventHandler::EventTargetData.
Differential Revision: https://phabricator.services.mozilla.com/D19320
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
Just for my sanity. I think the other scroll observer is sane after a quick
look, but this will ensure we don't ship security issues.
Differential Revision: https://phabricator.services.mozilla.com/D19725
--HG--
extra : moz-landing-system : lando
Now, we can create methods to update event target into EventTargetData().
This moves a block in PresShell::EventHandler::HandleEvent() to retarget
to active document into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D19318
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() looks for PresShell, nsIFrame and
nsIContent a lot for aGUIEvent. Sometimes part of them are modified,
otherwise, all of them are modified by some reasons. Therefore, for
splitting each of the modifiers into separated methods, we need a struct
for making them as a group and usable for in/out parameter.
(If you have some ideas of better name, let me know.)
Differential Revision: https://phabricator.services.mozilla.com/D19317
--HG--
extra : moz-landing-system : lando
This patch moves the block, which discard or put the event into the delayed event
queue if handling event is a mouse event, to new method.
Differential Revision: https://phabricator.services.mozilla.com/D19301
--HG--
extra : moz-landing-system : lando
This patch splits the part handling event when there is pointer capturing
content but it does not have frame.
Differential Revision: https://phabricator.services.mozilla.com/D19300
--HG--
extra : moz-landing-system : lando
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::ComputeRootFrameToHandleEvent() computes root frame
to handle event with popup frame and/or capturing content. The former result
can be rewritten with the latter. So, for cleaning it up with early return
style, we need to split it to 2 methods.
Differential Revision: https://phabricator.services.mozilla.com/D18525
--HG--
extra : moz-landing-system : lando
In some reasons, handling event should be handled in specific frame even if
the coordinates are out of the frame. PresShell::EventHandler::HandleEvent()
computes it with popups, capturing content, etc. This patch moves the blocks
into new method for making HandleEvent() simpler.
Note that most of the code is just moved. The following patch will clean it
up.
Differential Revision: https://phabricator.services.mozilla.com/D18523
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() tries to flush pending animation first
when it decides frame to handle events using coordinates. This patch moves
the code into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D18522
--HG--
extra : moz-landing-system : lando
There is an unclear variable `frame` in PresShell::EventHandler::HandleEvent().
It's overwritten with different frame and its meanings is changed sometimes.
Finally, it's necessary only in the `if (aGUIEvent->IsUsingCoordinates())`
block. Therefore, we can move it into the block and rename it when them for
each purpose.
Differential Revision: https://phabricator.services.mozilla.com/D18521
--HG--
extra : moz-landing-system : lando
Both of reftests in this commit are based on an exmaple [1] in the Viewports
Explainer written by David Bokan.
position-fixed-out-of-view.html fails without the fix because the position:fixed
element is rendered at the right edge of the visual viewport so that it's
visible in the first place.
position-fixed-on-minimum-scale-size.html does NOT fail without the fix either
because the position:fixed element sticks at the right edge of the visual
viewport so that it still be there even after the visual viewport offset has
been changed.
[1] https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md#chrome-2
Differential Revision: https://phabricator.services.mozilla.com/D18797
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() discards or puts off to dispatch
the handling event if it's a keyboard event and event dispatching is
suppressed by the document.
This patch moves the block into the new method for making HandleEvent() simpler.
Differential Revision: https://phabricator.services.mozilla.com/D18520
--HG--
extra : moz-landing-system : lando
Summary:
Flushing it at a bad time can cancel loads whose timer / completion
handler is in progress, which makes no sense.
Reviewers: jfkthame, jwatt, heycam
Tags: #secure-revision
Bug #: 1523181
Differential Revision: https://phabricator.services.mozilla.com/D17856
It may not be safe to handle events even when
PresShell::EventHandler::HandleEvent(). In such case, we need to discard
received events with notifying somebody. This patch move this rare case
jobs into the new method, MaybeDiscardEvent(). Then, the caller, HandleEvnet(),
becomes easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D16960
--HG--
extra : moz-landing-system : lando
Let's move the redirection of coming event in
PresShell::EventHandler::HandleEvent() into a method. This makes the caller
easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D16959
--HG--
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--HG--
extra : moz-landing-system : lando
Next, we need to look for a frame for first parameter of calling
PresShell::HandleEvent() of another PresShell instance. This patch creates
PresShell::EventHandler::GetFrameForHandlingEventWith() to do it.
Unfortunately, the result is used in 3 patterns. One is, the caller should
stop handling the event. Another one is, the caller should keep handling
the event by itself. The other is, the caller should call
PresShell::HandleEvent() of different PresShell instance. Therefore, this
patch makes the method take aFrame of the caller. Then, the caller can check
the last 2 patterns with check the result is same as aFrame. This is not so
smart approach, but I have no better idea without adding a bool argument or
making the return type bool and adding out argument of nsIFrame.
Differential Revision: https://phabricator.services.mozilla.com/D16957
--HG--
extra : moz-landing-system : lando
In some cases, PresShell::EventHandler::HandleEvent() needs to call
HandleEvent() of another instance.
For retrieving the instance, we need to compute retarget document first.
This patch makes new method to retrieve it. The following patch will clean
up it.
Differential Revision: https://phabricator.services.mozilla.com/D16955
--HG--
extra : moz-landing-system : lando
PresShell::HandleEvent() treats capturing content only when received event is
related to pointing device. And it's used in 2 purposes. One is for computing
to target document of coming event. The other is for handling events using
coordinates. Therefore, if we create a helper method to retrieve it, we can
move the variable into smaller blocks.
Differential Revision: https://phabricator.services.mozilla.com/D16954
--HG--
extra : moz-landing-system : lando
Because of spinning out from PresShell::EventHandler::HandleEvent(), we can use
early-return style in MaybeHandleEventWithAccessibleCaret(). This patch
rewrites MaybeHandleEventWithAccessibleCaret() with the style.
Differential Revision: https://phabricator.services.mozilla.com/D16953
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() is too big. That makes us difficult to
understand the flow of them. So, first of all, we should split the method to
smaller chunks. Then, we can understand what we're doing in HandleEvent() more.
This patch creates MaybeHandleEventWithAccessibleCaret() for first handling
block in HandleEvent(). Note that the following patch will clean it up.
I.e., this patch just moves the existing block into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D16952
--HG--
extra : moz-landing-system : lando
PresShell::HandleEvent() and PresShell::HandleEventInternal() are too big.
Additionally, we have a lot of methods used only by them. So, if we'll
split those big methods, PresShell will have a lot of small methods which
are not grouped as a part of event handling. That's too bad because some
of them may depend on the calling order, etc.
So, for grouping them, PresShell should create a stack class instance to handle
each event. Then, we can store shared information in it only while we're
handling an event.
This patch creates PresShell::EventHandler and PresShell methods become
wrappers of the stack class, but this patch does not change any logic in the
code, i.e., just reorganizing existing methods.
Note that HandleEventWithTarget() and HandleEventInternal() need to take
WidgetEvent rather than WidgetGUIEvent. Additionally, some other methods
require WidgetGUIEvent to refer WidgetGUIEvent::mWidget. Therefore, this
patch does not make the new class store the event as a member.
Differential Revision: https://phabricator.services.mozilla.com/D16951
--HG--
extra : moz-landing-system : lando
I think this is slightly better fix given the amount of offenders we have that
don't make sure this is the case.
Generally we get through the flush just fine, but there's code that relies on
nsIDocument::GetShell to return something meaningful, like the styleset code
that gets a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D14689
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Performance of sync animation with large images is worse with WebRender than non-WebRender case. We want to use async animation as much as possible and relax aysnc animation size restriction. With WebRender, memory usage increase for async animation is limited compared to non-WebRender case. Image does not needs additional TextureClient allocation for async animation and majority of frames are comverted to WebRenderCommands. Then we could relax aysnc animation size restriction with WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D16791
--HG--
extra : moz-landing-system : lando
We currently perform anchor adjustment in three spots:
1. If the target of RestyleManager::RecomputePosition is in a scroll anchor chain
2. If the reflow root is in a scroll anchor chain
3. In nsHTMLScrollFrame::DidReflow, for itself
It looks like it's possible for a scroll anchor container to be adjusted by (1)
and (2 or 3) in the same PresShell flush.
This should be okay, except that we consume mSuppressAnchorAdjustment when
performing an adjustment, and this can lead us to miss the second time that
we perform adjustments in a PresShell flush.
This commit reworks how we run anchor adjustments so that we collect all
scroll anchor containers that should be adjusted, and only perform the
adjustments once.
Differential Revision: https://phabricator.services.mozilla.com/D16407
--HG--
extra : source : cbdbd08379d99f9d55f756c57d728c28331be5da
To reproduce, execute
"GECKO_FRAMECTOR_DEBUG_FLAGS=really-noisy-content-updates ./mach run".
nsIFrame::List()'s second argument should be a const char*, not an
integer. We can fix the bug by omitting it because the default value of
the argument is an empty string.
Differential Revision: https://phabricator.services.mozilla.com/D16075
--HG--
extra : moz-landing-system : lando
This allows us to e.g. avoid sending a value that's (0,0) because it hasn't
been set yet in a visual scroll update.
Depends on D16346
Differential Revision: https://phabricator.services.mozilla.com/D16477
--HG--
extra : moz-landing-system : lando
We only ever add a single sheet (EditorOverride.css) there anyway.
Depends on D16282
Differential Revision: https://phabricator.services.mozilla.com/D16283
--HG--
extra : moz-landing-system : lando
So that the caller doesn't have to retrieve and compare the previous viewport
offset himself.
Differential Revision: https://phabricator.services.mozilla.com/D15785
--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
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
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
If there is no scrollable frame, PresShell::GetScrollableFrameToScroll() returns
nullptr. However, even when we don't expand selection, we need to move caret
in current selection root. Therefore, it should call
nsFrameSelection::CommonPageMove() with the result of
nsFrameSelection::GetFrameToPageSelect() to move caret.
Differential Revision: https://phabricator.services.mozilla.com/D16020
--HG--
rename : layout/base/tests/test_expanding_selection_per_page.html => layout/base/tests/test_moving_and_expanding_selection_per_page.html
extra : moz-landing-system : lando
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 9d40a5d5b73777d0da3799f162eeb85bb8e6d8f0
extra : source : d9052f7b34d9857863b66d64797f8b0b82504bec
This commit adds a mechanism for scroll anchor containers to request an anchor
node selection at a future time. Currently this is before styling so that anchor
adjustment suppression will have current anchor nodes.
Differential Revision: https://phabricator.services.mozilla.com/D13269
--HG--
extra : rebase_source : 7af2dcc7953e446eb993625fa7ff32aa5a141eab
extra : source : e7124fecb7215769a5404c5f2268bbe715162393
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.
There is no reason to use nsAtoms*, it's error prone, i.e. the function
can take arbitrary nsAtoms*.
Depends on D15339
Differential Revision: https://phabricator.services.mozilla.com/D15340
--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
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
This changes the semantics of the relative visual viewport offset calculation in
the PresShell slightly, in that a missing root scroll frame will no longer
force the relative offset to zero, even if the visual viewport itself has a non-
zero scroll position [1].
On the other hand, the visual viewport's own relative offset calculations
already work that way today, in that layout and visual viewport scroll positions
are retrieved separately and then subtracted from one another regardless of
whether those values are actually valid or merely a fallback because the
PresShell/scroll frame weren't available.
[1] Though I'm not sure under what circumstances this could really be relevant.
Differential Revision: https://phabricator.services.mozilla.com/D14686
--HG--
extra : moz-landing-system : lando
Internally, Gecko stores and updates the *absolute* offset between the visual
viewport and the page, however the spec demands that the scroll event be fired
whenever the *relative* offset between visual and layout viewport changes.
Differential Revision: https://phabricator.services.mozilla.com/D14044
--HG--
extra : moz-landing-system : lando
The event rate throttling mechanism is modelled on the logic for "scroll" events
in nsGfxScrollFrame.cpp.
That is
1. When a request to fire an event is posted to the VisualViewport, we create a
new runnable for this and register it with the RefreshDriver. If we already
have a pending runnable, calling VisualViewport->Post...Event() becomes a
no-op.
2. When the RefreshDriver is ready, it executes the runnable, which in turn
fires the actual event and then cleans itself up.
To keep this patch manageable, we simply fire a scroll event every time the
stored visual viewport offset is changed. Because we are storing the absolute
offset of the viewport relative to the page, this behaviour doesn't match the
spec, which demands that scroll events are fired only when the relative offset
between visual and layout viewport changes. We'll fix this up in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D14043
--HG--
extra : moz-landing-system : lando
The following APIs are changed.
1. Contains() needs to become contains(). (EnumSet's methods have lowercase names.)
2. Use list constructor rather than "|" like a plain enum.
3. Use operator+= instead of operator|=.
Differential Revision: https://phabricator.services.mozilla.com/D14908
--HG--
extra : moz-landing-system : lando
When popping a dirty root, take the shallowest one first (so we reflow from
outer frames first, to avoid potential duplicate reflow of inner frames).
Prevent duplicate roots (to be reworked in a future bug).
Differential Revision: https://phabricator.services.mozilla.com/D9490
--HG--
extra : moz-landing-system : lando
As mDirtyRoots will be accessed through a more cohesive API, this patch hides
the storage details (nsTArray) -- but provides almost the same API for now.
Differential Revision: https://phabricator.services.mozilla.com/D9489
--HG--
extra : moz-landing-system : lando
All of the removed includes are redundant (i.e. they're #included elsewhere in
the same file).
In most cases, I'm removing the second (redundant) copy of the
#include, except when that copy makes more sense (i.e. if it's in better sorted
order, or if it's paired alongside a closely-associated header while the
earlier copy is not).
Here's the script that I used to generate candidates here -- I ran this in
every subdirectory of layout, on my linux machine (warning, this writes two
files to your /tmp directory):
for FILE in *.h *.cpp; do
nonunique=$(grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | wc -l)
unique=$( grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq | wc -l)
if [[ "$unique" != "$nonunique" ]]; then
echo "$FILE: $nonunique / $unique"
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort > /tmp/nonunique.txt
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq > /tmp/unique.txt
diff /tmp/nonunique.txt /tmp/unique.txt
echo
fi
done
Depends on D13773
Differential Revision: https://phabricator.services.mozilla.com/D13774
--HG--
extra : moz-landing-system : lando
The tracking is done using nsAtom origins, similarly to how updates to the
scroll offset are tracked.
Currently, APZ still uses some heuristics to deduce that the main thread
originated a resolution change in some cases, but the intention is to try
to remove those and rely only on this mechanism in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13741
--HG--
extra : moz-landing-system : lando
Basically, we shouldn't have blacklist to disable web API. However, the
keypress event behavior changes are not standardized things. Therefore,
if some web developers realize that they need to change their apps when
it's too late for them, Firefox users need to use another browser for
such web apps for several weeks or more, and such things may make the users
switch their default browser. For avoiding such worst scenario, we should
take the blacklists and if we get such compatibility reports, we should
add the domains into the blacklist even in release channel.
Differential Revision: https://phabricator.services.mozilla.com/D13374
--HG--
extra : moz-landing-system : lando
Can't land the test-case from bug 1510208 as a crashtest because it needs you to
move the mouse around, and as such it doesn't crash in the crashtest harness.
Differential Revision: https://phabricator.services.mozilla.com/D13054
--HG--
extra : moz-landing-system : lando
In each file touched by this commit, there were no mentions of nsAutoPtr
besides the #include.
I verified that the folder layout/base still builds successfully in
non-unified mode after this patch, too. So, none of these files are secretly
using nsAutoPtr and depending on some other .cpp file to provide the header.
Differential Revision: https://phabricator.services.mozilla.com/D12993
--HG--
extra : moz-landing-system : lando
When popping a dirty root, take the shallowest one first (so we reflow from
outer frames first, to avoid potential duplicate reflow of inner frames).
Prevent duplicate roots (to be reworked in a future bug).
Differential Revision: https://phabricator.services.mozilla.com/D9490
--HG--
extra : moz-landing-system : lando
As mDirtyRoots will be accessed through a more cohesive API, this patch hides
the storage details (nsTArray) -- but provides almost the same API for now.
Differential Revision: https://phabricator.services.mozilla.com/D9489
--HG--
extra : moz-landing-system : lando
LocalStorage needs to be exposed in every context except for sandboxes and
NullPrincipals (data: URLs, for instance). But we need to keep data
separate in some scenarios: private-browsing and trackers.
In private-browsing, LocalStorage keeps data in memory, and it shares
StorageEvents just with other origins in the same private-browsing
environment.
For Trackers, we expose a partitioned LocalStorage, which doesn't share
data with other contexts, and it's just in memory. Partitioned localStorage
is available only for trackers listed in the
privacy.restrict3rdpartystorage.partitionedHosts pref. See
nsContentUtils::IsURIInPrefList to know the syntax for the pref value.
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
In case fuzzers or somebody can catch this in a reproducible way...
I'd be interested in knowing what the hell is going on.
Differential Revision: https://phabricator.services.mozilla.com/D11053
--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
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
PresShell::PageMove() climbs up to parent document when there is no scrollable
parent in current document. However, if aExtend is true, it should expand
Selection in the document itself. Therefore, it needs different rules to
look for container of expanding Selection from scrollable element to scroll.
Additionally, old rules (i.e., before the fix of bug 1369072 which caused
this regression) were also buggy. It used parent scrollable element or
root scrollable element simply. Therefore, if found scrollable element is
ancestor of selection limiter, it didn't work as expected.
This patch creates nsFrameSelection::GetFrameToPageSelect() to retrieve
per-page selection container element with the following rules:
- look for a scrollable element in selection limiter.
- if there is no scrollable element, use selection limiter.
- if there is no selection limiter, use the root frame.
So, nsFrameSelection::CommonPageMove() should take nsIFrame rather than
nsIScrollableFrame since container of per-page selection may be used in
non-scrollable contenteditable element. If it's called with non-scrollable
frame, it needs to compute the expanding range with the frame size.
Differential Revision: https://phabricator.services.mozilla.com/D8954
--HG--
extra : moz-landing-system : lando
nsRefreshDriver::ObserverArray is a nsTObserverArray which is
infallible, so no need to check the return value from AppendElement
(which a later patch in this series will remove).
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
It can flush the parent document from MediaQueryList::RecomputeMatches, which
can destroy our pres context.
I think that flush is wrong btw, it should probably either flush layout so the
viewport size is correct, or just not flush (we should make MediaList::Matches
take a document now that we don't need a pres context to match media queries,
but that requires a bit more refactoring).
Differential Revision: https://phabricator.services.mozilla.com/D5524
AccessibleCaretEventHub is an nsISelectionListener of Selection whose type is
"normal". This is added only when nsFrameSelection::Init() is called and
accessible caret is enabled. Additionally, nsFrameSelection::Init() is
always called immediately after creating nsFrameSelection.
Therefore, when AccessibleCaretEventHub is installed to Selection, this is
always second selection listener and won't be installed multiple times. So,
Selection can store pointer of AccessibleCaretEventHub directly only when
it's enabled and the Selection needs to notify it of selection change.
This patch makes Selection stores AccessibleCaretEventHub with RefPtr, then,
makes Selection::NotifySelectionListeners() call its OnSelectionChange()
immediately after AutoCopyListener.
Unfortunately, this patch includes making of MOZ_CAN_RUN_SCRIPT_BOUNDARY and
MOZ_CAN_RUN_SCRIPT a lot since some methods of AccessibleCaretEventHub are
marked as MOZ_CAN_RUN_SCRIPT and including AccessibleCaretEventHub.h into
Selection.h causes compile the compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D4733
--HG--
extra : moz-landing-system : lando
When CSS rules change, we usually do this implicitly from FlushUserFontSet & co.
However there's a code path that dirties the stylist but not the CSS rules, and
that's when the compat mode changes and we're an SVG document.
I don't think that can get hit (easily, at least?), but it's pretty easy to do
so and I think this is cleaner too.
This fixes that case so the stylist can't assert in that case either, and so
that we still rebuild the cascade data so that the hash maps use the right keys
for a given quirks-mode.
Differential Revision: https://phabricator.services.mozilla.com/D4361
The regressing bug made RepaintSelectionRunner do nothing for any
nsISelectionListener that wasn't a PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D2846
--HG--
extra : moz-landing-system : lando
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
Including refactoring mDirtyRoots into nsIPresShell to avoid virtual call.
MozReview-Commit-ID: KxST8FMsZl9
--HG--
extra : rebase_source : 1be1a8065815bb1e67293c7839c6e9189fc693bc
Summary:
This fixes a couple fuzz bugs and prevents special-casing <svg:use> even more in
bug 1431255.
Unfortunately not as many hacks went away as I'd have hoped, since we still need
to match document rules, see the linked SVGWG issues.
But blocks_ancestor_combinators goes away, which is nice since it's on a very
hot path.
Test Plan: WPT for style invalidation, covered by existing tests otherwise.
Reviewers: heycam
Tags: #secure-revision
Bug #: 1450250
Differential Revision: https://phabricator.services.mozilla.com/D2154
MozReview-Commit-ID: C4mthjoSNFh
Currently, if an event is consumed in the main process, EventStateManager
does not send it to remote process. However, this is unexpected behavior
for some WidgetKeyboardEvent dispatchers. OS sometimes has consumed native
key events before sending applications. For example, Alt key on Windows
should activate menu bar of focused window but Alt key may be consumed before
focused window receives the event. In such case, we mark Alt keyboard event
as "consumed before dispatch", and chrome treat it like as its preventDefault()
is called in web content. (Note that for compatibility with other browsers,
the consumed state is not exposed to web content. So, Event.defaultPrevented
returns false in web content.)
Therefore, we need to treat "consumed" state and "cross process forwarding"
state separately. This patch makes calling WidgetEvent::PreventDefault()
always stops cross process forwarding for backward compatibility. Additionally,
for the special case mentioned above, this patch makes
WidgetEvent::PreventDefaultBeforeDispatch() take additional argument,
|aIfStopCrossProcessForwarding|. If this is CrossProcessForwarding::eStop,
the event won't be sent to remote process as same as calling PreventDefault().
Otherwise, CrossProcessForwarding::eHold, PreventDefaultBeforeDispatch() call
does not change "cross process forwarding" state. I.e., if the event's
StopCrossProcessForwarding() and PreventDefault() are not called until
EventStateManager::PostHandleEvent(), the event will be sent to remote process
as usual.
MozReview-Commit-ID: IQGWJvXetxV
--HG--
extra : rebase_source : 4ccdd500e80b8fe29e469ac3b85578e1c07c8358
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
--HG--
extra : rebase_source : 7d6f739b7fb58a46e1624ba62e717412057ea9c1
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
They're empty, and make PresShell::BeginUpdate useless. Now we don't have
document observers that listen for these anymore.
MozReview-Commit-ID: GpDDNonFUFC
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly.
However, some web apps actually broken with the standardized behavior. For
protecting testers from known broken web apps, this patch introduces a
blacklist to take the traditional behavior under specific domain (and path in
it, optionally). Currently, docs.google.com and mail.google.com are set by
default.
MozReview-Commit-ID: HSrYX8LUB0p
--HG--
extra : rebase_source : a2677d07410af289534db051767543a25c9a957a
Masayuki Nakano
Boris Zbarsky
Emilio Cobos Álvarez
Gurzau Raul
Timothy Nikkel
Noemi Erli
Ciure Andrei
Markus Stange
Sylvestre Ledru
Ryan Hunt
Hiroyuki Ikezoe
Razvan Maries
garvitdelhi
Cosmin Sabou
Bobby Holley
Csoregi Natalia
Greg Tatum
sotaro
Ting-Yu Lin
Oana Pop Rus
Botond Ballo
Cameron McCormack
Jan Henning
Daniel Varga
Jeff Muizelaar
Margareta Eliza Balazs
Ehsan Akhgari
Neil Deakin
Brian Hackett
Bogdan Tara
Ting-Yu Lin
Andrea Marchesini
longsonr
L. David Baron
Gerald Squelart
Brindusan Cristian
Miko Mynttinen
Daniel Holbert
Dorel Luca
Jeff Muizelaar
Nazım Can Altınova
Mats Palmgren
Edgar Chen
Brad Werth
Andrew McCreight
Ryan VanderMeulen
Jeremy Lempereur
Xidorn Quan
Dan Glastonbury
Mike Conley
Andi-Bogdan Postelnicu
Olli Pettay
Chris Peterson
arthur.iakab
Adrian Wielgosik
Kartikaya Gupta
Sebastian Hengst
Tristan Bourvon
Jonathan Watt