Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : source : 088dc24eabc75eea96301d50550e0a8817f5f809
Once nsIPresShell::SetVisualViewportSize is called, we currently have
no way to restore the default viewport sizing behavior. This corrects that.
We need the default behavior to get correctly-placed scrollbars when
turning off meta viewport handling in Responsive Design Mode panes.
Differential Revision: https://phabricator.services.mozilla.com/D20593
--HG--
extra : source : 178210eb72baa05f877b3a35e0c94d0b23880d13
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
--HG--
extra : moz-landing-system : lando
Bug 1472637 makes the decision of whether to construct an image frame not depend
on this, so this is sound.
We need to avoid reframing to fix this bug because otherwise we lose track of
the previously painted image.
Differential Revision: https://phabricator.services.mozilla.com/D23127
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : moz-landing-system : lando
Once nsIPresShell::SetVisualViewportSize is called, we currently have
no way to restore the default viewport sizing behavior. This corrects that.
We need the default behavior to get correctly-placed scrollbars when
turning off meta viewport handling in Responsive Design Mode panes.
Differential Revision: https://phabricator.services.mozilla.com/D20593
--HG--
extra : moz-landing-system : lando
It took me a long time to understand why
KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to
KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that
while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more
generally useful. This will allow us to tidy up the various animation checks in
nsLayoutUtils later in this patch series.
Ultimately, however, we should make this check part of the regular compositor
animation vetting machinery in bug 1534884. That should remove a number of
inconsistencies such that we don't need the extended comments added in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D23281
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
And use correct AccessibleCaret preference to disable it individually in tests.
Differential Revision: https://phabricator.services.mozilla.com/D10299
--HG--
extra : moz-landing-system : lando
The assertion can be reproduced locally by running
"./mach test dom/canvas/test/chrome/test_drawWindow_widget_layers.html"
with layout.accessiblecaret.enabled=true.
When AccessibleCaret is enabled, caret elements will be inserted into
nsCanvasFrame::mCustomContentContainer, thus it recursively invokes
ConstructFramesFromItemList() to construct frames for carets before it had a
chance to construct popup group.
I feel it's too strict to assume that ConstructFramesFromItemList() cannot be
invoke recursively whenever there's a popup group item. I move the assertion to
the end of ConstructDocElementFrame() to ensure the popup group is processed by
then.
Differential Revision: https://phabricator.services.mozilla.com/D10298
--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
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
The test case triggers MOZ_ASSERT(!IsFramePartOfIBSplit(aParentFrame))
in MaybeRecreateForColumnSpan() because WipeContainingBlock() returns
early when the FrameConstructionItemList is empty. Thus, it doesn't wipe
the aParentFrame even if it's part of an IB split.
An empty FrameConstructionItemList constructs no frames. Therefore,
MaybeRecreateForColumnSpan() doesn't need to do anything if aFrameList is empty
since an empty frame list cannot contain any column-span.
Differential Revision: https://phabricator.services.mozilla.com/D23820
--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
The Timestamp implementation on Windows seems to be based off of two system APIs: GetTickCount64 and QueryPerformanceCounter. QPC seems to be preferred over GTC, unless a "failure" in QPC is detected.
There is code in the Timestamp implementation to detect if QPC "fails" be comparing elapsed time of QPC to elapsed time of GTC.
Through logging on try server I observed the following in different failures:
1) the QPC failure detection kicks in a lot and disables use of QPC
2) the QPC of the vsync timestamp was in the future compared to the QPC of TimeStamp::Now().
3) the QPC of TimeStamp::Now() was missing (presumably because it was disabled) and the GTC of the vsync timestamp was in the future compared to the GTC of TimeStamp::Now()
4) the vsync timestamp printf of raw GTC and QPC values matched at the source (SoftwareDisplay::NotifyVsync) and in the refresh driver, so the vsync timestamp wasn't getting messed up.
I guess we could spend more time on the error detection in our Windows TimeStamp code, but this failure is only happening on 32-bit machines.
Here's a patch to disable the assertions on 32-bit Windows. Depends how important we think this assertion is relative to the work to investigate more.
Differential Revision: https://phabricator.services.mozilla.com/D22453
--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
Since bug 1524480 we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit when needed
in RestyleManager::ProcessRestyledFrames so that it is now redundant to also set
it from KeyframeEffect.
Furthermore, setting frame bits from KeyframeEffect is a little fragile since it
depends on the life cycle of the KeyframeEffect which is independent of the
nsFrame. If we can avoid doing that, we probably should.
Differential Revision: https://phabricator.services.mozilla.com/D21885
--HG--
extra : moz-landing-system : lando
As with the previous patch in this series, we need to pay particular attention
to how we handle display:table content when detecting animations on a element.
Please see the extended description in that patch for an explanation of
different frame types involved.
As with transforms, our handling of opacity is also inconsistent. In
particular, we fail to return true from nsIFrame::HasOpacityInternal for
display:table content with opacity animations applied due to the conflicting
requirements for a primary frame and having opacity animations (which are stored
on the style frame).
Unlike transforms, however, we do not inherit the opacity to the table wrapper.
Instead we leave it on the inner table frame. As a result, we should not check
for a primary frame, but instead we should check for the style frame for the
primary frame.
This patch adjusts this handling to check instead for the appropriate style
frame as opposed to requiring a primary frame. It includes a reftest that fails
without the code changes in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D21884
--HG--
extra : moz-landing-system : lando
For display:table content we generate two frames: a table wrapper frame and an
inner table frame. The styles are applied to the inner frame (referred to as the
style frame), whilst the wrapper frame is the primary frame for the content.
However, in order to make tables with transforms behave as a container for
abspos/fixed-pos content as required by the spec, we apply the transform to the
wrapper frame (bug 722777) by inheriting the transform from inner to wrapper and
then ignoring the transform on the inner frame (bug 722777 and bug 816458).
When handling animations on table elements we need to be careful of this
distinction. in particular, css animations[1] and web animations[2] require that
when we have an unfinished transform animation targetting an element, the
element acts as if it had `will-change: transform` applied and therefore
generates a stacking context. As a result we need to accurately detect when
a frame should be considered as having transform animations applied to it or not
for the purpose of creating a stacking context.
Previously our handling of display:table content was quite inconsistent and
contradictory. For example, `nsIFrame::HasAnimationOfTransform` would check for
a primary frame AND for animations on that frame, despite the fact that we only
ever store animations on the style frame. As a result it could never return true
for either a table wrapper or inner table frame.
This patch attempts to make this handling at least a little more consistent,
producing the following result:
Outer table frame (primary frame):
nsIFrame::IsTransformed → true
nsIFrame::IsCSSTransformed → true
nsIFrame::HasAnimationOfTransform → true
nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → false
Inner table frame (style frame):
nsIFrame::IsTransformed → false
nsIFrame::IsCSSTransformed → false
nsIFrame::HasAnimationOfTransform → false
nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → true
We maintain that the NS_FRAME_MAY_BE_TRANSFORMED bit is only set on the primary
frame whilst the mMayHaveTransformAnimation flag is only set on the style frame.
Note that we don't simply always put everything on the primary frame because for
other property types (e.g. opacity) the default setup of putting all styles and
animations on the style frame is simpler and correct. So far it is only
transforms that require special handling to apply the effect to the wrapper
frame.
This patch adds a reftest that fails without the code changes included in this
patch.
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Differential Revision: https://phabricator.services.mozilla.com/D21883
--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
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
NS_NewLayoutDebugger() is defined in nsLayoutDebugger.cpp.
layout/base/nsLayoutDebugger.cpp:44:10 [-Wmissing-prototypes] no previous prototype for function 'NS_NewLayoutDebugger'
Differential Revision: https://phabricator.services.mozilla.com/D21853
--HG--
extra : rebase_source : d56bdbce2030fdd3d036493c32af69addc6d1b73
extra : histedit_source : 61343f17eb6d5a774c848b1694e6507b7c1239ed
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
Transform display item may have multiple properties, so it's better to
use display item type as the input.
Also, factor some code out of AddAnimationsForProperty, so we can easier
to extend this for multiple properties.
We will pass a list of layers::Animation to the compositor thread. In
this list, the animations belonging to the same property are grouped together,
so we can easily separate the animations by property and sample the animations
for each property on the compositor thread. (Will do this in Bug 1425837.)
Depends on D19628
Differential Revision: https://phabricator.services.mozilla.com/D19629
--HG--
extra : moz-landing-system : lando
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
--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
This doesn't matter yet because all the states that return a change hint are on
stylesheets, but will matter with bug 1472637.
Differential Revision: https://phabricator.services.mozilla.com/D21616
--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
This doesn't matter yet because all the states that return a change hint are on
stylesheets, but will matter with bug 1472637.
Differential Revision: https://phabricator.services.mozilla.com/D21616
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
The main behavior changes are:
1) We no longer create a new Window when doing document.open(). We use the
same Window but remove all the event listeners on it and on the existing DOM
tree before removing the document's existing kids.
2) We no longer create a new session history entry. The existing one always
gets replaced instead.
3) We now support document.open on documents that are not in a Window.
The reasons for the various test changes are as follows:
The change to browser_modifiedclick_inherit_principal.js is because we no
longer set the docshell to a wyciwyg URL when document.open() happens and the
test was depending on that to terminate.
browser_wyciwyg_urlbarCopying.js is being removed because it's trying to test
wyciwyg URIs, which no longer exist.
The changes in docshell/test/navigation are because document.open() no longer
affects session history. One of the tests was testing the interactions there
and is being removed; another is being repurposed to just test that
document.open() does not affect history.length.
The change to test_x-frame-options.html is because document.open() now removes
event listeners on the window, which it didn't use to do (and in the specific
case in this test reused the existing inner too, so the listener was still
around in practice). The new behavior matches other browsers.
The removal of test_bug172261.html is because document.open() no longer affects
session history, so you can't go back across it or forward to the "opened"
state, so the situation that test is trying to test no longer exists.
The changes to test_bug255820.html are because reloading a document after
document.open() will now just load the URL of the document that was the entry
document for the open() call, not reload the written content. So there's not
much point testing reload behavior, and in this test it was just reloading the
toplevel test file inside the frames.
The change to test_bug346659.html is because now we no longer create a new
Window on document.open().
The change to test_bug1232829.html is because document.open() (implicit in this
test) no longer adds history entries, so the back() was just leaving the test
page instead of going back across the document.open(). The test is a
crashtest in practice, so might still be testing something useful about how
document.open() interacts with animations.
The change to test_bug715739.html is because the URL of the document after
document.open() is now the URL of the entry document, not a wyciwyg URL, so
reload() has different behavior than it used to.
The change to test_bug329869.html is because now when we go back we're
reloading the original document we had, not doing a wyciwyg load, and the
security info now doesn't include the untrusted script.
The changes to the wpt expectations are removing a bunch of expected failures
now that we pass those tests and disabling some tests that are fundamentally
racy and hence fail randomly. The latter all have github issues filed for the
test problem.
The change to testing/web-platform/tests/common/object-association.js is fixing
tests that were not matching the spec (and were failing in other browsers).
The change to parser-uses-registry-of-owner-document.html is fixing tests that
were not matching the spec (and were failing in other browsers).
The change to document-write.tentative.html is because the test was buggy: it
was using the same iframe element for all its tests and racing loads from some
tests against API calls from other tests, etc. It's a wonder it ever managed
to pass, independent of these patches (and in fact it doesn't pass according to
wpt.fyi data, even in Firefox).
The changes in html/browsers/history/the-history-interface are because
document.open() no longer adds history entries. The test was failing in all
other browsers for the same reason.
The changes in html/browsers/history/the-location-interface are because
reloading a document.open()-created thing now loads the URL of the page that
was the entry document for the open() call. The test was failing in all other
browsers.
The change to reload_document_open_write.html is because we now reload the url
of the document that entered the script that called open() when we reload, not
the written content. Other browsers were failing this test too; Gecko with
the old document.open implementation was the only one that passed.
The change to http-refresh.py is to fix a test bug: it was not returning a
Content-Type header, so we were putting up helper app dialogs, etc.
The change to test_ext_contentscript.js is because we no create a new global
for document.open() calls. Kris Maglione OKed this part.
Differential Revision: https://phabricator.services.mozilla.com/D17323
--HG--
extra : moz-landing-system : lando
As per the following change to the HTML spec:
86b05f8a07
when running a requestAnimationFrame callback it should be possible to cancel
another requestAnimationFrame callback scheduled to run in the same frame by
using cancelAnimationFrame.
See issue:
https://github.com/whatwg/html/issues/4359
Differential Revision: https://phabricator.services.mozilla.com/D20974
--HG--
extra : moz-landing-system : lando
In the next patch in this series we want to compare the handle of frame
callbacks we are about to run, with a set of canceled handles stored on the
document. This patch makes us pass the handles along with the callbacks so we
can do that.
Incidentally doing this allows us to just swap array elements when building up
the refresh driver's set of callbacks to run. That is hopefully a little more
efficient than running the implicit conversion operator on each item and then
appending to an array.
Differential Revision: https://phabricator.services.mozilla.com/D20973
--HG--
extra : moz-landing-system : lando
Add comments and property check for the caller of ActivityTracker.
Depends on D19525
Differential Revision: https://phabricator.services.mozilla.com/D19632
--HG--
extra : moz-landing-system : lando
Let ActiveLayerTracker track individual transforms. (Will add
motion-path in the future.)
Besides, using a property set for transform and opacity is more efficient,
so let's change it. For background position, we use a different code path,
so we can have more restrictions in IsStyleAnimated.
Differential Revision: https://phabricator.services.mozilla.com/D19631
--HG--
extra : moz-landing-system : lando
Only nsBlockFrame and its subclasses recognize the nsIFrame::eBlockFrame
flag, so we can replace the usage of the flag with either
nsIFrame::IsBlockFrameOrSubclass() or a do_QueryFrame().
Differential Revision: https://phabricator.services.mozilla.com/D20542
--HG--
extra : moz-landing-system : lando
aFrameList can contain placeholder frames. If we decide to nuke
aFrameList, we need to destroy the out-of-flow frames gracefully.
In this case, out-of-flow frames are still in nsFrameConstructorState's
absolute item lists. To rely on nsPlaceholderFrame::DestroyFrom() to
remove its out-of-flow frame properly, we manually flush all the frame
insertions for all the lists in aState before destroying aFrameList.
Differential Revision: https://phabricator.services.mozilla.com/D19460
--HG--
extra : moz-landing-system : lando
nsIFrame::BuildDisplayListForStackingContext() will check the existence
of transform animations, so we need to update
nsLayoutUtils::HasAnimationsOfPoperty(). However, checking only
eCSSProperty_transform is not enough. We have to check all the transform-like
properties. Therefore, we update these functions to accept a property
set as the argument, and pass a collection of transform-like properties
into them.
Differential Revision: https://phabricator.services.mozilla.com/D20412
--HG--
extra : moz-landing-system : lando
Make it always forward to the document's docshell. We rely on it being setup by
the time our stuff runs, and we cannot have multiple pres contexts per document
in different docshells anymore.
This allows me to also move some state to the document (about whether it's
currently loaded in a chrome docshell (nsPresContext::mIsChrome) and whether
it's a chrome origin image (nsPresContext::mIsChromeOriginImage), which will
help for bug 1490401 / bug 1418159.
The pres context already relies on having the docshell available on `Init` and
we don't properly handle dynamic changes to it.
The reason I store some state like whether the doc URI is chrome:// and whether
we're in a chrome docshell is not (only) to avoid recomputing it over and over,
but also to allow me to read them from Stylo (main-thread blocked, but poke at
that from multiple non-main-threads).
Differential Revision: https://phabricator.services.mozilla.com/D20301
--HG--
extra : moz-landing-system : lando
This is more consistent with all the other image request code, and handles
pseudo-elements properly without having to add more out-of-band calls to
UpdateStyleOfOwnedChildFrame and such.
Differential Revision: https://phabricator.services.mozilla.com/D20107
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
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--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
--HG--
extra : moz-landing-system : lando
Even less so on reframe, where it's just unsound to do so. I had to give a value
to eSetValue_Internal, since otherwise I cannot check for its presence. I can
further special-case the reframe case if you prefer.
Differential Revision: https://phabricator.services.mozilla.com/D20133
--HG--
extra : moz-landing-system : lando
This is more consistent with all the other image request code, and handles
pseudo-elements properly without having to add more out-of-band calls to
UpdateStyleOfOwnedChildFrame and such.
Differential Revision: https://phabricator.services.mozilla.com/D20107
--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
These assertions can happen in certain circumstances (see the referenced bug).
These assertions are not security sensitive, but they affect correctness.
They're old (from before my change), so I prefer dealing with them in a public
bug and stop crashing release for now.
Differential Revision: https://phabricator.services.mozilla.com/D20105
--HG--
extra : moz-landing-system : lando
r?njn only because this is the first example that adds any actual subcategories.
Differential Revision: https://phabricator.services.mozilla.com/D11340
--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
The primary frame hashtable is long gone; we have a pointer on the node now.
Differential Revision: https://phabricator.services.mozilla.com/D19952
--HG--
extra : moz-landing-system : lando
Typically we set the NS_FRAME_MAY_BE_TRANSFORMED bit on a frame when one of the
following situations arises:
a. We update the keyframes of a KeyframeEffect to include transforms or we
create a new KeyframeEffect that animates transforms (in
KeyframeEffect::SetKeyframes), or
b. We retarget a KeyframeEffect with transforms at a new element (in
KeyframeEffect::SetTarget), or
c. We create an nsFrame with transform animations applied to it (in
nsFrame::Init), or
d. We get a nsChangeHint_AddOrRemoveTransform hint in
RestyleManager::ProcessRestyledFrames and decide to update the frame bit on
the frame and its continuations accordingly.
However, there are some situations where we can have a transform animation on
a frame where none of the above are triggered.
For example, if the style frame is not unavailable (e.g. a display:none
element) when the KeyframeEffect is initialized we will fail to the frame bit in
(a) and if we never retarget the effect we will never set reach (b).
Furthermore, if we have an animation that is "not relevant" (e.g. idle) and
hence not registered with the EffectSet when the frame is initialized we will
fail to set the frame bit in (c).
Finally, if the the animation does not produce a style change that causes the
nsChangeHint_AddOrRemoveTransform bit to be set (e.g. the transform animation
begins at 'none') we will not set the frame bit in (d).
As a result, we can end up failing to set the NS_FRAME_MAY_BE_TRANSFORMED bit
for some content.
The crashtest included in this patch produces such a case and, without the code
changes in this patch, will fail the assertion in ApplyRenderingChangeToTree[1]:
NS_ASSERTION(!(aChange & nsChangeHint_UpdateTransformLayer) ||
aFrame->IsTransformed() ||
aFrame->StyleDisplay()->HasTransformStyle(),
"Unexpected UpdateTransformLayer hint");
That is because although the nsChangeHint_UpdateTransformLayer bit will be set,
aFrame->IsTransformed() will return false because the frame bit has not been
set, and aFrame->StyleDisplay()->HasTransformStyle() will return false because
the animation sets the transform to 'none'.
Not only will this assertion fail, but once we cease flushing style as part of
triggering an animation later in this patch, the reftest
layout/reftests/web-animations/stacking-context-transform-changing-effect.html
will begin to fail. That reftest produces a similar situation to the crashtest
but it currently does not fail because the style flush that happens as part of
creating an animation ensures the style frame is available at the point when the
animation is triggered and hence case (a) from above is hit.
This patch addresses this by detecting the case where we have this change hint
set but not the corresponding frame bit, and setting the frame bit.
[1] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/layout/base/RestyleManager.cpp#1191-1199
Differential Revision: https://phabricator.services.mozilla.com/D18911
--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
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
Brad Werth
shindli
Emilio Cobos Álvarez
Brian Birtles
Ting-Yu Lin
Dorel Luca
Sylvestre Ledru
Chris Peterson
Csoregi Natalia
David Major
Masayuki Nakano
Boris Zbarsky
Olli Pettay
Henrik Skupin
Razvan Maries
Henri Sivonen
longsonr
arthur.iakab
Miko Mynttinen
Timothy Nikkel
Tim Nguyen
Boris Chiou
Gurzau Raul
Narcis Beleuzu
Hiroyuki Ikezoe
Ciure Andrei
Noemi Erli
Matt Woodrow
Ehsan Akhgari
Ting-Yu Lin
Markus Stange
Botond Ballo
Edgar Chen
Cosmin Sabou
Ryan Hunt
Daniel Varga
Mike Hommey