This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
nsIPresShell.h is widely included, so this avoids excessively long rebuilds
when MobileViewportManager.h is modified.
Differential Revision: https://phabricator.services.mozilla.com/D26245
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
This is the last step to be able to call matchMedia on display: none iframes.
This is green, except for some startup preference query tests that I'm going to
address in a blocking bug (making LangGroupFontPrefs global, basically).
The setup is similar to the ShadowRoot one, except we don't eagerly keep the
StyleSet around up-to-date, we only fill it if it ever had a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D23903
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
This allows this enumeration to be used from nsIPresShell.h without introducing
a circular dependency.
Its new home in layout/base/ScrollTypes.h, included as mozilla/ScrollTypes.h.
Others similar enums can be added to that file if desired.
This patch also makes ScrollMode an enum class (as it's no longer nested
inside a class) and switches its enumerators to the |eName| naming convention.
Differential Revision: https://phabricator.services.mozilla.com/D24796
--HG--
extra : moz-landing-system : lando
The only caller of `TouchManager::PreHandleEvent()` is
`PresShell::EventHandler::HandleEventWithCurrentEventInfo()` which is guaranteed
that it never handles untrused event by bug 1536353. Therefore, we can make
`PresShell::EventHandler::PrepareToDispatchEvent()` call it instead. That's
better place from the point of view of semantics and making
`PresShell::EventHandler::PrepareToDispatchEvent()` simpler.
Note that this may cause changing the score of a telemetry probe,
"INPUT_EVENT_QUEUED_APZ_TOUCH_MOVE_MS" because it will include the time of
the runtime cost of `TouchManager::PreHandleEvent()` when the event is an
`eTouchMove` event and handled by APZ. However, this was expired in 60.
So, we don't meet any changes with this patch actually.
Differential Revision: https://phabricator.services.mozilla.com/D24133
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
--HG--
extra : moz-landing-system : lando
Now, other methods taking `aFrame` of `HandleEvent()` names the argument as
`aFrameForPresShell`. So, `HandleEvent()`'s `aFrame` should also be renamed.
This patch renames it and adds MOZ_CAN_RUN_SCRIPT and comment to
`nsIPresShell::HandleEvent()`.
This is the final patch for bug 1466208.
Differential Revision: https://phabricator.services.mozilla.com/D22463
--HG--
extra : moz-landing-system : lando
In my understanding, `PresShell::EventHandler::HandleEvent()` may redirect
the event to another class or PresShell first. Otherwise, it computes
event target and sets current event info of mPresShell to it. Then, calls
`HandleEventInternal()` to dispatch the event. Then, `HandleEventInternal()`
may handle the event before dispatch, and/or prepare to dispatch, then,
finally dispatches the event and finalize the state of mPresShell and the
event. Therefore, `HandleEventInternal()` actually handles the event, but
the word, "internal" is not explicitly explain its different points from
`HandleEvent()`. Therefore, I think that `HandleEventWithCurrentEventInfo()`
is better name since `HandleEvent()` considers the current event info.
Differential Revision: https://phabricator.services.mozilla.com/D22462
--HG--
extra : moz-landing-system : lando
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
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
`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
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
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
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
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
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
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
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
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
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
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
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
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 : ba621678b697847e59203444d7b6b0e737742675
extra : histedit_source : b0c6f8642a01bd8ded312d0fa27eecd55c4422a9
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
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
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
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
Including refactoring mDirtyRoots into nsIPresShell to avoid virtual call.
MozReview-Commit-ID: KxST8FMsZl9
--HG--
extra : rebase_source : 1be1a8065815bb1e67293c7839c6e9189fc693bc
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
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
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
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
It is no longer used, and removing this from ServoStyleSet allows us to
remove dependency from ServoStyleSet.h to StyleSheetInlines.h.
MozReview-Commit-ID: HzYNulJF7tf
--HG--
extra : rebase_source : f54811369fd7af27b2ee61d54143726e473c6640
extra : source : f872ca0df2d0a71508eeba67c2b922b87bdcbe01
The nsCSSFrameConstructor bits are now handled in PresShell::Destroy along with
the other refresh driver observers.
I cleaned up the nsRefreshDriver methods because they were using infallible
append anyway, and that simplified the logic.
MozReview-Commit-ID: 1eDUUXjUUS9
PresShell only uses performane.now to track refresh times, and notify internal
observers. We can provide more accurate times by not clamping and jittering
these numbers.
MozReview-Commit-ID: FkDGJhrLeAy
--HG--
extra : rebase_source : 99c571d1e5df53f51b4be0304df3818c161d2972
This code was originally added to debug the frame visibility code.
However it wasn't architected correctly and makes the compositor use an
untrusted layers id from content. Instead of fixing this I'd rather just
delete it, since it's a big pile of code that is basically a debugging
tool that nobody owns anymore.
MozReview-Commit-ID: nPZqVeYsFp
Summary:
* Remove unnecessary virtual, since we also override.
* Remove unnecessary mozilla:: qualification, since we are in the mozilla
namespace already.
* Avoid inconsistently-followed member-variable indentation.
* Make the destructor not virtual, since it doesn't override anything and this
is a final class (the destructor is called from the virtual Release()).
Reviewers: dholbert
Bug #: 1443753
Differential Revision: https://phabricator.services.mozilla.com/D690
MozReview-Commit-ID: Hy2aKuhoOKd
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
--HG--
extra : rebase_source : 0fcd0ed461856c1e87e45ef63c9e1d2e81281469
The event targets of touch events are not necessarily to be the same as their corresponding pointer events. So we don't have to cache the event target of pointer events when they are generated from touch.
MozReview-Commit-ID: 9Gd6ion7NXf
This makes the pres shell be notified as the last observer unconditionally.
In practice this doesn't matter, and it may already be the case if an iframe
goes display: none and back. In practice, the only dependency that requires this
order is that the pres shell needs to be notified _after_ the content sink, so
we don't try to enter frame construction before beginning the shell update.
That may be worth looking into, but definitely not in the scope of this bug... :)
MozReview-Commit-ID: 9WeJ5kaUtBq
--HG--
extra : rebase_source : 6589df0aa8a875dc270894fabb6b4bc170d6b6fe
This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
I'm drive-by removing the comment about the frame tree state because I looked
into it, and the answer is: we properly restore it.
The gotcha is that we retain it too much, indeed, we retain it enough that it
can leak. See bug 1397239.
MozReview-Commit-ID: LP6bXkduEZ4
--HG--
extra : rebase_source : f7e18fc35e48b75c07fcc84b939614d379926828
After the fix to bug 1294442 and bug 1324499, ResizeReflow began to be called
twice for each DOM update in webext popups, and we also artificially re-set the
scroll outside of ResizeReflow to counter the DidDoReflow callback in
nsHTMLScrollFrame setting scrolltop to zero due to the first reflow, which is
done with unconstrained height.
Because of the scrollport being reset we get spurious DOM scroll events.
Replacing the scrollport also interrupts smooth scrolling.
Move the double-reflow down one level into PresShell, doing it before
DidDoReflow is called. The scrollport is no longer reset (causing a spurious
scroll event), and we don't need to replace it (interrupting smooth scrolling).
Also partially fixes bug 1396034.
MozReview-Commit-ID: HzYITyH4UeW
--HG--
extra : rebase_source : 567056300bc81c9e4c197783f48636caf67cde34
extra : intermediate-source : ef7322dfd99d79a403bb0804638a46c70ece1b45
extra : source : 4f1761bb955473026b4deba76a5e76e93b7ede35
For parent process, users may expect the UI is interactable after they saw the
first tab has restored/shown.
So this patch added a new topic "sessionstore-one-or-no-tab-restored" which
represents the parent process has finished a tab restoring. If there is nothing
to restore, it is effectively equal to "sessionstore-windows-restored".
For centent processes, users may expect web content is interactable when the
top-level-content-document has finished loading, which is different from the
parent case.
MozReview-Commit-ID: AtEUW80Ea6n
--HG--
extra : rebase_source : d920975bf95545ea9e3127d3f570b814fe301be9
There's only one case of sync frame construction from ContentRemoved now, and
it's not on the element being removed, but on the whitespace siblings if needed,
and _only_ when they don't support lazy frame construction.
Basically, this switches all the RecreateFramesForContent calls to use
`aAsyncInsert` (which I changed to an enum class for readability), except when
we're already reframing.
Also, it switches ReframeTextIfNeeded to opt-in into lazy frame construction,
since it's used only when aFlags == CONTENT_REMOVED.
This allows to simplify the DestroyFramesFor API (which I'm happy to rename to
something more meaningful, since now it's something like
DestroyFramesForAndRecreateThemAsync), and do some other consistency cleanups.
A bunch of the ContentRemoved callsites were pretty random at passing
aAsyncInsert, and that was some kind of a mess. This patch ensures consistency,
and makes it impossible to do O(n^2) work when removing DOM nodes, which is
nice.
The underlying reason for this is explained in the description of bug 1377848,
and basically allows us to remove a bunch of Servo hacks on the longer term (a
few of them are going away already, yay!).
MozReview-Commit-ID: 2DrUTxGV8RX
--HG--
extra : rebase_source : f428d839a5482477dea22c0fea600d54f3e8799c
This patch does the following.
- Moves nsWindowSizes from nsWindowMemoryReporter.h to its own file,
nsWindowSizes.h, so it can be included more widely without exposing
nsWindowMemoryReporter.
- Merges nsArenaMemoryStats.h (which defines nsTabSizes and nsArenaMemoryStats)
into nsWindowSizes.h.
- Renames nsArenaMemoryStats as nsArenaSizes, and nsWindowSizes::mArenaStats as
nsWindowSizes::mArenaSizes. This is the more usual naming scheme for such
types.
- Renames FRAME_ID_STAT_FIELD as NS_ARENA_SIZES_FIELD.
- Passes nsWindowSizes to PresShell::AddSizeOfIncludingThis() and
nsPresArena::AddSizeOfExcludingThis(), instead of a bunch of smaller things.
One nice consequence is that the odd nsArenaMemoryStats::mOther field is no
longer necessary, because we can update nsWindowSizes::mLayoutPresShellSize
directly in nsPresArena::AddSizeOfExcludingThis().
- Adds |const| to a few methods.
MozReview-Commit-ID: EpgFWKFqy7Y
FocusTarget used to be needed in nsIPresShell, but it was moved to PresShell.
MozReview-Commit-ID: HQFpT9OJaUz
--HG--
extra : rebase_source : ddc29462fc71f8a71dd2419823ddf6f7e92a60ce
Masayuki Nakano
Botond Ballo
Emilio Cobos Álvarez
Dorel Luca
Csoregi Natalia
Cosmin Sabou
Olli Pettay
Oana Pop Rus
Boris Zbarsky
Ehsan Akhgari
Ryan Hunt
Bogdan Tara
Hiroyuki Ikezoe
Sylvestre Ledru
L. David Baron
Daniel Holbert
Edgar Chen
Brad Werth
Daniel Varga
Neil Deakin
Dan Glastonbury
Florian Quèze
Mike Conley
Ciure Andrei
Xidorn Quan
shindli
Tom Ritter
Kartikaya Gupta
Cameron McCormack
Stone Shih
Brindusan Cristian
James Willcox
angelsl
Wei-Cheng Pan
Michael Kaply
Nicholas Nethercote