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
urlExtraReferrer could be null, we should check before dereference. Otherwise
it will cause crash when webrender is enabled by gfx.webrender.enabled=true
and gfx.webrender.all=true,
Differential Revision: https://phabricator.services.mozilla.com/D20805
--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
As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
Instead of storing them as LengthPercentage | Number, always store as
LengthPercentage, and use the unitless length quirk to parse numbers instead.
Further cleanups to use the rust representation can happen as a followup, which
will also get rid of the boolean argument (since we can poke at the rust length
itself). That's why I didn't bother to convert it to an enum class yet.
Differential Revision: https://phabricator.services.mozilla.com/D21804
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
We restrict the argument (i.e. `nsCSSPropertyIDSet`) of some functions is
the subset of other property set (e.g. transform-like properties), so
add this function for better readability.
Depends on D19629
Differential Revision: https://phabricator.services.mozilla.com/D21598
--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
FrameLayerBuilder needs to clear this flag by DisplayItemType, so we add
a new function for it.
Differential Revision: https://phabricator.services.mozilla.com/D19630
--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
This patch avoids a potential division by 0 (one that's unlikely to be
triggered by real content), for correctness and robustness.
This patch isn't really changing the logic, because the newly-guarded code is
already guarded by a "length < sum" check, and "length" is expected to be
nonnegative [1], which means "sum" would already have been nonzero in cases
where the existing strict less-than comparison returned true.
[1] except for integer overflow or other bizarreness.
Depends on D21578
Differential Revision: https://phabricator.services.mozilla.com/D21579
--HG--
extra : moz-landing-system : lando
This patch doesn't change any logic/behavior -- it's just adding braces for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D21578
--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
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
